Why Business and IT architect the same world — and what happens when we apply Enterprise Architecture to IT itself.
Two Camps, One Reality
When you talk about Enterprise Architecture, you’ll notice that there seem to be two camps, clustering around two poles.
The ones who are more business architecture focused and the ones who are more IT architecture focused.
Both camps are right. Both are striving for the same thing: better alignment between business and IT. They are simply approaching it from different directions.
And yet, in the daily work, the two sides often believe they are talking about different things. They are not. They are standing in the same room, looking through different windows at the same reality.
But windows shape what you see. As a consequence, the architecture of enterprises has been built as if these two views were two worlds, not two perspectives. The result is the familiar friction, and a quiet suspicion on both sides that the other camp just doesn’t get it.
This article is about closing that gap, not by building bridges between two sides, but by recognizing the two sides were always one surface.
Rotation and Revolution
To see why the gap was never real, we need a metaphor.
Think of the business as the sun. It is the gravitational center of the enterprise, the reason any of it exists. The customer, the product, the market, the value being created. Without it, nothing else has a reason to move.
For most of business history, IT had no real orbit of its own. It was there to support: a necessity, not a world.
Then digitalization happened, and the planet started moving. Capabilities that used to live in offices, on shop floors, in conversations between people, began migrating into the digital space. Not as copies. As their primary form.
The digital space has its own structure, its own grammar, its own gravity. Data has to be modeled. Systems have to be integrated. Lifecycles have to be managed. Incidents happen. Changes propagate. None of this is overhead. It is what the digital home requires in order to hold the capability at all.
So now think of IT as the Earth.
Like every planet, it does two things at once. It revolves around the sun, because its purpose is still to enable value for the customer. That motion is the end-to-end flow from the business side. And it rotates on its own axis, because it has become a world of its own, with its own geography, its own weather, its own day. That motion is the end-to-end flow on the IT side: the internal turning through which the digital world is continuously built, run, and evolved.
Revolution gives IT its direction. Rotation gives it its day.
This is not an argument for inflating the importance of IT. It is an ontological observation. The business remains the content: the why, the what, the for-whom. IT has become the vessel in which that content increasingly takes its shape. And vessels are never neutral. The shape of the glass determines how the water sits.
If IT now has its own rotation, it must have its own architecture. Not a derivative of the business architecture. Its own.
That is the move EA4EA makes.
The business as the sun. IT as the Earth, revolving around it and rotating on its own axis.
BDAT: The Shared Grammar
Before we can talk about what makes IT unique, we need a shared grammar. And most Enterprise Architects reach for the same one: BDAT.
Business, Data, Application, and Technology.
Four layers, stacked. The business layer describes what the organization does: its capabilities, processes, value streams. The data layer describes the information that flows through those processes. The application layer describes the software systems that manipulate that data. The technology layer describes the infrastructure that runs those applications.
Across the technical layers, four lifecycle motions: Plan, Build, Deliver, Run.
This is the grammar we share. It is the reason an architect in manufacturing can have a meaningful conversation with an architect in banking. BDAT is the common reference frame.
BDAT with Plan / Build / Deliver / Run
But here is the underlying problem: BDAT, as it is usually taught, assumes that the only thing being architected is the business itself. The “B” at the top is the business capability layer. The “D”, “A”, “T” below describe how technology serves that business.
This view is not wrong, but it is incomplete.
The Missing Piece: IT has its own Architecture
What BDAT misses, or rather, what BDAT hides, is that IT is not only a service to the business. IT is itself an organization with capabilities, processes, value streams, customers, and products.
IT has portfolios to manage. IT has demand to orchestrate. IT has a lifecycle from idea to operations, just like the business does. IT has its own customers, internally, sometimes externally. IT runs a value chain.
In other words: IT is not just the “D-A-T” underneath a business. IT is its own enterprise, with its own BDAT.
Once you see this, the picture changes.
BDAT Applied to the Core Business
Let’s make the first application concrete.
When we use BDAT to describe the core business, we are describing how the organization creates value for its customers. The end-to-end motion here is something like Lead-to-Cash (L2C): the journey from a prospective customer discovering the business, through purchase, delivery, invoicing, and cash application.
The “B” describes the capabilities required for that journey: marketing, sales, supply chain, finance. The “D” describes the data that flows through it: customer records, orders, invoices. The “A” describes the applications that enable it: CRM, e-commerce platforms, billing systems. The “T” describes the infrastructure underneath.
And crucially: the central application layer of the core business is typically anchored by an ERP. The ERP is the heart of the business’s operational data and process flow. It is where the business’s reality is registered, tracked, and moved forward.
BDAT of the core business with Lead-to-Cash overlay
This is familiar territory. The next step is the move EA4EA makes.
IDAT: The Enterprise Architecture of IT
Apply the same logic, BDAT, to IT itself.
IT has its own business capabilities: architecture management, portfolio management, demand management, development, testing, operations, support, assurance. IT has its own data: configuration items, incidents, changes, releases, service catalogs. IT has its own applications: ITSM, EAM, PPM, SCM, monitoring platforms. IT has its own infrastructure.
IT also has its own end-to-end motion. If the business moves from Lead-to-Cash, IT moves from Idea-to-Operations: from strategic intent through portfolio, development, delivery, and operation.
When you draw this out, you get a structure that looks structurally identical to BDAT, because it is BDAT, applied to IT, but the content is entirely different. This is IDAT.
IT (Business) Architecture. Data Architecture of IT. Application Architecture of IT. Technology Architecture of IT.
IDAT (IT Enterprise Architecture) with Idea-to-Operations overlay
Here the IT4IT™ Reference Architecture by The Open Group becomes indispensable. It gives us the four canonical value streams of IT: Strategy-to-Portfolio (S2P), Requirement-to-Deploy (R2D), Request-to-Fulfill (R2F), and Detect-to-Correct (D2C). These are the Idea-to-Operations flow of IT, made concrete.
But notice what has happened. We have not just described how IT supports the business. We have described the Enterprise Architecture of IT as an enterprise in its own right.
ITSM is the ERP of IT
Here is a consequence of IDAT that crystallizes the whole shift in one sentence:
ITSM is the ERP of IT.
Just as the business runs its operational reality through its ERP, the system that holds the truth of orders, products, customers, and finance, IT runs its operational reality through its ITSM platform. Incidents, changes, configuration items, service requests, assets. The ITSM is where IT’s state of the world is registered, tracked, and moved forward.
This is not a loose analogy. They play the same structural role. An ERP is the system of record and system of action for the core business. An ITSM is the system of record and system of action for IT itself. Both are the operational heart of an enterprise: one of the business-as-enterprise, the other of IT-as-enterprise.
Once you see this, many decisions become clearer. How you treat data in ITSM. How you integrate it with your Enterprise Architecture tooling. How you govern it. You treat it the way the business treats its ERP: as the single operational source of truth, for IT as an enterprise of its own.
Two End-to-Ends, One Motion
Now we can place the two flows side by side.
The business runs Lead-to-Loyalty. I’ve extended the classical Lead-to-Cash with an Issue-to-Resolution subprocess, to make the comparison clearer. IT runs Idea-to-Operations. Each is an end-to-end process. Each has its own BDAT (one as BDAT proper, one as IDAT). Each has its own operational heart (ERP, ITSM).
Side-by-side comparison of Lead-to-Loyalty (business / BDAT) and Idea-to-Operations (IT / IDAT)
For a long time, Enterprise Architecture treated these as one vertical stack: the business at the top, IT underneath as its D-A-T. That view is no longer sufficient. What we actually have is two end-to-end motions, parallel and entangled, each with its own full architecture.
And here the metaphor from the beginning returns: Revolution and Rotation.
Like the Earth, IT does two things at once. It rotates on its own axis, running its own Idea-to-Operations flow, governed by IDAT, centered on D-A-T as the substance of its work. And it revolves around the business, because the reason for IT’s existence is still to enable value for the customer of the enterprise.
Two motions. One world.
The Culmination Point: Where the two Architectures meet
If IT rotates and revolves, there must be a place where the two motions meet most intensely. There is. It is the point where the business expresses a requirement and IT translates it into a capability: the moment of process and product development.
This is where DevOps lives. This is where Agile lives. This is where BizDevOps and DevSecOps and every other portmanteau of the last decade has tried to put its finger on something real: that the development of a digital product is simultaneously a business act and an IT act. The two end-to-end flows don’t just touch here — they momentarily fuse.
The “culmination point of integration” of the business’ EA (BDAT) and IT’s EA (IDAT)
This is the culmination point. It is where the business’s Lead-to-Loyalty and IT’s Idea-to-Operations intersect with the highest density. Everything before it is preparation. Everything after it is consequence.
And this is where most transformation initiatives either succeed or quietly fail. Because the culmination point cannot be owned by one side alone. It is, by nature, shared.
The Möbius Strip: Why Business and IT Were Never Two Sides
There is one more image we need.
A Möbius strip looks, at first glance, like a normal ribbon with two sides. But if you trace your finger along its surface, you discover something unsettling: there is only one side. What seemed to be two — inside and outside, top and bottom — is one continuous surface that appears as two depending on where you stand.
This is the structural insight at the core of EA4EA.
Business E2E and IT E2E are not two separate flows that need to be connected. They are two appearances of a single continuous motion. The customer’s Lead-to-Loyalty journey and IT’s Idea-to-Operations delivery are the same movement seen from different positions on the same surface.
You don’t need to build a bridge between them. You need to recognize that the bridge was always already there — as the surface itself.
Möbius strip with Business E2E and IT E2E as two apparent sides of one continuous surface
Same Reality, Different Windows
What, then, is EA4EA?
EA4EA is Enterprise Architecture applied to itself. It is the recognition that IT, in the age of digitalization, is not a subordinate layer of the business but an enterprise within the enterprise: with its own capabilities, its own value streams, its own operational heart, its own architecture.
Two architectures. One customer.
BDAT and IDAT side by side, both oriented toward the customer
Every role in the business sees BDAT through its own window. Every role in IT sees IDAT through its own window. The windows are many; the reality is one. And what flows through all of them, across departments, across the business / IT divide, across the Möbius surface, is data, work, decisions, value.
This is where the toolchain stops being a topic for IT specialists and becomes the substance of the enterprise itself.
Seen from the outside, the toolchain is the customer journey. The customer doesn’t experience marketing, then sales, then service as separate functions. They experience the seams between the tools that hold those functions. A broken handover between CRM and ERP is not a backend issue; it is a moment in the customer’s day where the enterprise stops feeling like one company. A clean flow from inquiry to invoice to support is not operational excellence; it is the customer journey, made real.
Seen from the inside, the toolchain is the we of the enterprise. It is the shared ground on which colleagues from different functions, different specializations, different windows, recognize that they are looking at the same world. Without that shared ground, “collaboration” is a value statement on a wall. With it, collaboration becomes the natural state, because the tools themselves carry the recognition that we are all building the same thing.
This is also where EA4EA becomes a daily practice rather than a concept. The operational question it poses, every day, is simple: which capabilities are enabled by which D-A-T architectures, and how do we bring them into alignment, for the customer outside and for the colleagues inside?
The full potential of this view unfolds only in the interplay. Not in silos. Not in bridges between silos. In the recognition that what looked like two sides was always one surface.
Two perspectives, one toolchain. Two architectures, one customer. Two motions, one world.
This is EA4EA.
What Comes Next
This article opens a space, for ideas that’ll follow at archforsense.com.
Toward AI. What does it mean for AI when IT itself is treated as an enterprise with its own architecture?
Toward collaboration. What does it mean for the way we work together when the toolchain becomes the we of the enterprise?
More on both, soon.
Attribution
EA4EA — Enterprise Architecture for Enterprise Architecture
© 2026 Eric Hedler. Published at archforsense.com
EA4EA incorporates Value Stream terminology (S2P, R2D, R2F, D2C) from the IT4IT™ Reference Architecture. IT4IT™ is a trademark of The Open Group. EA4EA and IDAT are independent of and not affiliated with The Open Group.
