Pg 1

EA development: Methods, Challenges, and Best

Practice


Group 1
Carlo DAbbraccio
Colin Espie
Emmanuel Asamoah-Okyere
Graeme Clark




















Pg 2
Introduction

Enterprise Architecture also commonly referred to as EA, is defined as a logical and consistent set of
descriptions that covers a design, regulation, and patterns-oriented perspective on an enterprise, which
provides indicators and controls that makes it possible for the informed governance of the enterprises
evolution and success (Op't Land et al, 2009).

EA was first proposed in its modern form by John Zachman. Zachman's basic vision was to keep
businesses from disintegrating, the concept of information systems architecture is becoming less of an
option and more of a necessity. Today there is a various range of different Enterprise Architecture (EA)
Frameworks (Schekkerman:131).

EA was developed out of the work of P. Duane (Dewey) Walker who pioneered in the field of
Information Architecture (Coetzee, 2009). The term EA was suggested by Dr. Steven H. Spewak in his
book of EA Planning (Wu, 2007). The United States developed the Technical Architecture Framework
for Information Management (TAFIM) in 1994. The Clinger-Cohen Act which was passed two years later
required that federal agencies should establish and maintain EA programs to improve effectiveness of
Information Technology investments. A chief information council was formed for the development of the
Federal Enterprise Architecture Framework (FEAF) which later evolved into the Federal Enterprise
Architecture (FEA). In 1998 FEAF was retired and was turned over to The Open Group, from which they
developed The Open Group Architectural Framework ( TOGAF) (Sessions, 2007).

There are four main architectural subsets which make up EA. These are
Business Architecture: defines the processes and activities that take place within the business.
Data Architecture: defines the organizing, collecting, distributing and securing data
Application Architecture: defines software tools
Technology Architecture: defines the hardware used

Another two important aspects when dealing with EA is system thinking and the information spectrum.
Both of these are important as they help in the designing of the system and also help with finding out
problems with the current system. System thinking is used to bring together related components which are
essential for accomplishing set tasks. Below is an overview of what aspects system thinking can involve
looking and how they link together.

Pg 3

Figure 1.System thinking diagram

The information spectrum is used to decide the importance of information by splitting it up into three
distinct types: data, information and knowledge. Data is low priority and has very little value, it is
generally historic and quantitative. Information is medium priority it is valuable which makes it tradable
and as it can be analyzed it can often guide and inform the business. Knowledge is high priority, it can
vary for common sense and public knowledge to more valuable personal knowledge and proprietary
knowledge which can give a business a competitive advantage over its competitors.

This essay will outline the challenges faced by an organisation when attempting to develop an enterprise
architecture. The best practices that they could follow to mitigate these challenges are backed up by
previous experience by other organisations, and several of the possible frameworks that could be used; the
Zachman framework, TOGAF, the US Department of Defence Architecture Framework and the Extended
Enterprise Architecture Framework. The aim is to critically analyse these frameworks and to produce a
final recommendation of which framework to use, based on how well it solves the challenges inherent in
architecture development.





Pg 4
Frameworks Overview
Zachman Framework

John Zachman had a basic idea about stopping the disintegration of enterprises and setting up a full-scale
system architecture. From 1987 on, he developed this idea and created a commonly used EA Framework.
The Zachman Institute for Framework Advancement (ZIFA) is the main source of development new
aspects and constantly improving the Frameworks main structure.

Zachmans Framework is used for business and industry information systems (Schekkerman:131) . The
Zachman Framework has been updated since then, and the latest (2011) version will be discussed in this
assignment (Zachman, 2013).

The scope of the Zachman framework is a holistic description of an enterprise's information model using
six perspectives: planner, owner, designer, builder, subcontractor (technician) and working system. There
is no guidance on sequence, process or implementation. The Zachman Framework can be described as a
set of principles. The Zachman Matrix (see Figure 1) describes the whole implementation for business
and industry information systems. The Zachman Matrix has 36 cells, and every cell is needed to create a
complete framework. It provides an organized way to describe and analyze a whole enterprise, a
department, a value chain or even an airplane.

Pg 5


Figure 2. Zachman matrix (Zachman, 2013)


The rows (reification transformations) provide unique perspectives represented by the role of each
stakeholder: executives, management, architects, engineers, technician and enterprise.

The executive role is that of an investor or planner interested in the estimate of the scope of the system,
the overall costs and performance by creating a contextual view. A business management role is an owner
of some aspect of the business who is interested in the business process model and an overall
understanding of his own project/investment by analyzing the relationship between entities and processes
by creating a conceptual view. An architect defines data elements and functions representing business
entities and processes by creating a logical view. Engineers define the information system model by
choosing tools, technology and resources (e.g. programming languages) by creating a physical view.
Technicians are responsible for implementing detailed specifications by producing out-of-context views,
and the enterprise role is the collection of instantiations, the working systems, that create the users view
(Zachman, 2013).
.

Pg 6
The columns (communication interrogatives) are questions providing the view classification types,
leading to different perspectives (Schekkerman, 2004). These columns each represent the 'what', 'how',
'where', 'who', 'when' and 'why' questions. The 'what' column highlights the entities involved in each
perspective, such as system data, for example. The 'how' column shows the functions within a
perspective, such as the business processes that make up that perspective. The 'where' column shows the
different locations within the enterprise's network, such as system components. The 'who' is the
relationships between people in the organisation who provide the authority, responsibility and the
allocation of work. The 'when' is the relationships between events in the schedule, and the 'why' column
shows the motivations of the enterprise, such as the general goals or the knowledge architecture.

The Zachman Framework is restricted by a set of rules that govern it (Zachman's Information System
Architecture, 2003). 'Dimension importance' states that columns have no order (i.e. no priority or set
sequence) but there is a left-to-right order for improved reading and referencing. 'Dimension simplicity'
means that one model maps to one column. These models describe a snapshot of the enterprise and its
systems. If one column changes this affects often several other columns. 'Dimensional uniqueness' means
that every model is unique to allow distinct classification. 'Dimension necessity' states that an individual
point of view can't be represented if a dimension is missing. A complete model of a perspective is given
when all row models are combined.

'Perspective uniqueness' requires a single participant for each row to clearly define responsibility. 'Cell
uniqueness' means that, as a consequence of dimensional uniqueness and perspective uniqueness, each
cell must be unique too. 'Logic recursive' states that the framework is a self renewing work flow.

These rows and columns give 36 individual cells. These cells give a complete description of every point
of view ensuring all aspects are dealt with (Zachman, 2013). To fill the cells it is necessary to combine
the communication interrogatives (What, How, Where, Who, When and Why) with the Reification
Transformations (Identification, Definition, Representation, Specification, Configuration, Instantiation).
Each of the cells must be unique and independent, and the meaning behind the cells characterises the
context of the related model. Each cell, apart from the executive row, then represents both a "Thing" and
a "Relationship" (Zachman, 2013).

The Cells (from left to right) are: Inventory Identification (What), Process Identification (How),
Distribution Identification (Where), Responsibility Identification (Who), Timing Identification (When),
Motivation Identification (Why). The cells in row one contain lists. These lists provide a complete
identification of the scope contexts and are therefore called scope identification lists. There are no
Things and Relationships in this row, since a list may give a better overview and is more practical
from the executive perspective.


The cells in the second row contain the business definition models. Every model has a business entity and
a business relationship. The Cells (from left to right) are: Inventory Definition including business entities
and business relationships (What), Process Definition (How), Distribution Definition (Where),
Responsibility Definition (Who), Timing Definition (When), Motivation Definition (Why).

Pg 7
All other rows (3-6) are built like row 2. Zachman gives a very generic definition of the single models,
model names, Things and Relationships (Figure 2). For example, row 2s Motivation Definition, the
why, has a Thing defined as the business end, and a Relationship defined as the business means
(Zachman, 2013).




Pg 8
Extended Enterprise Architecture Framework

The Institute for Enterprise Architecture Developments (IFEAD) developed this Enterprise Architecture
(EA) framework in 2002 as a result of the experience of using other EA frameworks. According to
IFEAD Enterprise Architecture is about understanding the elements that encloses the areas of people,
processes business and technology and how these elements are interdependent on each other. This
approach to EA develops a design for both the business and information parts of an organisation as well
as the supporting IT infrastructure (Institute for enterprise architecture developments, 2006).

The architecture has guidelines, principles and rules for the components the business may be composed
of, how the components fit together, how the components communicate, what assemblies the components
allow, the functions of the components as well as how the style expresses the values of the organisational
stakeholders (Institute for enterprise architecture developments, 2006).

The major principles of an E2A supported by the E2A framework are as follows: the creation and
maintenance of a common vision for both business and IT whilst promoting continuous business and IT
alignment and the creation of a holistic enterprise architecture process that perfectly reflects the business
strategy of the enterprise, the improvement upon the agility of the enterprise by lowering the complexity
barrier and increase the ease with which the enterprise links with external partners, developing an
innovation driven company capable of meeting customer needs whilst outpacing the competition and
preparing the organisation for rapid but unplanned change whilst reducing the risk of doing so, the
avoidance of pitfalls created as a result of conflict between business-unit IT functions, creating a program
of progressive technology refinement and the creation, unification and integration of business processes
across the enterprise, the unification of information silos to make available the full power of information
in the organisation, the elimination of duplicate and overlapping technologies resulting in the lowering of
support cost and the increase in the reuse of technology, information and business applications so as to
reduce solution delivery times and development costs (Schekkerman, 2004).

The approach to EA is holistic in scope and collaboration-based, as such it addresses all facets of the
extended enterprise and input is made by all key stakeholders. The methodology to Enterprise
Architecture is alignment and value driven meaning it addresses the need to directly align technology and
business drivers in a comprehensible and transparent way to all key stakeholders, and it demonstrates the
business value of EA solutions. The approach to EA supports Dynamic Environments which allows
flexible Enterprise Architectures to function seamlessly in the ever changing elements of the environment.
The Enterprise Architecture is able to provide normative results that can be measured, validated and
applied, E2AF uses a nonprescriptive approach to EA (Schekkerman, 2004).

The structure of the E2AF is based four aspects and six abstraction levels. The four aspects; business,
information, information systems and technology infrastructure; are integrated for an EA design
(Schekkerman, 2004).

The business aspect is where the general scope of the architecture is defined, the information aspect is
where information gathering takes place to find out which functions can be automated, if any, and these
Pg 9
functions are implemented in the information systems aspect. Finally, the technology infrastructure aspect
defines the environment that supports the information systems.

The first of the abstraction levels is the contextual level. This gives a description of the context of the
company and the scope of the EA study. Its at this level that the mission, vision, scope and business and
technology drivers are made known. Next is the environmental level; at this level there is a description of
the formal extended business relations and the related information flows. The business and technology
relationships with the extended enterprise is represented here. The next level is the conceptual level;
where the goals, objectives and requirements of the enterprise entities are described. The logical level is
next; where the logical solutions within each aspect area are shown. The penultimate level is the physical
level; where the physical solution of products and techniques are dealt with, as it shows the physical
solutions in each aspect area. Finally, the transformational level deals with a description of the impact that
the proposed solutions will have on the organisation.

The results of the Enterprise Architecture is visualised and communicated to all stakeholders since the
E2A framework is to serve as a guide for all stakeholders involved in the exercise. The E2A approach is
derived from the E2A framework to deal with the objectives and goals of the framework (Schekkerman,
2004).





Pg 10

DoDAF (Department of Defense Architecture Framework)

The DODAF is arranged around a shared repository to hold work products. This repository is defined by
the Core Architecture Data Model, and the DOD Architecture Repository System with the framework as a
whole based around 4 sets of views.

The framework used by the Department of Defense allows different managers in the department to share
data through this repository across the Department, Joint Capability Areas (JCAs), Mission, Component,
and Program boundaries (Department of Defense (A), 2013).

To visualise architectural data, a set of models is used, where a model can be any kind of method for
displaying data in some meaningful way, such as a spreadsheet or dashboard, for example. These are used
as a template to be filled in so that the data inserted is organised and therefore can be better understood.
Data input into one of these models is a view. The following view sets form the Architectural Description
(Department of Defense (A), 2013).

The all view provides descriptions of every part of the architecture, including the architectures scope
and context. An operational view describes the entities required during operation, such as tasks and
information exchanges. The systems view involves graphical and text representations of systems and
their relationships with others. The technical standards view displays all of the standards that should be
adhered to during implementation and the rules in place.

The DOD Enterprise Architecture consists of five reference models that are used to ensure consistency
between the DOD and the Federal Enterprise Architecture. The business/operational reference model
defines common business functions regardless of who carries out the function, since these operations
should be available for collaboration with others. The service component reference model allows for
classification of services by what aspect of the business the perform, so that the services can be reused
across different functions. The technical reference model is a hierarchy of how different technologies
back up the implemented services. For each of the components of the architecture, toolsets and
established products will be included in this view. The data and information reference model defines a
common ground for how data is organised to enable better sharing of information. The performance
reference model provides the means to indicate the performance of the architecture against the goals set
out early in development.

To provide guidance during implementation so that an organisation can guarantee it is following the
correct principles of DoDAF, the documents outline six key steps that enable all of these principles to be
fulfilled (Department of Defense (B), 2013).

The first step is to determine the intended use of the architecture. Here the process owner, such as a
manager in the DoD, will define the purpose of the architecture and how it may be used, and what is
required for the implementation of the architecture (Department of Defense (B), 2013).

The second is to determine the scope of the architecture. This is where the depth and breadth of the
architectural description are defined and the level of detail required (Department of Defense (B), 2013).

The third is to determine the data required to support architecture development. Here the level of detail
required for the architectural data and what type is needed for the future steps of the process (Department
of Defense (B), 2013).
Pg 11

The fourth step is to collect, organise, correlate and store architectural data, where an architect would
have to collect and arrange data in such a way that the framework's views are used to present the data for
use in decision making. This data would need to be stored using some commercial or government tool
(Department of Defense (B), 2013).

The fifth step is to conduct analyses in support of architecture objectives. This step is designed to
determine the extent to which the requirements set out in step one are adhered to by using data analysis.
More requirements can be added to the process at this step also. The guiding principles of DoDAF are
used to validate the success achieved in the architectural development process (Department of Defense
(B), 2013).

The final step is to document results in accordance with decision-maker needs. The underlying
architectural data is arranged into architectural views so that potentially many different types of people
are able to see and understand the data equally well (Department of Defense (B), 2013).



Pg 12
TOGAF (The Open Group Architecture Framework)

The Open Group Architecture Framework more commonly know as TOGAF was developed by the Open
Group in 1995. The Open Group used the Technical Architecture Framework for Information
Management (TAFIM) developed by the Department of Defence as their base for the inspiration in design
of TOGAF. The Open Group is a vendor and technology natural group meaning that it is not biased to
tailor the framework to a specific element within the framework .
(Schekkerman, J., 2004) (The Open Group, n.d.)

The Open Group is currently made up of over 400 members spanning a range of different organizations
and business sectors. This helps further the development of the framework making it suitable for a wider
range of different applications and areas. Currently TOGAF is in its 9th version
(The Open Group, n.d.)

TOGAF is made up of a number of methods and frameworks this providing it with an advantage over
other frameworks by giving it a complete process for the development of a business EA.
(Sessions, R., 2007) (The Open Group - 2, n.d.)

Some of these are: Architectural Development Method, Architecture Content Framework, Enterprise
Continuum and Technical Reference Model.

Architectural Development Method (ADM) provides a tried and tested structure that aids in the
development within the company. This method is made up of eight development stages and one initiation
phase. Each of the stages can be repeated at any time allowing for repeated and incremental development
within the stage.
(The Open Group - 2, n.d.)

The ADM stages are: the Preliminary Phase, Architecture Vision, Business Architecture, Information
System Architectures, Technology Architecture, Opportunities & Solutions, Migration Planning,
Implementation Governance and Change Management. The Preliminary Phase focuses on the initial setup
of the problem and the infrasture required to deal with the development in the design method. The
Architecture Vision focuses on the continued scoping and further investigation. Business Architecture
focuses on investigate into the business current EA (if it has one) and develop the new target architecture
for the business to strive towards. Information System Architectures focuses on two main aspects Data
and Application. The goal of focusing on these aspect is to develop entities that are relevant to the
enterprise architecture meaning that they are free from being tied to a specific system or design.
Technology Architecture creates a technical architecture for the agreed upon architectural vision.
Opportunities & Solutions focuses on developing the solution as to how the current environment will be
changed into the target. This can take place in a number of projects or programs containing detailed
processes and plan specific design to aid in the change.Migration Planning creates a detailed plan for the
implementation of the new framework and migration. Implementation Governance provides and overview
of the implementation that is going to take place. Change Management creates a governing system to
manage the change to the new architecture.
(The Open Group - 2, n.d.)
Pg 13

The Figure below shows how all the stages in the ADM link together into the process flow.


Figure 3: ADM process flow (The Open Group - 2, n.d.)

Architecture Content Frameworks (ACF) is a framework for providing a consistent structure and
presentation of work products. This ensure that the company presents documents such as specification
and design documents in the same and consistent format. There are three main categories for products
within the AC Framework.
These stages are: Deliverables, Artifact and Building Block. Deliverables are form documents that are
agreed upon by stakeholders and contractually binding. Artifact use to describe pieces of work that are
used to describe parts of the architecture. Building Block are items that have been produced that have the
potential to be reused by a number of different areas and so can be used as building blocks to deliver
complete products of work.
(The Open Group - 2, n.d.)

Enterprise Continuum: is a view of the Architecture Repository. This repository show the development of
related architures going from organisation specific to complete generic.

The Technical Reference Model is concerned with the generation of generic services which allows for
more specific components to be built upon these generic services.


Pg 14
Challenges

Adapting to the terminology of an architectural framework is the first challenge an architect faces.
Because of the intentions of architecture frameworks common terms have to be stated in a particular
application context (Ota & Gerz, 2011).

Systems could be made up of subcomponents and can have many interfaces. Formally documenting all
these interfaces is beyond what is possible within an architecture framework. Because of this the architect
has to be particular when choosing what information on interfaces is important for architectural
considerations and what information can be made general (Ota & Gerz, 2011).

Meta models of architecture frameworks define the concepts together with their relationships that could
be used in architectural views. Because of the generic nature of the architectural frameworks meta models
are only made up of core concepts such as service, system and operational node. Any changes to the meta
model would mean more difficulty in reusing an architectural view. Right tool supports can be used to
handle meta model extensions (Ota & Gerz, 2011).

A modelling process is needed when the definition of an architecture is not being handled by a small core
team. The modelling process dictates who provides which views and at what stage and what degree of
detail. All participants need to have a common understanding of this process or else uncoordinated
modelling could result in confusion.
To prevent the outcome of the modelling process from being criticised no matter the outcome, all
stakeholders should be integrated into the modelling process from the very onset (Ota & Gerz, 2011).

Enterprise architectures are not static, they need to be modified to changing constraints and operational
requirements over time. Architectural descriptions also need continual maintenance. The central
architecture repository also needs maintenance so as to be able to facilitate the reuse of architectural
elements. There is therefore the need for a central organization unit whose tasks will be the provision of
methodological support, the enforcement of the enterprise modelling process, adjustment of the enterprise
modelling process, identification of the relationships between different architectures, avoidance of
redundancy among different architectures and the harmonization of views with regard to the level of
abstraction, terminology and structure (Ota & Gerz, 2011).

Another of the main challenges of enterprise architecture development is an architect not having
appropriate levels of sponsorship to be able to perform effectively. This is because, according to Kabai
(2013), an enterprise architect should have three important tools to succeed in the development of an
enterprise architecture: access, leverage and 'goodies'. In some cases, the sponsorship may even need to
be at the executive level, since to have the appropriate access, an architect must be able to communicate
with any required stakeholder.

In terms of leverage, an architect needs to have the relevant authority to make changes where required, so
as to ensure the implementation of a complete solution, rather than stumbling at certain areas as a result of
being unable to make changes.

Pg 15
The 'goodies' referred to by Kabai are items that may not be available under normal circumstances, but an
enterprise architect would benefit greatly from having them during EA development. For example, testing
new technologies, reassigning technology experts based on other's needs and access to new information
early (Kabai, 2013).

Getting the right people to take part in developing the architecture is also a major challenge. According to
Kabai (2013) in many cases the people who have strong technical skills are put forward as enterprise
architects. This could create problems since it is vital that an enterprise architect has a good knowledge of
the business, and they should also be able to communicate effectively with the more business-oriented
people in the organisation, translating the technical aspects into a more understandable format to show
others how the technology affects the business in general.

Another challenge in EA development, as stated by Kabai (2013) and Scott(2010), is a failure to correctly
align the technological aims with those of the business. Even though technological aspects such as
standards and engineering will help to create an architecture that is reusable and more supportable (Kabai,
2013), the whole process could be a waste of time and money if the implemented technologies don't help
move the business forward in some way by fulfilling one of its needs.

Another challenge, as identified by Kabai (2013) is that EA teams may develop the architecture in relative
isolation from the rest of the business, in a type of 'silo'. As Kabai (2013) states, this results in confusion
once the architecture comes to be shown to the more business-oriented people in the organisation, such as
executives, meaning the solution is not accepted by the business due to the complexity and unfamiliarity.

The Zachmans holistic as is approach doesnt implement the description of the process to reach his as
is state. There is no description in Zachman how to reach the as is model. Other EA Frameworks or
methods like Rational Unified Process( RUP) can be used to reach the as is state. But there is no
specification or general advice by Zachmann on how to combine his Framework with others. This open
structure helps keep an holistic view. (see example Figure 2 on Zachmann). Schekkerman.













Pg 16
Best Practises and Example from industry

Each enterprise architecture has its own specific set of best practices. There are however, a number of
generic practices which organisations can follow to get the best out of whichever framework they have
chosen.

The first is you can only move as fast as the business. This highlights to facilitators of the architecture that
no matter how hard they try to push through changes, they will never be able to push a business on to the
next level if it is not ready to move. A business has to evolve at the rate that is best for itself. (Saran,
2010)

The second is delivering a system to the business where the benefits are easily seen and understood..If the
benefits that are going to be delivered are obscure then it is likely that some parts will not fully invest in
developing and fulling the project to the highest possible standards. This would result in the project being
a waste of time and changes failing to happen, resulting in the step needing to be repeated, wasting time
and valuable budget.(Saran, 2010)

The third is make sure the company retains their technical staff if they have outsourced the development
to allow for analyze of the system that the outsource is proposing. Outsourcing to other companies
requires a level of trust in what the company is going to deliver. If the system proposed requires a lot of
change within the companys current system then it might be unfeasible to implement the new proposed
system. Without the technical staff the company would be unable to make a sound judgement or have to
knowledge to know what would be required for the change. (Saran, 2010)

The fourth is that the enterprise architecture can only successfully work if the corresponding IT is at the
right level of maturity for the architecture. EA depends completely on the underlying system to allow for
successful implementation. A company could have a game changing EA but without the correct
underlying IT it would be useless.(Saran, 2010)

The more specific best practices for the Zachman framework are:
The rows on top are very abstract and incomplete but become far more specific and detailed on the
bottom. This is because in the implementation process top rows are used early to define e.g. a product.
Since the planning must be agile and react to issues fast, it is necessary to keep the top rows unspecific.

The bottom rows are used later in the implementation process of e.g. a product so they are more specific
and detailed. Also this scheme allows continuous integration of new requirements in the planning and for
maximal agility.

Furthermore this practice is enhanced by the fact, that the two top rows are business orientated while the
bottom 4 rows are technical orientated. Practical implementation is the last step in this framework.

Business concepts from top must match business objectives and components in the bottom. Concepts can
change and be modified but the relationships should stay the same. By implementing this component,
there is a check if the requirements have been fulfilled.
Pg 17

The order of the columns can be arranged as needed. e.g. in object orientated design the first column
should be why (requirements) and then who (actors).

Since it is an EA Framework, the top instance can be used to represent the whole enterprise modeling
while in another case the Framework can be used on Project or Enterprise division level.

The aim of the Zachman Framework is that it can be used to solve a complex problem by breaking the
problem down into small pieces. One Framework can be used and combined with other Frameworks to
solve enterprise issues of all kinds. The following example is from IBM and it shows how an agile
development Method (RUP) can be combined with the Zachman Framework (Schekkerman,2004).

Procedural and Object-Oriented software projects can be released with this Framework. The RUP Model
on specific projects can be implemented easily in the enterprises Zachman framework just to show how
the Zachmans Framework can be integrated. (Temnenco, 2006).

This IBM paper shows, that there are several advantages by doing so like e.g. the possibility to implement
fragments of previous projects in new ones and to prevent errors on similar projects.
The only problems that software developers may face are homemade but often easy to solve. A reason for
failing in the implementation of RUP is that existing RUP-artifacts are hybrids of several different
Zachmann cells. Another reason is that the artifacts are often created using different notations.

It is very comfortable to transfer artifacts from project to business levels. Unfortunately iteration/activity
events can't be mapped properly in the Zachman Framework.
Figure 4 shows a possible iterative implementation of RUP artifacts in a Zachman framework.

Figure 4: Zachman and RUP (Rational Unified Process)(Temnenco, 2006)
Pg 18
Recommendations

Many software developers may neglect enterprise architecture until it is too late. The complexity and
therefore risk of their own projects may bring them a lot of problems. So the organization needs to
introduce a cross-system and cross-project issue which will help to solve EA Framework solutions.
The advantage of Zachman is, to manage artifacts produced by projects. These artifacts can be used to
reduce business risk and solve problems in projects by introducing common models. Any EA Framework
implementation will improve interaction between enterprise and project teams in general, both groups will
benefit (Temnenco, 2006).

There isn't something like the ultimate EA Framework solution, but (Figure 4) shows what can be
achieved by implementing the Zachman Framework on project level. It is very unlikely that projects
architects and developer teams will have more conflicts when it comes to implementation if a general
cross-project and cross-enterprise implementation of standards through the Zachman Framework has been
done. In fact, through general notification the numbers of conflicts will decrease. This is the reason why
the Zachman Framework is the most used EA Framework and its usage is steady growing in industry,
even if it isnt really a EA Framework (IFEAD survey). Based on the challenges, it is important, that
taxonomy and process completeness are approached by the EA Framework solution. Therefore the
solution can be a hybrid of different EA Frameworks, to find the best approach to challenges to enterprise
may face.

Scale (1-4) on Zachman & TOGAF Challenges (Sessions, R., 2007)
Table 1: Criteria and ratings for each methodology

We recommend a blended methodology of Zachman as the ontology with TOGAF as the underlying
process for carrying out the EA. Since the requirement is to find an appropriate approach for an enterprise
architecture development level on a corporate federated enterprise the Zachmans Framework should be
used on an enterprise level to make sure the holistic view is implemented and to guarantee a constant
check of requirements and their implementation.

Pg 19
Therefore the first six cells (row one) are the most important, these lists can ensure an holistic approach
on the future planning and that every relevant point of view is implemented. The other cells can be used
to check if the implementation of the aims is fulfilled.

The problem is that this as is state defined by Zachman must be reached. The Zachman Framework fails
in terms of describing and planning processes, therefore we use the TOGAF as an approach to implement
dynamic realization of projects and aims to reach the as is state advised by Zachman (see table
Zachman TOGAF challenges). The Zachman Framework is the taxonomy, the TOGAF is the process.
Combining both Frameworks is our basic approach.

The TOGAF ADM provides a complete process from which the organisation can successfully implement
the required changes. This complete process is an essential base to the taxonomy. TOGAF has a very well
thought out structure due to the large group that helped to develop it. This has allowed for a full process
to be developed and has given TOGAF a major advantage. The only down side that TOGAF has is that it
lacks a completer maturity model. (Sessions, R., 2007)

Therefore multiple Frameworks on multiple levels should be implemented. One Zachman/TOGAF
hybrid on enterprise level. One on divisions level. The projects can be handled with the Zachman/TOGAF
hybrid or with a complete new hybrid like the Zachman/RUP if this fits better to the requirements of the
project. Projects should be approached in an agile way, so the Zachman Framework can be combined with
any process Framework fitting the project requirements.
Table 2. (What framework is used how often) shows that the Zachman is very common and often
combined with others as hybrids (Organisation own). Therefore our approach is fitting the industry
trend (Table 2). Figure 4 furthermore shows that an hybrid Zachman Framework (e.g. with RUP) is an
appropriate ISA/EA development approach.


Table 2: Popularity of EA Frameworks
Pg 20

By an iterative implementation of the Zachman + (TOGAF/....) hybrids on different levels it is assured,
that the rightful implementation of the requirements can be checked periodically.

A general model for our approach could be a dynamic n-stage model based on the complexity of the
enterprise (table 3).


Table 3: General implementation of EA Frameworks solution; a holistic & dynamic approach

Table 3 shows a possible various level approach for a large scale implementation of a Zachman
Framework solution in a corporate federated enterprise. Other approaches are possible, especially on
Level n (the project level). Therefore it is absolutely necessary to check requirements and individual
challenges of the enterprise/division/team/project,... level with the possible benefits of the chosen
Framework.
List of Tables

Table 1: Criteria and ratings for each methodology
Table 2: Popularity of EA Frameworks
Table 3: General implementation of EA Frameworks solution




List of Figures
Figure 1: System thinking diagram
Figure 2: Zachman matrix
Figure 3: ADM process flow
Figure 4: Zachman and RUP
Pg 21
References

atb-bremen, 2006. atb-bremen. [Online]
Available at: http://atb-bremen.eu/projects/prosme/Doku/oqim/pera_old.htm
[Accessed 27 October 2013].

Saran, C., 2010. Computer Weekly. [Online]
Available at: http://www.computerweekly.com/news/2240104534/Case-study-Enterprise-
architecture-at-Syngenta
[Accessed 1 November 2013].

Coetzee, F., 2009. Xpdian. [Online]
Available at: http://xpdianea.blogspot.co.uk/2009/08/brief-history-of-enterprise.html
[Accessed 3 November 2013].

Institute for enterprise architecture developments, 2006. Extended Enterprise Architecture
Framework Essentials Guide v 1.5. s.l.:The Institute For Enterprise Architecture Developments
(IFEAD).

Op't Land, M. et al., 2009. Definitions of Enterprise Architecture. In: Enterprise Architecture;
creating Value by Informed Governance. s.l.:springer, pp. 32-34.

Ota, D. & Gerz, M., 2011. Benefits and Challenges of Architectural Frameworks. Quebec,
Fraunhofer FKIE, pp. 7-14.

Schekkerman, J., 2004. How to survive in the jungle of Enterprise Architecture Frameworks.
s.l.:Trafford Publishing.

Sessions, R., 2007. Microsoft Developer Network. [Online]
Available at: http://msdn.microsoft.com/en-us/library/bb466232.aspx
[Accessed 3 November 2013].

Temnenco, V. (2006, November 15). Developer works. Retrieved November 8, 2013,
from IBM web site: http://www.ibm.com/developerworks/rational/library/nov06/temnenco/
Wu, J., 2007. IToolbox. [Online]
Available at: http://blogs.ittoolbox.com/print.asp?i=15973
[Accessed 3 November 2013].

Zachman, J. P. (2013, November 8). Zachman International. Retrieved November 8,
2013, from Zachman International Web site: http://www.zachman.com/ea-articles-
reference/54-the-zachman-framework-evolution


Pg 22
Zachmans Informaion System Architecture. (2003, October 21). Retrieved October
2013, from Archive.org web site:
http://web.archive.org/web/20031021175853/http://www.isqa.unomaha.edu/vanvliet/arch
/ISA/isa.htm

The Open Group, n.d. The Open Group. [Online]
Available at: http://www.opengroup.org/aboutus
[Accessed 28 October 2013].

The Open Group - 2, n.d. Core Concepts: TOGAF Version 9.1 Architecture. [Online]
Available at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/
[Accessed 28 October 2013].

Department of Defense (A), 2013. Department of Defense Architecture Framework V2 -
Background. [Online]
Available at: http://dodcio.defense.gov/dodaf20/dodaf20_background.aspx
[Accessed 10 11 2013].

Department of Defense (B), 2013. Department of Defense - Architecture Development.
[Online]
Available at: http://dodcio.defense.gov/dodaf20/dodaf20_arch_development.aspx
[Accessed 10 11 2013].