From Any Role into EA Thinking

Part 6 · Navigating the Territory

The book turns outward now. The first five parts mapped the territory — the frameworks, the concepts, the diagrams, the language. This part is about you, the reader, wherever you happen to be sitting. And it opens with a claim that is the quiet thesis of the whole book: you are almost certainly already doing enterprise architecture thinking. You just have not been told that is what it is called.

This chapter shows five common IT roles — the helpdesk analyst, the developer, the infrastructure engineer, the project manager, the business analyst — each already practising EA thinking in the course of ordinary work. The point is not flattery. It is to give you the vocabulary to recognise and name what you already do, because naming it is the first step to doing it deliberately and being seen to do it.

EA Thinking Is Not a Job Title

Enterprise architecture, stripped of its frameworks and certifications, is a particular way of thinking: seeing the whole rather than only the part, noticing the connections between things, weighing the long-term consequence of a near-term decision, and asking what the structure of a situation is rather than only its surface. None of that is the exclusive property of people with “architect” in their title. It is a cognitive habit, and cognitive habits are distributed across roles regardless of who is paid to have them.

This matters for two reasons. First, it means the contribution this book is preparing you to make does not require permission or promotion — you can think this way from where you are. Second, it means the architecture function, when it is good, is not the only place architectural thinking happens; it is the place that coordinates and names the architectural thinking happening everywhere. Recognising the EA thinking in your own work is how you join that conversation.

The Five Things Everyone in IT Already Knows

There are five recognitions that constitute EA thinking, and each is already present in ordinary IT work.

Seeing the system, not just the component. EA thinking sees how parts connect and how a change in one ripples to others. This is not exotic; it is what anyone does when they say “if we change that, it’ll break this other thing.”

Noticing the gap between the local fix and the whole. EA thinking distinguishes the solution that helps here-and-now from the solution that helps the whole over time. Anyone who has resisted a quick fix because “we’ll pay for it later” has had this thought.

Tracing a symptom to its structural cause. EA thinking does not stop at the presenting problem; it asks what underneath produces it. Anyone who has said “this keeps happening — the real problem is upstream” is doing root-cause thinking, which is structural thinking.

Weighing the long horizon against the short. EA thinking holds the consequence over years against the pressure of the moment. Anyone who has flagged that a deadline-driven shortcut creates a lasting liability has weighed the horizons.

Asking who owns the decision. EA thinking notices when a decision has no owner or a process has no accountable party. Anyone who has asked “wait, whose call is this?” has spotted the governance gap that Part 3 spent chapters on.

These five are EA thinking. They are also things competent IT people do every day without a framework in sight. The frameworks are the formalisation; the thinking is the substance, and the substance is already yours.

Five Roles, Already Doing It

Five people at Meridian, none of them architects, each shown doing EA thinking in the course of their ordinary work.

The helpdesk analyst notices that the same category of ticket keeps recurring — clinicians locked out of a system after a password reset on another. She does not just resolve each ticket; she observes the pattern and traces it to its cause: two systems with separate, unsynchronised identity, so a reset in one breaks the other. She has, without naming it, identified the patient-identity architecture problem from the symptom upward. That is structural, system-level EA thinking, performed at the helpdesk.

The developer is asked to build “a quick integration” between his application and the clinical portal. He pushes back: “if I wire these directly, that’s another point-to-point connection, and we’ve already got too many — can we put it through something central instead?” He has recognised a pattern (point-to-point), named its failure mode (proliferation), and proposed a better structure (hub-and-spoke). That is Chapter 31’s pattern thinking, performed in a stand-up.

The infrastructure engineer — the one this chapter’s sibling, Chapter 49, returns to — reviews the VMware exit migration plan and spots that two “low-risk” workloads scheduled for early migration actually feed a clinical tool. She sees the dependency the plan missed because she sees the system, not just the components. That is whole-system EA thinking, performed in a change review.

The project manager running a system procurement asks the question nobody else asked: “before we buy this, have we checked whether we already have something that does it?” She is, without knowing the term, applying portfolio governance (Chapter 27) — the check that prevents duplication. That is EA thinking, performed in a procurement meeting.

The business analyst mapping the referral process notices that one decision point has no defined owner — the unowned eligibility decision from Chapter 37. She flags it: “who actually decides this? Because right now it’s different depending on who picks it up.” That is governance-gap thinking, performed in a process workshop.

None of the five has “architect” in their title. All five are doing EA thinking. The only thing they lack is the vocabulary to name it — and naming it is what would let them contribute to the architecture conversation as recognised participants rather than as people who happened to have a good point.

Why Naming It Matters

It might seem that if you are already thinking this way, the name is irrelevant — the thinking is what counts. But the name does real work, for two reasons.

First, the name makes the thinking transferable. A recurring observation that stays in your head as “this keeps happening” stays a personal frustration. The same observation named as “this is an architecture-debt pattern — separate identity stores producing recurring failures” becomes something you can raise in the architecture conversation, connect to the roadmap, and see acted on. The vocabulary is what lifts the insight from your desk to the decision.

Second, the name makes the thinking visible, and visibility is how contribution gets recognised. The infrastructure engineer who says “I think those workloads have a dependency” makes a useful point. The same engineer who says “those workloads are a hidden cross-system dependency the migration sequence doesn’t account for” is recognisably doing architecture, and is far more likely to be invited into the next planning conversation. Chapter 49 develops this fully; for now the point is that the vocabulary you have acquired across this book is not decoration. It is the means by which the EA thinking you already do becomes EA contribution that others can see and build on.

Translator Panel

People say: “I’m not an architect, I just do [helpdesk / development / infrastructure / delivery / analysis].” > What that means: They are doing EA thinking without claiming the label — seeing the system, tracing symptoms to causes, spotting unowned decisions — and discounting it because they lack the title. The thinking is real architecture; the missing piece is only the vocabulary to name it and the confidence to raise it.

Architects say: “That’s exactly the kind of thinking we need — you’ve spotted a cross-system dependency.” > What that means: They are recognising EA thinking in someone without the title, and naming it. This recognition is how the architecture conversation widens beyond the architecture function — and it is available to anyone whose insight is expressed in terms the conversation recognises.

The Key Idea

Enterprise architecture, stripped of frameworks and titles, is a way of thinking — seeing the whole, noticing connections, tracing symptoms to structural causes, weighing the long horizon, and asking who owns the decision — and it is already distributed across IT roles regardless of who is paid to have it. The helpdesk analyst tracing recurring lockouts to an identity problem, the developer resisting another point-to-point integration, the engineer spotting a hidden dependency, the project manager checking the portfolio before buying, the analyst flagging the unowned decision: all are doing architecture without the label. What they lack is not the thinking but the vocabulary to name it — and naming it matters because it makes the thinking transferable, lifting a private observation into the architecture conversation, and visible, turning EA thinking into recognised EA contribution. The thinking is already yours; this book has been giving you the words.

Next: Chapter 47 puts you inside an architecture conversation and teaches you to follow it — to see what is actually being discussed and where the real decision sits, even when the vocabulary is unfamiliar.