Enterprise Architecture Frameworks, Origins, and Evolution

Marketing that product, collecting payment, reporting, and complying with whatever relevant regulations are individually complex. 

Assemble these actions into a chain, and the complexity increases exponentially. What happens when digital disruption, market fluidity, cybersecurity, global reach, and ever-changing regulatory requirements are introduced? 

All this complexity, risk, and opportunity must be intimately understood in terms of business. That is precisely how enterprise architecture came to be.  

Enterprise Architecture (EA) evolved from the need to manage complexity in organizing the business, or enterprise, through comprehensive perspectives that provided visibility into how the enterprise components were connected and co-operated. 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, must be comprehensive, scalable, and, more importantly, portable. In other words, businesses didn't want to completely "reinvent the wheel" every time the market, the operating model, or even the employees changed.  

Digital transformation, technology disruption, and business agility in enterprises today have forced frameworks and enterprise architecture to evolve. 

What is an Enterprise Architecture Framework? 

An enterprise architecture framework defines an enterprise's structure, governance, and operations.  
It is a tool for enterprise architects to plan and execute enterprise-wide digital transformation initiatives and guides architecture development over time. 

The main components of an enterprise architecture framework are: 

• A business model that outlines the goals and objectives of the enterprise  
• A set of principles that guide decision-making  
• A set of architectural patterns that guide how to design and implement solutions  
• A set of tools and techniques for managing enterprise architecture. 

The framework also includes for each architecture layer the following: 

• A clear statement of the problem to be addressed. 
• An identification of the key stakeholders. 
• An overview of possible solutions. 
• Evaluate the costs, benefits, and risks associated with each answer. 

For instance, the business architecture framework includes the description of the object employing terms and concepts that define the business.

• A taxonomy that categorizes those terms or concepts 
• A method that describes the use of that taxonomy  
• A shared vocabulary, enablers, or capabilities that define how these concepts and methods are implemented 
• And objectives or results of those implementations.  

The management toolset includes tools, processes, components, and key performance indicators (KPIs). That allows the enterprise to be represented in comprehensive and tangible visions, allowing it to see itself as it is, as it could be, and how it is progressing toward the envisioned future state. 

The framework provides the mechanism and rules for connecting and interacting with the components and presenting these connections to decision-makers.  

The framework ensures consistency and reliability so that decision-makers know how to use this information and can confidently rely on the data's validity. 

Benefits of an Enterprise Architecture Framework 

The benefits of using such a framework include the following:  

• Improved communication and collaboration among stakeholders 
• Better alignment of IT with business goals 
• More efficient and effective use of resources 
• Reduced risk and increased agility 
• Improved decision-making and 
• Improved governance.

A Comparison of Enterprise Architecture Frameworks 

There are four main enterprise architecture frameworks: The Open Group Architecture Framework (TOGAF), the Zachman Framework, the Software Engineering Institute's Capability Maturity Model Integration (CMMI), and DoDAF. 

Frameworks tend to favor an academic approach that is not sufficiently focused on delivering results quickly that meet business expectations. 

In many organizations, EA teams that focus on specific use cases, such as application portfolio rationalization, cloud migration, or introducing new products/services, are often more recognized than those that try to apply a framework academically.  

With the need for an EA framework understood, the question becomes: "What Enterprise Architecture framework should we adopt?" Understanding the evolution of EA frameworks will provide context for better decision-making. 

Types of enterprise architecture framework 

There are various enterprise architecture frameworks, such as Zachman Framework, TOGAF, FEAF, and DoDAF. The Zachman Framework is a classification system that comprehensively covers all aspects of an enterprise. TOGAF is an open-source framework that helps organizations develop and use an enterprise architecture. FEAF helps organizations develop a high-level view of their IT system, while DoDAF provides the structure for organizing data into actionable information. All these frameworks can be used together or separately to optimize the performance of an organization’s IT systems. 

Zachman Framework: 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 developed the Zachman Framework in 1987 while working at IBM*. The Zachman Framework is more of an ontology than a framework, but it is the go-to for classifying 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, and 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. In 2012, John Zachman 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 / DOD Architecture framework). 

What is TOGAF Framework? 

Over the last thirty years, one Enterprise Architecture framework has become the most popular EA framework. That framework is The Open Group Architecture Framework or TOGAF.  

Structure - TOGAF Architecture Development Method 

The Open Group was founded in 1996 to form a consortium that seeks to enable the achievement of business goals through the development of open, vendor-neutral technology standards.  

The Open Group grew to over 650 active members, who create standards for computer engineering. Through this effort, they developed ArchiMate, a model that breaks down systems into dynamic structures, passive structures, or behaviors. ArchiMate provides a common language for describing, analyzing, and visualizing the relationships between the elements of an enterprise architecture.

Different versions of The Open Group Architecture Framework 

TOGAF is currently in its 10th Edition, but the ADM, or Architecture Development Model, is the most widely recognizable feature of The Open Group's TOGAF. This model uses a cyclical approach to the development of 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 maintaining the requirements as a central focal point. The ADM outlines and classifies specific deliverables associated with each of the phases. 

Other examples of 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 to use the information to support 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 IT project analysis, design, and management model. Merise was widely used in the 1970s and 1980s to support the computerization of businesses. Merise treats data ad processes in three stages: conceptual, logical, and physical. Process views also follow three phases: 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 its framework of concepts known as the EA Grid, which preserves the Merise system and declines it in the different layers of the company. The UAF model also inspires the EA Grid. 

Many other frameworks exist, such as DODAF, The Common Approach, FEAF, MODAF, DNDAF, NAF, and UAF. Each has a specific orientation and is used by organizations to accomplish a standardized, consistent approach to developing an enterprise architecture consumable by the business or organizations they support. 

Specific Business Architecture Frameworks 

Every industry vertical has its specificities, and not surprisingly, some frameworks address EA for these. ACORD (Association for Cooperative Operations Research and Development) is insurance industry-specific.  

BIAN (Banking Industry Architecture Network) is specific to banking, MIMOSA for manufacturing, etc. 

The Business Architecture Guild (The Guild) is an organization focused specifically on business architecture and developing reference models for common areas that span all industries and industry-specific reference models.  

The Guild developed the Business Architecture Body of Knowledge (BIZBOK), which provides a general and basic framework for business architecture. These industry-specific reference models are easy to implement. 

Why do we need Enterprise Architecture Frameworks?  

 Creating an enterprise architecture is challenging but could be facilitated using an enterprise architecture framework.  

However, very few companies deploy a complete EA framework. Due to the exhaustive nature of these frameworks, implementing a comprehensive framework is expensive and intensive. Not only must the framework be implemented, but it also requires maintenance. 

For these reasons, most companies adopt a framework, or even cobble together parts of different frameworks, to meet their business's needs and provide value. EA frameworks are used more than guidelines; they are used instead of rigorous standards and practices.  

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

Understanding how Enterprise Architecture frameworks evolved to reach their current state and learning their respective areas of success and failure will provide the information needed for businesses to adopt or adapt an EA framework. It will also provide the complete visibility required to help the company manage the complexity inherent in today's industry. 

Moving to an Agile Enterprise Architecture 

One of the most common complaints of the traditional enterprise architecture function is that it does not keep up with the pace of change. It does not facilitate agility. The development and adoption of the Agile methodology have forced enterprise architecture to change its approach more than any other force in the business.  

Businesses must be able to change course rapidly, account for technological disruption, develop new capabilities, or enhance the customer experience of existing capabilities. 

Fortunately, recent technological advancements have enabled the automation of architecture processes. Enterprise architects can now focus on exploring emerging technologies and innovation, build reference architectures, and help set and achieve strategic business objectives.  

To do this, enterprise architects must understand more than just technology. They must understand the business and how technology enables that business. 

The Problem with Agile Methods 

Agile methods solved some problems. Projects had very high failure rates. Either the stakeholders were not getting what they expected, or time to value was not keeping up with the pace of change in the marketplace.  

Also, many projects experienced heavy technical debt, which caused enormous downstream costs when technologies became obsolete and had to be updated.  

The results were inevitable immobility. Changing the organizational structure by breaking the pyramidal hierarchies and focusing on interactions between individuals more than on processes and tools could be more rapidly implemented, thus allowing rapid changes in direction and development of user-friendly functionality.  

This organizational revolution did not come without risk. Small agile teams may be able to make rapid changes and adjust to meet changing requirements, but the absence of the traditional pyramidal structure means that the big picture is no longer seen.  

The collection of teams loses the perspective of a common goal and iterates on details that no longer contribute to the value of the initial effort. 

Scaled Agile framework 

There is no argument against a need for agile thinking. Due to rapid technological advancement, where barriers to entry of new products in the marketplace are virtually non-existent, and where market shares are frequently redistributed, there is a strong need for a variable adjustment.  

This variable comes in the form of Agile @ Scale. One of the most popular examples of Agile @ Scale is SAFe (Scale Agile Framework), designed in 2011 by Dean Leffingwell. This framework has shaken up traditional architecture.  

Not only does SAFe integrate with architecture frameworks, but it also allows the methodology to be applied to larger groups that can work effectively without dispersing and according to an overarching plan.  

The purpose of SAFe is not to manage a project but to build a product. The product is decomposed into functionalities or capabilities instead of requirements. In this way, we achieve a faster feedback loop with the customer and avoid the costs of product release delays. 

How do you Choose the proper enterprise architecture framework? 

There is no one-size-fits-all answer to this question, as the best enterprise architecture framework for your organization will depend on several factors, including your specific business goals, the size and structure of your organization, and the existing IT infrastructure.  

However, a few general tips can help you choose the proper framework for your needs:  

1. Do your research: Various enterprise architecture frameworks are available, so it's essential to research the different options before deciding.  
2. Consider your goals: What are you hoping to achieve with your enterprise architecture? Ensure that your chosen framework is well-suited to help you reach your goals.  
3. Consider your organization: Your organization's size and structure will impact the feasibility of implementing a particular framework. Take these factors into account when making your decision.