NAME : AMALIA FIQHIYAH

NIM : 1202164314

CLASS : SI-40-INT ASSIGNMENT 2

ENTERPRISE ARCHITECTURE FRAMEWORK

1. Zachman Framework
The Zachman architecture framework was developed by John Zachman in 1987. The Zachman
Framework is based arounf the principles of classical architecture that establish a set of
perspectives for describing complex enterprise systems.
• Foundation structure
In today's complex business environments, many large organizations have
great difficulty responding to changes. Part of this difficulty is due to a lack of internal
understanding of the complex structure and components in different areas of the
organization. Enterprise Architecture (EA) is a discipline which has evolved to structure
the business and its alignment with the IT systems.
The Zachman Framework is an enterprise ontology and is a fundamental
structure for Enterprise Architecture which provides a way of viewing an enterprise
and its information systems from different perspectives, and showing how the
components of the enterprise are related.
• Methods
a. Perspectives
There are six perspectives in the framework and they can be classified as:
• Principal
The principle perspectives of the framework are ;
The planner’s perspectives - The planner provides scope for the enterprise,
establishes the context for the enterprise, inner and outer limits and the list of
relevant constituents which must be accounted for in the artifacts of the other
perspectives.
The owner is a conceptual view of the final product or service. Intended recipient of
the final product or service and the artifacts produced
represent the desirable characteristics of the product or service and the artifacts show
what the owner is going to do with the product or service.
The designer’s perspectives has a logical view of the final product or service. The
artifacts produced by the designer represent the laws of nature, the system or the
logical constraints of the product’s or service’s design.
The builder’s perspectives is a physical view of the final product or service or general
contractor of the final product or service. The builder applies the physical constraints
of what is possible to the designer’s artifacts understands how the product can be
built and used.
The subcontractor’s perspectives seeks to fabricate and assemble all the necessary
components. creates the detailed descriptions that disassociate the parts or pieces of
the complex object for purposes of manufacturing.
 The functioning enterprise perspectives is represents the functioning product, goods
or services and what the users will experience. The physical materialization of the
product or service and is the result of what is articulated through artifacts.
• Empirical
The empirical perspectives of the framework are the planner and subcontractor (rows
1 and 5), so that the product or service can be manufactured piece by piece and then
assembled into the final product.
• Certifiable
The certification perspective is the functioning enterprise and there is no artifact
representation because the functioning enterprise is the culmination of the other
perspectives and is the real thing.
b. Aspect
The framework’s aspects are normalizes the framework and reduces facts and questions to
one location within the framework, which makes the framework an effective communication.
When going through the table vertically, only one aspect is considered, but the player is
changed from the perspective of which this element is considered. Column give the answer
to 6 question:
What – data that needs to be understood and worked with.
How – function or how the process of changing the aim of the enterprise into a more detailed
description of its operations.
Where – network or where the business activities are taking place or will be distributed in the
future.
Who – people who are involved in the business processes and into implementing the new
architecture.
When – Time and effects of time on the organization.

Why – motivation and formulating the business goals and strategies.

• Key tools and guideline

 Each cell represents a fundamental piece of knowledge relative to the row and column
and is known as a primitive. A comprehensive knowledge base (knowledge of all the
primitives) helps one to understand and determine whether the functioning enterprise is
working appropriately.
This tool can also be an information system decision support tool, particularly in the
issues relating to the Enterprise Architecture because :
a. It allows a multi-dimensional analysis of the concepts interconnection that exist in each
cell, namely in the dependency between perspectives (rows) and/or dimensions (columns);
b. It supports an analysis of the alignment level between Enterprise Architecture components.
The zachman framework doesn’t 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.

• Reference (special purpose)

It serves as an organizational tool in developmental efforts. This framework provides a
blueprint, or architecture, for the organization’s current and future information
infrastructure. It serves as an organizational tool in developmental efforts. This framework
provides a blueprint, or architecture, for the organization’s current and future information
infrastructure.

With the purpose of supporting the Zachman Framework’s concepts, as well as the artifacts
and method proposed, a tool was developed whose main functionalities are :
a. It behaves as an information repository for the concepts in the zachman framework
For each one of the Zachman Framework specific form were developed that enable data entry
of the cell’s concepts. Using this data, it is possible to perform common operations such as
create, edit, remove, search and print, as well as filter the records according to the criteria
defined for each cell.
b. It allows us to produce several artifacts related to each framework cell.
For the proposed artifacts, with exception of those which have graphical representation, such
as the Entities Diagram or Activity Diagram, all the others are supported by the tool, being
created from the introduced elements of each cell.

2. TOGAF (The Open Group Architecture Framework)

TOGAF is based on TAFIM (Technical Architecture Framework for Information Management),
an IT management framework developed by the Department of Defense’s Technical
Architecture Framework in the 1990s. It was released as a reference model for enterprise
architecture. TOGAF was released in 1995, expanding on the concepts found in the TAFIM
framework. TOGAF 7 was released in December 2001 as the “Technical Edition,” followed by
TOGAF 8 Enterprise Edition in December 2002; it was then updated to TOGAF 8.1 in December
2003. The Open Group took over TOGAF in 2005 and released TOGAF 8.1.1 in November 2006.
TOGAF 9 was introduced in 2009, with new details on the overall framework, including
increased guidelines and techniques. The most recent version of TOGAF is TOGAF 9.1, which
was released in 2011.
• Foundation Structure and Method
TOGAF foundation architecture is an architecture of generic services and functions that
provides a foundation on which specific architectures and architectural building blocks can be
built. There are include:
a. TOGAF Standards Information Base (SIB), a database of open industry standards that can
be used to define the particular services and other components of an organization-specific
architecture. The TOGAF Standards Information Base (SIB) provides a database of open
industry standards that can be used to define the particular services and components
required in the products purchased to implement the developed architecture. The SIB
provides a simple and highly effective way to procure against an IT architecture.
b. TOGAF Architecture Development Method (ADM), which explains exactly how to get
from the Foundation Architecture to an organization-specific one. The ADM is at the heart
of TOGAF. The ADM can be adapted and customized to a specific organizational need, which
can then help inform the business’s approach to information architecture. ADM helps
businesses develop process that involve multiple check points and firmly establish
requirements, so that the process can be repeated with minimal errors.

The TOGAF ADM stages :

a. Preliminary phase
Prepare the enterprise for the realization of the architecture work.
b. Phase A : Architecture Vision
Describes the initial phase of the architecture development cycle. Defining the scope,
identifying stakeholders, creating an architectural vision (Architecture Vision), and requesting
and obtaining approval.
c. Phase B : Business Architecture
Describes the development of business architecture (Business Architecture)
to support the architectural vision (Architecture Vision) that has been approved.
d. Phase C : Information System Architecture
Describes the development of information systems architecture for a
architectural projects, including the development of data architectures and applications.
e. Phase D : Technology Architecture
Describes the development of technology architecture for an architectural project.
f. Phase E : Opportunities and Solutions
Initial implementation planning and identification of delivery facilities from
architecture that has been defined in the previous phase.
g. Phase F : Migration Planning
Initial implementation planning and pointing out the formulation of a set of stages for
architectural transition accompanied by the implementation plan and the implementation
and migration plan. identification of delivery means of architecture that has been defined in
the previous phase.
h. Phase G : Implementation Governance
Provides architecture management for implementing Enterprise Architecture.
i. Phase H : Architecture Change Management
Establish procedures to manage changes / changes to architecture
the new one.
j. Requirements Management
The process of managing architectural requirements during a cycle ADM.

• Key tools and guideline

There are four architecture domains that are commonly accepted as subsets of an overall
enterprise architecture, all of which TOGAF is designed to support:
a. The Business Architecture defines the business strategy, governance, organization, and key
business processes.
b. The Data Architecture describes the structure of an organization's logical and physical data
assets and data management resources.
c. The Application Architecture provides a blueprint for the individual application systems to
be deployed, their interactions, and their relationships to the core business processes of the
organization.
d. The Technology Architecture describes the logical software and hardware capabilities that
are required to support the deployment of business, data, and application services. This
includes IT infrastructure, middleware, networks, communications, processing, standards,
etc.
• Reference (special purpose)
The Architecture Development Method (ADM) is applied to develop an enterprise
architecture which will meet the business and information technology needs of an
organization. It may be tailored to the organization's needs and is then employed to manage
the execution of architecture planning activities.

3. FEAF (Federal Entreprise Architecture Framework)

• Foundation Structure
FEAF is based on Zachman framework, but refers only to the first three columns
there (using slightly different column names) and focuses on the top three rows. FEAF consists
of six reference models : Performance Reference Model (PRM) – is used for
measuring the performance of initial IT investments and estimating how they contribute to
identifying opportunities that can be improved; Business Reference Model (BRM) – is used
for organising, constructing in a hierarchical way and describing day-to-day business
operations in the government; Data Reference Model (DRM) – describes the interactions and
data exchanges between the government and ordinary citizens; Technical Reference Model
(TRM) – is used for categorising the standards and technologies, supporting and delivering
service components; Infrastructure Reference Model (IRM) – is used for supporting the
hardware that provides functionality; Security Reference Model (SRM) – is used as a common
language, as well as a methodology, for describing security and privacy regarding business
goals in various organisations.

• Methods
The primary method for modelling FEAF is the Collaborative Planning Methodology (CPM).
The CPM is structured in a way that allows to use, reuse and guide planners in determining
whether other organisations previously addressed such needs and whether they can use their
business models, experiences, and work products. The methodology also helps planners to
support management and stakeholders, as they make decisions regarding the directions,
which are appropriate for the mission, investment and implementation. And also provides
the planners with guidance in their support of measuring the actual performance changes
that were the result of the recommendations, and in turn, the use of these results in the
future planning activities.
The more detailed description of the five steps of the CPM is as follows :
a. Definition and verification
Identifying and assessing what needs to be achieved, understanding the primary drivers of
change, identifying, approving and prioritising the operational realities of the mission and
objectives with management, stakeholders and executive staff.
b. Research and use
Identifying external organisations and service providers that may have already completed or
are currently facing similar needs, analyse their experience and results to determine whether
they can be applied.
c. Definition and Planning
Developing a plan, which defines what will be done, when it will be done, how much it will
cost, how to measure success and what significant risks should be considered to meet the
needs identified in Step 1. Also, it includes a timetable; what benefits will be achieved, when
they can be expected, and how they will be measured.

d. Invest and Execute

Making investment decisions and implementing the changes defined in the integrated plan.
At this stage, many groups participate, but it is important to note that these groups will have
to work as a joint team to achieve the primary goal of this step.
e. Execution and Measurement
Managing and measuring the performance of the work by specific indicators.
• Key Tools and Guideline
The FEAF-II document contains detailed guidance for those who implement the
Common Approach. The document contains a detailed overview over tools and methods.
A key part of FEAF-II is the Consolidated Reference Model (CRM), which equips OMB
and Federal agencies with a common language and framework to describe and analyze
investments. It consists of a set of interrelated reference models that describe the six sub-
architecture domains in the framework:
a. Strategy
b. Business
c. Data
d. Applications
e. Infrastructure
f. Security
• Reference (special purpose)
The key point of FEAF :
a. The point of view where the architecture of the enterprise will be considered.
b. A set of reference models describing different perspectives on the structure of the
organisation (the six models listed above).
c. The process of creating EA.
d. The process of transition from the old paradigm (before the creation of the
organisation’s architecture) to the new one (after its inception).
e. Taxonomy for classifying assets that fall within the scope of the enterprise’s
architecture.
f. The technique, allowing to estimate success of EA use for increasing the business value.

4. DODAF (DoD Architecture Framework)

• Foundation Structure
The DODAF 2.0 Architects Guide repeated DOD Instruction 4630.8 definition of an integrated
architecture as An architecture consisting of multiple views facilitating integration and
promoting interoperability across capabilities and among integrated architectures. For the
purposes of architecture development, the term integrated means that data required in more
than one of the architectural models is commonly defined and understood across those
models. Integrated architectures are a property or design principle for architectures at all
levels: Capability,Component, Solution, and Enterprise (in the context of the DoD Enterprise
Architecture (EA) being a federation of architectures).
• Method
DoDAF has various kinds of stages :
a. Determine the intended use of the architecture
Defines the purpose and intended use of the architecture the methods to be used in
architecture development; the data categories needed; the potential impact on others; and
the process by which success of the effort will be measured in terms of performance and
customer satisfaction.
b. Determine scope of architecture
The scope defines the boundaries that establish the depth and breadth of the Architectural
Description and establish the architecture's problem set, helps define its context and defines
the level of detail required for the architectural content.
c. Determine Data Required to Support Architecture Development
The required level of detail to be captured for each of the data entities and attributes is
determined through the analysis of the process undergoing review conducted during the
scoping in Step 2. This includes the data identified as needed for execution of the process,
and other data required to effect change in the current process.
d. Collect, Organize, Correlate, and Store Architectural Data.
Architects typically collect and organize data through the use of architecture techniques
designed to use views (activity, process, organization, and data models as views) for
presentation and decision-making purposes.
e. Conduct Analyses in Support of Architecture Objectives
Architectural data analysis determines the level of adherence to process owner requirements.
This step may also identify additional process steps and data collection requirements needed
to complete the Architectural Description and better facilitate its intended use.
f. Document Results in Accordance with Decision-Maker Needs.
The final step in the architecture development process involves creation of architectural
views based on queries of the underlying data.

• Key Tools and Guideline

Representations for the DoDAF products may be drawn from many diagramming techniques
including:
a. tables
b. IDEF
c. Entity-relationship diagrams (ERDs)
d. UML
e. SysML

• Reference (special purpose)

The purpose of DoDAF is to define concepts and models usable in DoD’s six core processes:
a. Joint Capabilities Integration and Development (JCIDS)
b. Planning, Programming, Budgeting, and Execution (PPBE)
c. Defense Acquisition System (DAS)
d. Systems Engineering (SE)
e. Operational Planning (OPLAN)
f. Capability Portfolio Management (CPM)
In addition, DoDAF 2.0's specific goals were to Increase utility and effectiveness of
architectures via a rigorous data model (the DoDAF Meta Model) so the architectures can be
integrated, analyzed, and evaluated to with more precision.