Middle-Out Architecture: The Missing Link Between Enterprise Architecture and Systems Engineering

Architecture comes into focus where strategy and systems meet.
By Ed Bednar

Suppose, for a moment, that we need to understand how a machine as complex as a modern aircraft is constructed.

The Gap Between Organizational Models and Engineered Systems

We might begin with an Aircraft Manufacturing Capability Map to define the organization’s aerospace competencies.

This might be supported by Aerospace Supply Chain Value Streams describing the realization of commercial passenger transportation. 

Then, we might establish Aircraft Information Domain Models to ensure conceptual alignment between flight operations, maintenance telemetry, and transportation data entities. 

From there, we might create Avionics Application Portfolios and Flight Systems Technology Reference Architectures to provide governance oversight of the aircraft technology ecosystem. 

Then, Transition Architectures for Next-Generation Fleet Enablement might define the roadmap toward future-state sustainable objectives for the aviation business.

And finally, Aviation Governance Frameworks might be used to establish standards oversight, stakeholder alignment, and lifecycle governance across the aircraft delivery ecosystem.

Except that, so far, while we may have learned quite a bit about the organization surrounding the aircraft, we’ve learned very little about the aircraft itself.

And at some point, we need to understand the machine we are actually building. Where are the engines? How do they work? How fast can the thing go?

Why Planning Models Are Not Structural Models

An aerospace manufacturer absolutely cares about portfolio management, supply chain capabilities, maintenance governance, and fleet modernization roadmaps, so these planning abstractions can be important.

They describe the organizational ecosystem surrounding the aircraft, and they can make perfect sense from an organizational, operational, regulatory, and corporate planning perspective.

In the right setting, they are entirely appropriate, although it’s arguable if enterprise architecture is really where developing these abstractions is best situated in most organizations.

But aircraft construction itself is not structurally understood through planning abstractions. You have to get down to the metal to understand the major assemblies, like the engines. Or into the metal, if we’re being more technically precise.

Understanding the aircraft requires a different kind of model, one concerned with the structure of the system itself rather than the organization surrounding it.

Why Enterprise Architecture Needs a Structural Representation

Many enterprise architecture approaches are quite good at describing organizational intent through conceptual models.

But they often stop short of establishing a stable structural representation of the organization’s systems, which creates a persistent disconnect between architecture and engineering.

That’s because, in some corners of enterprise architecture, one can travel quite a long way through layers of abstraction without ever encountering the system itself.

Engineering, by contrast, is concerned with structure, behavior, and operation.

Most large organizations can benefit from both perspectives. The challenge is connecting them.

And the architecture blueprint provides a common structural model through which both disciplines can reason about the same system.

This shared structural representation is where if you are working with high-level enterprise architecture abstractions, they can be resolved to systems engineering structure in a pragmatic way.

I refer to the approach as middle-out architecture.

Architecture Blueprints as the Structural Layer

The architecture blueprint provides the shared structural representation where enterprise architecture and systems engineering converge.

It establishes the asset structure in the middle, much as assemblies provide the structural organization of a complex machine like an aircraft.

To illustrate how middle-out architecture works, we’ll walk through a simple customer management example.

From Capability Maps to Architecture Assets

A capability map describes what an organization must be able to do to execute its strategy and operate its business.

The capability itself is not the implementation. It is a business construct.

From there, the capability resolves into the architecture assets through which it is realized.

The architecture blueprint provides the structural traceability that makes this transition explicit, connecting strategic abstractions to the systems that enable them.

For example, a Customer Account Management capability might be realized through application assets such as a CRM platform and data assets such as a Customer Master dataset.

Those assets, in turn, depend on infrastructure, security, and technology assets.

Middle-out architecture makes this relationship explicit by providing a shared structural representation through which strategy, architecture, engineering, and operations can reason about the same system.

Asset Design and Structural Decomposition

A dataset such as Customer Master is a data asset composed of multiple layers.

Each layer represents a different aspect of the asset’s design and is developed through corresponding architecture and engineering techniques:

• Conceptual – Meaning and Identity
• Logical – Structure and Rules
• Physical – Platform Implementation
• Operational – Runtime Behavior

This layered decomposition provides the structural representation of the asset and is typically already where architecture and implementation intersect.

• The conceptual layer defines meaning and identity through artifacts such as glossaries and data definitions.
• The logical layer establishes structure and rules through taxonomies, metadata models, and related representations.
• The physical layer implements those structures through database schemas, tables, and views.
• The operational layer governs runtime behavior through interface specifications, lifecycle policies, and operational controls.

The additional step is connecting this structural representation to planning abstractions such as capability maps, value streams, and reference architectures. These artifacts are often treated as architecture, even though they describe the organization surrounding the system rather than the structure of the system itself.

For a detailed walkthrough of what this looks like for application assets, see Extending the Architecture Blueprint: Modules, Components, and Architectural Decomposition.

Connecting Enterprise Architecture to Systems Engineering

We have now traced a strategic abstraction through architecture assets to the structural design of the system that realizes it.

Capability maps, value streams, reference architectures, and solution designs all serve different purposes. But if your goal is, like mine, to make a computer do something, it all must be connected and put into motion.

The architecture blueprint provides a shared structural representation through which strategy, architecture, engineering, and operations connect and through which we can reason about the same system.

In this way, enterprise architecture can become the meeting point between organizational intent and engineered systems.

In the next article, Enterprise Architecture Blueprints: Don’t Draw a Rectangle, we’ll explore how architecture blueprints can be developed and managed at scale.

Notes:
1. Headline image generated by Gemini and ChatGPT.