ArticlePDF Available

Abstract and Figures

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 integrated within existing services. Owing to the size of governments, different 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 architecture is driven by a Service Oriented Architecture (SOA) model and uses ontologies to provide semantic interoperability.
Content may be subject to copyright.
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
{bkanagwa,jnakatumba, rmugwanya,ekahiigi}@cis.mak.ac.ug,
{ngabirano.silas}@gmail.com
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
1 Introduction
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 aect the main goal of interoperability [16]. As
[12] 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 defines standards
and structures for any e-government system to be able to share information and
processes.
1http://www.nita.go.ug
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 ocials 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 [23]. As stated in
[16], interoperability can be defined 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 [13]. 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 dierent countries
at dierent 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 oered. The e-GIF’s in Estonia [8], Nepal [21] and
Mozambique [19] provided detailed organizational interoperability. All these e-
GIF’s oered the common e-government services. The UK [22] 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
Business services.
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 confidentiality. For example, Estonia and Australia [3] use federated identity
management where the users can use various identities for authentication and
authorization to access the e-government systems.
Conceptual framework: This identifies which components of the e-GIFs
that semantic and technical interoperability used. The European Interoperabil-
Interoperability Framework 3
ity Framework (EIF) [14] 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
interoperability.
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 [2] arms that a large number of organizations
apply one of these three enterprise architecture frameworks because of their
level of maturity: the Zachman framework [25], the Open Group Architecture
Framework (TOGAF) [11], and the Federal Enterprise Architecture (FEA) [6].
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 [14]
that provides specific 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 eorts. 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-
sification methodology that can be used by a government to create a common
understanding of concepts based on the country’s laws policies and procedures
[15]. 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 specifications the proposed e-GIF.
4 Benjamin Kanagwa et al.
3 Methodology
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 ocials
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 finer 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 field 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 identified dimensions of interoperability.
Lastly, the categorization of the findings 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
interoperability requirements.
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
fine tune the e-GIF. The evaluation employed the Enterprise Architecture (EA)
Scorecard [18] which provides a qualitative measure of EA quality and complete-
ness.
Interoperability Framework 5
4 The Framework
Our architectural framework follows the TOGAF version 9 architecture devel-
opment methodology [11]. Unlike TOGAF which has four major domains, the
proposed architecture has five 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
Fig. 1.
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 defined 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 specifications 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 identified 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 identified as concepts in the receptive modules of the e-government ontology.
57
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
defined in the e-government ontology. Overall, the architecture is premised on a
SOA model [24] that is realized using Web Services [17]. The section that follows
briefly explains the dierent 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
government services.
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 identification number,
surname, etc. (iii) Relationships: identify and define 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 identification 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 ocially recognized registration documents include i) birth certificate; ii)
baptism card; iii) immunization card; iv) voters identification card; v) immigration
document; vi) National identity card; vii) valid Ugandan or foreign Passport; viii)
valid driving permit; ix) valid residence permit; x) certificate 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
identifiable numbers such as passport number or national identification 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
69
Fig. 2: Part of ontology for Registration
of Persons.
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
ocially recognized registration doc-
uments include: i) birth certificate; ii) baptism card; iii) immunization card;
iv) voters identification card; v) immigration document; vi) National identity
card; vii) valid Ugandan or foreign Passport; viii) valid driving permit; ix) valid
residence permit; x) certificate of acquired citizenship.
4.2 Services Architecture
In order to achieve high levels of interoperability, the e-Government services
must be defined 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 [5] will be used to provide an endpoint
description of the web service; v) web services can be discovered by use of the
UDDI registry [7]. 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
architecture framework.
Interoperability Framework 7
4.3 Business Process Architecture
The business process architecture is a segmentation of logically related tasks per-
formed to achieve a defined 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 stadeployment. 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 specifications,
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
identified as shared tasks while those tasks that do not use similar inputs and steps
are identified as independent tasks.
The Business Process Architecture identifies the relationships between the tasks
and this information provides key input for the development of the Web services.
Functionality for related tasks such as verification of personal identification data
which are shared across dierent 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
defined 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)
59
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 identifies 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
verification is a common task that is shared across dierent services.
4.4 Data Architecture
The data architecture promotes the common identification, 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
standards.
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 predefined set of rules for choosing
the character sequences to be used for identifiers. 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 benefits 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 [18] 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 dierent abstract levels and
aspect areas of the framework.
Abstract Aspect Areas
Levels Business Information Information Technic a l
Systems Infrastructure
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.
satisfies 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 satisfies the technical infrastructure requirements
in respect to the technical goals, drivers and concepts.
Environmental level: measured the business relationships and information
flows. 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 suciently 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
suciently high.
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 suciently 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 sucient 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 sucient 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
5.2 Discussion
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 five 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.
6 Conclusion
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 ocials 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.
References
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
(2014)
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.
egov.wa.gov.au/index.cfm?event=policiesEgif.
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 Aairs and Communications Department of State Informa-
tion Systems, Estonian IT Interoperability Framework http://www.riso.ee/
en/files/framework2005.pdf
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
(2005)
13. Lallana, C.E.: E-government interoperability. http://unpan1.un.org/
intradoc/groups/public/documents/UN-OTHER/UNPAN032094. (2008)
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., Villafiorita, 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-Pacific. 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://
www.govtalk.gov.uk/documents/eGIF%20v6_1%281%29.pdf (2005)
23. UNDP e-Government Interoperability: Overview. United Nations Development
Programme. (2007)
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)
... In Uganda, although some criticisms and limitations exist (Kigwana et al., 2017;Kanagwa et al., 2018;Nakakawa and Namagembe, 2019), it seems evident that the relative success is also the consequence of public policies, including the commitment to become a leading e-government country in Africa in the scope of the 2012 Uganda e-Government Master Plan (National Information Technology Authority Uganda, 2012), which was developed with the technical support of the National IT Promotion Agency of Korea. The situation is similar in the case of Nepal, whose first master plan was also developed with Korean technical support (Elets News Network, 2006). ...
Article
Full-text available
Purpose This study aims to investigate whether, discounting the effect of the relative wealth of countries, it is possible to observe the relevance of policies for e-government development. Design/methodology/approach The deviations of countries' results from what could be expected, considering their relative wealth is calculated by using the residuals of a linear regression using the Gross Domestic Product per capita as the independent variable and the UN E-Government Development Index as the dependent variable. The countries that achieve better and worse results than expected are then identified and their cases are analyzed by resorting to secondary sources, namely, published research referring to their cases. Those research documents were identified by successively searching the Scopus database, the Google Scholar database and the Web of Science. Findings The existence of formal e-government strategies and plans and the capacity to implement them can make a difference, allowing countries to achieve better results than expected or, in their absence, to perform worse than expected. Research limitations/implications The proposed methodology can be useful to e-government researchers, particularly as a basis for deeper and more detailed studies. Practical implications Countries should invest in well-developed and focused strategies and continuity of public policies and their capacity to deliver results. For that purpose, political commitment and high-level coordination are key factors. For low-income countries, long-lasting cooperation with external experienced partners is crucial. For high-income countries, innovative thinking is a key enabler. Originality/value This study uses an innovative method to look beyond the effect of the relative wealth of countries and investigate the relevance of public policies for e-government development.
Article
In this study, it is aimed to evaluate the electronic records management systems (ERMS) used in universities in the context of interoperability from a technical and organizational perspective. For this purpose, a survey was applied to the administrative staff of universities in Ankara, Turkey and 104 people participated in the survey. In the light of the data obtained, it was concluded that the records management procedures in universities are carried out in a distributed manner and are not gathered under a single unit. Official correspondence between institutions in universities is mostly carried out by registered electronic mail (REM). It was determined that while there are not many legal and technical obstacles to the interoperability of electronic records management systems, there are more organizational and administrative problems. Within the scope of the results, some suggestions have been made to university administrators and system developers. The study may guide universities in the transition and development stages to ERMS.
Conference Paper
Full-text available
The major challenge when integrating information systems in any domain such as e-Government is the challenge of Interoperability. One can distinguish between three aspects of Interoperability; technical, semantic, and organizational. The technical aspect has been widely tackled especially after the ubiquity of internet technologies. The semantic and organizational aspects deal with sharing the same understanding (semantics) of exchanged information among all applications and services, in addition to modeling and re-engineering governmental processes to facilitate process cooperation that provision seamless e-government services. In this paper, we present the case of the Palestinian Interoperability Framework 'Zinnar', which is a use case of using ontology in e-government (i.e., data and process governance) to tackle the issues of semantic and organizational interoperability. The followed methodology resulted in a success story within a very short time and has produced a framework that is intuitive, elegant, and easy to understand and implement.
Article
Full-text available
E-Government offers a new electronic channel by means of which citizens and government ministries can interact with one another, unconstrained by the locations and schedules; and thereby improving government effectiveness. However, realizing this vision is strictly depending on the ability of diverse computing systems owned and managed by different government ministries to be able to interact together across all ministerial boundaries. This ability is known as e-government interoperability. Since ministries have built their computing systems independently with specifications and solutions relevant to their particular needs but without adequate attention to the need to interact with other ministries systems, this has result in a patchwork of heterogeneous computing solutions that have limited coherence and are largely uncoordinated. Therefore, during the last few years, e-government interoperability has been an important research area. To this direction, although several approaches have been proposed, all these approaches would be insufficient since they are theoretical solutions and technically focused. In this paper low level e-Government architecture is proposed driven by Service Oriented Architecture (SOA) to solve the architectural problem in achieving seamless e-government interoperability. This architecture acts as unifying architectural vision and helps in finding a common understanding of e-government and its realization.
Article
Full-text available
ABSTRACT An Enterprise Architecture Framework,(EAF) maps all of the software development,processes within the enterprise and how they relate and interact to fulfill the enterprise’s mission. It provides organizations with,the,ability to,understand,and,analyze weaknesses,or inconsistencies to be identified and addressed.,There,are,a,number,of,already established,EAF in use,today; some,of these frameworks were developed for very specific areas, whereas others have broader functionality. This study provides a comparison,of several frameworks,that can then be used for guidance in the selection of an EAF that meets the needed criteria. Keywords: Architecture Frameworks, Enterprise
Book
This book embarks on a mission to dissect, unravel and demystify the concepts of Web services, including their implementation and composition techniques. It provides a comprehensive perspective on the fundamentals of implementation standards and strategies for Web services (in the first half of the book), while also presenting composition techniques for leveraging existing services to create larger ones (in the second half). Pursuing a unique approach, it begins with a sound overview of concepts, followed by a targeted technical discussion that is in turn linked to practical exercises for hands-on learning. For each chapter, practical exercises are available on Github. Mainly intended as a comprehensive textbook on the implementation and composition of Web services, it also offers a useful reference guide for academics and practitioners. Lecturers will find this book useful for a variety of courses, from undergraduate courses on the foundational technology of Web services through graduate courses on complex Web service composition. Students and researchers entering the field will benefit from the combination of a broad technical overview with practical self-guided exercises. Lastly, professionals will gain a well-informed grasp of how to synthesize the concepts of conventional and “newer” breeds of Web services, which they can use to revise foundational concepts or for practical implementation tasks.
Article
This guide describes the Extended Enterprise Architecture Framework (E2AF) style and foundation. E2AF by itself is a Communication Framework describing the topics and relations that can be addressed during an architecture program. The purpose of E2AF is to communicate with all the stakeholders involved in the program. E2AF at a whole and the identified aspect areas are subject of IFEAD's – research & development and address the relevant topics and process steps to deliver an overall result related to the goals and objectives to achieve in a certain situation. The Extended Enterprise Architecture Essentials Guide is the foundation of E2AF. It describes in generic terms the context, drivers, principles and rules related to the philosophy behind E2AF. Based on the style elements of this guides, IFEAD has developed several methods, approaches to address specific EA topics. These Methods & Approaches describe the content to address in a specific aspect area and guides the enterprise architect in doing the appropriate activities. Enterprise Architecture in the context of this essentials guide addresses aspects and issues for the 'enterprise' architecture of organizations & technology as envisioned by IFEAD's Enterprise Architecture style. This document explains in general terms the rules and principles (style) that are used as the foundation for the way IFEAD thinks about enterprise architecture. It explains the Extended Enterprise Architecture Framework and relates the methods & approaches to the framework. The approaches themselves are described in separate documents like the Enterprise Architecture Score Card and accompanied articles, white papers and books. The Glossary is the last chapter of this document. It explains the most common used terms and acronyms used in this guide. Intended audience This document is intended for (potential) 'enterprise' architects, using IFEAD 's Extended Enterprise Architecture Framework, who: Are working in the field of 'Enterprise' Architectural Design; Want to understand the role of the E2AF; Are looking for a context description of IFEAD's Architecture approach. 'Enterprise' Architecture IFEAD has developed architectural design methods, which prescribe a coherent design and realisation of new business and the supporting IT systems. This guarantees the full integration between the business & human perspective of an organisation and the technology functionality of supporting IT systems. IFEAD describes architecture as a set of principles, rules, standards and guidelines reflecting the organisational culture and behaviour that prescribe architects, program / program mangers and developers how to deal with the transformation of both the business and IT systems. See the Glossary for an explanation of the terms: principles, rules, standards and guidelines. The definition of architecture IFEAD uses the following definition for enterprise architecture: Enterprise Architecture is about understanding all of the different elements that go to make up the Enterprise and how those elements inter-relate. Enterprise Architecture embodies a set of principles, rules, standards and guidelines, expressing and visualising the vision, culture & behaviour of an organisation while implementing certain concepts that serves as prescription for the design and construction of a certain object type. It contains a combination of style, engineering and construction principles, guaranteeing the uniformity and quality of the resulting object. IFEAD has developed such an architectural approach for the design and realisation of both the business & Information areas of an organisation as well as for the supporting IT systems. This approach is applicable for different organizations, in different situations and at different contemplation levels. The architecture style reflects the philosophy and mindset behind the framework and approaches and delivers a certain commonality in execution with respect to organizations unique situation. In the development of a house, building or any object we can always identify the following main steps: • A discovery process to identify the needs and requirements in the context of a certain situation; • A design process which leads to a design of the object in the form of drawings and/or models; • A transformation process to plan the realisation of the object in its environment; • A construction process that regards the realisation of the actual object based on the design and realisation plan.
Book
The discipline of Enterprise Architecture Management (EAM) deals with the alignment of business and information systems architectures. While EAM has long been regarded as a discipline for IT managers this book takes a different stance: It explains how top executives can use EAM for leveraging their strategic planning and controlling processes and how EAM can contribute to sustainable competitive advantage. Based on the analysis of best practices from eight leading European companies from various industries the book presents crucial elements of successful EAM. It outlines what executives need to do in terms of governance, processes, methodologies and culture in order to bring their management to the next level. Beyond this, the book points how EAM might develop in the next decade allowing today’s managers to prepare for the future of architecture management.
Article
Harmonizing decentralized development of ICT solutions with centralized strategies, e.g., meant to favor reuse and optimization of resources, is a complex technical and organizational challenge. The problem, shared by virtually all the governments, is becoming a priority also for developing countries, such as Mozambique, that have started their ICT policy relatively recently and for which it is now evident that—if no particular attention is devoted to the interoperability of the ICT solutions being developed—the result will rapidly become a patchwork of solutions incompatible with each other. The focus of the chapter is on formulation of e-GIF4M, E-government Interoperability Framework for Mozambique. The framework is based on a holistic approach, which we believe is needed for making interoperability sustainable within those countries. It builds on top of the existing experiences in e-GIFs all over the world, but it addresses some specific needs and peculiarities of the developing countries. The result is a comprehensive framework based on (i) a reference service delivery architecture along with technical standards, (ii) a standardization life cycle, (iii) a maturity model, and (iv) some key actions meant to make the initiative sustainable in the longer term.