Ask ten executives what 'architecture' means and you will get ten different answers. The CHRO thinks org design. The CTO thinks network, intrusion, databases. Facilities thinks workspace design. The CFO thinks ERP landscape. The COO thinks process flows. The head of strategy thinks capability maps.
Every one of them is right — and every one of them is looking at one piece of a system that nobody is designing as a whole.
This isn't a terminology problem. It's a structural one. Each architecture discipline has its own frameworks, its own governance, its own reporting lines, and its own definition of success. All of this work is necessary. None of it is sufficient. Understanding the landscape is the first step toward fixing the gap.
Six architecture disciplines every enterprise needs
Most large organizations employ some combination of the following architecture disciplines — each with its own body of knowledge, certification programs, and professional communities. Each is valuable. Each has a blind spot.
01 — Enterprise architecture
Enterprise architecture is the most established discipline, rooted in frameworks like TOGAF and the Zachman Framework. It maps the relationship between business strategy, information systems, application portfolios, and technology infrastructure. At its best, enterprise architecture provides a strategic view of how technology enables the business.
The blind spot: enterprise architecture excels at mapping what technology exists and what technology is needed. It's less effective at addressing who does the work, where it gets done, or how the operating model should evolve to absorb new technology. The result is technology maps that are technically sound but often detached from operational reality and value delivery.
02 — Business architecture
Business architecture, codified by the Business Architecture Guild and its BIZBOK framework, focuses on capabilities, value streams, and the strategic alignment of business functions. It provides an essential bridge between strategy and execution — mapping what the organization needs to be able to do.
The blind spot: business architecture operates at a strategic level that doesn't always translate into the way work gets done and handed off. It's rooted in times where many organizational layers demanded a high-level view and details were too many to process coherently. Capability maps tell you what the organization needs. They don't tell you how the operating model should be configured to deliver those capabilities — who does the work, from where, using what platforms, under what governance.
03 — Technical and solution architecture
Technical architecture designs infrastructure: networks, servers, cloud environments, security layers. Solution architecture designs how specific systems solve specific business problems — APIs, integration patterns, microservices, data flows. Both are critical to execution.
The blind spot: technical and solution architects optimize for system performance, scalability, and reliability. They design excellent technology. But technology architecture optimized in isolation produces systems that work beautifully on their own and create friction when you look at how humans, processes, and organizational structures interact with them. It's also permeated with a risk-reward equation favoring risk avoidance, which yields slow adaptation and processing velocity.
04 — Data architecture
Data architecture governs information assets — data models, master data management, data quality, privacy, and compliance. As organizations become more data-driven and AI-dependent, data architecture has moved from a supporting function to a strategic discipline.
The blind spot: data architecture typically treats data as a technical asset to be governed, not as an operating model input that shapes how work flows, who makes decisions, and where accountability sits. With the influx of APIs and electronic work handoff, this function tends to favor data protection and has limited visibility into getting work done autonomously or digitally with limited human interaction — an area of immense promise and challenge as RPA evolves and autonomous agentic AI takes flight.
05 — Process architecture
Process architecture standardizes how work gets done — workflows, procedures, quality frameworks, escalation paths. It's fundamental to operating model effectiveness, especially in global business services environments where consistency across geographies is essential.
The blind spot: process architecture typically standardizes within a function. It doesn't routinely account for the cross-cutting connections that make an operating model work — how process design should inform geographic decisions, how workflow automation should reshape role definitions, how communication protocols should adapt when AI agents share the work.
06 — Organizational design
Organizational design determines who does the work — reporting structures, role definitions, spans of control, GBS structures, leverage ratios, supervision models, decision rights. It shapes skill architecture, credentialing, training, and talent development.
The blind spot: organizational design typically restructures within a business unit. It needs to evolve toward much flatter organizations empowered by technology and work handoff between machines and humans at warp speed. It doesn't routinely account for how organizational structure should reflect technology capabilities, how geographic strategy should shape team composition, or how the workforce model needs to evolve as AI agents absorb capacity.
The pattern across all six
Every discipline listed above has real, essential value. The pattern is the same across all of them: each optimizes its own dimension brilliantly, but none is designed to account for the others.
Enterprise architects report to the CIO. Business architects report to strategy. Solution architects sit in IT delivery. Organizational designers sit in HR. Process architects, if they exist at all, may sit in operations or in a shared services function.
Nobody reports to the operating model.
That's the gap. And it's the gap where value gets lost — where a cloud migration captures twenty percent of its potential because nobody redesigned the target operating model to match, where an AI deployment stays in pilot purgatory because the workforce model and governance weren't redesigned alongside the technology.
So what fills the gap?
There is a discipline that integrates all six architectures into a coherent system — one that designs how the full target operating model works, not just individual pieces of it. It answers the question that none of the six disciplines above can answer on their own: how do all of these architectures work together?
That discipline is operating model architecture. It doesn't replace enterprise architecture, business architecture, or any of the others. It integrates them — across four dimensions that every operating model must address.
Read next: From enterprise architecture to operating model — the missing design layer
Key Takeaways
- Six architecture disciplines shape the modern enterprise — enterprise, business, technical, data, process, and organizational design
- Each discipline has its own governance, reporting line, and definition of success — but none designs the full operating model
- The pattern is the same across all six: each optimizes its own dimension brilliantly while ignoring the connections between them
- The gap where value gets lost isn't the disciplines themselves — it's the missing integration layer that ties them together
Diego Navia
Managing Director, digitiXe · 35+ years in business transformation