The Three Types of Enterprise Architecture Framework
The right enterprise architecture framework will spell the difference between success with enterprise architecture or failure. They designed each of the three types of EA Framework to support different decision making and change - comprehensive, industry and domain frameworks.
Change is hard. Few transformation programs succeed. A good enterprise architecture can improve your odds of success.
Enterprise architects use an EA framework to simplify the complexity of your organization so that you can understand it, and drive the most effective change.
Misunderstanding how your enterprise needs to change leads to miscommunication. Building a transformation on top of misunderstanding and miscommunication can kill a company.
Which enterprise architecture framework will work best for you? Find out more below.
What is an Architecture Framework
An enterprise architecture framework provides the essential scaffolding to develop, implement, govern, and sustain an enterprise architecture. It should provide universal concepts, stable best practice, and guidance on how to develop and use your enterprise architecture.
There are three types of enterprise architecture framework - comprehensive, industry and domain frameworks.
Enterprise architecture helps align your business operations and IT systems. In modern digital enterprises, IT systems sit at the centre of products, processes, and organization.
A framework helps optimize your enterprise, the business operations and the IT systems support the business structure.
Digital transformation and IT complexity have driven the need for enterprise architecture to an all-time high.
Compare EA Frameworks
Three Types of EA frameworks
There are three types of EA frameworks - comprehensive, industry and domain frameworks.
Comprehensive EA Frameworks
Comprehensive Architecture Frameworks are industry and domain agnostic. They broadly apply.
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.
Domain Architecture Frameworks
They optimize domain Architecture Frameworks for one domain. These frameworks typically provide the most detailed techniques and method.
Comprehensive EA Frameworks
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 an enterprise architecture,
- How to describe an enterprise architecture
- What is needed to have an enterprise architecture capability
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.
The value of the TOGAF standard comes from its comprehensive coverage of the enterprise architecture profession. It covers method (TOGAF ADM), documentation (TOGAF Content Framework), and building an EA Team (TOGAF Architecture Capability Framework).
The TOGAF standard must be configured, with the universal concepts set-up for individual EA Teams. The TOGAF Series Leader's Guide provides the essential guidance for building an EA Team.
Key TOGAF Guides
- EA 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.
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.
DODAF is the Department of Defense Architecture Framework. The United States Department of Defense develops it, with other NATO players developing their own version (Canada's DNDAF, MODAF from the UK, and NATO's TAF).
The central problem defence 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.
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.
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 one domain architecture framework, SABSA.
SABSA is the industry leading security architecture framework. They build the SABSA model upon the stakeholders 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 on realizing your objectives.
The Best Architecture Framework for You
Each of these frameworks is viable for different organizations. We lean to using TOGAF as a foundation because it covers method, and building an EA Capability as well as describing an architecture.
In fact, we never use TOGAF's Content Framework. The reason is simple, content frameworks need to be optimized to the problem you are facing in your architecture. We replace it with Navigate, or DODAF, or BIAN, or FEAF, or your customized content framework.
We design best-practice EA Teams to support their organization's change problems. The configuration is in the content framework.
Understanding the challenge, deficiency and opportunities in your business in order to improve it is the role of an enterprise architect.
We are committed to your professional development. Want to learn more? Contact us today!