Developing Business Architecture and Operating Model: Steps, Processes, and Core Elements
This article outlines the iterative Enterprise Architecture (EA) process for building business architecture, detailing seven key steps—from definition and scope to migration planning and optimization—followed by an explanation of operating models and the five essential elements needed to create an effective operating model.
Develop Business Architecture
The EA process model can be expressed as a series of seven steps that can be followed for any architectural viewpoint, including ongoing management, governance, and communication work. It must be performed iteratively: architects continuously evolve depth and breadth as business context changes (e.g., new business strategies). The EA development steps are overlapping and can start before the previous step finishes; a strict waterfall approach is not required.
Building a business architecture is an iterative process; the same EA process can be applied when developing an Enterprise Business Architecture (EBA).
Figure 1
The business architecture is an abstract representation of how an organization operates, where, and with whom, encompassing daily decisions to achieve its mission and strategic goals while delivering value to target customers.
1] Definition and Scope
To start using EBA, the EA team should:
Establish a clear EBA definition, including overall objectives.
Create a scope statement for the specific iteration and an out‑of‑scope statement.
Develop a statement of relevant assumptions (e.g., availability of business subject‑matter experts).
Identify the overall business sponsor and business owner for each iteration.
Determine relationships between EBA activities and other viewpoint activities, dependencies, and relationships.
Draft a statement describing the relationship with the overall EA process.
Identify key constraints (compliance, extended enterprise ecosystem, organizational culture and politics, industry and regional requirements).
2] Organization
Identify and organize the team to complete the iteration’s work. For any EA domain, this means detailing key leadership and member roles and ensuring formal participation from designated leaders. Also, gather necessary (and available) supporting information, models, and artifacts.
Any EBA team should have:
A clear charter based on goals and objectives.
Clearly defined roles and responsibilities.
3] Future State
The third step defines the EA vision of the future state by specifying requirements, principles, and models that describe long‑term goals and how to achieve them. The first task is to define the context of EBA changes and understand how business context applies to the EBA iteration.
4] Current State
The fourth step establishes a baseline of the current state, aiming to understand the status of business dimensions within the EA/EBA scope. The current‑state documentation should reflect the level of detail needed for the future‑state documents, preparing for the next step—identifying gaps between where you are and where you want to be.
5] Gap Analysis
When the EBA team reaches this step, the gaps between the current and future states should be evident. The goal is to clearly record these gaps.
6] Migration Plan
The EA roadmap serves as a valuable planning tool, helping the organization define a set of clear proposed change projects to move the enterprise from the current state to the future state.
EBA teams should:
Recommend changes to EBA dimensions (people, processes, organization, finance).
Identify changes to related ETA, EIA, and ESA architectures.
Determine adjustment decisions (organizational changes, re‑defining projects, project launches).
Determine investment decisions (skills, personnel, technology).
Identify scenarios for key areas that may be affected by internal or external factors (compliance, culture, politics, industry, region).
7] Iteration and Optimization
As the organization continuously moves toward the future, the EBA team should consider deeper iterations as needed, especially strengthening dependencies on other architectural viewpoints; this enables better relevance analysis and impact analysis, thereby increasing agility.
Operating Model
An operating model is an abstract representation of how, where, and with whom an organization operates, encompassing daily decisions to achieve its mission and strategic goals while delivering value to target customers.
The alignment of operating model and business model is a key component for tightening a company’s execution model, allowing more value to be delivered at lower cost. Business architects have a huge opportunity to define operating models that create significant value for their companies.
Figure 2
Five Core Elements for Creating an Effective Operating Model
The five elements are essential for defining an operating model:
Leadership
Governance
Organizational Model
Capabilities
Services
Business architects who focus on the clarity and consistency of these elements will support the success of corporate strategy.
---
For further discussion, join the Chief Architect Circle, WeChat groups, or follow the listed channels.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.