sema.cloud
Post
Enterprise Architecture

Agility Needs Structure: How Enterprise Architecture Enables Change Without Chaos

Companion to LinkedIn Post 4 — “Agility Needs Structure”

The first three articles in this series made the case for Enterprise Architecture as a discipline: not a collection of diagrams, not a particular framework, and not a technology practice. Enterprise Architecture creates value when it helps an organization move from strategy to coherent, operable change.

At the end of the previous article, I described the next subject as TOGAF in a cloud-native world: how the framework evolves when architecture is delivered through platforms, products, and continuously changing systems. But the question is larger than TOGAF, and larger than cloud-native technology.

The answer is not a new framework for every new technology. It is understanding what a framework is for. A framework should give the enterprise enough structure to preserve direction, coordinate decisions, and learn from implementation — but not so much that the structure becomes the objective. TOGAF provides a mature working example of that principle, not its boundary.

Every business wants to be agile.

Markets move. Regulations change. New competitors alter customer expectations. Acquisitions redraw organizational boundaries. A technology that looked optional eighteen months ago becomes the price of remaining relevant.

The instinctive response is to remove structure. Fewer controls. Fewer standards. Fewer artifacts. Fewer people involved in decisions. Give teams autonomy and let them move.

Some of that instinct is healthy. Organizations accumulate processes long after those processes stop creating value. But eliminating unnecessary bureaucracy is not the same as eliminating structure.

Agility does not come from eliminating structure. It comes from having enough structure to change without creating chaos.

Three operating conditions showing that too little structure creates chaos, too much creates paralysis, and deliberately tailored structure enables coherent agility

A team can move quickly without the enterprise becoming more agile. If every initiative has to rediscover who owns a decision, where authoritative data resides, which capabilities already exist, how systems connect, and which obligations apply, the organization is not adapting. It is improvising.

That is why Enterprise Architecture needs a framework and a structured, repeatable process.

The framework does not have to be TOGAF. It does not have to use a particular notation, repository, or governance model. It does have to give the organization a consistent way to understand change, involve the right people, make decisions, guide implementation, and learn from the result.

TOGAF is useful here because it is one of the most mature and established examples. It is also useful because it demonstrates both the value of a framework and the easiest way to misuse one.

The weight of the whole framework

When people first encounter a comprehensive framework such as TOGAF, they see its full scope: methods, phases, techniques, governance, repositories, content structures, and deliverables.

It can look as if an architecture department must implement all of it before creating value.

That is the trap.

A framework is comprehensive because enterprises face a wide range of problems. A regulated financial institution integrating an acquisition does not need the same depth of analysis as a regional business introducing a new customer capability. A global organization changing its operating model does not need the same stakeholders, views, or governance as a product team replacing a single application.

The existence of a technique or deliverable in a framework does not make it necessary for every decision.

The right starting point is not:

How do we implement the framework?

It is:

We have a business problem or strategic change. Which architectural questions must we answer, which stakeholders must participate, and which parts of our architecture process will help us move coherently?

That difference matters. The first question makes framework adoption the objective. The second makes better enterprise decisions the objective.

The value of structure is not that every initiative follows an identical path. It is that the organization does not invent a new path every time.

The enterprise does not work for the framework

Here is the blunt reframe:

A framework should help the enterprise make better decisions. The enterprise should never manufacture work merely to demonstrate fidelity to the framework.

Frameworks can create a peculiar kind of organizational gravity. Once adopted, their terminology enters job descriptions, templates, review boards, and policies. Teams begin producing artifacts because the process requests them, not because a decision requires them. Completion becomes a proxy for quality. Conformance to the method becomes easier to measure than whether the method improved an outcome.

The framework has quietly changed from a tool into a customer.

A healthy architecture practice resists that inversion. It uses a framework to establish a shared foundation:

  • A common language for discussing the enterprise
  • A repeatable set of questions
  • A way to identify stakeholders and understand their concerns
  • A way to examine change across business, information, application, and technology domains
  • A structure for making and recording consequential decisions
  • A connection between strategy and implementation
  • A mechanism for learning from results

How those elements are applied should depend on the problem, the risk, and the maturity of the organization.

That requires tailoring. Tailoring is sometimes described as a concession made by organizations that are not ready to adopt the complete method. I see it differently.

Tailoring is not weakening a framework. It is the architectural judgment required to make the framework useful.

The Open Group makes this point about TOGAF’s Architecture Development Method. It describes architecture development as iterative and ongoing, and explicitly says the ADM may need to be modified or extended for the circumstances of the enterprise. The method is a body of proven practice from which an organization configures an approach; it is not a universal project plan.

The same principle applies to any framework. Start with the decision the enterprise needs to make. Choose the depth of analysis that the consequence of that decision deserves. Engage the people who own, understand, fund, operate, or will be affected by the outcome. Produce only the information necessary to create clarity and carry the decision into implementation.

Consistency should exist in the questions and decision discipline, not in the volume of paperwork.

A repeatable process is a feedback loop

TOGAF’s Architecture Development Method, or ADM, is a useful working example of what a repeatable architecture process can provide.

Viewed as a large diagram of named phases, the ADM can appear linear and imposing. Viewed in terms of the questions it helps an enterprise answer, it is much more practical:

  1. Understand the pressure for change. What happened in the market, business, regulatory environment, operating model, or technology landscape that requires a response?
  2. Establish direction and constraints. What outcome matters, what principles guide the response, and what limits cannot be ignored?
  3. Examine the affected domains. How will the change affect business capabilities, information, applications, technology, people, ownership, and operations?
  4. Identify viable paths forward. What options exist, what do they cost, what risks do they carry, and what do they make possible later?
  5. Sequence the change. What can the organization implement coherently, and in what order?
  6. Govern implementation. Are decisions surviving contact with budgets, delivery pressure, and operational reality?
  7. Observe what happens. Did the change produce the expected business and operational outcomes?
  8. Feed the evidence into the next decision. Which assumptions were right, which were wrong, and what should change as a result?

An eight-stage architecture learning loop moving from pressure for change through direction, affected domains, viable paths, sequencing, implementation, and observation before evidence feeds the next decision

This is not a demand that every initiative execute eight formal stages. It is a way of seeing architecture as a learning system.

A repeatable process prevents important questions from disappearing simply because a deadline is close or a particular stakeholder is not in the room. It gives the organization a known way to move from pressure for change to informed action. Because the process is familiar, attention can go to the problem instead of renegotiating how the problem will be approached.

The final two activities are especially important.

Implementation is not the end of architecture. It generates evidence that should modify the architecture.

A decision may be strategically sound and still prove too expensive to operate. A shared capability may be technically effective but poorly adopted. A policy may reduce one risk while introducing delivery friction somewhere else. A market assumption may change before a program finishes.

If implementation evidence does not travel back into architectural decisions, the process is not a loop. It is a document handoff.

This is where a structured process improves agility. The organization does not cling to a plan merely because it was approved. It has a deliberate mechanism for observing outcomes, challenging assumptions, and changing direction without discarding everything it has learned.

Stability is what makes agility possible

An enterprise cannot respond rapidly when every change requires rediscovering:

  • Who owns the decision
  • Which capabilities already exist
  • Where authoritative data resides
  • How systems integrate
  • Which security and regulatory requirements apply
  • Which standards are mandatory
  • Which exceptions already exist
  • What dependencies could break

That information does not eliminate uncertainty. It eliminates avoidable uncertainty.

Enterprise Architecture gives the organization memory. It preserves the small amount of stability needed to move quickly:

  • Shared language, so teams do not spend the first month debating what the problem means
  • Clear ownership, so decisions reach the people accountable for their consequences
  • Known boundaries, so local autonomy and enterprise responsibility are understood
  • Reusable capabilities, so the organization does not rebuild what it already knows how to provide
  • Traceable decisions, so teams understand why a constraint exists and when it should be reconsidered
  • Visible dependencies, so speed in one area does not produce a surprise somewhere else
  • Current principles and standards, so recurring decisions do not restart from first principles

The same business change entering two organizations: one begins with questions and rediscovery, while the other begins with clear ownership, trusted information, visible dependencies, current standards, reusable capabilities, and traceable decisions

This is organizational memory with a purpose. It reduces the cost and uncertainty of the next change.

Consider a business responding to a new regulatory requirement. Without a shared understanding of data ownership, system dependencies, control responsibilities, and decision authority, the response begins with discovery under pressure. Different teams interpret the requirement independently. Work is duplicated. Gaps surface late. Temporary controls become permanent because nobody has time to design a coherent alternative.

With the right architecture foundation, the enterprise still has difficult decisions to make. But it knows where to begin. It can identify the affected capabilities and stakeholders, trace where relevant information moves, distinguish existing controls from genuine gaps, and coordinate a response through a process people already understand.

The framework did not predict the regulation. It preserved the enterprise’s ability to respond to it.

That is the kind of stability agility needs.

Structure should stabilize how the enterprise understands and governs change. It should not freeze the technologies, products, or business models that need to evolve.

Too little structure creates fragmentation. Too much creates paralysis. The architecture practice has to find the useful minimum: enough consistency to keep the enterprise coherent, with enough freedom to let the response fit the situation.

Use only the architecture products that earn their keep

Eric Jager offers a pragmatic perspective on this problem in Getting Started with Enterprise Architecture: A Practical and Pragmatic Approach to Learning the Basics of Enterprise Architecture. Jager developed an Enterprise Architecture Implementation Wheel, a four-stage approach organized around documenting, defining, implementing, and monitoring a fundamental Enterprise Architecture. His approach uses clearly defined architecture products to make the work practical and applicable.

That implementation wheel is Jager’s model, not mine. What I take from it is the practical discipline of connecting architecture products to the work of establishing, applying, and improving an architecture practice.

An artifact earns its place if it helps someone:

  • Make a decision
  • Understand an impact
  • Coordinate change
  • Manage risk
  • Govern implementation
  • Measure an outcome

The useful test is straightforward:

Who uses this, what decision does it support, and what becomes harder if it does not exist?

If nobody can answer those questions, the artifact is probably documentation overhead.

This does not mean the goal is to produce as little architecture as possible. Minimalism can become its own ideology. Some decisions genuinely require detailed models, multiple viewpoints, careful traceability, and durable records. In a highly regulated environment, an artifact may earn its keep by providing evidence long after the original decision. In a complex transformation, a view may be the only practical way for several groups to understand the same dependency.

The objective is not the fewest products. It is the smallest coherent set that supports the decisions the enterprise repeatedly needs to make.

Each product should have a consumer and a lifecycle. Someone should be responsible for keeping it useful. If it represents a decision, it should change when the decision changes. If it shows a dependency, it should be current enough to guide action. If it exists only because a methodology once listed it, it should be challenged.

An outdated architecture repository can be worse than no repository at all. It gives false confidence to the people who assume the organization remembers more than it actually does.

Repeatability should create learning, not ceremony

There is an important distinction between a repeatable process and a rigid one.

A rigid process performs the same activities regardless of context. A repeatable process preserves the same decision discipline while adjusting its depth to the situation.

A low-risk, reversible change may need a short conversation, a recorded decision, and confirmation that established boundaries still apply. A change affecting customer identity, regulated data, or several business units deserves broader participation and deeper analysis. Both can use the same architecture process without receiving the same treatment.

The repeatable elements are:

  • How the pressure for change is made explicit
  • How stakeholders and concerns are identified
  • How impacts across domains are considered
  • How decisions and assumptions are recorded
  • How implementation is governed in proportion to risk
  • How outcomes are observed
  • How learning returns to the architecture

This creates consistency without pretending that every problem is the same size.

It also creates trust. Business leaders know what the architecture practice will help them understand. Delivery teams know when they can act independently and when a change requires coordination. Architects know which questions they are accountable for answering. Governance becomes more predictable because it is based on consequence, not preference.

Predictability reduces organizational anxiety. People do not have to navigate an informal network to discover who can approve a decision or what an architecture review might demand. Exceptions can be discussed openly. Constraints can be traced to their rationale. Decisions can be revisited when the evidence changes.

That is sanity in an IT journey: not the absence of uncertainty, but a reliable way to work through it.

Measure the framework by the next change

An architecture framework should not be judged by how completely it has been implemented.

It should be judged by what happens when the enterprise needs to change again.

When a market moves, can the organization quickly identify the capabilities affected? When a regulation changes, does it know where the relevant data and controls live? When an acquisition closes, can leaders see the most consequential overlaps and dependencies? When a new technology becomes viable, can the enterprise evaluate it against business need instead of momentum and fear?

If the answer improves over time, the architecture practice is creating value.

A good framework leaves the organization with:

  • A known way to make consequential decisions
  • Visible ownership and dependencies
  • Trusted information about the enterprise
  • Reusable knowledge and capabilities
  • Governance proportionate to risk
  • A mechanism for learning from implementation

None of those prevents change. They make deliberate change possible.

So the question I would ask of any Enterprise Architecture framework, method, artifact, or governance process is:

What is the minimum architecture this organization needs to make its next important change coherently?

The answer will differ by organization and by decision. That is the point. A framework supplies structure and accumulated practice. Architects tailor it to the enterprise in front of them.

The purpose of an architecture framework is not to make the enterprise more architectural.

It is to make the enterprise more capable of changing without losing control of itself.

References