Learning Center
Plans & pricing Sign in
Sign Out




White Paper
Enterprise Architecture – Executive Overview
(Prepared by Matrix Engineers, Enterprise Architecture Practice)

All information contained in this White Paper is the sole property of Matrix Engineers, except as otherwise
noted. Any reproduction, retransmission, or republication of all or part of this document is expressly
prohibited, unless Matrix Engineers expressly grants its prior written consent to reproduce, retransmit or
republish the material. All other rights reserved.
                            Table of Contents

Section/Title                                          Page No.






Enterprise Architecture (EA) is a disciplined process that leads to the production
of a blueprint showing the relationship between the mission of the organization
and supporting information technology resources. The blueprint initially presents
an “As-Is” view of the resources that supports the organization. Based on the “As-
Is” view adjustments can be made with goal of obtaining a “To-Be” view of the
resources that are more closely aligned with the organizations mission. As the
mission of the organization evolves, the EA is adjusted accordingly. This process
ensures that all applications, data, and technology utilized in the organization is
tied to a specific business process. A successful EA plan leads to the
comprehensive support of an organization’s mission.
The defined relationship model will reveal:
1. Business processes that are not properly supported
2. Excessive IT expenditures for duplicative systems
3. Security required to support the mission of the organization
4. Accurate method of managing data in the organization.
Improved decision support in the following area:
1. Capital Planning / IT Funding
2. Portfolio Management
3. Strategic Plan Development
Key success factors
1. Executive Sponsorship
2. Solid coordination between the CIO and CTO
3. Proper Funding
4. Clearly defined organizational struture
5. Clearly defined scope
6. Comprehensive EA framework training
Key Benefits
1. Ensure support resources are aligned with the organizations mission
2. Business justification of IT expenditures

3. Enhanced decision support capabilities
4. Adherence to government mandated policies

The definition of a comprehensive Enterprise Architecture Plan results from the analysis
of 5 key areas. These areas are described as sub-architectures.

1. Business Architecture
   The Business Architecture is based on organizational Mission/Business Strategy. An
   analysis of the business defines each business process that is used to accomplish the
   mission of the organization. Essentially the Business Architecture takes into
   consideration the businesses strategy of the organization, its long-term goals and
   objectives, the technological environment, and the external environment. This level
   also takes into consideration the interests of the various stakeholders of the firm, such
   as the government, regulatory agencies, customers, employees, stockholders, etc.

2. Application Architecture
   The Application Architecture results in the documentation of the organization’s
   inventory of current applications. It then maps the applications to a specific business
   process. The value of the application can then be defined in terms of its relationship
   to a business process. This will lead to the identification of duplicative applications
   and provide justification for application updates and/or additions.

3. Data Architecture
   The Data Architecture describes the information the organization needs to operate its
   business and characterizes the relationship between its applications and data. It
   consists of commonly defined and accepted definitions of the information used by the
   organization. It defines the information independent of who produces it, when it is
   produced, where it is physically kept, in what form it is kept, or how it is transmitted.

4. Security Architecture
   The Security Architecture identifies the critical vs. non-critical business processes,
   applications, and data elements within an organization. Based on this information the
   authorized creation, modification, deletion, and access to these components is
   identified. This relational matrix will determine what level of security should be
   assigned to these key organizational elements.

5. Technology Architecture
   The Technology Architecture defines the current infrastructure components and
   standards that are used within the organization. This would include the hardware
   components such as workstations, servers, and mainframes. This area would also
   encompass communication standards such as network protocols and web-based
   communication standards.


In order to systematically collect and document the information required for an EA,
frameworks have been developed, as a guide to ensure the all of the required information
is collected. In the federal government there are three primary frameworks that are used
as a guide to gather, define, and organize the information gathered during the Enterprise
Architecture Planning process.

1. Zachman Framework
   Matrix of 36 cells covering the Who, What, Where, When, Why and How questions
   of an enterprise. The enterprise is then split into six perspectives, starting at the
   highest level of business abstraction going all the way down to implementation. Such
   objects or descriptions of architectural representations are usually referred to as
   Artifacts. The framework can contain global plans as well as technical details, list
   and charts.

2. Federal Enterprise Architecture Framework
   The Federal Enterprise Architecture Framework (FEAF) was established in 1999 by
   the Chief Information Officers. The purpose of the FEAF is to facilitate shared
   development of common processes and information among Federal Agencies and
   other government agencies. The FEAF is essentially a guide for collecting common
   architecture information and building a repository to store this information.

3. DoD Architecture Framework (C4ISR)
   C4ISR stands for Command, Control, Communications, Intelligence, Surveillance,
   and Reconnaissance. In 1995 the Assistant Secretary of Defense for Command,
   Control, Communications, and Intelligence (ASD, C3I) formed the C4I Integration
   Support Activity (CISA) to develop a unified approach for development and
   evaluation of information and architectures.


Architecture teams are structured as hybrids of both hierarchical and virtual team
structures, drawing talent from numerous sources on an "as needed" basis while retaining
focus through dedicated resources. Successful architecture teams cast a broad net to
capture the required talents necessary to deliver on the expanded mandate of the
architecture function. In general the roles are defined as follows:

Chief Architect
       Concerned with the strategic plan development and fiscal management of the
       organization. Acts as the executive liaison and handles the personnel
       management of the enterprise architecture team. Oversight of governance
       requirements and policies related to the architecture.

Enterprise Solution Architect
       Concerned with all functional architecture, process, business requirement and
       system requirement analysis efforts. Provides guidance regarding blueprint
       implementation to the development team. Handles transformational issues
       associated the development of the enterprise architecture plan.

Enterprise Data Architect
       Concerned with the data and application architectures - the logical architectures
       supporting the business, and the relationships between them. Provides support for
       the development of taxonomies and the categorization of data associated with the
       (possibly separate roles of Applications Architect and Data Architect)

Enterprise Business Architect
       Concerned with business models and organizational design - the structural and
       functional components of the organization and their relationship, and how the
       business functions and activities of the organization are distributed among them;
       also the governance of the organization and the roles and responsibilities required.

Enterprise Technical Architect
       Concerned with the physical technology model, and the infrastructure components
       and their relationships, including choices of technologies, interfaces and
       protocols, and the selection of products to implement the infrastructure.

The titles given to these roles will vary, depending on the organization and its suppliers -
for example, an enterprise architect might be known as a Chief Technology Officer. In
some organizations the role of the Application and Data Architect is combined into an
Information Architect.


By 2004, 80% of Global 2000 enterprises will have failed in merging their IT and
business strategies. Only 20% will have succeeded in creating a unified business/IT
strategy and establishing an architecture process that addresses the enterprise's key
business, information, application, and technology strategies, along with their impact on
business functions and processes. These 20% will replace the traditional static and
discrete yearly planning process with a continuous improvement strategy and architecture
The following subject areas must be considered when justifying the
implementation of an Enterprise Architecture Plan.

       Policy Adherence
       Clinger-Cohen Act (CCA) of 1996 provides that the government information
       technology shop be operated exactly as an efficient and profitable business would
       be operated. Acquisition, planning and management of technology must be treated
       as a "capital investment." While the law is complex, all consumers of hardware
       and software in the Department should be aware of the Chief Information
       Officer's leadership in implementing this statute.
       CCA emphasizes an integrated framework of technology aimed at efficiently
       performing the business of the Department. Just as few businesses can turn a
       profit by allowing their employees to purchase anything they want to do any
       project they want, the Department also cannot operate efficiently with hardware

   and software systems purchased on an "impulse purchase" basis and installed
   without an overall plan. All facets of capital planning are taken into consideration
   just as they would be in private industry:
             cost/benefit ratio
             expected life of the technology
             flexibility and possibilities for multiple uses

   OMB consolidated guidance from different acts and produced circulars, which
   provide direction on implementing the activities and realizing the goals from the
   above-mentioned acts. OMB A-11 became the basis for business case analysis
   other wise called capital asset plan and justification, cost/benefit planning across
   agencies. OMB revised circular A-130 provides guidance in accordance with
   GPEA to manage information resources. This is possible only by having a
   coherent view of the enterprise wide information resources. This circular became
   the basis for enterprise architecture efforts across agencies.

Benefit Statement
The benefits of adhering to the policy guidelines are two-fold.
1. OMB has directed that federal organizations that do not have a defined
   Enterprise Architecture Plan will be denied funding in upcoming fiscal
   years. In order to prevent this from happening all organizations must have
   an Enterprise Architecture Plan in place.
2. The Enterprise Architecture Plan is a repeatable methodology that can be
   used to develop the business case for all future IT projects. By utilizing a
   repeatable methodology an organization can ensure that requested funding
   is always tied to a business need. This alignment will facilitate the
   establishment of metrics to evaluate the business case of the IT request.

Financial Impact
The lack of defined technology standards has led to the development of applications
and systems that are not interoperable. This has increased the overall cost of
application development because of additional custom programming and the purchase
of integration tools to compensate for the lack of standardization. The development
of stovepipe applications have also been a result of the use of non-standard
technologies. This has increased the overall burden on the IT support staff and has
lead to escalation in cost.

Benefits Statement

The consistent use of IT standards has led to a 41% reduction in development cost in
top-performing organizations. As organizations adopt new technologies, integrate
acquisitions and operate in a more real-time global environment, the case for
standardization becomes even stronger.


To top