Structure becomes visible once its boundaries are defined.
By Ed Bednar
Architectural thinking often begins in abstraction, reaching for frameworks that promise immediate order.
Frameworks introduce categories, relationships, and sequences, implying that the work has already acquired meaning simply by being named and organized within a formal structure.
But rigorous analysis requires a defined boundary. And before something can be categorized or sequenced, it must first be defined as a coherent whole.
Architecture, at its most basic level, begins with clarification. It determines what is being described and where the limits lie.
But before interrogatives, matrices, or philosophical lineage, before phases, capability maps, or architecture repositories, there is a more primitive architectural instantiation:
Draw a rectangle.
Enterprise Architecture and the Discipline of Boundaries
Each rectangle establishes a boundary. It makes explicit what exists within it, distinct from what surrounds it.
At this stage, there are no arrows, no flows, no sequence, no causality. The drawing does not yet describe behavior, imply timing, or suggest optimization. It is certainly not yet burdened by A through H.
And, importantly, in the beginning, each rectangle is an asset.
From Boundary to Baseline Architecture
What we are building is an architecture blueprint, a diagram of ordered assets.
It is a baseline structural view of the assets that exist across the enterprise’s technology estate—the structural truth at a given moment in time.
This structure is the baseline.
Structural vs. Behavioral Views in Enterprise Architecture
Most architectural artifacts emphasize movement rather than structure.
For example:
- Value stream maps show progression.
- Process diagrams show flow.
- Component models show structural decomposition.
- Sequence diagrams show timing.
- Integration diagrams show exchange.
These are behavioral views. They describe what happens.
A blueprint is different.
A blueprint answers a structural question: What exists, and how is it contained?
A Hierarchy of Contained Assets
An architecture blueprint first identifies assets, then encapsulates them hierarchically.
This encapsulation and hierarchy is not aesthetic. It is structural. At each level, containment reveals dependency throughout the asset hierarchy.
When containment and hierarchy are correctly evaluated, questions of redundancy, coupling, risk, and resilience can be answered precisely.
Why Baseline Architecture Must Come Before Optimization
Optimization begins with coherence. Simplification requires clear boundaries, modernization requires an understanding of what exists, and governance requires a defined structure.
Many architectural efforts stall because they attempt to build momentum for change before establishing structure and ownership, as discussed in Creating the Structural Foundation for Enterprise Architecture and Enterprise Architecture Begins Where Responsibility Is Defined.
They jump to patterns, standards, and roadmaps while the underlying containment model remains ambiguous.
A baseline blueprint does not solve everything. But it does something more fundamental. It makes the system legible.
And legibility is the prerequisite for coherence.
Preparing to Construct the Baseline Architecture
In the next article, Constructing the Baseline Architecture Blueprint, we move from principle to construction. We examine how to draw and layer a baseline blueprint in technical detail.
We explore representing composition and containment cleanly and how to model dependencies without collapsing structure into behavior.
But for now, the discipline is simple:
Draw the rectangle.
The Computer Is Going to Do Something – Join an ongoing, practical examination of technology strategy, enterprise architecture, systems engineering, and technology operations.
Notes:
1. Headline image generated by Gemini and ChatGPT.
Leave a Reply