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 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.

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.

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.

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.