Towards a Framework for Enterprise Architecture Frameworks Comparison

and Selection

Saber Abdallah Galal Hassan Galal-Edeen

Faculty of Computers and Information, Faculty of Computers and Information,
Cairo University Cairo University
Saber_abdallah@[Link] & The British University in Egypt
[Link]@[Link] / Galal@[Link]

Abstract − system includes the application software system,

platform, system-of-systems, enterprise, product
A number of Enterprise Architecture Frameworks line, ...
(EAF) do exist, which are sometimes different in − environment is developmental, operational,
approaches and at other times are based on other programmatic, … context of the system.
frameworks. This paper presents a survey of the Framework: The framework is fundamentally a
current state of EAF. Comparisons will be held conceptual model [2]. A framework is a structure
among some selected frameworks based upon within which the key components of the architecture
different criteria. These criteria will include the and the relationships between these components are
current market share of the selected frameworks, defined. A framework [3]:
goals, inputs, outcomes, strengths, weaknesses and
frameworks supported tools. Conclusion is made − Helps organize thinking about the architecture
concerning EAF selection. − Provides a description of the architectural artefacts
− Helps ensure that everyone is using the same set of
Key words: Enterprise Architecture Frameworks
(EAF), Information Systems Architecture semantics and presents them to the group of
Frameworks comparisons, Enterprise Architecture stakeholders interested in the contents of the
Frameworks selection criteria. architecture.
− Provides a way to communicate the architecture
1. Introduction − It level-sets stakeholders about the contents of the
architecture by providing common definitions and
This paper starts by outlining the basic terms of concepts
architecture, enterprise, framework and Enterprise − It shows the relationships between business and
Architecture Frameworks (EAF). Background on technology elements, ensuring that there is
different frameworks and a classification of these coherence between all elements and that every
frameworks will be presented. Different criteria for business element can map to a corresponding
EAF will be discussed. At the end of this paper we element in the technical architecture and, similarly,
will conclude how to choose an EAF regarding these that technical elements can be seen as supporting
criteria and the current state of EAF. Also key business requirements.
recommendations for further research in this area Enterprise:
will be presented. In this paper we will use EAF and
Any collection of organizations that has a common
information system frameworks interchangeably.
set of goals and/or a single bottom line [4]. In that
sense, an enterprise can be a government agency, a
1.2 Basic definitions whole corporation, a division of a corporation, a
single department, or a chain of geographically
Architecture: In this paper, we will use the IEEE distant organizations linked together by common
Standard 1471-2000 for the term architecture. It is ownership.
defined as “The fundamental organization of a
Enterprise architecture (EA):
system embodied in its components, their
relationships to each other, and to the environment, A coherent whole of principles, methods, and models
and the principles guiding its design and evolution.” that are used in the design of an enterprise's
[1], where: organizational structure, business processes,
information systems, and infrastructure [5]. The most
− fundamental organization means essential, important characteristic of an EA is that it provides
unifying concepts and principles. a holistic view of the enterprise.
Enterprise Architecture Framework (EAF):
The EAF is an instrument. When utilized it facilitates architecture addresses one or more concerns held by
a holistic (cross-organizational, cross-functional, one or more of its stakeholder [9].
collaborative view of, delivery of and approach to Viewpoint
the following key concepts [6]:
− Communication It is a collection of patterns, templates, and
conventions for constructing one type of view. It
− Organization around EA defines the stakeholders whose concepts are reflected
− Mapping technical elements to business strategy in the viewpoint and the guidelines, principles, and
− Priority planning template models for constructing its views [9].
− Asset and artifact management Stakeholder:
− Service delivery
An individual, team, or organization (or classes of
− Semantics thereof) with interests in, or concerns relative to, a
Which collectively, guide the organization in the system [5]. Most stakeholders of a system are not
development of the EA. probably interested in its architecture, but only on the
An EAF is comprised of a coupling of two major impact of this on their concerns. However, an
components: Methodology and Framework. Table architect needs to be aware of these concerns and
(1) shows the main characteristics of both discuss them with the stakeholders, and thus should
components. be able to explain the architecture to all stakeholders
Methodology Framework involved, who will often have completely different
Describes standardized Standardized classification backgrounds.
processes for developing tool for the EA deliverables
the EA. or artifacts. Describes the 2. Enterprise Architecture Frameworks
"What" of EA.
Describes standardized A place for everything and
deliverables and processes everything in it's place 2.1 EAF history and taxonomies
for developing the EA EA gained popularity when John Zachman
Table (1) Methodology and Framework developed his framework for dealing with large
characteristics information systems on 1987 [10]. Figure (1), [8]
Software Architecture: illustrates the historical relationships among several
frameworks. We notice that most enterprise
The software architecture of a system or a collection
architecture frameworks have a common history and
of systems consists of the important design decisions
are built on refinements and add-ons of other
about the software structures and the interactions
frameworks. Zachman framework is the oldest and
between those structures that comprise the systems.
the father of the most frameworks. Different
These design decisions support a desired set of
taxonomies are there for EAF. One of these is
qualities that the system should support to be
differentiations between two classes of frameworks:
successful. The design decisions provide a
classic EAF, and federated EAF [11]. The federated
conceptual basis for system development, support,
enterprise architecture deals with creating integrated
and maintenance [7]. It relates requirements, fixed
architectures. Examples of federated enterprise
system hardware, and infrastructure (i.e., COTS,
architectures are C4ISR architecture framework, the
GOTS) to software structures in order to demonstrate
federal enterprise architecture framework and the
software effectiveness [8].
treasury enterprise framework.
Information System Architecture:
Another taxonomy has been put by ISO 15704 [12],
An information system architecture typically it considered that there are two and only two types of
encompasses an overview of the entire information architectures that deal with enterprise integration:
system—including the software, hardware, and System architectures (sometimes referred to as "type
information architectures (the structure of the data 1" architectures) that deal with the design of a
that systems will use). In this sense, the information system, e.g. the system part of an overall enterprise
system architecture is a meta-architecture [2]. It integration;
relates the requirements and the external world to Enterprise-reference projects (sometimes referred to
system / solution structures, including both hardware as "type 2" architectures) that deal with the
and software, so that the effectiveness of a system organisation of the development and implementation
design concept can be communicated [8]. of a project such as an enterprise integration or other
View: enterprise development programme.
It is a representation of one or more structural In other words, type 1 architecture represents system
aspects of an architecture that illustrate how the or sub-system in terms of its structure and
behaviours. The type 2 architecture is actually
framework aiming at structuring activities/tasks

2
necessary to design and build a system. For example, architecture, which previously defined. Figure (2),
Zach-man’s architecture is type 2 architecture [13]. represents the Relationships among System
Outside the EA different taxonomies, we can find Architecture, Software Architecture, and Enterprise
three main types of architecture. These three types Architecture.
are: EA, software architecture and system
referenc DoD AF
JTA es 2003

referenc
es
ISO/IEC Supported
14252 referenc C4ISR by
DoDTRM es
influence 1999
influence d
d supported influence
by TOGAF d TOGAF
TAFIM adopted 1995 influence 2002
by d
influence
Zachman d Zachman
1987 2003
TEAF
influence influence 2000
d d
EAP influence FEAF FEAF
1992 d 1999 2003
influence
influence supported d
d by
influence TISAF influence E2AF
d 1997 d 2003
influence
d

UVA Model IAF v1 IAF v3 EE XAF

influence
1994 1996 d 2001 2003
influence
d
1985 1990 1995 2000 2005
Figure (1) Historical relationship among EAF

3
 Enterprise

Strategic
Architects

Governance Enterprise Architects

Business
Technology Strategy

Enterprise Architecture
System Architects

System Architecture
Solution System Architects

Information

Information

Infrastructure
Design Business (B&I and IS&TI)

Technology
System
Solution Software Architects
Intra Designers (CID)
Delivery
BPM/CRM/ER

Architecture

Architecture
Workflow
Supply Chain

Information

Architecture

Architecture
Management

Analysis

Network
Security
Security Specialists
Analysis

Software

Governance Specialists

Data
P

Figure (2): Relationship among System Architecture, Software Architecture, and Enterprise Architecture

2.2 Enterprise Architecture survey IAF, Capgemini's – (Integrated Architecture

The most important survey report in EAF is published Framework) 0.03
yearly since 2003 by Institute For Enterprise Architecture TAFIM, US Defense (Technical Architecture
Developments (IFEAD). This report presents the results Framework for Information Management) 0.02
of the third electronic survey [14], its title is "Trends in
ISO/IEC 14252 (IEEE Std 1003.0) Guide to
Enterprise Architecture : How are Organizations
the POSIX Open System Environment 0
Progressing?". The report is based on a 25 questions
survey, addressing geographical aspects, branch aspects, None 0
EA implementations aspects as well about tools and TEAF, US (Treasury Enterprise Architecture
methodologies used in Enterprise Architecture programs Framework) 0
and the role of architects in organizations. 79 respondents Table (1)
filled in the EA 2005 survey. One of these issues is "What Enterprise Architecture Framework Market share
kind of Enterprise Architecture Framework does your
organization use?". The following table represents the Table (1) shows the most used framework in 2005 is
result of the survey question. Zachman’s Enterprise Architecture Framework and
organization's own EAF came in the second. When
What kind of Enterprise Architecture dealing with such surveys, we should take into
Framework does your organization use? consideration the following points:
Framework Rate − Filling in the EA survey 2005 at the website of IFEAD
Zachman Framework 0.25 was voluntary, so the results can be a little bit distorted
Organization own 0.22 by the fact that only people who are interested in
Enterprise Architecture are taking the effort to fill in
C4ISR, US Defense Architecture Framework 0.11
this survey.
TOGAF, The Open Group Architecture − The rate of framework may differ from year to year,
Framework 0.11 and other frameworks may be disappeared from the
Extended Enterprise Architecture Framework survey.
(E2AF) 0.09
3. Enterprise Architecture Framework
FEAF, US Federal Enterprise Architecture
Framework 0.09 selection criteria
Other 0.09 There are different criteria that can be used to help in
selecting an EAF. These criteria can be categorized into

4
four sections, these section are goals, inputs, outcomes (QA) or Quality of Services (QoS). These requirements
and miscellaneous as shown in the following subsections. include availability, reliability, scalability, security,
Other criteria elements could be added to these sections, performance, inter-operability, modifiability,
specially when taking into consideration the software maintainability, usability and manageability.
frameworks architecture, which may be in some EAF
included in it, such as TOGAF. These criteria will be
3.3 Enterprise Architecture Outcomes
defined only in each section under Other Criteria, but not Outcomes represent results and deliverables. Typical
included into comparison table. outputs to architecture activities are the following [15].
− Business Model – describes business models, business
3.1 Enterprise Architecture Goals
requirements, business process, system roles, and
The following goals are common, independent of industry policy statements.
domain, architecture style and system size [15]. − Transitional Design – provides designs and plans to
− Architecture Definition and Understanding – make use support system transition and evolution.
of standard terms, principles and guidelines for Other Outcomes Criteria
consistent application of the framework for the − System Model – models major components of the
communication of architecture information to system. To arrive at a system architecture model, major
stakeholders. tradeoffs and design decisions are made. Future system
− Architecture Process – employ a well-defined process enhancements are also taken into consideration
to guide the construction of architecture. − Information Model – contains data model, data
− Architecture Evolution Support – employ processes and transformation and data interface Computation Model –
mechanisms that support systems evolution. contains system functional description, system process
− Standardization – ensure development and architectural flow, system operations, software components and
standards are maintained. interactions.
− Architecture Knowledge Base – provide consistent − Software Configuration Model – describes how
representation and repository of design and architecture software is packaged, stored, configured, managed and
design rationale. shared.
Other Goal Criteria: − Software Processing Model – describes how software
− Architecture Models – provide consistent standards to processes, software threads and run-time environment
document architecture specifications for the planning, are structured.
management, communication and execution of − Implementation Model – describes physical system
activities related to system development. structure such as operating environment, hardware
− Architecture Analysis – provide a set of viewpoints to components and networking components of the system.
guide the collection and analysis of information for Models implementation processes such as installation,
making architecture choices. deployment, configuration and management.
3.2 Enterprise Architecture Inputs − Platforms – describe platform software such as
operating systems, hardware and networking
Inputs represent information that architecture modelling components, protocols and standards.
considers. Typical inputs to architecture design activities − Non-functional Requirements Design – models the
are the following [15]. structure of the system to reflect design of
− Business Drivers – business goals, direction, principles, nonfunctional requirements.
strategies and priorities − Design Rationale – documents reasons of design based
− Technology Inputs – strategic architecture direction on analysis and tradeoffs that involve multiple
including technology platforms, future architecture, dimensions of inputs.
systems interoperability and emerging technology
standards. 3.4 Other Criteria
Other Inputs Criteria − Conformance - The modeling method should support
− Business Requirements – users’ requirements, the ability to define conformance testing criteria (of the
functional requirements, data requirements and other implementation to the architecture specification).
business system related requirements Otherwise, the "architecture specification" may or may
− Information System Environment – budget, schedule, not specify the architecture of the resultant system—no
technical constraints, resources and expertise, one will know for sure without provable tests. Some
organization structure, other constraints, enterprise models provide compliant test criteria to ensure the
knowledge base. architecture model is compliant with the modeling
− Current Architecture – current standards and method [16].
infrastructure. − Clinger-Cohen Act (CCA) Compliance - The CCA
− Non Functional Requirements – some of these specifies how the U.S. government is to plan, manage,
requirements are also referred to as Quality Attributes and acquire information technology. This legislation

5
 focuses on carrying through the information technology Architecture Evolution Support N Y Y
aspects of Government Performance and Results Standardization N Y Y
Architecture Knowledge Base N Y Y
(GPRA) [17]. CCA mandates the following : Inputs
 U.S. government agencies are to establish strategic Business Drivers P Y Y
performance goals for any information technology Technology Inputs N Y Y
Outcomes
that supports the agency. Business Model Y Y Y
 Agencies are to achieve at least a five percent Transitional Design N Y Y
Miscellaneous
decrease in the costs incurred to operate and Conformance N Y P
maintain IT systems, and a five percent increase in (CCA)Compliance P P P
agency operational efficiency as a result of IT Visualization tool Y Y Y
investments every year. Table (2): Comparisons of EAFs
 Each federal agency is to have a chief information 4.1 Zachman Information System
officer (CIO). The CIO is to help foster better Framework
technology investment, accountability, and
decision making within the agency. The CIO is to 4.1.1 Introduction
implement capital planning and investment
controls for IT acquisition and management, where John Zachman is the "Father" of the Zachman Framework
performance outcomes are measured, analyzed, and for Enterprise Architecture and Information Systems
reported (per GPRA). Architecture. The primary goals of Zachman framework
are for enterprise architecture analysis and modelling and
− Visualization tool - The visualization is a graphical of
it is also concerned with perspectives of constructing an
architecture or some part of architecture. Here we information system. A perspective is a row in a table
investigate if the framework has a graphical tool or not. representing how a stakeholder in a project team would
Different tools are available in the market, and each one view the system [15].
of them has its capabilities and supported framework(s),
such as Allen Systems Group (ASG) Rochade, What How Where Who When Why
Casewise Corporate Modeler, Computas Metis, IDS Data Function Network People Time Motivation
Scheer ARIS, MEGA International, Popkin Software Scope List of List of List of List of List of List of goals
(Planer) things processes locations organizations events
System Architect, Proforma ProVision and Ptech Contextual
Enterprise FrameWork. A comparison among these Enterprise Semantic Business Business Workflow model Master Business plan
tools can be found in [18]. Model
(owner)
model process logistics schedule

Conceptual
4. Frameworks System Model Logical Application Distributed Human interface Processing Business rule
(designer) data architecture system architecture structure model
Logical model architecture
In this section we provide a high level comparison and Technology Physical System Technology Presentation Control Rule design
analysis of three EAFs. Our selection for the three EAF is Model data design architecture architecture structure
(builder) model
based on table (1) of enterprise architecture framework Physical
market share. We select the high ranking (equal or over Detailed Data Program Network Security Timing Rule
11%). The three selected EAF contain the basic two Representations definition architecture architecture definition specification

classes of EAF: two classical and one federated. The Functioning

Enterprise
Data Function Network Organization Schedule Strategy

classical are Zachman and TOGAF, and the federated is (Subcontractor)

C4ISR. Table (3): The Zachman Framework
Table (2) provide an overview and comparisons of EAFs. The framework architecture is a matrix of 30 cells, where
The following notations are used to express the the rows represent the different perspectives and the
framework status for supporting an element in the table: columns the things viewed from each perspective. The
“Y”: If a framework explicitly supports an element. examples suggested by Zachman for each cell are shown,
“N”: If a framework does not support an element or there slightly abbreviated table (3) [19].
is no mention of that element in the documentation.
“P”: Where a framework partially supports or eludes to Each Cell is an outcome of an architecture activity based
support an element. on an aspect of a system for a particular group of people
The extent to which each EAF supports and interpret an and a singular focus on one aspect of the architecture such
element may differ even when they have the same values as data, process or location.
in the same row. The following subsections will provide ZACHMAN has six rules, these rules helps in building
details analysis for each EAF described in table (2). the EAF. The six rules are as follows [20]:
Zachman TOGA C4ISR
F Rule 1: Columns have no order
Goals Rule 2: Each column has a simple, basic model
Architecture Definition and P Y Y Rule 3: Basic model of each column is unique
Understanding Rule 4: Each row represents a distinct view
Architecture Process N Y Y

6
Rule 5: Each cell is unique
Rule 6: Combining the cells in one row forms a complete
description from that view
4.1.2 Zachman Framework Discussion
Although Zachman has been referred to and used in
frameworks such as FEAF, DoDAF and TOGAF, it
doesn't support most of the comparison criteria. Below
some of Zachman framework drawbacks.
− Zachman uses an analogy from classical building
architecture and military aircraft manufacturing to
help define information systems architecture (ISA).
This approach is useful when the final outcome is a
“system” because ISA helps in understanding the
components that make up each individual application
or system. Information Framework (IFW) uses the
alternative analogy of a “city plan”’ rather than a
building plan. It provides an effective way to
gradually develop a complete “city” of information. Figure (3): TOGAF main components
This compilation includes information about  Architecture Development Method (ADM), which
individual applications and systems, as well as is a specific process defined by TOGAF for the
information output from other types of projects such development and maintenance of the organization's
as strategic planning or business process technical architecture [23]. The ADM consists of
reengineering. [21]. seven major phases: initiations and framework,
− The relation between one cell and another is not baseline description, target architecture,
defined. That is, the consistency of the artefacts is not opportunities and solutions, migration planning,
addressed. There is no discussion as to the implementation, and architectural maintenance.
consistency from one cell to another, or from one row The ADM is considered to be the core of TOGAF,
to another, or from one column to another [16]. A and consists of a stepwise cyclic approach for the
solution was provided by [22] to facilitate using of development of the overall enterprise architecture
Zachman and relates in a consistency way among [5].
cells.  The TOGAF Enterprise Continuum, which
− Semantic behaviour, and how that behaviour affects aggregates two continua, the architectural
the functioning of the components and their continuum and the solutions continuum. The
interactions, is not addressed [16]. architectural continuum describes the
− The Zachman framework is not a standard written by generalization / specialization of architectural
a professional organization, so no explicit compliance components, whereas the solutions continuum
rules have been published. However, if the illustrates the actual implementation of the
framework is used in its entirely and all the given components [23], and TOGAF Foundation
relationship rules are followed, then compliance can Architecture that contains the Technical Reference
be assumed by default [8]. Model, The Open Group's Standards Information
− Many visualization tools support Zachman are Base (SIB), and The Building Blocks Information
available, such as Popkin and IDS Scheer ARIS. Base (BBIB) [5].
 The TOGAF Resource Base, which is a set of
4.2 The Open Group Architecture resources including guidelines templates and
Framework (TOGAF) background information to help the architect in the
use of the ADM.
4.2.1 Introduction TOGAF has a list of recommended architecture views
as part of its resource base. These architecture views
TOGAF developed by the Open Group in 1995. TOGAF can be divided into two main views, as follows:
is based on the Technical Architecture Framework for − Business architecture views, which addresses the
Information Management (TAFIM), which developed by
concerns of the users of the system, and describes the
the Department of Defence (DoD). Version 8.0 of
flows of business information between people and
TOGAF is called the 'Enterprise Edition' and is dedicated
business processes (e.g., People View, Process View,
to EA. The main components of the TOGAF are
Function View, Business Information View, Usability
described in figure (3) [5].
View, Performance View) [5].
− Technical architecture views, which include:

7
 o Engineering views, which address the
concerns of System and Software Engineers 4.3 The Command, Control,
and include Security, Software engineering,
Communications, Intelligence, Surveillance,
Data, System engineering, and
Communications engineering view. and Reconnaissance (C4ISR)
o Operations views, which address the concerns
4.3.1 Introduction
of Operators, Administrators and Managers
and include Security, Software, Data, The Command, Control, Communications, Intelligence,
Computing / Hardware, Communications Surveillance, and Reconnaissance (C4ISR) Architecture
view. Framework, came from Defence Science Board, who
o Acquirers’ views which address the concerns determined in the early 1990s that one of the key means
of procurement personnel responsible for for ensuring interoperable and cost effective military
acquiring the Commercial Off-The-Shelf systems is to establish comprehensive architectural
(COTS) software and hardware and include guidance for all of DoD. Consequently, the C4ISR
Building blocks cost, Standards view. Integration Task Force developed version 1.0 of the
C4ISR Architecture Framework in June of 1996, and the
4.2.2 The Open Group Architecture C4ISR Architecture Working Group completed version
Framework discussion 2.0 in December of 1997 [24]. C4ISR considers three
TOGAF has "Y" for all of the comparison criteria, except viewpoints, namely, an operational viewpoint, a systems
for (CCA) Compliance, it gets "P". TOGAF is like viewpoint, and a technical viewpoint. The three views and
Zachman in its compliance with CCA. CCA compliancy their relationships are shown in figure (4) [11].
can be it can be achieved using TOGAF when following − The operational view describes the tasks and
the compliancy rules [8]. From our point of view, activities, the operational nodes, and the information
TOGAF has many strengths and may be the leader of flows between nodes that are required to accomplish
Enterprise Architecture Framework. The strengths are: or support an operation. The operational view
− TOGAF is supported by an open strong committee, describes the nature of information exchanges in
which anyone can participate on and provide a fully detail sufficient to determine what specific degree of
published product of its results. information-exchange interoperability is required.
− Proven Method—TOGAF offers a proven method − The systems view translates the required degree of
that is the result of years of research and development interoperability into a set of system capabilities
by the world's leading enterprise architects. needed, identifies current systems that are used in
support of the operational requirements (or postulated
− Common Vocabulary—TOGAF guides architects in
systems that could be used), and facilitates the
using a standard taxonomy for business, information comparison of current/postulated system
systems, and technology modelling. This shared implementations with the needed capabilities.
vocabulary means that everyone in an organization
− The technical view articulates the criteria that govern
can read and understand the information.
the implementation of required system capabilities
− Communication—Models of the enterprise
[24].
architecture give visual representation to business
concepts, and, when published on the corporate
intranet, disseminate knowledge of the business to
the workforce.
− Command Decisions—A business-focused enterprise
architecture provides knowledge about an
organization and enables managers to make better-
informed decisions.
− Reduced complexity—A well developed architecture
leads to a better integrated solution portfolio, fewer
interfaces, increased data sharing, improved
reliability of the solutions, and easier maintenance.
− Business-IT alignment—The business focus of the
architecture development process and the strong
emphasis on the need for the implemented solution to
be architecture-compliant together will help ensure
that IT solutions are aligned to the needs of the
business.
− Many visualization tools support TOGAF are
available, such as MEGA and Popkin.

8
 4.3.2 C4ISR discussion
C4ISR has "Y" for most of the comparison criteria;
except for Conformance and (CCA) Compliance it
gets "P. There is no conformance of a system to the
architecture, there are only conformance criteria for
the use of C4ISR in an architecture representation
[16]. In order to comply with CCA, the architecture
description must [8]:
a. Include the appropriate set of products for the
intended use.
b. Use the common terms and definitions as specified in
the framework.
c. Be consistent with the Global Information Grid
(GIG) Architecture and the Joint Technical
Architecture (JTA).
d. Describe interoperability requirements in a standard
way.
Figure (4): C4ISR views and their linkages C4ISR is intentionally vendor-tool-independent.
The kinds of information represented in each architecture Vendor products exist to provide the framework
view are highlighted in each view box. The words on the products, but no specific vendor is required. Some
arrows between the different architecture views represent of the vendor tools that could be used are Ptech
the manner in which the framework provides consistency FrameWork, netViz and Sterling Software's
among the different views. The architecture products COOL™ tools.
result from each of the views, plus the general Consistency across the architecture views is not
information artefacts [16]. Table (4) represents the truly addressed and Relationships among the
essential products of C4ISR framework. concepts, and rules of structure, are minimal [16].
Applicable Architecture General Nature
Architecture Product
View
All Views Overview and Scope, purpose, intended users, 5. Conclusions
(Context) Summary environment depicted, analytical
Information findings of the architecture.
All Views Integrated Definitions of all terms used in all
This paper has review the current state of EAF and
(Terms) Dictionary products. the criteria that can be taken into consideration for the
Operational High-level High-level graphical description of election of EAF. An examination of the literature will
Operational operational concept (high-level reveal the following very popular themes:
Concept organizations, missions,
Graphic geographic configuration, − There is no ‘one’ best Framework
connectivity, etc.). − No one framework is fully complete. Rather, each
Operational Operational Operational nodes, activities has strengths and weaknesses. It is important to
Node performed at each node,
Connectivity connectivity & information flow match a framework’s strengths with the particular
Description between nodes. "pain points" in your organization, so that the specific
Operational Operational Information exchanged between aspects of the framework that you need are well
Information nodes and the relevant attributes of represented in the choice you make. Also, it is not
Exchange that exchange such as media,
Matrix quality, quantity, and the level of
our expectation that any framework will be
interoperability required. implemented in its entirety. Rather, think of a
Systems System Interface Identification of systems and framework as a restaurant menu, where you can pick
Description system components and their from among the most-appetizing dishes, and in doing
interfaces, within and between
nodes.
so, think about implementing those pieces in a
Technical Technical Extraction of standards that apply sequence that makes sense.
Architecture to the given architecture. − Frameworks have strengths and weaknesses
Profile
− Frameworks are adaptable
Table (4): C4ISR Architecture Framework Products
− Tailoring the framework you choose is not only
acceptable, it is expected
− Selecting a framework should not consume a great
deal of resources (get in and get out).

9
 References

About the authors:

Saber Abdallah is a PhD student at the department of

information systems, faculty of computers and
informatics, Cairo University. He is conducting
research into enabling and supporting debate
during architecting activities.

Dr Galal H. Galal-Edeen is an associate professor of

information systems at the faculty of computers
and informatics, Cairo University and a
professor of information systems at the British
University in Egypt.

10