There are two kinds of Enterprise Architects. The first kind reads a chapter of an industry framework, finds a reference architecture on a vendor blog, redraws it in their tool of choice, and presents it as their own thinking. They are useful. They are also, on a long enough timeline, automatable. The second kind treats every engagement as a small piece of original research. They produce frameworks, not slides. They get paid for what only they could have written. I’ve been thinking a lot about which one I’m becoming, and a passage I read recently sharpened the question in a way I want to share.
The argument that started it runs like this: a part-timer is paid for time, but a professional is paid for capability, for the outcomes their ability creates. If your salary depends on the hours you sit at your desk, you’re a part-timer wearing a corporate badge. That stings, because for most of us in salaried architecture roles the truth is uncomfortable. We are technically paid by the hour even when the contract says otherwise. The senior architect who spends Friday afternoon in a stakeholder meeting that produces nothing has been paid the same as the one who spent it drafting a target-state model that will save their division eight figures over three years. The market eventually corrects this. The first architect’s role gets redefined as a coordination function, and coordination is exactly what AI is coming for first. The question for every architect is no longer what they deliver. It’s what they create that no one else could have.
Most people cluster around the mean. That has always been true. What’s new is that the value of clustering around the mean has collapsed. For an EA function, anyone-can-do-it work used to mean entry-level documentation. In 2026 it means drawing a context diagram from a transcript, mapping an application to a capability through the obvious keyword match, producing a current-state inventory from a CMDB extract, or writing a principles document by remixing the previous one. A junior with the right AI assistant does each of these in minutes. If your value proposition is that you can do this carefully and consistently, you’ve described a tool, not a person. The architects who keep getting the interesting problems share something else: they have a point of view that the AI doesn’t, and that point of view didn’t come from frameworks. It came from the friction of having seen things, written things, and reconciled things no one had quite reconciled before.
There is a metaphor I like for what senior architects actually have in their heads. Imagine each thing you know, a regulatory clause, a deployment pattern, a war story from a failed integration, a fund-flow diagram, as a Lego brick. Not a fact in a list, but a brick with studs on top and slots underneath, waiting to click onto something else. A junior architect has a pile of bricks. A senior architect has an interlocking structure, and the moment a new brick arrives, a new regulation, a new vendor pattern, a new failure mode, it finds its place inside the structure, and sometimes the whole structure reorganises around it. This is the difference between memorising frameworks and thinking architecturally. It is also the difference between an architect who panics when the rules change and one who quietly says, here is where this fits, and here is what now becomes irrelevant. The implication for how we learn is uncomfortable: collecting more bricks is not the goal. Wiring the bricks together is the goal, and you can only wire them together by writing, debating, and being wrong in public.
Here is where most ambitious architects, myself absolutely included, get stuck. We read a lot. We listen to podcasts at 1.5x speed. We bookmark analyst reports. We attend webinars. We feel productive. And then a year passes and we cannot point to a single new framework, model, or pattern that we produced. The reframe that helped me is simple: input is a means, not an end. The purpose of input is to sharpen your own questions and produce output. Reading a paper to stay current is consumption. Reading the same paper to answer a question you’ve already written down is research. The first leaves you slightly more informed and entirely replaceable. The second leaves you with a draft of something only you could have written. I’ve started keeping a literal list of questions I want to answer, and the next book or paper I read, I read against the list. Anything that doesn’t connect to a question gets skimmed and dropped.
A small confession: until recently, I rarely read academic papers. I read books, vendor whitepapers, consultancy PDFs, the occasional Substack. Then a line stuck with me: no amount of learning becomes research. The point is not snobbery. It is that books and analyst reports are second-hand knowledge, by the time they’re packaged for general consumption, the original insight is two or three years old and has been smoothed of all the interesting edges. Papers are knowledge direct from the producer, with the methodology visible and the limitations honestly stated. For an architect, that matters in two ways. You stop confusing popularity with truth, because a pattern everyone is talking about on LinkedIn is often three years downstream of a paper that already showed its limits. And you learn the structure of a real argument, since papers force claim, evidence, and limitation into the open. Most architecture documents would be dramatically better if they were forced through the same shape. If you have never tried it, Google Scholar and SSRN are reasonable starting points, and the working-paper sections of central banks and regulators are often surprisingly readable.
I will be candid: I am writing this partly to commit to it publicly. The pull toward consumption is enormous. There is always one more report to read, one more LinkedIn post to skim, one more course to enrol in. The pull toward production is harder, slower, and at first lower quality. It is the difference between feeling smart and being useful. But the architects whose work I respect, the ones I want to be like in ten years, share one trait. They write things down. They take a position. They are wrong in public sometimes. And over years, they accumulate a body of original work that compounds into something no framework certification can replicate. That is the bet I want to make.
If this resonates, don’t try to overhaul your reading habit, your career strategy, or your knowledge graph this weekend. Do one thing: write down five questions you wish someone would answer about your specific architecture domain, questions you haven’t seen answered well anywhere. Pick the one that scares you most. That is your first piece of research. Everything else, the reading, the structuring, the writing, follows from having a real question of your own.