Enterprise Architecture Framework: a Complete Guide

Many business executives of various industries often request our assistance in the development of their enterprise architecture. As we adapted our methods of building proper business architecture and business model design, our clients can benefit more appropriately from the proven expertise and technical know-how of our skilled enterprise architects.

Today, many organizations are struggling to keep pace with the evolution of information technology strategy. Without an infrastructure architect, their business’ IT systems struggle and eventually get disrupted by outside forces. 

Today, IT and business leaders must ensure that their organizations develop and execute enterprise architecture strategies successfully. It is very important to adapt to an ever-changing environment and avoid lagging behind other organizations. In this article, we introduce the need for an architectural approach and explain how to establish long-term success through EA.

Read further on to learn how to shape the strategic direction and organize IT infrastructure to align with your business vision and goals. 

Our record of achieving great results is apparent from the many case studies we have collected over the years. Jelvix has taken a leadership role in the market by applying proven strategies and adapted designs that have been successfully used by many enterprises in various industries.

Our performance and professional skills in digital transformation, enterprise architecture, and experience design have proved durable and effective. Please, see our Services page to learn more about our company. 

What is Enterprise Architecture?

Before we get into defining different enterprise architecture frameworks, let us first explain what Enterprise Architecture is. Enterprise Architecture (EA) is a practice of identifying, designing, and implementing the structure and operation of a business organization.

The purpose of EA is to use a comprehensive approach toward desired business goals and successfully execute the business strategy. Each enterprise architecture involves governing principles (frameworks) that guide enterprise architectural planning (EAP).

EA frameworks help businesses execute and sustain digital transformation since they are primarily responsible for presenting IT leaders with newer legacy applications to beat relevant business disruptions. 

The use of EA frameworks originated through the progressive growth of business technologies in the 1980s when there was a need to transition from non-conventional business models to more efficient, contemporary, and technology-driven solutions.

Many principles and methods employed in today’s EA frameworks could be found in IS and IT architecture frameworks prevailing in that decade and the following one. Pretty soon, the process of business transformation spread throughout all industries, not just information technology.

Significantly, different functional areas of an organization interpret the concept of EA in their own way. For example, IT professionals regard enterprise architecture strategies as an alignment of clearly defined infrastructure, application, and management components, while enterprise architects focus on business structure analysis and working methods to implement it. 

Understanding the Purpose and Structure of Enterprise Architecture

Enterprise architecture aims to broaden an existing business model and take on challenges and business risks resulting from disruptive forces to achieve the desired business vision and goals.

EA plays a crucial role in business process unification and gives business leaders an understanding of operational gaps that separate the company’s current situation from an ideal one. 

In particular, EA offers a map or a blueprint of the corporate strategy and associated operations of an organization. This blueprint is a diagram or schema that gives an overview of both the conceptual and physical levels of an enterprise and provides the scope, design, and realization solutions to the current situation within the enterprise.

An Enterprise Architecture Blueprint (EAB) can be visualized in a hierarchical view, like a pyramid, where logical business functions and capabilities represent the “foundation” of an organization, human roles represent the physical organizational structure, and finally, the top of the pyramid holds data flows and stores, business applications (hardware), and communications infrastructure. 

All of the above-mentioned components are interlinked and mutually reinforce one another. However, due to poor enterprise architecture or the company’s inability to define the business approach clearly, different departments across an organization usually have a fragmented legacy of processes and are often disorganized. 

With the use of an effective enterprise architecture framework, these business environments will be able to align and create a purposeful unified structure across teams and the organization as a whole. 

The Four Major EA Frameworks 

Now that you have learned the concept of Enterprise Architecture, let us proceed with introducing the four typical domains (frameworks) of EA. There are many different frameworks designed for a specific type of organization, each focused on particular elements of the business process.

For instance, some EA frameworks feature methods and methodologies aimed at reinforcing the consistency between various parts of an overarching enterprise and are typically suited for larger organizations with many moving parts.

While others, designed for small and medium businesses, pursue a flexible architectural model, with a strong degree of connectivity between business services, functions, channels, data, and people involved. 

The top four Enterprise-Architecture frameworks are:

• EA Template frameworks are developed for organizing architectural artifacts (design documents, specifications, and models). Example: The Zachman Framework.
• EA Content Frameworks are designed for developing the artifacts and deliverables for each of the EA development phases. Example: The Open Group Architectural Framework (TOGAF).
• The Federal Enterprise Architecture Framework (FEAF) is a prescriptive methodology intended for (but not limited to) wider government use that combines the best of both the Zachman Framework and TOGAF.
• The Gartner Framework (methodology) is an enterprise architectural practice that focuses on a constant state of adapting to the business environment.

The Zachman Framework

Developed in 1987 by J.A. Zachman, the Zachman framework can be described as an enterprise ontology or taxonomy that provides a disciplined approach to managing systems architecture.

In particular, it is a way of looking at the enterprise’s important issues from every important perspective and showing how structural connections of the enterprise are related.

The framework describes six architectural focal points and six-player perspectives (primary stakeholders) that aid in standardizing the IT architecture components and outputs. 

Zachman framework, like any other EA Template framework that aims at collecting, managing, and organizing a massive variety of architecture artifacts, takes into account the target of an artifact (e.g., business owner) and a particular issue that is being addressed (e.g., data and functionality). 

• Enterprise architecture artifacts provide a description of the organization from different viewpoints that are important for the stakeholders involved. 

In the Zachman framework, architectural artifacts are organized using a two-dimensional classification schema. The first dimension describes “players in the game”; these are CEOs, CFOs, general managers, etc., that represent the driving force behind the company.

The second dimension is the descriptive focus of the artifact that uses primitive interrogatives: What, How, When, Who, Where, and Why. 

Zachman then suggests that these interrogatives stand for the six descriptive areas of focus – data, function, network, people, time, and motivation, while “players in the game” are represented by the planner, owner, designer, builder, subcontractor, and enterprise.

Each of the “players” has his/her own focus and pursues his/her own objective. For example, the builder needs information on the construction process and materials, whereas the owner is interested in the functionality process and quality assurance. 

Such an approach to systems architecture enables complex organizational subsets to be systematically segmented into teams or categories and provides the participants of such teams with a multi-perspective understanding of organizational patterns.

So, a shared perspective of business functionality and goals provides a means for more effective business communication. Thus, possible gaps within an organization can be defined and averted, while leaving room for maintaining, or rebuilding, IT’s credibility in the organization. 

Although originally invented for the purpose of aligning Technology with Business Needs, the Zachman framework has improved IT planning processes across thousands of commercial and governmental organizations, went far beyond IT, and continues to benefit savvy companies even now, when the whole world is experiencing an economic downturn. 

The Open Group Architecture Framework 

The Open Group Architecture Framework (TOGAF) is considered one of the most common framework structures used across business industries today. TOGAF was originally developed by the U.S. Department of Defense in 1995, but eventually was turned over to the Open Group and morphed into the current standard. 

The Open Group defines the TOGAF framework as the de facto standard in an EA practice and uses an overarching approach (including the process, steps, and guidelines) for developing artifacts and deliverables for each of the development phases.

One of the major benefits of TOGAF is that it can be customized to the organizational needs; once an architecture is developed, it can be rolled out to organizational departments in iterative cycles without much modifying. This establishes the process with multiple checkpoints and ensures minimal error for most cases of applications. 

• A deliverable is a contractually specified and formally reviewed architectural work product that represents the output of projects. 

TOGAF intends to help businesses address critical problems and is built on the four major principles that, in the Open Group’s view, allow developing solution-specific architecture:

• Common vocabulary. This ensures that everyone within the organization understands the framework, business goals, ideas, and concepts in the same way and is focused on achieving organizational success. A common language sets the organizational culture and improves internal communication, so it’s crucial for the employees to speak the same language. 

• Non-commercial use. The TOGAF architecture framework is free for companies that have non-commercial priorities. For organizations that wish to use TOGAF for commercial purposes, the Open Group has specified conditions, of which the most important are having a TOGAF standard and Version 9.2 Annual Commercial License.

• Effective resource management.

• Achieving demonstrable ROI. 

The four major goals listed above are the theoretical outcomes of using TOGAF. In order to achieve them, you need to learn the three main pillars of the framework; these pillars help to design an organized process and use software technology in alignment with business goals and objectives. 

Now, let’s look at the three main pillars of the TOGAF architecture framework. 

1. Enterprise Architecture Domains. Every enterprise architecture contains four domains (business, data, application, and technology) that are subsets of an overall EA; these are partial representations of a whole structure of an organization. 

1.1. Business architecture. Describes the organization’s business strategy, key business processes, and standards. 

1.2. Applications architecture. Describes application systems, their interactions, and relationships to essential business processes of an organization.

1.3. Data architecture. Describes the structure of physical and logical data assets and data management resources.

1.4. Technical architecture. These are hardware, software, and network infrastructure used to support the deployment of necessary applications. 

2. Architecture Development Method (ADM). It is a core component of TOGAF that uses performance engineering to specify the process for developing an IT architecture. In particular, it contains six architectural parts that provide descriptions, models, and patterns for managing the lifecycle of an enterprise architecture. 

3. Enterprise continuum. This is a “framework-within-a-framework” used for classifying architecture artifacts related to the context of the overall enterprise architecture. Particularly, the framework categorizes the “virtual repository” of the architecture assets, such as architecture descriptions, standards, reference models, and organizational structures that are used both within the enterprise and in the IT industry at large. The enterprise then determines which of these architecture artifacts will be included in its Architecture Repository for reuse. 

The Federal Enterprise Architecture Framework

The Federal Enterprise Architecture Framework (FEAF) is a reference enterprise architecture methodology developed in 1999 for the Federal Government of the U.S. The original purpose of FEAF was to accelerate the shared development of processes and information systems among federal government agencies. 

The current standard – FEA – suggests that an enterprise is built with segments and provides a taxonomy for segmenting assets of the EA. According to FEA, a segment is an organizational unit and a cross-agency business area that transcends federal agency boundaries; the Core-mission area and Business-services segments are two major segments in the framework. 

FEA entails a set of interrelated reference models for describing the six architecture domains (strategy, business, data, applications, infrastructure, and security).

In the combination with a segment model, these reference models facilitate cross-agency analysis and identify possible duplicative investments or gaps, as well as opportunities for collaboration within and across agencies.

Also, with reference models, agencies can create a perspective on how to best use the software and hardware infrastructure to achieve corporate-level strategic goals.

The Consolidated Reference Model (CRM) is the core of the FEA framework which provides the Office of Management and Budget (OMB) and Federal agencies with a common language and framework to describe important elements of federal agency operations. 

The FEA framework includes the best features of the Zachman Framework, TOGAF, and the Spewak Enterprise Architecture Planning (EAP) methodology.

The Gartner Framework 

Last but not least, the Gartner Framework is a common EA framework created in 1985 which is neither a taxonomy (like Zachman), nor a process (like TOGAF), nor a complete methodology (FEA); instead, it is defined as a practice by one of the leading IT research and advisory companies in the world: Gartner, Inc.

Gartner, Inc., employs well-qualified specialists in the IT industry and has a long-running history of effective organizational communication, so it’s no wonder it has had such an enormous impact on EA development.

The Gartner community encourages collaboration and mutual commitment towards a singular goal and vision; particularly, it focuses on the idea of combining business owners, information specialists, and tech implementers in a single entity.

According to that idea, if you can bring these three constituents together around a common goal, you have succeeded. Gartner measures success in pragmatic terms, such as driving profitability, and not by a brilliant taxonomy that categorizes architecture artifacts. In other words, an enterprise architecture that is just a bunch of stiff artifacts is useless and will never drive business value. 

The current Gartner practice methodology suggests that Architecture is a verb, not a noun, explaining that it is the ongoing process of creating and leveraging EA artifacts that give architecture its movement and vitality.

Using this methodology with the focus on three core entities, the framework designs an enterprise-architecture vision and ensures that everyone in the organization understands the scope and the nature of the EA strategy.

Once the organization has a common vision of the future, it can think about the implications of this vision on the business, technical, and solutions architectures of the enterprise. 

Summing up 

We have learned about the four most popular EA methodologies that dominate the field. Now that you have a basic knowledge of the frameworks, you can choose the one that best suits your organization’s vision. We recommend that you focus your energy on what you want to end up with; think of where your company’s strategic direction is heading towards and what business drivers it responds to. 

If you are interested in our services and would like to collaborate with us to create powerful EA, please contact us for a free consultation.