From Enterprise Architecture Transformation: A Practical Guide
Before enterprise architects leave for holiday, it is useful to do a small health check on the enterprise architecture (EA) function.
EA functions tend to collect unfinished decisions, open questions, architecture tasks, and half-finished descriptions. That is normal. Architecture work sits between strategy, development, IT, operations, and governance, so it naturally attracts topics that are important enough to matter and unclear enough to need attention.
That is exactly why the state of the EA function is worth checking before a longer break. And this is best done together, not as a private evening exercise by the person who already has too much on their plate. A short discussion within the EA team usually reveals quickly whether responsibilities are clear, decisions are documented, and someone else can continue the work when needed.
This is a practical check rather than a maturity assessment, an architecture review, or a three-day governance exercise. The idea is to make sure that the most important architecture topics, responsibilities, deliverables, and decisions are in a good enough state. Enterprise architects should be able to close the laptop, leave for holiday, and let their thoughts move to more urgent seasonal matters, such as grilling something that is delicious but probably too expensive.
Everything rarely becomes finished before the holidays. That is fine. The more useful goal is to leave the EA function in a state where work can continue, decisions can be made, and people know what they are supposed to do next.
In other words, architecture work should rely on clear responsibilities and shared understanding rather than one person remembering everything.
1. Are the Open Architecture Issues Clear?
Most EA functions have open issues. That is normal. If there are no open issues, the organization is either very small, very calm, or not telling the architects everything.
The important question is whether the open issues are visible and understandable.
Which architecture questions are still unresolved? Which assumptions need to be validated? Which dependencies are still unclear? Which topics are waiting for a decision, and which are simply waiting because nobody has had the energy to touch them?
Before the holidays, open issues should be either closed, assigned, or made explicit. Leaving a few things open is fine. Leaving them floating around in meeting notes, chat messages, and someone’s memory is less fine. Especially if that someone is about to spend three weeks somewhere with poor mobile coverage.
2. Are All Relevant Initiatives Supported?
The EA function should also check whether all relevant development initiatives have the architecture support they need.
This does not mean that every project needs a full architecture review, a complete target architecture, and a ceremonial blessing from the architecture board. Some projects need only light guidance. Some need a few good questions at the right time. Some need more serious attention because they affect core capabilities, critical applications, data flows, integrations, security, or long-term technology choices.
The health check is about coverage. Are there important initiatives that the EA function is not aware of? Are there projects making architecture-relevant decisions without support? Are some architects overloaded while other topics receive no attention at all?
A project that does not ask for architecture support may be doing perfectly well. Or it may be quietly creating a problem for August. Both options exist. Only one of them is pleasant.
3. Are Architecture Decisions Clear?
Architecture decisions have a habit of becoming blurry.
A direction is discussed. Someone agrees “in principle.” A slide is updated. A steering group nods. The architect makes notes. Later, everyone remembers the decision slightly differently.
Before the holiday season, it is worth checking whether the important architecture decisions are clear. What has been decided? Who made the decision? What alternatives were considered? What assumptions does the decision depend on? What still needs to be confirmed?
This does not require a heavy decision log with more fields than actual decisions. But the important decisions should be documented well enough that someone else can understand them later.
A decision that only exists in the chief architect’s head is fragile. It may feel clear at the time, but after a few weeks of holiday, it can become just another item in the long list of things someone meant to write down.
4. Does Every Architecture Task Have an Owner?
Architecture work often fails between meetings.
A topic is discussed, everyone agrees it is important, and then it quietly waits for someone to do something. Usually this someone has no name, no time, and no idea that they have been selected.
Before the holidays, every important architecture task should have an owner and a clear next step.
Who will update the application landscape? Who will prepare the recommendation for the integration approach? Who will clarify the data ownership issue? Who will support the CRM project while the lead architect is away? Who will follow up on the security architecture concern?
The owner does not need to solve everything alone. But someone needs to hold the ball. Otherwise the ball will still be there in August, only slightly dustier.
5. Are Escalation Paths Clear?
Some things can wait until after the holidays. Some things should not.
The EA function should be clear about what needs escalation, who can make decisions during absences, and which topics can safely wait. This is especially important if architecture governance depends heavily on a few senior people.
Who can approve exceptions? Who can give direction if a project needs an architecture decision? Who should be contacted if a critical need appears? Which decisions must wait for the chief architect, and which can be handled by others?
It is not about creating drama but about reducing unnecessary drama.
A good holiday setup makes it clear when people can move forward and when they should stop and ask for help. Without this, organizations tend to do both at the wrong time.
6. Are Architecture Descriptions Usable Without Their Author?
Architecture descriptions should be understandable without the person who created them standing next to the screen.
That is a painfully useful test. Can someone understand the current state, target state, dependencies, and key open questions from the available material? Are the most important descriptions up to date? Do they support the decisions and projects that are active now? Is it clear where the latest official version can be found?
The goal is to make the critical descriptions usable enough before the holidays. This does not mean perfecting the architecture repository before July. That way lies sadness. It means making sure that people can find the right material, trust that it is current enough, and use it without a private guided tour from the original author.
If a diagram needs a 45-minute explanation before it means anything, it may still have some value. But if nobody knows whether it is the latest version, it becomes less of an architecture description and more of an organizational rumor with boxes and arrows.
7. Is the Autumn Pipeline Visible?
Before the holidays, it is also useful to look slightly ahead.
What architecture topics are likely to become important in August and September? Which initiatives are starting? Which decisions are coming? Which strategy, portfolio, sourcing, or technology discussions will need architecture input? Which architecture descriptions should be started, updated, or prepared when people return?
The EA function should have enough visibility to avoid starting from zero after the holidays. It should be clear which topics need architecture support, which descriptions will be needed first, and who will take the first steps.
Autumn usually arrives faster than expected. Much like architecture debt, but with more calendar invitations.
Leave the Architecture Function in a Usable State
The purpose of this health check is not to make the EA function perfect before the holidays.
The purpose is more practical. Open issues are clear. Relevant projects have support. Architecture decisions are documented. Tasks have owners. Escalation paths are known. Critical descriptions are usable. The autumn pipeline is visible enough.
That is already a lot.
And if these things are in place, even the chief architect can probably leave for holiday with a reasonably clear conscience.
Not completely, of course. That would be unrealistic. But clear enough.
🏖️ A Short Summer Break
I will also take a short summer break from publishing.
The next post will come in mid-August. Until then, I hope your architecture decisions are documented, your open issues have owners, and your holiday is not interrupted by urgent questions about integration principles.
Have a good summer!
🔗 You May Also Like
Looking to dive deeper? Here are more enterprise architecture insights you might find useful:
👨💻 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 | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | 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.
