An Architectural View on Why Work Never Gets Finished
Why organizations keep starting—and what architects can do about closure
Happy New Year!
The turn of the year is supposed to be about fresh starts. Calendars reset, priorities get reshuffled, and for a brief moment it feels like some things might finally be left behind.
That’s the theory, anyway. In practice, in some of my current assignments, I have a task list in Outlook that never really changes. Items rotate, dates move, details are added—but the list itself remain. Tasks are not so much completed as carried forward, quietly surviving every planning cycle. At some point, you stop expecting the list to get shorter. You just learn to live with it.
Architecture work has a peculiar rhythm like that. Priorities shift, roadmaps evolve, diagrams get updated. From the outside, it looks like steady progress. But the work itself rarely ends. Items don’t disappear; they rotate. If you are an architect, this probably feels familiar—and slightly irritating.
To be clear, enterprise architecture (EA) work is continuous by nature. It does not “finish,” and it shouldn’t. But individual architectural tasks are different. They should have a clear endpoint: a deliverable produced, a review completed, or an approval given elsewhere. When that distinction starts to blur, everything begins to feel permanently unfinished. And that is usually not a personal productivity problem. It is a structural one.
This article is about why architecture work so often feels like this—and what architects can realistically do when “done” keeps drifting just out of reach.
Organizations Love Beginnings
That sense of permanent incompleteness is not accidental. It follows a pattern that many organizations share.
New strategies appear regularly. New technologies are introduced with enthusiasm. New initiatives are launched before the previous ones are properly closed. Old work is not finished; it is reclassified as “ongoing,” “continuous,” or quietly folded into “phase two.”
From an architectural perspective, this creates a one-way accumulation. Portfolios grow wider every year but almost never smaller. Applications, integrations, and data groups are added, but rarely retired. Temporary solutions settle in and become permanent residents. Priorities shift, but they are seldom removed.
The structure strongly rewards starting new work, while offering very little support for deliberately finishing and closing the old.
The Architect’s Role Makes This Worse
The feeling of permanent incompleteness is amplified by the nature of the architect role itself.
Architects depend on other people’s work and on information that lives elsewhere. They do not invent the content of the current state; they structure, validate, and make visible information provided by others. They also don’t implement solutions or own budgets, and rarely make the final decisions.
Architect’s role is to facilitate, clarify, and support: to make dependencies and consequences visible, and to structure discussions so that decisions can be made. But making decisions possible is not the same as making decisions happen.
Architects can complete their outputs—current state models, principles, target states—but not the outcomes they are meant to enable. You can finish the model, but not the change. You can close the architectural task on paper, while the real issue stays open.
Motion Without Closure Looks Like Progress
The actual decision-makers usually sit higher in the organization. They carry formal responsibility, but their attention is fragmented across strategy, operations, politics, and the next urgent issue. Architectural topics compete with many others, and postponing a decision is often the easiest short-term option. Nothing breaks immediately. The meeting still has to end on time.
This creates a structural gap. Architectural work progresses, but decisions lag behind.
Topics move through forums, documents get refined, and alignment increases—but ownership does not. It looks like progress from the outside. Inside, it feels like motion without arrival.
What an Architect Can—and Cannot—Do
There is an uncomfortable truth here: an individual architect cannot fix this alone.
You cannot create architectural content alone. You cannot force decisions you don’t own. You cannot end initiatives that management keeps alive. And you cannot “solve” structural indecisiveness with better diagrams.
What you can do is help the organization see the cost of never finishing.
Some survival tips that may actually help:
Take care of your own patch. Finish your part cleanly, so nothing unnecessary is left hanging on your side. Be explicit about what is done, what is intentionally left open, and what is no longer owned by architecture. Structural ambiguity is an organizational issue—not a personal one.
Design for endings. When something new is introduced, ask what will be retired. Name the application, integration, report, or process that should disappear. If nothing is named, “nothing” is already the decision.
Make closure visible. Treat end states, exit criteria, and decommissioning as part of the design itself. If an initiative has a start date, make its end condition visible—even if that end is conditional or phased.
Lower the bar for input—and make assumptions explicit. Do not wait for perfect information. Use partial input, document reasonable assumptions, and mark them clearly. Incomplete input is often more useful than no input at all.
Show drafts and timebox waiting. Rough models trigger reactions; empty templates do not. Set a visible deadline after which the work continues with assumptions rather than waiting indefinitely.
Frame incompleteness as a trade-off. Not everything has to end. But keeping everything open consumes attention, budget, and decision-making capacity. Make that cost explicit: what cannot change as long as this remains unfinished?
Separate architectural work from organizational waiting. Waiting for input, decisions, or alignment is not architectural progress. Make that distinction visible—to others, and to yourself.
Use language that reflects reality. If something is stalled, call it stalled. If ownership or input is missing, say so. Soft wording makes unfinished work easier to tolerate and harder to resolve.
This does not magically create closure. But it turns vague frustration into a conscious structural issue, which is already an improvement.
A Different Question to Ask
At the start of a new year, organizations usually ask what they should begin: new initiatives, new capabilities, new transformations.
Architects might want to ask a different question:
What will we actually allow to end this year?
Not pause. Not reframe. Not absorb into something bigger.
But end.
Until organizations become as intentional about endings as they are about beginnings, architecture work will continue to feel unfinished. And architects will keep noticing it first—not because they are cynical, but because they see the structure clearly.
Sometimes that uneasy feeling is not a problem to fix. It is simply architecture doing its job.
🎥 New Video: What My Enterprise Architecture Book Is Really About
I’ve just published a short and lighthearted video introducing my book Enterprise Architecture – Your Guide to Organizational Transformation.
In the video, I explain what the book covers, who it’s written for, and what you’ll get from.
🎞️ Book Launch Videos Available
If you couldn’t attend the launch for my book Enterprise Architecture – Your Guide to Organizational Transformation live, the recordings are now available.
If you want a compact overview of why the book was written and how enterprise architecture is approached in practice, this is an easy way to catch up.
Each video includes the presentation part. The Q&A session and participant list have been removed for privacy reasons.
English event recording (Thursday, October 30, 2025)
Finnish event recording (Wednesday, October 22, 2025)
👨💻 About the Author
Eetu Niemi is an enterprise architect, consultant, and author.
Follow him elsewhere: Homepage | LinkedIn | Substack (consulting) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.