ArticlePDF Available

Abstract and Figures

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
Content may be subject to copyright.
Volume VII, No. 2, 2006 18 Issues in Information Systems
Lise Urbaczewski, Eastern Michigan University,
Stevan Mrdalj, Eastern Michigan University,
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
Architecture, Comparison
Enterprise architecture serves as the blueprint for the
system and the project that develops it. An enterprise
architecture framework can describe the underlying
infrastructure, thus providing the groundwork for the
hardware, software, and networks to work together.
According to the Systems & Software Consortium
[11], “An Enterprise Architecture relates
organizational mission, goals, and objectives to work
processes and to the technical or IT infrastructure
required to execute them.” In addition, a good
architecture and its corresponding documentation
allow for ease of maintenance in order that the
system does not become obsolete before it is even
built. There are a number of architectures and
architectural frameworks in use today. Though they
may overlap or address similar views, frameworks
also have been designed to address specific needs or
concerns. These frameworks differ by the
stakeholders they address and the issues that concern
their *world*. These issues or “building blocks”
represent methods, common vocabulary, standards
[13], and tools that provide a means to implement
and integrate the building blocks. In addition,
government, commercial, and sub-categories of each
of these may require certain protocols to follow.
Goethals [6] and Schekkerman [8] provide
comprehensive overviews of EAF in the literature.
Informal comparisons between specific architectures
have also been made [7]. The Open Group [12] has
drawn comparisons between its architectural
framework, TOGAF, and existing frameworks. Tang
et. al provide an analysis of frameworks at a high
level, based on their “goals, inputs and outcomes”
[10]. The aim of this paper is to provide a direct
comparison of the frameworks, based on their views
and aspects. In order to establish a common ground
for the framework comparison, we studied several
existing enterprise architecture frameworks. Second,
we created a method to compare the frameworks
based on the perspectives of their stakeholders and
abstractions. Third, we then compared the
frameworks. From this, we discuss the ways that such
comparisons can be used in determining a best-fit of
a framework dependent on specific stakeholder needs
for a given project.
The following are concise descriptions of five EAFs
that are used in this comparison.
Zachman Framework for Enterprise
Architecture: John Zachman published the Zachman
Framework for Enterprise Architecture in 1987 [14]
and is considered to be one of the pioneers in this
domain [6]. According to Zachman [15], “the
increased scope of design and levels of complexity of
information systems implementations are forcing the
use of some logical construct (or architecture).” The
Zachman Framework is based around the principles
of classical architecture that establish a common
vocabulary and set of perspectives for describing
complex enterprise systems. The Zachman
Framework has six perspectives or views: Planner,
Owner, Designer, Builder, Subcontractor, and User.
The second dimension of Zachman’s Framework
deals with the six basic questions: what, how, where,
who, when and why [6]. The framework does not
provide guidance on sequence, process, or
implementation, but rather focuses on ensuring that
all views are well established, ensuring a complete
system regardless of the order in which they were
established. The Zachman Framework has no explicit
compliance rules since it is not a standard written by
or for a professional organization. However,
A Comparison of Enterprise Architecture Frameworks
Volume VII, No. 2, 2006 19 Issues in Information Systems
compliance can be assumed if it is used in its entirety
and all the relationship rules are followed [9].
Department of Defense Architecture Framework
(DoDAF): The Department of Defense Architecture
Framework (DoDAF) [2] builds on three sets of
“views”: Operational, System, and Technical
Standards. A fourth view, ‘All View,augments the
other views by providing the linkage between the
views by means of a dictionary to define terms and
by providing context, summary, or overview-level
information [3]. This framework provides
descriptions of final products as well as guidance and
rules for consistency. This ensures a “common
denominator for comparing, and integrating Families
of Systems, Systems of Systems, and interoperating
and interacting architectures” [2].
Federal Enterprise Architecture Framework
(FEAF): The Federal Enterprise Architecture
Framework was developed and published by the US
Federal Chief Information Officers (CIO) Council
[5]. Government was following the industry trend of
defining architectural frameworks to guide in the
development of large, complex systems development.
FEAF was in response to the Clinger-Cohen Act,
1996 [1], which required Federal Agency CIOs to
develop, maintain, and facilitate integrated systems
architectures. The overriding goal of FEAF is to
organize and promote sharing of Federal information
for the entire Federal Government [6]. The
architectural segments are developed individually,
within structured guidelines, with each segment
considered to be its own enterprise within the Federal
Enterprise. We include the Federal Enterprise
Architecture (FEA) - Practical Guide [4] within our
discussion on FEAF because it provides the guidance
to U.S. federal agencies for frameworks. FEA allows
for flexibility in the use of methods, work products,
and tools to be used by the individual federal
Treasury Enterprise Architecture Framework
(TEAF): The Department of the Treasury published
the Treasury Enterprise Architecture Framework
(TEAF) in July 2000. The Department of the
Treasury is comprised of a number of offices that
function as individual enterprises. Therefore, its
enterprise architecture needs to map the
interrelationships among the organizations in order to
manage IT resources. The TEAF aims at facilitating
“integration, information sharing, and exploitation of
common requirements across the department” [6].
Similar to DoDAF, TEAF includes descriptions of
work products for documenting and modeling
enterprise architectures. TEAF also explicitly states
that these work products align with FEAF models
and DoDAF products [6].
The Open Group Architectural Framework
(TOGAF): The Open Group Architectural
Framework (TOGAF) was first developed in 1995
and was based on the Department of Defense’s
Technical Architecture Framework for Information
Management [12]. TOGAF focuses on mission-
critical business applications that use open systems
building blocks. “A key element of TOGAF is
Architecture Development Method (ADM) that
specifies a process for developing enterprise
architecture” [10]. TOGAF explains rules for
developing good principles, rather than providing a
set of architecture principles. The three levels of
principles support decision making across the entire
enterprise; provide guidance of IT resources; and
support architecture principles for development and
To compare the existing frameworks, we must first
define what an ‘enterprise architecture framework’ is
for the sake of our comparison. The definition
utilized for this study, as stated earlier, is: A tool that
can be used for developing a broad range of
architectures for capturing the needed information in
an enterprise. The framework also provides a vehicle
for accessing, organizing, and displaying that
information. We also define two key elements of
enterprise architecture as
A definition of the deliverables that the
architecting activity should produce;
A description of the method by which this is
There are many challenges in comparing EAFs. We
will list several of them. Some of the frameworks
have a very specific scope and therefore are
applicable to those applications. There are
frameworks that apply to a specific application or
development methodology, for example object
oriented development or distributed systems. Some
frameworks are truly enterprise oriented and some
are specific to the development of the IT system only.
In order to overcome above challenges, we decided to
compare the frameworks based upon their views,
their abstractions, and their coverage of the Systems
Development Life Cycle.
A Comparison of Enterprise Architecture Frameworks
Volume VII, No. 2, 2006 20 Issues in Information Systems
Comparison by Views and Abstractions
Our study performed both the views and abstractions
comparisons, with the views comparison being more
quantifiable. We found the Zachman’s views to be
the most comprehensive and therefore other EAFs
stakeholder perspectives could be represented using
the Zachman terminology (Table 1). The planner
view includes the concepts for the final product and
may encompass items such as the relative size, shape,
and basic intent of the final structure. The second
view is that of the owner which may represent an
architect’s drawings in which the owner agrees that
the architect has captured what he has in mind. The
designer view is the architect’s final product,
whereby he has detailed and described the plans
including materials needed. This represents the plan
that will be committed to construction. The fourth
view, or that of the ‘builder,’ represents the view in
which the architect’s final plans are modified to
reflect how construction will proceed. The
subcontractor view represents drawings of parts or
subsections of the plans. They are considered “an
‘out-of-context’ specification of what actually will be
fabricated or assembled. The last view represents the
final product, building, or project. It is the physical
result. From the standpoint of an information system,
this would reflect the users’ view and therefore, the
functional enterprise. Though the terminology may
differ somewhat amongst frameworks, the views can
be represented in this manner.
Table 1. Comparison by Views/Perspectives
Framework Planner Owner Designer Builder Subcontractor User
Zachman Scope Business
DoDAF All View Operational
FEAF Objectives/Scope
Planner’s View
TEAF Planner Owner Designer Builder
TOGAF Business
Technical Architecture
As noted, the abstractions comparison is less
quantifiable (see Table 2). Most of the EAFs studied,
provide recommendations for what each of the
abstractions represent, but do not provide methods,
procedures, or deliverables that are required. All of
the EAFs in our study included information in what
data was needed and the functionality of the data and
system. The frameworks started to differ when
comparing the technology and physical aspects of the
system, with some providing detailed architectures
whereas others were not as specific. In the people
abstraction, the frameworks provide the
organizational relationships related to
implementation of the system. Timelines and
justification for the system, as can be represented in
the Time/When and Motivation/Why abstractions
respectively, were only found in Zachman’s
DoDAF: The Operations View is the ‘business’
being undertaken by the military. This depicts
activities performed as parts of DoD missions, i.e.,
the exchanges among organizations or personnel, and
reveals the requirements for interoperability and
capabilities. The Systems View describes the actual
existing and future systems that support the DoD and
how they are physically interconnected. The
Technical View or Technical Standards View adds
detail to the Systems View by providing information
on standard system parts or components that are
currently available off the shelf, either commercially
or government, and also provides technical detail and
forecasts of standard technology evolution that may
apply to the architecture. The DoDAF defines 26
different architecture products that are organized into
the four views [3].
A Comparison of Enterprise Architecture Frameworks
Volume VII, No. 2, 2006 21 Issues in Information Systems
Table 2. Comparison by Abstractions
Framework What How Where Who When Why
Zachman Data Function Network People Time Motivation
DoDAF Data (mission)
Logical Data
Function /
connectivity plus
availability of off-
the-shelf solutions
(activities = how)
(locations = where)
TEAF Information
Functional View Infrastructure View Organizational
TOGAF Decision-making
IT resource
FEAF: Currently, the FEAF corresponds to the first
three columns of the Zachman Framework and the
Spewak Enterprise Architecture Planning (EAP)
methodology. The FEAF contains guidance and is
oriented toward enterprise architectures as opposed to
IT architectures. The rows of the FEAF matrix
correspond to the Zachman Framework, but they do
not prescribe the approach for developing the
products for each of the cells.
TEAF: TEAF can be described in terms relative to
the Zachman Framework, i.e., ‘perspectives’ and
‘views.’ The four perspectives are the same as in the
Zachman Framework and FEAF matrix with the
exception that TEAF combines the ‘Builder’ and
‘Subcontractor’ into one, named ‘Builder.’ Also, the
TEAF Information view corresponds to the FEAF
Data Architecture; the TEAF Functional view
corresponds to the FEAF Applications Architecture;
and the TEAF Infrastructure view corresponds to the
FEAF Technology Architecture. FEAF does not
currently reflect the TEAF Organizational view. This
view shows the types of workers and the
organizational structures. TEAF allows the flexibility
to define additional views and perspectives that focus
uniquely on areas important to specific stakeholders.
TOGAF: Strong on the Business Architecture and
Technical Architecture aspects. It does not provide as
much detail from the planning and maintenance
aspects. TOGAF is one of the most comprehensive
with regards to the actual process involved. This
framework provides guidance towards principles for
decision making, guidance of IT resources, and
architecture principles. The framework is gauged
towards open systems development.
Comparison with the Systems Development Life
It is very important to address whether or not the
framework encompasses the entire Systems
Development Life Cycle (SDLC). The frameworks
presented can be compared to the 5 phases commonly
used in SDLC models: Planning, Analysis, Design,
Implementation, and Maintenance (see Table 3).
Overall, the frameworks do not specify HOW the
system is to be developed, i.e., tools and work
products, and in general are weighted towards
planning and analysis, ensuring that all views are
addressed. The frameworks provide the guidance that
is then implemented in the SDLC.
One might question how the scope/planner and the
subcontractor views are incorporated into the SDLC?
Those aspects of the framework assist the enterprise
in minimizing those risks as outlined earlier, when
one may not view the enterprise in its entirety, i.e.,
designing a system that doesn’t meet the underlying
objective. The ‘view’ will determine the requirements
necessary in order to be deemed successful. As
discussed previously, the frameworks tend to be
heavy on the planning, since their objective is more
to provide guidance. It was found that most if not all
frameworks were weak in addressing the
maintenance of an information system.
A Comparison of Enterprise Architecture Frameworks
Volume VII, No. 2, 2006 22 Issues in Information Systems
Table 3. Comparison by SDLC Phases
SDLC Phase/
Planning Analysis Design Implementation Maintenance
Zachman Yes Yes Yes Yes No
DoDAF Yes Yes Yes Describes final products No
Yes Yes Yes Yes Detailed
Subcontractor’s View
Yes Owner’s
Yes Yes No
principles that support decision making across enterprise;
provide guidance of IT resources; support architecture
principles for design and implementation
Many of the enterprise architecture frameworks differ
in terms of their approach and level of detail. Some
are proposed guidelines, whereas others have specific
methodologies and aspects to follow. The majority of
the frameworks are abstract in that due to their
generality of terms, one might then question the
validity or the ability to work accurately within that
framework. The Zachman framework appears to be
the most comprehensive framework of those studied.
It uses a number of viewpoints related to the different
aspects. Most frameworks only represent a small
number of viewpoints and aspects. In this paper we
report of an effort to compare EAFs based on their
coverage of different viewpoints and aspects. Some
of the frameworks do not clearly ‘map’ to the idea of
‘viewpoints’ and “aspects” e.g., the rows and
columns of the Zachman framework, therefore
making the comparison of the frameworks difficult.
The major contribution of this study is a possibility to
use it as guidelines in selecting an EAF and
determining a best-fit of a framework dependent on
specific stakeholder needs for a given project. This is
important to minimize risk or failure of an
information system development process. Our plan is
to expand this research to include more quantifiable
measures as well as additional frameworks to better
assist in the determination of a framework to meet
specific organization needs.
1. Clinger-Cohen Act of 1996 (1996). Available:
2. DoD Architecture Framework (2004). Version
1.0. Volume 1: Definitions and Guidelines.
3. DoDAF (2005). DoDAF. Systems & Software
Consortium. Available:
4. FEA (2001). Federal Enterprise Architecture –
Practical Guide, version 1.0, February 2001.
5. FEAF (1999). Federal Enterprise Architecture
Framework, Version 1.1, September 1999.
6. Goethals, F. (2003). An Overview of Enterprise
Architecture Framework Deliverables. May
2003. Available:
7. Iyer, B. & Gottlieb, R. (2004). The Four-
Domain Architecture: An approach to support
enterprise architecture design. IBM Systems
Journal, 43(3), 587-97.
8. Schekkerman, J. (2003). How to Survive in the
Jungle of Enterprise Architecture Frameworks:
Creating or Choosing an Enterprise
Architecture Framework. 2
edition, ISBN 1-
4120-1607-x, 2003, Oxford: Trafford
9. Sowa, J. & Zachman, J. (1992). Extending and
Formalizing the Framework for Information
Systems Architecture, IBM Systems Journal,
31(3), 590-616.
10. Tang, A., Han, J., Chen, P. (2004). A
Comparative Analysis of Architecture
Frameworks, School of Information
Technology, Centre for Component Software &
A Comparison of Enterprise Architecture Frameworks
Volume VII, No. 2, 2006 23 Issues in Information Systems
Enterprise Systems, Swinburne University of
Technology, Technical Report: SUTIT-
TR2004.01, CeCSES Centre Report:
SUT.CeCSES-TR001, August 25, 2004.
11. TEAF (2005). TEAF. Systems & Software
Consortium. Available:
12. The Open Group Architectural Framework
(2005). Welcome to TOGAF. Available: www.
opengroup. org /architecture/togaf7-doc/arch/
13. Van den Hoven, J. (2004). Data Architecture
Standards for the Effective Enterprise.
Information Systems Management, 21(3), 61-4.
14. Zachman, J. (1987). A Framework for
Information Systems Architecture,IBM Systems
Journal, 26(3), IBM Publication G321-5298.
15. Zachman, J. (1999). A Framework for
Information Systems Architecture. IBM Systems
Journal, 38(2-3), 454-70.
... EA in practice is rarely based on a self-created EA approach for the organization (Urbaczewski and Mrdalj, 2006). Instead, organizations tend to implement existing EA frameworks. ...
... These frameworks are typically designed either for very general level or for a very specific purpose, which might not be fully comprehended in the implementing organization. For example, depending on the framework EA can be defined as a tool for developing large and complex systems (FEAF), a tool for creating different organizational views (DoDAF), a tool for supporting organizational decision-making (TOGAF) (Urbaczewski and Mrdalj, 2006) or a tool providing a shared language among different operators (Zachman, 1999). When these frameworks are utilized without a proper understanding of their purpose and without a clear vision of the purpose of EA in general, it is no surprising that EA practitioners do not have a coherent understanding of EA or what it is intended for (Doucet et al., 2009). ...
... similarly reading or writing does not need to be mentioned). Second, they are so complex (Lucke et al., 2010) and laborious to learn (Urbaczewski and Mrdalj, 2006) that they do not need to be known. Third, most organizations have a tendency to choose one framework and hold on to that even though it might not support their needs in the best possible way (Doucet et al., 2009). ...
Conference Paper
Enterprise architecture (EA) is used to improve business-IT alignment. In order to achieve this, the organizations need skilled and competent work-force, namely enterprise architects. However, EA is a management approach without a commonly agreed definition or scope. This makes the education and recruitment of enterprise architects ambiguous and elusive. Even though the enterprise architects often operate in IT department, their job description can significantly differ from other IS professionals. Therefore, EA roles or skills and competences cannot be extrapolated solely from IT/IS discipline or literature, but more domain specific understanding is needed. Yet this is not studied comprehensively. Some frameworks exist where enterprise architects are described as jack-of-all-trades but they provide very little understanding about what type of skills should be emphasized and in what type of EA work. In this Delphi study, we elucidate these shortages by identifying different approaches of EA work and by providing a list of most important skills for an enterprise architect. The skill list shows that the enterprise architect position themselves in the intersection of social and technical communities. This indicates that although different EA domains emphasise different skills, the main defining factor of EA skills is the capability to operate in a sociotechnical playground.
... To that end, the discipline of EA (management) provides important implications for this work, as it offers a solid base for developing a digitalization strategy and planning the company's transformation. EA practice and research have produced a large number of best practices and models [41,48], which help to map and manage corporate structures. In this field, architecture represents "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment" [19, p. 3]. ...
Conference Paper
Full-text available
Like larger companies, small and medium-sized enterprises (SMEs) need to develop and implement digitalization strategies. These help to address necessary organizational-and technology-related changes in order to create competitive advantages. However, SMEs often face specific challenges, including a lack of IT know-how, relevant market information and appropriate methods for developing a strategy. In this paper, we present a lightweight, architecture-based method including its underlying model for the development and implementation of digitalization strategies in SMEs. It was developed by following the Action Design Research (ADR) method and in cooperation with two medium-sized companies. Rather than adopting highly abstract and complex enterprise architecture (EA) frameworks, we suggest creating easy-to-use visualizations of the enterprise architecture, the business ecosystem and related cross-layer dependencies. While transferring the discipline of EA into the context of digital entrepreneurship, we derived four design principles which help to enrich the theoretical body of knowledge in this research area.
... Enterpriser Architecture (EA) frameworks facilitate technology, information and business alignment and integration, especially when extended to decision-making frameworks such as those proposed by Ghildyal, Chang, and Joiner (2018). Urbaczewski and Mrdalj (2006) state the EA frameworks are beneficial to any or-ganisation because they provide: ...
The research literature has found current Enterprise Architecture (EA) methods are limited in dealing with uncertainty and pathologies of complex systems to enable design and operation of a resilient enterprise. To some extent, EAs’ approaches persist in applying textbook plans and activities in the face of mounting evidence of changing circumstances and the challenges of uncertainty. They rely on a qualitative shift in assessment, priorities, or response strategy, that often lead to a ‘failure to adapt adequately.’ To address this gap in EA resilience representation, we have combined several prior research proposals to produce a wholistic Department of Defence Architecture Framework (DoDAF) resilience architecture and enhanced that with our original underpinning resilience framework. Despite still being in an ongoing major case study, our comprehensive resilience representation shows promise of assisting all enterprise stakeholders with adapting this representation to their capability systems. Doing so will better incorporate resilience considerations in capability systems’ design and likely help capability stakeholders to evolve capability systems with appropriate levels of resilience throughout their life cycle.
... Una arquitectura empresarial relaciona los procesos de trabajo con la infraestructura de tecnologías de la información necesaria para ejecutarlos (Urbaczewski, y Mrdalj, 2018). También hace posible la comunicación sobre diferentes aspectos de la organización y entre sus diferentes dominios (Dragstra, 2005) mediante un lenguaje unificado y estandarizado (Silva, 2016), proporcionando el soporte necesario en el contexto de problemas de diseño organizacional (Proper y cols., 2012). ...
Full-text available
Propósito: Analizar los beneficios de la arquitectura empresarial utilizando las capacidades organizacionales. Diseño/Metodología: La investigación es cualitativa con enfoque exploratorio y se utilizan métodos y técnicas de análisis documental, como el análisis de contenidos y la descripción bibliográfica a través de la identificación, indexación, revisión y resumen. Resultados: Se demostró que los trabajos e iniciativas de evaluación de los beneficios de arquitectura empresarial analizados carecen de una clasificación clara y no ofrecen evidencias empíricas. En base a esto se establece el análisis de los beneficios de la arquitectura empresarial a través de cuatro capacidades organizacionales. Implicaciones prácticas: Utilizar las capacidades organizacionales como elementos mediadores entre las iniciativas de arquitectura empresarial y los resultados de las organizaciones, sirviendo de vinculo para aportar pruebas empíricas. Originalidad/Valor: La investigación aborda el tema de los beneficios de la arquitectura a través de un enfoque novedoso que abre nuevas posibilidades para estudios empíricos sobre la temática.
... The following are EA frameworks discussed in [23]: [28], is based on the following items: primary outcomes, levels of scope, essential elements, sub-architecture domains, reference models, current and future views, transition plans, and a roadmap. ...
Full-text available
The chemical industry has sustained the development of global economies by providing an astonishing variety of products and services, while also consuming massive amounts of raw materials and energy. Chemical firms are currently under tremendous pressure to become lean enterprises capable of executing not only traditional lean manufacturing practices but also emerging competing strategies of digitalization and sustainability. All of these are core competencies required for chemical firms to compete and thrive in future markets. Unfortunately, reports of successful transformation are so rare among chemical firms that acquiring the details of these cases would seem an almost impossible mission. The severe lack of knowledge about these business transformations thus provided a strong motivation for this research. Using The Open Group Architecture Framework, we performed an in-depth study on a real business transformation occurring at a major international chemical corporation, extracting the architecture framework possibly adopted by this firm to become a lean enterprise. This comprehensive case study resulted in two major contributions to the field of sustainable business transformation: (1) a custom lean enterprise architecture framework applicable to common chemical firms making a similar transformation, and (2) a lean enterprise model developed to assist chemical firms in comprehending the intricate and complicated dynamics between lean manufacturing, digitalization, and sustainability.
... The concept of enterprise architecture (EA) is not new, it has been adopted in many private organisations (Ross, Weill & Robertson, 2006) and government institutions and agencies for many years (Urbaczewski & Mrdalj, 2006). The views of Cabrera et The Enterprise Architecture as Agent of Change for Government Enterprises Tiko Iyamu ...
In the last three decades, two fundamental things have happened to the concept of the enterprise architecture (EA). One, the interest on EA continues to increase, which enacts popular debate and discourse at both academic and business platforms. Two, the pace of deployment within government enterprises is slow, which affects actualisation of the benefits towards service delivery. This can be attributed to confusions and misunderstandings about the concept, which manifests from the fact that the influential factors of the concept are not clear. As a result, many enterprises continue to be hesitant or dismissive about the concept. Thus, the purpose of this study was to develop a conceptual an EA framework that can be used to guide government enterprises towards transformative goal. The framework is intended to guide the fundamental components, which causes confusion about the deployment of EA as agent of change within government enterprises.
... Enterprise architecture identifies the main components of the organization and their relation to achieve business objectives. It acts as an integrating force between aspects of business planning, operation, technology, etc. (Urbaczewski and Mrdalj 2006). It has been identified that apart from shortcomings in its internal processes, there are other factors related to suppliers and the distribution of the finished product, which impact operations and, consequently, the competitiveness of SMEs (Fonseca et al. 2018). ...
Globalization and technological development have imposed a great challenge in the search for business competitiveness. This research studies the business, competitive or generic strategies that favored or disadvantaged the achievement of a sustained competitive advantage in the period 2013 to 2015 in medium and large companies of the Bucaramanga Metropolitan Area (AMB), for which we worked with a sample of 213 of the 685 companies under study, for a margin of error of 5% and a confidence level of 90%. To select the companies that achieved a sustained competitive advantage, those that exceeded the Dupont profitability of their respective national economic subsector in the three years of study were identified. The test of difference of proportions using the t-student distribution with the Minitab-v17® software, allows to conclude at 10% of significance that implementing the differentiation and approach or niche business strategies favored the achievement of a sustained competitive advantage in the companies and period under study. These results allow efforts to be focused by the local government and the business sector towards the improvement of regional competitiveness.
Although a variety of specialised formalisms have been proposed specifically for enterprise modelling, the use of existing modelling languages has not received as much attention. In this paper, we demonstrate that the systems modelling formalism SysML is in fact not sufficient to act as a standalone language for enterprise modelling. To demonstrate this claim, we show that there are four key enterprise modelling scenarios that cannot be addressed while adhering to SysML semantics: temporal representation, timing and scheduling, collaborations between two or more teams and decision trees .
To fit the renewed globalized economic environment, enterprises, and mostly SMEs, have to develop new networked and collaborative strategies, focusing on networked value creation (instead of the classical value chain vision), fitting the blue ocean context for innovative products and service development. Even if collaborative organizations have been studied for decades, the closer connection of information systems involved by the so-called “Industry 4.0” developed by leading industries in Europe, US and Asia requires to set new IT models to support agile and evolving collaborative Business Process (BP) enactment, integrating both traditional Information Systems (IS) and production control processes. By now, these product/service ecosystems are mostly supported by software services, which span multiple organizations and providers, and on multiple cloud-based execution environments, increasing the call for openness, agility, interoperability and trust for both production and Information System organization. These requirements are well supported by SOA, Web 2.0 and XaaS technologies for Information Systems. Taking advantage of IoT, services and Cloud technologies, the development of Cloud of Things (CoT) changes the way control application are engineered and developed moving from a dedicated design and development of control applications to a Control as a Service vision. This vision requires developing a new architecture to connect physical and logical objects as well as integrating basic control patterns to organize a consistent control service orchestration. To fit this challenge, we propose a multi-layer Control as a Service architecture to describe control systems in a holistic way. Our Control service model is built according to an event-driven orchestration strategy. Thanks to the integration of a context manager, analyzing continuously the system environment as well as the control system behavior, these context-aware control services can be deployed
Many cities are adopting information and communication technologies (ICT) to add value to business process. This has led to the realisation of smart cities making them dependable on ICT. In Namibia, the focus is to transform Windhoek into a smart city. However, it is not easy as Windhoek continues to face many challenges, for example lack of collaboration among stakeholders. The challenges could be attributed by lack of approaches such as enterprise architecture (EA). As a management and design approach, EA provides a system view of all components and their relationship. In the absence of EA, realisation of Windhoek smart city will continue to be challenging, impeding the city from providing smart services. The study's aim was to develop EA framework for Windhoek smart city realisation. A qualitative case study approach was employed. Data was interpretively analysed to enable a deeper understating of the influencing factors. Based on the findings, a conceptual EA framework was developed. The framework aims to guide and govern Windhoek city transformation towards its smart objectives.
Full-text available
With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system. This paper defines information systems architecture by creating a descriptive framework from disciplines quite independent of information systems, then by analogy specifies information systems architecture based upon the neutral, objective framework. Also, some preliminary conclusions about the implications of the resultant descriptive framework are drawn. The discussion is limited to architecture and does not include a strategic planning methodology.
Full-text available
John Zachman introduced a framework for information systems architecture (ISA) that has been widely adopted by systems analysts and database designers. It provides a taxonomy for relating the concepts that describe the real work to the concepts that describe an information system and its implementation. The ISA framework has a simple elegance that makes it easy to remember, yet it draws attention to fundamental distinctions that are often overlooked in systems design. This paper presents the framework and its recent extensions and shows how it can be formalized in the notation of conceptual graphs.
Managing an enterprise architecture is a challenging task. While careful planning typically goes into its design, an enterprise architecture actually emerges as a result of implementing individual projects. It is this de facto architecture, not the conceptual one, that provides the capabilities for executing business strategies, and understanding this emergent architecture is of paramount importance. In this paper, we present the Four-Domain Architecture (FDA), which integrates business process, information, knowledge, and elements pertaining to infrastructure and organization. The FDA approach can help guide the development of both the conceptual and emergent architecture. The FDA helps an enterprise in the definition, design, and creation of a set of tools and methods to support frameworks such as the Zachman framework.
DoDAF. Systems & Software Consortium Available: Federal Enterprise Architecture – Practical Guide, version 1.0 Available: https://secure
  • Dodaf
DoDAF (2005). DoDAF. Systems & Software Consortium. Available: 4. FEA (2001). Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001. Available: ractical_guide_to_federal_ enterprise_architecture.pdf
How to Survive in the Jungle of Enterprise Architecture Frameworks: Enterprise Systems
  • J Schekkerman
Schekkerman, J. (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks: Enterprise Systems, Swinburne University of Technology, Technical Report: SUTIT- TR2004.01, CeCSES Centre Report: SUT.CeCSES-TR001, August 25, 2004.
Federal Enterprise Architecture Framework, Version 1 Available: hpcc/docita/files/federal_enterprise_arch_frame work An Overview of Enterprise Architecture Framework Deliverables
FEAF (1999). Federal Enterprise Architecture Framework, Version 1.1, September 1999. Available: hpcc/docita/files/federal_enterprise_arch_frame work.pdf 6. Goethals, F. (2003). An Overview of Enterprise Architecture Framework Deliverables. May 2003. Available: Page.htm
  • Clinger-Cohen
  • Act
Clinger-Cohen Act of 1996 (1996). Available: ppm/documents/clingercohen.pdf
TEAF. Systems & Software Consortium Available: 12. The Open Group Architectural Framework Welcome to TOGAF. Available: www. opengroup. org /architecture/togaf7-doc/arch/ 13 Data Architecture Standards for the Effective Enterprise
TEAF (2005). TEAF. Systems & Software Consortium. Available: 12. The Open Group Architectural Framework (2005). Welcome to TOGAF. Available: www. opengroup. org /architecture/togaf7-doc/arch/ 13. Van den Hoven, J. (2004). Data Architecture Standards for the Effective Enterprise. Information Systems Management, 21(3), 61-4.