cancel
Showing results for 
Search instead for 
Did you mean: 

Origins of Enterprise Architecture Frameworks

Origins of Enterprise Architecture Framework.jpg
9523
0

All this complexity, risk, and opportunity needs to be intimately understood as it relates to business. That is precisely how enterprise architecture came to be. Enterprise Architecture (EA) was born out of the need to manage complexity by organizing the business, or enterprise, into comprehendible views that provide visibility into how the components of the enterprise were connected and worked together.

The problem with enterprise architecture as a concept was that there needed to be some way to organize, classify or catalog these components. This taxonomy, or ontology, not only needed to be comprehensive, it needed to be scalable, and more importantly, portable. In other words, businesses didn’t want to completely “reinvent the wheel” every time there was a change in the market, the operating model, or even a change in employees. What was needed was a framework.

What is An Enterprise Architecture Framework?

The formalization and codification of Enterprise architecture into a framework includes the description of the object using terms and concepts that make up the business. The framework also includes the definitions of those terms or concepts; a taxonomy, which categorizes those terms or concepts; a method, which describes the use of this taxonomy; enablers or capabilities, which define how these concepts and method are implemented; and objectives or outcomes of these implementations.

This collection of management tools, processes, components and key performance indicators (KPIs) makes it possible to render the enterprise using comprehendible, digestible views thereby enabling the business to see itself as it is, as it could be, and how it progresses to the anticipated future state. The framework provides the mechanism and the rules for how components are connected and interact as well as how these connections are presented for consumption for decision-makers. The framework ensures consistency and reliability so that decision-makers not only know how they can consume this information, but that they can trust in the validity of the data.

Choosing an Enterprise Architecture Framework

With the need for an EA framework understood, the question becomes: “what Enterprise Architecture framework to adopt”? understanding the evolution of EA frameworks will provide some context for better making that decision.

The Godfather of Enterprise Architecture

When the topic of EA frameworks comes up, all EAs pay homage to the pioneer of EA frameworks, John Zachman, who in 1987 while working at IBM*, developed the Zachman Framework. The Zachman Framework is really more of an ontology than a framework, but it is the go-to for the classification of descriptive representations (models) that constitute the enterprise architecture. The classification uses the six primitives (who, what, why, when, where, and how) to describe these models.

Later, in 1990, John Zachman teamed up with Samuel Holcman where they founded the Zachman Institute for Framework Advancement. In 2008 this institute was dissolved, Samuel Holcman went on to found the Enterprise and Business Architecture Center of Excellence, and John Zachman, in 2012, acquired the FEAC Institute where he incorporated executives from the Zachman Institute, the Federal Enterprise Architecture Framework (FEAF), the Finnish Enterprise Architecture Framework (FEAR), and the Department of Defense Architecture Framework (DODAF).

The Most Popular Enterprise Architecture Framework to Date

Over the last thirty years, one Enterprise Architecture framework has risen to become the most popular EA framework. That framework is The Open Group Architecture Framework, or TOGAF. The Open Group was formed in 1988 as a result of the merger of The Open Software Foundation and X/Open Company. The mission was to form a consortium that seeks to enable the achievement of business objectives through the development of open, vendor-neutral technology standards. The Open Group grew to over 650 active members who create standards for the field of computer engineering. Through this effort the Open Group created ArchiMate, a model that breaks down systems into active structures, passive structures or behaviors.

TOGAF is currently in its tenth version, but the most widely recognizable feature of The Open Group’s TOGAF is the ADM, or Architecture Development Model. This model uses a cyclical approach to the development of an architecture. The cycle consists of developing a vision; defining the business, application, data, and technology domains; planning; managing change; deploying; and governing the architecture while maintain the requirements as a central focal point. The ADM outlines and classifies specific deliverables associated with each of the phases.

Other Common Frameworks

There are many Enterprise Architecture Frameworks, but some popular frameworks over time include:

  • Spewak Model – developed by Steven Spewak in 1992. Spewak defined EA planning as the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures. Spewak focused on the business implications of architecture planning. The business mission was the primary driver, followed by the data required, applications that use the data, and the technology used to implement the applications.
  • Merise Model – The French Merise model defines a conceptual model of analysis, design and management of IT projects. It was widely used in the 1970s and 1980s to support the computerization of businesses. Merise treats data ad processes separately. Data is modeled in three stages: conceptual, logical, and physical. Process views follow three stages as well: conceptual, organizational, and operational. These stages in the modeling processes are paralleled by the stages of the lifecycle: strategic planning, preliminary study, detailed study, development, implementation, and maintenance. Merise is a model based on entity relationship.
  • Unified Modeling Language (UML) – UML was developed in 1994-1995 by Grady Booch, Ivar Jacobson, and James Rumbaugh. UML was adopted by the Object Management Group in 1997 and published by the International Organization of Standards (ISO) as an approved ISO standard in 2005. UML is a general purpose, developmental modeling language that aims toward a standard way to visualize the design of a system.
  • MEGA EA Grid – Mega has developed it own framework of concepts known as the EA Grid, which preserves the Merise system and declines it in the different layers of the company. The EA Grid is also inspired by the UAF model.

There are many other frameworks: DODAF, The Common Approach, FEAF, MODAF, DNDAF, NAF, and UAF to name a few. Each of these has specific orientation and is used by organizations to accomplish a standardized, consistent approach to developing an enterprise architecture that is consumable by the business or organizations they support.

Business Specific Frameworks

Every industry vertical has its own specificities, and not surprisingly, there are frameworks that address EA for these. ACORD (Association for Cooperative Operations Research and Development) is specific to the insurance industry. BIAN (Banking Industry Architecture Network) is specific to banking, MMOSA for manufacturing and on and on.

One organization that is focused specifically on business architecture and the development of reference models for common areas that span all industries as well as industry-specific reference models is the Business Architecture Guild (The Guild). The Guild developed the Business Architecture Body of Knowledge (BIZBOK) which provides a comprehensive framework for business architecture in general as well as basic, industry-specific reference models that are easy to implement.

What to do with this Information on Enterprise Architecture Frameworks

Creating an enterprise architecture is an arduous task, but it can be facilitated by using an Enterprise Architecture framework, but very few companies actually deploy a complete EA framework. Due to the exhaustive nature of these frameworks, implementing a complete framework is expensive and resource intensive. Not only must the framework be implemented, it must be maintained. For these reasons, most companies adapt a framework, or even cobble together parts of different frameworks in order to meet the needs of their business and provide value. In these cases, EA frameworks are used more as guidelines instead of rigorous standards and practices.

Selecting the right framework concepts or practices is important in ensuring that the company will get value from enterprise architecture, and that practitioners will utilize the framework. Understanding the context behind EA frameworks in important in helping to make that decision.

Knowing how Enterprise Architecture frameworks progressed to where they are now, their strengths and weaknesses, and how the strengths of each one can best be applied will provide information that will allow businesses to adopt or adapt an EA framework that will provide the complete visibility needed to help the business manage the complexity inherent in business today. 

 

Read the next article of this serie: Moving Enterprise Architecture Frameworks into the Future

 
9523
0
Comment
MEGA

All this complexity, risk, and opportunity needs to be intimately understood as it relates to business. That is precisely how enterprise architecture came to be. Enterprise Architecture (EA) was born out of the need to manage complexity by organizing the business, or enterprise, into comprehendible views that provide visibility into how the components of the enterprise were connected and worked together.

The problem with enterprise architecture as a concept was that there needed to be some way to organize, classify or catalog these components. This taxonomy, or ontology, not only needed to be comprehensive, it needed to be scalable, and more importantly, portable. In other words, businesses didn’t want to completely “reinvent the wheel” every time there was a change in the market, the operating model, or even a change in employees. What was needed was a framework.

What is An Enterprise Architecture Framework?

The formalization and codification of Enterprise architecture into a framework includes the description of the object using terms and concepts that make up the business. The framework also includes the definitions of those terms or concepts; a taxonomy, which categorizes those terms or concepts; a method, which describes the use of this taxonomy; enablers or capabilities, which define how these concepts and method are implemented; and objectives or outcomes of these implementations.

This collection of management tools, processes, components and key performance indicators (KPIs) makes it possible to render the enterprise using comprehendible, digestible views thereby enabling the business to see itself as it is, as it could be, and how it progresses to the anticipated future state. The framework provides the mechanism and the rules for how components are connected and interact as well as how these connections are presented for consumption for decision-makers. The framework ensures consistency and reliability so that decision-makers not only know how they can consume this information, but that they can trust in the validity of the data.

Choosing an Enterprise Architecture Framework

With the need for an EA framework understood, the question becomes: “what Enterprise Architecture framework to adopt”? understanding the evolution of EA frameworks will provide some context for better making that decision.

The Godfather of Enterprise Architecture

When the topic of EA frameworks comes up, all EAs pay homage to the pioneer of EA frameworks, John Zachman, who in 1987 while working at IBM*, developed the Zachman Framework. The Zachman Framework is really more of an ontology than a framework, but it is the go-to for the classification of descriptive representations (models) that constitute the enterprise architecture. The classification uses the six primitives (who, what, why, when, where, and how) to describe these models.

Later, in 1990, John Zachman teamed up with Samuel Holcman where they founded the Zachman Institute for Framework Advancement. In 2008 this institute was dissolved, Samuel Holcman went on to found the Enterprise and Business Architecture Center of Excellence, and John Zachman, in 2012, acquired the FEAC Institute where he incorporated executives from the Zachman Institute, the Federal Enterprise Architecture Framework (FEAF), the Finnish Enterprise Architecture Framework (FEAR), and the Department of Defense Architecture Framework (DODAF).

The Most Popular Enterprise Architecture Framework to Date

Over the last thirty years, one Enterprise Architecture framework has risen to become the most popular EA framework. That framework is The Open Group Architecture Framework, or TOGAF. The Open Group was formed in 1988 as a result of the merger of The Open Software Foundation and X/Open Company. The mission was to form a consortium that seeks to enable the achievement of business objectives through the development of open, vendor-neutral technology standards. The Open Group grew to over 650 active members who create standards for the field of computer engineering. Through this effort the Open Group created ArchiMate, a model that breaks down systems into active structures, passive structures or behaviors.

TOGAF is currently in its tenth version, but the most widely recognizable feature of The Open Group’s TOGAF is the ADM, or Architecture Development Model. This model uses a cyclical approach to the development of an architecture. The cycle consists of developing a vision; defining the business, application, data, and technology domains; planning; managing change; deploying; and governing the architecture while maintain the requirements as a central focal point. The ADM outlines and classifies specific deliverables associated with each of the phases.

Other Common Frameworks

There are many Enterprise Architecture Frameworks, but some popular frameworks over time include:

  • Spewak Model – developed by Steven Spewak in 1992. Spewak defined EA planning as the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures. Spewak focused on the business implications of architecture planning. The business mission was the primary driver, followed by the data required, applications that use the data, and the technology used to implement the applications.
  • Merise Model – The French Merise model defines a conceptual model of analysis, design and management of IT projects. It was widely used in the 1970s and 1980s to support the computerization of businesses. Merise treats data ad processes separately. Data is modeled in three stages: conceptual, logical, and physical. Process views follow three stages as well: conceptual, organizational, and operational. These stages in the modeling processes are paralleled by the stages of the lifecycle: strategic planning, preliminary study, detailed study, development, implementation, and maintenance. Merise is a model based on entity relationship.
  • Unified Modeling Language (UML) – UML was developed in 1994-1995 by Grady Booch, Ivar Jacobson, and James Rumbaugh. UML was adopted by the Object Management Group in 1997 and published by the International Organization of Standards (ISO) as an approved ISO standard in 2005. UML is a general purpose, developmental modeling language that aims toward a standard way to visualize the design of a system.
  • MEGA EA Grid – Mega has developed it own framework of concepts known as the EA Grid, which preserves the Merise system and declines it in the different layers of the company. The EA Grid is also inspired by the UAF model.

There are many other frameworks: DODAF, The Common Approach, FEAF, MODAF, DNDAF, NAF, and UAF to name a few. Each of these has specific orientation and is used by organizations to accomplish a standardized, consistent approach to developing an enterprise architecture that is consumable by the business or organizations they support.

Business Specific Frameworks

Every industry vertical has its own specificities, and not surprisingly, there are frameworks that address EA for these. ACORD (Association for Cooperative Operations Research and Development) is specific to the insurance industry. BIAN (Banking Industry Architecture Network) is specific to banking, MMOSA for manufacturing and on and on.

One organization that is focused specifically on business architecture and the development of reference models for common areas that span all industries as well as industry-specific reference models is the Business Architecture Guild (The Guild). The Guild developed the Business Architecture Body of Knowledge (BIZBOK) which provides a comprehensive framework for business architecture in general as well as basic, industry-specific reference models that are easy to implement.

What to do with this Information on Enterprise Architecture Frameworks

Creating an enterprise architecture is an arduous task, but it can be facilitated by using an Enterprise Architecture framework, but very few companies actually deploy a complete EA framework. Due to the exhaustive nature of these frameworks, implementing a complete framework is expensive and resource intensive. Not only must the framework be implemented, it must be maintained. For these reasons, most companies adapt a framework, or even cobble together parts of different frameworks in order to meet the needs of their business and provide value. In these cases, EA frameworks are used more as guidelines instead of rigorous standards and practices.

Selecting the right framework concepts or practices is important in ensuring that the company will get value from enterprise architecture, and that practitioners will utilize the framework. Understanding the context behind EA frameworks in important in helping to make that decision.

Knowing how Enterprise Architecture frameworks progressed to where they are now, their strengths and weaknesses, and how the strengths of each one can best be applied will provide information that will allow businesses to adopt or adapt an EA framework that will provide the complete visibility needed to help the business manage the complexity inherent in business today. 

 

Read the next article of this serie: Moving Enterprise Architecture Frameworks into the Future