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

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 would be supported by Aerospace Supply Chain Value Streams describing the realization of commercial passenger transportation. 

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

From there, we would 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 would define the roadmap toward future-state sustainable objectives for the aviation business.

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

So far, we have learned quite a bit about the organization surrounding the aircraft, but very little about the aircraft itself.

At some point, though, 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.

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 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 the structure, behavior, and operation.

Most large organizations need both perspectives. The challenge is connecting them.

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

This shared structural representation is where enterprise architecture and systems engineering meet. I refer to this 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 often 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.

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.

The architecture blueprint connects them by providing a shared structural representation through which strategy, architecture, engineering, and operations can reason about the same system.

In this way, enterprise architecture becomes 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.