Hunting the Ghost of Business Architecture
IN THIS SECTION, YOU WILL: Understand that business architecture is a shared, often invisible practice that helps organizations understand how they create value — even if no one formally owns or names it.
KEY POINTS:
- Business architecture is a loosely defined, often invisible discipline that spans strategy, operations, design, and technology — making it hard to pin down or assign to a single owner.
- There’s ongoing debate about whether it exists as a standalone function or if it’s simply a set of shared perspectives and practices scattered across roles.
- Different roles shape business architecture in different ways — from enterprise architects and COOs to service designers and heads of strategy — often without using the term.
- Rather than centralizing ownership, the most effective approach could be shared stewardship, where multiple teams contribute to a common understanding of how the business works and changes.
- Ultimately, business architecture may be less about definitions and more about creating clarity — helping organizations see the whole, make better decisions, and connect intent with execution.
When we talk about business strategy and architecture, the term “business architecture” naturally comes up. But talk to a few people about business architecture, and you’ll quickly realize there’s no single, agreed-upon view. Some see it as a way to connect strategy to operations, while others think in terms of capabilities and value streams. Some associate it with enterprise architecture, while others associate it with service design or transformation.
And some quietly ask: “Does this even exist as a real, standalone discipline?”
It’s a fair question. Unlike more established functions like software architecture or product management, business architecture doesn’t always have a clear job title, team, or mandate. Some organizations formalize it. In others, it’s embedded, implicit, or scattered across teams that don’t use the term.
To help ground the discussion, here are a few reference points that often come up:
Business Architecture Guild: “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”
TOGAF: “The business strategy, governance, organization, and key business processes, at a high level.”
Thus, business architecture shows what a business does (its capabilities), how it delivers value (its value streams), and how it’s structured to operate (its people, processes, and systems). These are all helpful, but they are still just starting points.
Gregor Hohpe captures this ambiguity well when he writes, “Every organization has a business architecture, even if they don’t have business architects.”* The work is happening but might not be recognized as “architecture, “ and it rarely fits in a neat box.
This section explores what business architecture could mean, why it’s often hard to define or own, and who shapes it—whether by design or by default.
Business Architecture as a Way of Seeing
Rather than defining business architecture as a fixed discipline, it might be more helpful to ask: What kinds of thinking and coordination does it enable? What kinds of problems does it try to solve?
Because one of the deeper questions behind all the definitions is this: Does business architecture exist as its own thing? Or is it simply a collection of perspectives borrowed from strategy, operations, technology, and design?
In some organizations, it’s a named role or a structured practice. In others, it’s a loose set of activities across transformation programs, architecture teams, or service design efforts. Whether or not it exists “formally,” the need it tries to meet is real: making sense of how the business works and how it needs to change.
Some teams express this through capability models, others through service blueprints, value streams, or operating models. Some draw it out in workshops, and others manage it through planning spreadsheets. The tools and language vary, but the impulse is the same: to bring structure and clarity to how the business creates and delivers value.
Maybe that’s what makes business architecture compelling, even if it’s elusive: It doesn’t prescribe one way of working — it invites a more holistic way of seeing.
Why It’s Hard to Own (And That Might Be Okay)
One of the most common questions around business architecture is: “Who owns it?” The most honest answer is: “Well… kind of everyone, and kind of no one.”
Because business architecture lives at the intersection of so many disciplines—strategy, operations, technology, and design—it rarely fits neatly within one function. Trying to force it into a single box often misses the point. It’s not just about control or ownership. It’s about creating shared models that help people make better decisions.
Part of the difficulty is that everyone approaches it from a different angle:
- Strategy teams might see it as connecting goals to initiatives.
- Operations leaders might focus on how to streamline and scale.
- Designers often see flows of experience and service value.
- Architects see how systems and capabilities interconnect.
None of these are wrong. The challenge is stitching them together into a coherent, flexible view of the business that doesn’t just live in one person’s head or team’s slide deck.
Who Shapes Business Architecture?
So instead of asking who owns business architecture, it’s often more useful to ask:
Who’s already shaping it — knowingly or not?
Here are some of the usual suspects:
Business Architecture Teams
In larger or more mature organizations, dedicated business architects—often in strategy or transformation offices—might focus on modeling capabilities, designing operating models, and creating alignment frameworks.
Enterprise Architects
In many orgs, enterprise architects must step into the business architecture space. They bridge tech and business, and often use capability mapping to link solutions to outcomes. They may not “own” business architecture, but they carry much of its weight.
COOs and Operational Leaders
When business architecture is about getting things to work — streamlining operations, improving service delivery, building cross-functional capability — the COO or ops leadership often plays a key role. They may never use the term “architecture,” but their work reflects its principles.
Strategy and Planning Functions
The Head of Strategy, Chief of Staff, or enterprise planning team often develops views of the business that are architectural — even if they don’t call them that. They’re thinking about themes, investments, future state visions, and what the business needs to become.
Org Design and People Teams
When the focus is on structure, roles, capabilities, and how teams fit together, business architecture overlaps with organization design. These teams often model the human and structural side of the architecture — sometimes more clearly than anyone else.
Department Leaders
Every business unit has its mini-architecture — whether formalized or not. Department heads define how their teams function, what they need to deliver, and how they measure success. These localized views are valuable inputs into the broader enterprise picture.
Design and Service Strategy
Designers — especially in service or experience roles — often create maps of how value flows through the organization from a user’s perspective. These models reflect real business architecture concerns: handoffs, pain points, silos, and dependencies.
Business Architecture as Shared Space
So maybe the best way to think about business architecture isn’t as a fixed function or framework, but as a shared space — one that invites multiple perspectives and requires active coordination.
It’s less about who owns the models and more about:
- Who contributes to them?
- Who uses them to make better decisions?
- Who ensures they stay relevant as the business evolves?
When that space is nurtured—with the right conversations, models, and governance—business architecture can become an incredibly powerful enabler of strategy, agility, and clarity.
Final Thought
If you’re an IT or enterprise architect, you’re probably already contributing to business architecture — even if you’re not calling it that. You’re modeling capabilities, aligning systems to business needs, helping teams make sense of complexity.
You don’t need to own business architecture to shape it.
You just need to bring curiosity, structure, and empathy.
And maybe that’s what business architecture is really about: not having all the answers, but building better shared understanding — together.
To Probe Further
Questions to Consider
-
Where in your organization is business architecture happening — even if no one calls it that? Is it in strategy, enterprise architecture, ops, or somewhere unexpected?
-
Do you think business architecture exists as a distinct discipline in your company — or is it embedded across functions?
-
Who currently shapes the way your organization views capabilities, value, and structure? Is it formalized, or more implicit and ad hoc?
-
Is there a shared understanding of how your business creates value? Or does each team have its own mental model?
-
How often do strategy, operations, design, and technology teams align on how the business is structured?
-
What artifacts (if any) guide your organization’s understanding of business architecture? Capability maps, journey maps, operating models, org charts… or none of the above?
-
Do your technology architecture decisions reflect a clear view of business priorities and value delivery?
-
What would it take for business architecture to become more intentional and collaborative in your organization?
-
If you had to draw your organization’s business architecture today, where would you start — and who would you invite to help?
-
How might shifting from “ownership” to “shared stewardship” change how your org approaches business architecture?
On Strategy ← Enterprise Architecture as Strategy |
On Strategy Outsourcing Strategies → |