Towards an Interoperability e-Government
Framework for Uganda
Benjamin Kanagwa, Joyce Nakatumba-Nabende, Raymond Mugwanya, Evelyn
Kigozi Kahiigi, and Silas Ngabirano
Makerere University, Kampala Uganda
Abstract. In the absence of a single entity that develops all systems
for government, there is need to support a common understanding of the
development environments such that new products can easily be inte-
grated within existing services. Owing to the size of governments, dif-
ferent departments tend to conceive and develop services independently
and yet they serve the same citizens. These services should be consistent
regardless of which entity is providing the service. This paper proposes a
National Enterprise Architecture (NEA) to support the implementation
of an e-government interoperability framework (e-GIF). The architec-
ture is driven by a Service Oriented Architecture (SOA) model and uses
ontologies to provide semantic interoperability.
Key words: interoperability, e-government, enterprise architecture
Most government services are being delivered through the use of Information
and Communication Technology (ICT). The Government of Uganda through the
National IT Authority Uganda (NITA-U)1is supporting several e-government
systems which include: systems for registration of persons (e.g. national identity
cards, passport and driving permit), business registration systems, Integrated Fi-
nancial Management System, Integrated Personnel and Payroll System (IPPS),
e-Tax System, and the e-Visa Application System. However, most of these sys-
tems are decentralized and interoperability between them is not achieved.
As a result, there are numerous failed initiatives of adoption of e-government
frameworks especially in developing countries. This can be attributed to the fact
that the development process is mainly inclined to technology while eliminating
the non-technical issues which a↵ect the main goal of interoperability . As
 asserts, an important step in achieving seamless delivery of public services
across government entities is ensuring that the systems used are compatible and
interface coherently. This requires a holistic approach that deﬁnes standards
and structures for any e-government system to be able to share information and
2 Benjamin Kanagwa et al.
In this paper, we propose an e-government interoperability framework (e-
GIF) that is based on an ontology enabled National Enterprise Architecture
(NEA) driven by a Service Oriented Architecture (SOA) model and interoper-
ability standards developed for use as a reference for implementing e-government
systems in Uganda. The developed e-GIF was evaluated by users, application de-
velopers and public service oﬃcials who used their knowledge of software engi-
neering and public service delivery to validate the framework for appropriateness,
completeness and accuracy.
The rest of this paper is organized as follows. First, we provide an overview
of related work in Sect. 2. Sect. 3 discusses the methodology used in this paper.
Sect. 4 discusses the interoperability framework introduced in this paper. We
discuss the evaluation carried out based on the framework in Sect. 5. Finally,
Sect. 6 concludes the paper.
2 Related Work
E-government interoperability is the ability for government agencies to use ICTs
to meaningfully and seamlessly exchange and use information . As stated in
, interoperability can be deﬁned at three levels of operation: organizational,
semantic and technical [1, 13]. These dimensions also form the capabilities of an
e-GIF required to improve interoperability . Interoperability improvement
can be achieved through the right mix of policy, structure, standards, process,
management and technology across all these three constructs. Consequently im-
proving the ability of government organizations to deliver coordinated public
services [13, 16].
Review of Existing e-GIFs: There have been several initiatives to develop
e-GIFs and here we analyze some existing e-GIFs drawn from di↵erent countries
at di↵erent levels of economic development and e-government maturity. This
analysis was based on their scope, design principles and conceptual frameworks.
Scope of the framework: This covers the interoperability dimensions and
categories of the e-services o↵ered. The e-GIF’s in Estonia , Nepal  and
Mozambique  provided detailed organizational interoperability. All these e-
GIF’s o↵ered the common e-government services. The UK  and Estonia e-
GIFs provide for Government to other Government e-services, while Estonia also
provided for the private sector to implement the e-GIF in their own Business to
Design principles: This parameter covers the guiding principles on which
the e-GIFs are based. All the e-GIFs recommended the e-government appli-
cations to be Internet based and the use of open standards. Other common
design principles included resource sharing and reuse, collaboration, scalability
and conﬁdentiality. For example, Estonia and Australia  use federated identity
management where the users can use various identities for authentication and
authorization to access the e-government systems.
Conceptual framework: This identiﬁes which components of the e-GIFs
that semantic and technical interoperability used. The European Interoperabil-
Interoperability Framework 3
ity Framework (EIF)  provides conceptual guidance for the creation of an
European Interoperability Reference Architecture (EIRA). In general, all the e-
GIFs identify interoperability standards for implementing i) interconnection; ii)
data integration; iii) content management and metadata; iv) information access
and presentation; and v) security. All the e-GIFs recommend the use of SOA
and XML standards. With the exception of Nepal and Estonia who used on-
tologies. All the e-GIFs recommend and adopt metadata standards for semantic
Review of Enterprise Architecture Development Frameworks: Numerous au-
thors have carried out a comprehensive survey to provide comparisons between
the leading enterprise architecture frameworks and modeling tools [2, 4, 9, 10,
20, 24]. The work carried out in  aﬃrms that a large number of organizations
apply one of these three enterprise architecture frameworks because of their
level of maturity: the Zachman framework , the Open Group Architecture
Framework (TOGAF) , and the Federal Enterprise Architecture (FEA) .
The Zachman’s Framework focuses on constructing views of an enterprise rather
than on providing a process for the creation of an architectural description [4, 25].
The TOGAF has an Architecture Development Method which is used as a
process to describe how to create an enterprise architecture [4, 11]. The Federal
Enterprise Architecture Framework (FEAF) extends the Zachman Architecture
Framework. It comprises a set of models, principles, and methods that are used
to implement an enterprise architecture. The framework provides a means to
communicate information about architectural artifacts, their relationships to
each other, and to their stakeholders using a common vocabulary [4, 20]. An-
other prominent framework is the new European Interoperability Framework 
that provides speciﬁc guidance on how to improve governance of interoperabil-
ity activities, establish cross-organisational relationships, streamline processes
supporting end-to-end digital services, and ensure that both existing and new
legislation do not compromise interoperability e↵orts. Although, these are the
most popular frameworks, there is not a single framework that addresses all the
needs of a particular organization. This is one of the leading reasons as to why or-
ganizations are taking a hybrid framework approach in developing an Enterprise
Architecture Framework [9, 24].
In this paper we extend the TOGAF framework as it provides a holistic
and systemic view of all Enterprise Architecture components, and their busi-
ness, organizational and environmental contexts. We further adopt a Service
Oriented Architecture and an e-government ontology which provides for a clas-
siﬁcation methodology that can be used by a government to create a common
understanding of concepts based on the country’s laws policies and procedures
. The uniqueness of this approach is that the interoperability requirements
are elicited from the actual practitioners and are analyzed to derive the design
principles and speciﬁcations the proposed e-GIF.
4 Benjamin Kanagwa et al.
The requirements elicitation phase commenced with the selection of the respon-
dents. A purposeful sample selection method was used where 30 government
Ministries, Departments and Agencies (MDAs) were selected. A questionnaire
guide was designed for eliciting the interoperability requirements from oﬃcials
in the selected MDAs. Data collection was carried out using interviews and ob-
servations. Interviews were held with the key informants using the questionnaire
guide. The key informants for this study were domain experts who included
heads of IT departments, heads of user departments and industry experts such
as Application Developers.
In order to acclimatize ourselves with the ﬁner intricacies of the existing sys-
tems in use, we carried out observations of some of these systems while in use
and also got to interview some of the actual users. Our interactions with the
users focused on analyzing the system interfaces in relation to i) the applica-
tion boundaries; ii) stakeholder satisfaction; and iii) inputs/outputs processing.
Lastly, we also studied some of the system manuals so as to understand further
the interoperability requirements in relation to the existing systems
3.1 Analysis and Design Phase
During this phase, the requirements collected from the ﬁeld were edited and
categorized into main themes and sub themes for analysis. The major themes
were namely i) current state, ii) desired state and iii) adoption factors for in-
teroperability. The responses under each theme were further sub-divided into
sub-missions according to the earlier identiﬁed dimensions of interoperability.
Lastly, the categorization of the ﬁndings and the subsequent data analysis were
aligned to the research objective. The results from this analysis were then used
to develop the interoperability Framework design principles and the aggregated
3.2 Framework Design and Evaluation
Overall, the development of the e-GIF was guided by the interoperability design
principles and the aggregated interoperability requirements developed from the
analysis and design phase. Two comparative studies, one on existing e-GIFs and
the other on Enterprise Architectures were carried. Some of the lessons learned
from these studies were later adopted into the proposed interoperability frame-
work. In addition, we propose standards guidelines that are based on industry
best practice and the interoperability design principles and aggregated require-
ments developed from the analysis and design phase. A case study on the regis-
tration of a natural person was also carried out to demonstration e-government
interoperability. The interoperability Framework thus developed was presented
to a focus group for validation and the feedback obtained was then used to
ﬁne tune the e-GIF. The evaluation employed the Enterprise Architecture (EA)
Scorecard  which provides a qualitative measure of EA quality and complete-
Interoperability Framework 5
4 The Framework
Our architectural framework follows the TOGAF version 9 architecture devel-
opment methodology . Unlike TOGAF which has four major domains, the
proposed architecture has ﬁve major domains namely i) the services architec-
ture; ii) the business processes architecture, iii) the data architecture; iv) the
organizational architecture; and v) the technology architecture as illustrated in
At the cent er of the proposed archi tectural fram ework is a n e-Government onto l-
ogy which is the main engine for driving interoperability. The developed solution
is, therefore, an ontology-enabled architecture where the interactions between the
components will be guided by the concepts, relationships and rules deﬁned in the
e-government ontology. Additionally, the overall architecture will be premised on a
SOA model that uses Web Services. As illustrated in Figure 5.1, the design princi-
ples and design speciﬁcations which have been discussed in section 5.1 on page 48
and section 5.2 on page 50respectively provide the main entry into this architecture.
Figure 5.1: Contextual Architecture
Following is a discussion of each of the components that make up the proposed
National Enterprise Architecture Framework.
5.3.1 The e-Government Ontology
The e-government ontology shall be decomposed into modules that form the e-
government domain. The modules shall b e based on the major government services.
Such ontology modules will for instance include the Registration, Financial, Health
Services and Support Service Modules.
Each module shall contain the following artifacts:
a) Concepts. The ob jects under each module shall be identiﬁed as concepts. E.g.
Person in the registration services, cost center in the Financial Services, and Hos-
pital in the Medical Services are examples of physical or virtual objects that can
be identiﬁed as concepts in the receptive modules of the e-government ontology.
Fig. 1: Enterprise Architecture of the framework that consists of organizational
architecture, technology architecture, services architecture, business process ar-
chitecture and the data architecture.
A central aspect to this architectural framework is an e-Government ontology
which is the main engine for driving interoperability. The interactions between
architectural components are guided by the concepts, relationships and rules
deﬁned in the e-government ontology. Overall, the architecture is premised on a
SOA model  that is realized using Web Services . The section that follows
brieﬂy explains the di↵erent architecture components.
4.1 e-Government Ontology
The e-Government ontology concepts, attributes, relationships and axioms form
the basis upon which the XML Schemas of the exchanged messages are built. All
the messages exchanged by the Web services must comply with the terminology,
semantics, business rules, data structures, coding and naming schemes agreed
upon in the ontology in order for such messages to be processed and exchanged
in a meaningful manner. The e-government ontology is decomposed into mod-
ules that form the e-government domain. The modules are based on the major
Typical modules include the Registration, Financial, Health Services and
Support Service Modules. Each module contains the following artifacts: (i) Con-
6 Benjamin Kanagwa et al.
cepts which are the objects under each module (ii) Properties: for each con-
cept, e.g. a concept Person may have attributes such as identiﬁcation number,
surname, etc. (iii) Relationships: identify and deﬁne the relationships between
concepts and properties, e.g., the relationship between the concepts Person and
Voter may be depicted as Voter is-a Person and (iv) Constraints - determine the
rules that bind the concepts, attributes and the relations, e.g., a person must
have only one national identiﬁcation number.
5.6 Case Study
In this research, we use the registration of a natural person as a case study to demon-
strate the implementation of e-Government interoperability. Under the Registration
of Persons Act of 2015, all persons resident in Uganda should be registered except
for refugees and visitors whose stay in the country does not exceed a period of 90
days. The oﬃcially recognized registration documents include i) birth certiﬁcate; ii)
baptism card; iii) immunization card; iv) voters identiﬁcation card; v) immigration
document; vi) National identity card; vii) valid Ugandan or foreign Passport; viii)
valid driving permit; ix) valid residence permit; x) certiﬁcate of acquired citizenship.
Figure 5.5 shows the relationships between the various registration documents.
Figure 5.5: Conceptual Model of the Reg istration Module
These documents may be used to physically identify a person basing on a combina-
tion of attributes such as name, date of birth, names of parents inter alia. However
some of the documents such as the baptism card, immunization card and immigra-
tion document cannot be used electronically to identify a person because they do
not have unique numbers and they are also not cross referenced with the uniquely
identiﬁable numbers such as passport number or national identiﬁcation number.
Currently each of these registration systems issues its own unique number and they
are done independently of each other except for the National Identity and Voters
systems were the data has been integrated so that they can be used interchangeably.
Therefore, in this case study we are proposing that all the unique numbers should
Fig. 2: Part of ontology for Registration
Fig. 2 shows an example of onto-
logical relationships between the var-
ious registration documents for regis-
tration of persons. Due to space lim-
itations we include only small part of
the ontology. Under the Uganda Reg-
istration of Persons Act of 2015, all
persons resident in Uganda should be
registered except for refugees and vis-
itors whose stay in the country does
not exceed a period of 90 days. The
oﬃcially recognized registration doc-
uments include: i) birth certiﬁcate; ii) baptism card; iii) immunization card;
iv) voters identiﬁcation card; v) immigration document; vi) National identity
card; vii) valid Ugandan or foreign Passport; viii) valid driving permit; ix) valid
residence permit; x) certiﬁcate of acquired citizenship.
4.2 Services Architecture
In order to achieve high levels of interoperability, the e-Government services
must be deﬁned from a global perspective and not separately for each entity.
The choice is to use web services implementation of SOA. The individual services
provided by Government entities are loosely coupled with little dependence. Due
to the scalability requirements of National Enterprise Architecture, the services
are provided over the Internet using web services. The following characteristics
are provided by web services: i) communicate via open Internet protocols (such
as HTTP, SMTP); ii) process XML messages framed using SOAP; iii) use XML
schemas to describe messages; iv) WSDL  will be used to provide an endpoint
description of the web service; v) web services can be discovered by use of the
UDDI registry . The web services metadata must be stored in a globally acces-
sible services repository. Further, these services should be loosely coupled such
that it is easy to add or modify the services so as to enable the building of new
business processes thus supporting the evolution and sustainable maintenance
of the systems which is one of the core design principles for the overall proposed
Interoperability Framework 7
4.3 Business Process Architecture
The business process architecture is a segmentation of logically related tasks per-
formed to achieve a deﬁned business outcome. As shown in Fig. 3 the business
process architecture is comprised of sub-components namely: process categories,
activities and tasks. Major Process Categories are based on the purpose and
outcome of the business process, e.g., registration. The Sub-categories are com-
plete sets of related activities which transform inputs into outputs under a given
major category, e.g., Human Resources Management System. The Activities are
sets of actions carried out in each sub category, e.g., under the Human Resources
Management System the activities can include recruitment, leave roster manage-
ment, and sta↵deployment. The Tasks are the individual actions that are carried
out under each activity.
Figure 5.2: Business Process Architecture
E.g. under the recruitment activity, the tasks performed include receiving a job
placement request from a user department, determining a candidates speciﬁcations,
advertising the job, short-listing etc. Some of these tasks are similar in nature to
tasks under other activities e.g. the task of advertising a job vacancy will use sim-
ilar inputs and steps as the task of a procurement advertisement. Such tasks are
identiﬁed as shared tasks while those tasks that do not use similar inputs and steps
are identiﬁed as independent tasks.
The Business Process Architecture identiﬁes the relationships between the tasks
and this information provides key input for the development of the Web services.
Functionality for related tasks such as veriﬁcation of personal identiﬁcation data
which are shared across di↵erent processes will be built into common Web services.
5.3.3 The Services Architecture
In order to achieve high levels of interoperability, the e-Government services must be
deﬁned from a global perspective and not separately for each Entity. We propose to
use Web Services under a SOA. A web service is a network accessible interface to ap-
plication programs, built using standard Internet technologies. In this architecture,
the Web services will have the following characteristics: i) They will communicate
via open internet protocols (such as HTTP, SMTP); ii) They will process XML mes-
sages framed using SOAP; iii) They will use XML schemas to describe messages; iv)
Fig. 3: Business Process Architecture comprises of the major process categories
based on the purpose and outcome of the business process.
The business process architecture identiﬁes the relationships between the
tasks. This information provides key input for the development of the both
atomic and compound services. Functionality for reusable tasks are built into
common Web services. In our running example, the personal registration and
veriﬁcation is a common task that is shared across di↵erent services.
4.4 Data Architecture
The data architecture promotes the common identiﬁcation, use and sharing of
data across the Government entities through the standardization of the data. As
illustrated in Fig. 4, the major components of the data architecture include: (i)
metadata standards, (ii) data integration standards, and (iii) information access
and presentation standards.
8 Benjamin Kanagwa et al.
Fig. 4: Data Architecture that consists of three major components: metadata
standards, data integration standards, and information access and presentation
The aim of the metadata standards is to provide a means to uniformly de-
scribe data, thereby supporting its discoverability and shareability. The meta-
data standards are comprised of two sub-elements namely: (a) Naming and
addressing data standards: which follow a predeﬁned set of rules for choosing
the character sequences to be used for identiﬁers. They denote objects such as
variables, types, web services in the source code and documentation; and (b)
Database of databases: this is a repository of metadata and statistics about all
databases used by the e-government applications.
4.5 Organization Architecture
This provides mechanisms for implementing and managing the entities while fa-
cilitating inter-agency collaboration. The processes carried out while implement-
ing the organizational architecture include: i) Aligning the business goals and
organizational resources with the e-government infrastructure; ii) Implement-
ing business process re-engineering; iii) Planning and executing migration plans
from the legacy systems to the new e-government applications; iv) Carrying out
quality assurance of the e-government applications and products; and v) Ensur-
ing compliance to the interoperability framework. Due to scope constraints, the
organizational architecture was not developed further in this study.
The main beneﬁts to be derived from the use of the developed architecture
include: (a) Alignment of the business goals to the IT infrastructure through
the various architecture artifacts, like the Business Process Architecture, the
Technology architecture, the data architecture and the services architecture; (b)
Development of the e-government ontology which provides a common vocabulary
for sharing information across multiple software agents; (c) Provision of a gover-
nance mechanism to conform compliance with the interoperability requirements;
(d) Provision of a mechanism through which entities can collaborate while man-
aging changes to facilitate manageable growth of large scale government systems;
(e) Provision of a database of databases which functions as a central control reg-
istry of e-government databases where no database will be allowed to operate
without being registered in this central database. This helps to address the prob-
lem of data redundancy where entities re-register information already registered
in the databases of other institutions.
Interoperability Framework 9
5 Framework Evaluation
In this section, we present an evaluation of the e-GIF framework in order to
determine its suitability for implementing interoperability of e-government ser-
vices. The analysis of the evaluation results was done for each of the six levels of
abstraction: contextual, environmental, conceptual, logical, physical and trans-
formational levels. At each level the analysis was done with respect to each aspect
area: business,information,information systems and technical infrastructure.
In accordance with the EA Scorecard methodology, a score of two was
awarded for each clear rating, one for each partially clear rating and zero for
each unclear rating. The detailed scores for each evaluator were aggregated for
each abstract level and aspect area. Given that a question that produced a clear
response was awarded two (2) points, then the possible maximum points per
level were equivalent to 2 points ⇤total number of questions in that level. The
individual points at each level and aspect area where then summed up using
Microsoft Visual Fox Pro database management software.
5.1 Results from the Evaluation
Table 1 provides a summary of the results from the evaluation of the architec-
ture. The results shown here are presented based on the Enterprise Architecture
Scorecard  which summarizes the rating for each aspect areas and abstract
level. In the following, we discuss the results shown in Table 1 in more detail.
Table 1: Summary of the evaluation framework scores (%) based on the Enter-
prise Architecture scorecard which highlights the di↵erent abstract levels and
aspect areas of the framework.
Abstract Aspect Areas
Levels Business Information Information Technic a l
Contextual 75 68.8 56.3 54.7
Environmental 62.5 45 55 67.5
Conceptual 50 42.5 50 62.5
Logical 54.2 43.8 58.3 64.6
Physical 54.2 58.3 70.8 68.8
Transformational 35 22.5 52.5 47.5
In provide a summary of the aspect areas that were scored well and the ones
that were scored poorly under each abstract level as shown in Table 1.
Contextual level: was used to measure the extent to which the architecture
meet the scope, mission and vision of the organization. The Business aspect
area had an average score of 75% which indicates that the proposed architecture
10 Benjamin Kanagwa et al.
satisﬁes the business goals of the client who is the Government of Uganda (GOU)
and that the architecture is based on appropriate business drivers and concepts.
The technical infrastructure aspect area had an average score of 54.7% which
implies that the architecture satisﬁes the technical infrastructure requirements
in respect to the technical goals, drivers and concepts.
Environmental level: measured the business relationships and information
ﬂows. The Business aspect area had an average score of 62.5% which implied
that the architecture meets the requirements for business collaborations between
the various MDAs. The Information aspect area had a low score of 45% and
the framework does not model all the possible information exchanges that are
required in a fully automated e-government environment.
Conceptual level: explored the architectural functional and non-functional
requirements, goals and objectives. The Information aspect area had an average
score of 42.5% which implied that the architecture does not suﬃciently meet
the required level of information interaction. This result is attributed to the
lack of enough detailed functional requirements for the GOU since the proposed
solution put more emphasis on specifying requirements for a few selected priority
areas. The Technical infrastructure aspect area had an average score of 62.5%
which implies that the provision for inter-connection at the conceptual level is
Logical level: measured the logical solutions and sub-functions within each
aspect area. The Information aspect area had an average score of 43.8% which
implies that the architecture did not suﬃciently provide for all the possible types
of information interaction since the focus here was on only a few subfunctions
that the architecture performs. The Technical infrastructure aspect area had an
average score of 64.6% which showed that the type of interconnection proposed
in the architecture has suﬃcient interconnection layers.
Physical level: was concerned with assessing the physical solutions, concrete
products and techniques proposed in the architecture. The Business aspect area
had an average score of 54.2% which indicated that the proposed architecture
has suﬃcient business solutions for the MDAs to collaborate at the physical
business level. The Information systems aspect area had an average score of
70.8% which implied that the proposed architecture has excellent provisions for
interoperability at the physical level.
Transformational level: was concerned with assessing the impact of the
architecture on the enterprise after its implementation. The Information aspect
had an average score of 22.5% which showed that the proposed architecture does
not have adequate provisions for changes in information interaction. The focus
was not on all the possible information exchanges that are required in a fully
automated e-government environment. The Information systems aspect area had
an average score of 52.5% which indicated that the provisions for change in the
information systems are adequate.
Interoperability Framework 11
It is pertinent to note that four aspect areas do not have an equal impact on
the enterprise architecture. However, in this study all the aspect areas were
considered to be of equal importance. The results show that the information
aspect area received the least scores compared to all the other aspect areas
across four of the ﬁve abstract levels. This could be attributed to the fact that
not all the possible information exchanges are mot modeled and the architecture
focused on few priority areas.
Furthermore, the transformational abstract areas has received the least scores
across the four aspect areas. This could be due to the fact that the abstract level
focused on good design, cost savings and organizational change yet these were
not mainly highlighted in the implementation of the architecture, for example,
the cost sequences and all the possible information exchanges that are required
in a fully automated e-government environment. Overall, the results indicate
that the proposed architecture is acceptable as presented.
This paper presents an e-government interoperability framework that is driven by
a Service Oriented Architecture (SOA) model and interoperability standards de-
veloped for use as a reference for implementing e-government systems in Uganda.
The interoperability is achieved through a set of related ontologies. Lessons from
the study of existing country e-GIFs and enterprise architectures were enjoined
to complement the proposed architecture.
The developed e-GIF was evaluated by a focus group comprised of users,
application developers and public service oﬃcials who used their knowledge of
software engineering and public service delivery to validate the framework for
appropriateness, completeness and accuracy. It is therefore, our conviction there-
fore, that the proposed architectural Framework and interoperability standards
selection procedures are best suited for resolving the e-government interoperabil-
ity challenge in Uganda. Future studies will consider further development of the
organizational architecture and prototype implementation in partnership with
the Government of Uganda and NITA-U.
1. Al-Khanjari, Z., Al-Hosni, N., Kraiem, N.: Developing A Service Oriented E-
Government Architecture Towards Achieving E-Government Interoperability. In-
ternational Journal of Software Engineering and Its Applications, 8(5), pp. 29-42
2. Ahlemann, F., Stettiner, E., Messerschmidt, M., Legner, C., Basten, D., Brons, D.:
EA frameworks, Modelling and Tools. Strategic Enterprise Architecture Manage-
ment. pp. 201-227 (2012)
12 Benjamin Kanagwa et al.
3. Australia Electronic Government Interoperability Framework http://www.
4. Cameron, B. H., McMillan, E.: Analyzing the current trends in enterprise archi-
tecture frameworks. Journal of Enterprise Architecture, 9(1), pp. 60-71. (2013)
5. Christensen, E., Curbera, F., Greg, M., Weerawarana, S.: Web services description
language (WSDL) 1.1 (2001)
6. Council, C. I. O.: Federal Enterprise Architecture Framework version 1.1. Retrieved
from 80, pp. 3-1. (1999)
7. Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N. Weerawarana, S.: Un-
raveling the Web services web: an introduction to SOAP, WSDL, and UDDI, EEE
Internet computing. 6(2), pp. 86-93 (2002)
8. Ministry of Economic A↵airs and Communications Department of State Informa-
tion Systems, Estonian IT Interoperability Framework http://www.riso.ee/
9. Goethals, F.: An overview of enterprise architecture framework deliverables. (2005)
10. Guijarro, L.: Interoperability frameworks and enterprise architectures in e-
government initiatives in Europe and the United States. Government Information
Quarterly, 24(1), pp. 89-101 (2007)
11. Harrison, R.: TOGAF 9 Foundation Study Guide. Van Haren. (2013)
12. Heeks, R.: Implementing and Managing eGovernment: an international text. Sage
13. Lallana, C.E.: E-government interoperability. http://unpan1.un.org/
14. The new European Interoperability Framework https://ec.europa.eu/isa2/
publications/new-european- interoperability-framework_en (2017)
15. Mustafa J.,Deik, A. Farraj, B.: Ontology-based data and process governance
framework-The case of e-government interoperability in Palestine. (2011)
16. Novakouski, M., Lewis, G. A.: Interoperability in the e-Government Context. Tech-
nical Report CMUP. (2012)
17. Paik, H., Lemos, A. L., Barukh, M. C., Benatallah, B., Natarajan, A.: Web
Services–REST or Restful Services. Web Service Implementation and Composi-
tion Techniques. pp. 67-91 (2017)
18. Schekkerman, J.: Extended enterprise architecture framework essentials guide. In-
stitute for Enterprise Architecture Developments. (2004)
19. Shvaiko, P., Villaﬁorita, A., Zorer, A., Chemane, L., Fumo, T.: E-government in-
teroperability framework: A case study in a developing country. In Comparative
E-Government. Springer pp. 639-662 (2010)
20. Tang, A., Han, J. Chen, P.: A comparative analysis of architecture frameworks. In
Software Engineering Conference 11th Asia-Paciﬁc. IEEE pp. 640-647 (2004)
21. Kharel, P., Shakya, S.: e-Government Implementation in Nepal: A Challenges.
International Journal of Advanced Research in Computer Science and Software
Engineering. 2(1) (2012)
22. United kingdom e-government interoperability framework version 6.1 http://
23. UNDP e-Government Interoperability: Overview. United Nations Development
24. Urbaczewski, L. Mrdalj, S.: A comparison of enterprise architecture frameworks.
Issues in Information Systems, 7(2), pp.18-23 (2006)
25. Zachman, J.A.: A Framework for Information Systems Architecture. IBM Systems
Journal, vol. 26, pp.276-292 (1987)