Three Types of EA frameworks
What is an Enterprise Architecture Framework?
An enterprise architecture framework is used to simplify the development of an enterprise architecture. Good enterprise architects use the best framework to simplify the complexity of their organization. They use that simplification to understand where the organization cannot meet expectations, and where it must be changed to meet expectations.
We think of an architecture framework as the essential scaffolding. Scaffolding that helps an enterprise architect with the three challenges:
- how to develop enterprise architecture
- how to document an enterprise architecture
- how to develop an enterprise architecture team
What Architecture Framework is used in Enterprise Architecture?
Enterprise Architects use three types of enterprise architecture frameworks - comprehensive architecture frameworks, industry architecture frameworks, and domain architecture frameworks.
Comprehensive Enterprise Architecture Frameworks
Comprehensive Architecture Frameworks are industry and domain agnostic. They broadly apply. There are two leading comprehensive frameworks, TOGAF® Framework and Zachman.
Industry Architecture Frameworks
They optimize industry Architecture Frameworks for one industry. These Frameworks typically specify the stakeholders, viewpoints and model techniques. They may also provide industry reference models. We use six industry frameworks: BIAN, DODAF, FEAF, TMForum's ODF, and IndEA.
Domain Architecture Frameworks
They optimize domain Architecture Frameworks for one domain. These frameworks typically provide the most detailed techniques and method. We use one domain architecture framework, SABSA.
Comprehensive Enterprise Architecture Frameworks
There are two leading comprehensive enterprise architecture frameworks, TOGAF Framework and Zachman.
The TOGAF® Standard
The TOGAF Standard is modular, scalable, and configurable. It provides the universal essential scaffolding for the three central problems facing enterprise architects:
- how to develop enterprise architecture (TOGAF ADM),
- how to document an architecture (TOGAF Content Framework),
- how to develop an enterprise architecture team (Develop an EA Team)
They divide the TOGAF Framework into fundamental concepts and a set of guides. The fundamental concepts are universal and apply to every organization and industry. Different Guides identify how to use the universal scaffolding for different circumstances or domains.
- Enterprise Architecture Team Leader's Guide
- Enterprise Architecture Practitioner's Guide
- TOGAF/ SABSA Security Guide
- SOA Practical Guide
The Zachman Framework
The Zachman Framework is built on a set of perspectives. Each perspective exists at the intersection of the type of stakeholder and the aspect of the architecture. The set of perspectives represents part of your enterprise and its information systems.
The columns of Zachman Framework are six aspects based on English language interrogatives ‘what’, ‘where’, ‘who’, ‘when’, ‘why’, and ‘how’. The columns are used to frame different explanations for each of the stakeholders.
The rows define different stakeholder classes - planners, owners, designers (architects), implementers, sub-constructors, users. Alternatively, they are used to represent scope, context, business concepts, system logic, technology, physics, component assemblies, and operations classes.
The value of the Zachman framework comes at the intersection of each column and row. In many regards, the Zachman framework provides a strong viewpoint library. We require the Architect to describe the architecture in terms of the interrogatives for the different stakeholder classes.
While the Zachman Framework can imply a heavy documentation, only the information needed to solve the problem under analysis should be populated. For example, an organization with inventory and process-driven operations would focus on What and How columns. The exception is the Why column. It provides the drivers and motivations for the work.
The Zachman framework does not provide an underpinning model, nor a method of developing the enterprise architecture. The EA team needs to develop their method, process, and notation for collecting, managing, or using the information.
Industry Architecture Frameworks
We use six industry frameworks: BIAN, DODAF, FEAF, TMForum ODF, and IndEA.
Finance and Banking Architecture Framework - BIAN
BIAN is the Banking Industry Architecture Network. A consortium of financial services companies developed it. The BIAN Service Landscape is a blueprint for the logical components of a bank’s IT environment. Leveraging this blueprint and the Service Domain Specifications will significantly speed up architecture initiatives—be it in the planning of change initiatives, in the procurement of components, or benchmarking of an existing landscape against best practices.
>> Compare BIAN and TOGAF (TOGAF vs. BIAN)
Architecture Framework for Defence
DODAF is the Department of Defense Architecture Framework. The United States Department of Defense develops DODAF. The central problem defense agencies face is integrating long-lived systems and diverse organizations into common missions and capabilities. Many weapons systems have decade-long development and can be expected to be in use for 30-40 years.
The DODAF viewpoint library is optimized around communications and integration to address this problem. We routinely use DODAF's viewpoints where we have an integration problem across independent organizations.
Besides DODAF, other NATO countries have developed their own specialized defence architecture frameworks. Canada developed DNDAF, The United Kingdom developed MODAF and NATO uses NAF. DODAF-based defence architecture frameworks focus on the core problem of interoperability.
>> Compare DODAF and TOGAF (TOGAF vs. DODAF)
Government Architecture Framework - FEAF
FEAF is the United States Federal Enterprise Architecture Framework. The central problem government agencies face is duplication of process, IT system, and data across independently developed services and programs.
They designed the FEAF Reference models to highlight duplication. By describing business, IT systems, data, and infrastructure through a common language, duplication is uncovered. This allows the agency to ensure that duplicative processes, systems, and data are in the service interests of the program stakeholders.
We routinely used FEAF's approach, and derived reference models during acquisition and merger projects. Duplication isn't necessarily bad. It needs to be justified based on your organization's value proposition and operating model.
The Government of India has developed IndEA. IndEA takes a broader approach than FEAF. Besides duplication, IndEA attempts to set standards for modelling and description of many enterprise architecture domains.
TM Forum's Open Digital Framework
The TM Forum Open Digital Framework (ODF) is designed for the telecommunications industry. They optimize it for their challenges, which center around migrating from legacy IT systems and processes to modular, cloud native systems.
TM Forum member organizations develop ODF.
We have used TM Forum's FrameworX Business Process Model several times with consumer-facing organizations. The separation of eTOM into customer facing and operational systems has highlighted challenges in managing consolidated and simplified operations in the face of specialized offering to customers.
Domain Architecture Frameworks
We use two domain architecture frameworks, SABSA and DODAF
Security Architecture Framework - SABSA
SABSA is the industry's leading security architecture framework. They built the SABSA model to speak to different consumers and interrogatives of Zachman.
The SABSA uses the model as a foundation and builds specialized tools to identify objective and risk. After all, risk is the effective of uncertainty in realizing your objectives.
>>> Using a Risk Architecture with the SABSA Domain Model
>> Compare SABSA vs. TOGAF
Integration Architecture - DODAF
The central problem defense agencies face is integrating long-lived systems and diverse organizations into common missions and capabilities.
They designed DODAF to solve the two bookends of integration immediacy and legacy.
Immediacy: On a mission-to-mission basis, operators integrate different systems in real time. Operators are often from different countries, and different branches. Yet their systems must work.
Legacy: Systems typically have decades-long development and will stay in use for 30-40 years.
They optimized the DODAF viewpoint library to address this problem. When we face an integration problem, we reach for DODAF's viewpoints. It doesn't matter whether we are integrating modern agile-developed modules, or integrating between independent organizations.
Pick Your Best Framework for Enterprise Architecture
Your best framework for enterprise architecture will be driven by your specific needs.
First, if you work in Finance & Banking, Defense, Telecommunication, or Government you use an Industry Framework. You have it easy. There is an established way to describe your enterprise architecture. After that decision jump to Step Two.
If you don't have an easy Industry choice, look at the purpose of your enterprise architecture team. You need to understand the central problem that will drive the design of your enterprise architecture team. The Leader's guide to establishing an enterprise architecture team is adamant that you develop your enterprise meta-model from the problems you need to answer. The thinking behind consistent industry problems are great starting points for selecting the best enterprise architecture framework. Can you adapt an Industry Architecture Framework? If you share the design problem you should adapt the framework, BIAN, for managing the separation of customer engagement and operational systems. DODAF, for enabling integration. FEAF for avoiding duplication.
If you need to design your own enterprise-meta model you have a difficult problem. We strongly advise you get help. The worst place you can land is to follow a path to build a framework that describes many things and answers no question.
Second, look at the strength of your EA Team and your method for developing enterprise architecture. If you are not well established you are selecting the TOGAF Framework. It covers method, and building an EA Capability as well as describing an architecture. You will take advantage of TOGAF's modularity and substitute your framework for the TOGAF Content Framework
Conexiam Enterprise Architecture Consulting
These two steps are how Conexiam's enterprise architecture consulting selects the best framework for enterprise architecture. Our Enterprise Architecture Capability workshop answers the initial questions about purpose and problem.
Every enterprise architecture team needs to do the same three things:
- develop enterprise architecture,
- document an enterprise architecture,
- develop an enterprise architecture team
We always use the TOGAF Framework to provide the essential scaffolding for developing architecture and the architecture team. We never use the TOGAF Content Framework to document an enterprise architecture. We always substitute an architecture framework that is optimized to the problem you are facing. We use Navigate, DODAF, BIAN, FEAF, or develop a customized content framework. We always add SABSA to ensure effective coverage of risk and security.
As an enterprise architect, your job is to understand the challenge, deficiency and opportunities in your business. Using that understanding your help stakeholders improve your organization. The best framework for enterprise architecture will speed-up and improve the quality of your work.
Do it Yourself Tools to evaluate Enterprise Architecture Frameworks
Switch thinking from TOGAF vs SABSA to TOGAF plus SABSA
Every Enterprise Architecture Team shoud be built for purpose
Compare TOGAF and BIAN
Align the design of your EA Team to Value