Framework and Methodology

According to Bernard (Bernard 2004) then a Chief Enterprise Architect or what equals to an Enterprise Architecture program manager is selected then the definition of the EA framework and the EA methodology becomes a necessity.

The Definition of the EA Framework

An EA framework is dealing with what the EA program will document.

The Definition of the EA Methodology

The EA methodology deals with how the Enterprise Architecture documentation is articulated and used.

The EA Cube and its Construction

The simple edition of the EA cube that explains the various components, and layers within the framework.

The EA3 Cube.

The Documentation Process

There are six steps that needs to be gone through according to Bernard (Bernard 2005, p. 97):

• The process includes a framework.

• The process includes the components.

• The process includes the current architectural views.

• The process includes future architectural views.

• The process deals with the transition plan for going from “TO BE” and the “AS IS” architecture.

• The process deals with threads that influence the enterprise architecture on all levels.

A Comparison of EA Frameworks

Zachman’s Framework

The foundation of the EA Framework is John Zachman’s Framework. It was originally based on an approach that it could be explained and dealt with as if you had to build an airplane or a house. The blueprint analogy was used to articulate the framework.

Zachman's Framework (According to Bernard)

In general there is one single mistake that the Enterprise Architect can do when working with the Zachman framework and that is to focus too much on documentation. This is known as the “Zachman Trap”.

OIO IT Architecture Framework

The OIO framework (based on the white book on IT architecture) was developed for the Danish Ministry of Science. Its focus is on the Danish Public sector. The intention was to implement Enterprise Architecture to give the decision makers in the Public Sector a better foundation for how the single organizational entities operates.

From a management perspective the idea was to enable the public sector to standardize and centralize processes and decision making.

The OIO framework is based on the same paradigm as the EA 3 Cube by John Zachman.

The OIO-Framwork (The Two Main Processes).

As the illustrated above then there can be defined a governance process and a documentation process.

The two circles represent activities used to deal with updating and developing the architecture. The circle located in the bottom of the third illustration deals with the process of the “AS IS” and this is connected to the process of creating a vision, a business architecture, information architecture and the technical architecture.

The OIO-framework is often criticized for being to comprehensive and often the Enterprise Architects have to invest too much of their time to identify artifacts on various levels and organizing the artifacts according to the OIO-framework. Secondly it has been some time since the last edition of the framework was revised which might be an indicator for that the Danish Public sector is either static in its development or that the state plans to release a new edition of the framework or an entirely new framework. In the other hand the OIO-framework has an entire section dealing with defining and identifying architects which in my opinion is a strength by using the OIO-framework since it enables the Chief Enterprise Architect to communicate to the stakeholders who have what abilities, responsibilities and not to mention accountability during the Enterprise Architecture process.

The EA 3 Cube

The EA 3 Cube was developed in 2004. The Framework is designed as a cube and it is build upon the idea that hierarchies are needed to avoid sub-architectures (Bernard 2004, pp. 104 – 105).

According to Bernard then the business goals are the drivers of how the Enterprise Architecture is designed.

The EA 3 Cube is based on the primary function of organize and planning IT resources and documentation of the Enterprise Architecture. (Bernard 2004, p. 105).

The framework is build upon five levels and as before mentioned these are hierarchical to avoid sub-architectures.

The Five Layers of the EA 3 Cube

1. Goals and Initiatives is as before mentioned the driving force of the Enterprise Architecture and therefore are these located in the top of the cube (as the first and primary layer).

2. Products and services shows how Information Technology impacts the various products and services.

3. Data and Information is used to document how the Enterprise makes use of information “AS IS” and how the information flow should be designed for future situations “TO BE”.

4. Systems and Applications is used to organize and group the various information systems that give the organization its IS capabilities.

5. Networks and Infrastructure deals with the so called backbone of the Enterprise Architecture and it includes how the networks interact and how various technologies interact such as VOIP and LAN, WAN etc.

The EA3 Cube.

Lines of Business (LOBs) that can be considered as a specific activity within the organization and all the have all the five layers of the architecture. The LOBs are named “Vertical Mission Areas”. The LOBs can have their own administration and functions that can be considered divisions within the divisionalized organization.

Crosscutting Components are established so the LOBs don’t create redundant features e.g., e-mail hosting and IT services.

Threads are defined as security, standards and workforce. These three threads go through each level of the framework.

Conclusion

These three frameworks are all located within the same paradigm and are therefore compatible with one another; however in some situations it will be better to choose the one of the frameworks over the other e.g., if analyzing an Enterprise Architecture for a public institution in Denmark then it recommendable to make use of the OIO-framework.

The frameworks have their strengthens and their weaknesses such as the Zachman framework that focus too much on documentation instead of changing the Enterprise Architecture from the “AS IS” stage to the “TO BE” stage. Likewise does the EA3 framework and the EA 3 Cube some benefits and advantages. E.g., is the EA3 Cube a rather simple framework and is therefore easily applied to small and medium sized organizations. In the other hand it tends to be a bit simple and generic which can end up being a disadvantage.

The Coherency Architect should therefore emphasize on choosing the right framework for the right situation and the right type of organization by using a SWOT – matrix or other form of matrix that can assist him or her with making the right choice.

Sources

Bernard, S.A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.

]]> http://coherencyarchitect.com/2010/05/07/enterprise-architecture-frameworks-a-comparison-of-ea-3-oio-and-zachman/feed/ 0 coherencyarchitect The EA3 Cube Zachman's Framework (According to Bernard) Strategy Process. The EA3 Cube http://coherencyarchitect.com/2009/09/21/alignment-an-art-or-a-science/ http://coherencyarchitect.com/2009/09/21/alignment-an-art-or-a-science/#comments Mon, 21 Sep 2009 10:44:58 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=24 ]]> Currently there are several different ideas on how to align the organization with technology (IT), organization and processes to make the organization able to work smarter. However in the real world a lot of IT projects and attempts to apply alignment of IT in organizations leads to failure.

To avoid potential failures then the members of the Enterprise Architecture community have developed several frameworks which might be applied to make the EA projects work and yet the projects fail in the organizations that claim to be mature.
The question is if the alignment of IT and Business is a science or if it is an art form. Some CIOs, CXOs, teams and organizations are simply just better to apply EA thinking (models, foundations, process management etc.) than others though they make use of the exact same principles which founds the platform for Enterprise Architecture.

So talent has to be a part of the equation or even luck has to be a part of the EA. Science normally don’t think on luck or talent when research and science is done (especially if it is from the point of view of natural sciences) and therefore these factors are overlooked or simply not put into consideration.
The Alignment of IT with the business side has to be considered both an art form and a science since the science part shows how alignment is supposed to be done and where the art is when those people who are about to implement the alignment does apply the implementation.

As it is with Coherency Management then people is key since it is people who work with the systems which are supposed to be aligned, people who takes the decisions and people who implement the processes beneath the alignment projects. It is easily concluded that people are different they have different world views, different ways to interact and they are different in the way they use tools to aid them in achieving their goals. Alignment of IT is dependent on how people react to changes and how people interact with one another and with the technology and the information systems and therefor is the art form a very dominant but the science form can’t be neglected since the science crystallize and defuse the ideas of alignment, enterprise architecture and coherency management. Therefore is alignment of IT both a science and an art form.