What Enterprise Architects Should Spend Time On (and What Not)
Focusing time where enterprise architecture truly makes a difference
Enterprise architecture (EA) means different things in different organizations. In one company, EA might own high-level logical architecture models. In another, it could also include solution design, data governance, or even infrastructure standards. Sometimes EA is expected to step in anywhere there’s complexity—whether that’s integration issues, steering groups, or troubleshooting data quality.
That variation is natural, but it creates a challenge: if everything is “EA,” then nothing really is. And if architects try to cover all of it, they risk spreading themselves too thin—spending time on activities that don’t create real architectural impact.
The good news? Even if the exact scope of EA varies, there are still clear patterns of what’s worth focusing on—and what’s often a waste of scarce time and attention.
So let’s talk about what enterprise architects should actually spend their time on—and just as importantly, what not to.
Where Enterprise Architect’s Time Creates the Most Value
If there’s one universal truth about EA, it’s this: you can’t do everything. The discipline touches strategy, development, governance, IT, and operations—but not all activities move the needle equally. The best architects know where to lean in and where to step back.
Here are the areas where time spent by enterprise architects pays off the most:
Guiding decisions early: Architecture has the most impact upstream—when strategy is being translated into plans, when portfolios are shaped, or when projects are still defining what problem they’re solving. Time here multiplies: the earlier the guidance, the more it saves later.
Building and maintaining core architecture content: Not every diagram is worth the effort—but without architecture content, there is no EA. Current application maps, key data flows, capability models, target-state overviews, and principles form the foundation for decision-making across the organization. This is the source material that supports decision-making across the organization. Keep it usable, up to date, and aligned.
Facilitating dialogue: Half (or more) of EA work is conversation. Architects connect business and IT, strategy and delivery, silos and systems. Running workshops, framing trade-offs, making complexity understandable—this is where architecture earns trust and influence.
Connecting to governance: EA doesn’t replace governance, but it should feed into it. Portfolio boards, investment committees, PI planning, steering groups—all work better when architecture insight is present. Time spent here ensures that architecture isn’t a parallel universe but part of how the organization actually steers itself.
Securing continuity: Architecture isn’t a one-off initiative. To make EA sustainable, architects need to invest time in securing sponsorship, resources, and recognition for the function. Without organizational support, even the best EA content risks becoming shelfware.
Where Enterprise Architect’s Time Is Often Wasted
Enterprise architects rarely suffer from having too little to do. The real challenge is knowing what not to spend time on. Without focus, it’s easy to get pulled into activities that look productive but add little actual value.
Here are some of the most common time sinks I’ve seen—and why they’re worth avoiding (or at least limiting):
Perfecting diagrams: Spending hours tweaking notation or alignment rarely changes a decision. Consistency matters, but usability matters more. Deliver “good enough” visuals that people can actually use.
Chasing every detail: You don’t need to model every integration, every report, every process variant. Focus on the 20 % that drives 80 % of the outcomes. Otherwise, you end up curating a massive repository that no one looks at.
Being a late-stage reviewer: If you only show up to review solutions once they’re already designed, you’ve missed the moment. Don’t let EA become a rubber stamp. Your time is better spent earlier, guiding direction.
Doing the work of others: Process design, data modeling, infrastructure decisions—these all need EA input, but they’re rarely an enterprise architect’s core job. Even if the EA function sometimes owns these activities, the real role is to guide and align, not replace delivery teams. That said, if doing a small favor helps win leadership trust or keep things moving, do it—but don’t let it become the norm.
Overinvesting in tools and automation: It’s easy to get caught up tweaking EA tools or chasing the latest automation features. But at the end of the day, a tool is just that—a tool. In practice, you can run EA with very simple setups. Manual modeling rarely takes as much time as people think; the real bottleneck is usually gathering source data and validating EA content. What matters most is the clarity of your models and the conversations they enable, not how sophisticated your tool configuration looks.
Final Thoughts
EA is always a balancing act. You could spend time on almost anything—but only some activities really move the needle.
Invest your effort where architecture:
shapes decisions early,
provides source material that others actually use,
creates shared understanding across silos, and
secures continuity through sponsorship and resources.
And cut back where it doesn’t: polishing models endlessly, documenting everything “just in case,” perfecting tooling, or stepping in only when it’s already too late.
Above all, remember that EA isn’t only about diagrams—it’s about people. Active dialogue with leadership keeps architecture connected to strategy and priorities. Strong ties with top leadership, portfolio managers, business owners, delivery teams, and operations give it influence both at the top and on the ground.
Therefore, EA work only advances if two things happen: architects focus their own time on what matters most, and leaders and other stakeholders commit time to engage. Without both, even the best EA plans stall.
In short: focus, dialogue, and continuity. That’s how EA creates real impact—sustainably, and over time.
Thank You for Reading
A small milestone: this newsletter just passed 500 subscribers! 🚀
For such a niche topic as enterprise architecture, that feels significant—and I’m grateful for every reader.
Thanks for being part of this journey.
🔗 You May Also Like
Looking to dive deeper? Here are more enterprise architecture insights you might find useful:
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.
Hi Eetu, love your work. I think there are a lot of similarities in our thinking, but I think you're missing a couple of critical elements.
I completely agree with some of your key messages:
- Shaping strategy-to-execution before requirements lock down delivers disproportionate value.
- Feeding architectural insight into existing governance structures: portfolio boards or steering committees, don’t be a parallel entity
- No amount of modelling survives without executive backing and resourcing. Architecture needs secure sponsorship to drive continuity
However, I think you're missing a representation of the business layer (a business architecture) allowing modelling of the business and bridging into technology:
- Capabilities, data flows, and applications are not distinct artifacts, they need to align to deliver customer or stakeholder outcomes. Value-stream mapping represents value delivery and shows how capabilities collaborate in distinct business contexts.
- EA content tends to focus heavily on systems and data and underplays other operating model elements (e.g. people, process). To be useful, capabilities should be business capabilities representing all operating model elements.
- It is important to be able to have discussions with the business in their language. This means EAs should not just model applications and data flows but also vocabularies, business terms, or domain ontologies. A shared business language is crucial for unambiguous requirements, regulatory compliance, and cross-domain integration.