Running an Effective Enterprise Architecture Working Group
Practical ways to make your architecture forum focused, influential, and worth everyone’s time
In the previous articles (parts 1 and 2), we explored architecture reviews—how to run them effectively, and why they alone can’t guarantee architectural quality.
Now, let’s move to another essential governance element: the enterprise architecture (EA) working group—or the architecture forum, architecture council, or whatever name works in your organization. The label isn’t important; the function is.
Why focus on this? Because one of the simplest yet most overlooked governance questions is: “Is there a place to talk architecture?”
If the answer is “no,” it’s a gap worth closing. Without a dedicated forum, architectural issues get scattered across projects, informal chats, or not discussed at all—leaving decisions fragmented and alignment accidental.
Creating a consistent place for these discussions is one of the most practical steps you can take to strengthen your EA operating model.
Why You Need an Architecture Working Group
In many organizations, there’s no regular forum for architects and related experts to meet. Issues get handled ad hoc, often too late or without the right people present.
From my experience, this a shared forum is often essential for architectural decision-making, coordinating architecture work, and keeping EA visible and relevant in the organization.
A standing EA working group provides:
A consistent decision-making body for architecture topics
A channel to advance and coordinate architectural initiatives
A communication hub between business and technology stakeholders
It’s also a concrete part of your EA operating model—not an optional extra.
How to Make It Work: Best Practices
An architecture working group only delivers value if it’s well-structured and consistently run. It’s not just another meeting—it’s a focal point for aligning architectural thinking, resolving cross-domain issues, and ensuring EA work connects to real organizational priorities.
Define the purpose clearly: Is the group making decisions, sharing information, resolving conflicts, or all of the above? The clearer the scope, the easier it is to run productive sessions.
Get the right mix of participants: Include enterprise architects, solution/domain architects, and—when relevant—representatives from business, IT, security, operations, or portfolio management. The mix can shift depending on the topic.
Integrate with other governance: Avoid duplication with steering groups, portfolio boards, or agile release trains. Position the group so that it complements—not competes with—other decision-making forums.
Make it a regular event: A weekly or biweekly cadence works well in most settings. Too infrequent, and issues pile up; too frequent, and it risks becoming noise.
Use a standard agenda: A recurring structure helps keep discussions on track and ensures important topics aren’t forgotten. Prioritize topics where architectural input really matters.
Ensure real influence: If the group can’t affect priorities, budgets, or solution direction, it will lose relevance fast. When the group makes a decision, document it clearly. If the group is not the decision-making body for an issue, define which forum will decide and who is responsible for taking it there.
Document and follow up: Keep outcomes visible. A simple decision log can go a long way toward creating transparency and building trust. Track agreed actions and owners, and follow up in subsequent meetings. Keep an eye on members’ action lists—don’t let unresolved tasks pile up and stall progress.
Suggested Agenda for an Architecture Working Group
A standard agenda provides rhythm, predictability, and a shared expectation of what the group will cover. It also ensures that architectural priorities are consistently addressed, not left to chance. While the exact order and emphasis can be tailored to your organization, the following structure works well in most settings—particularly when you want to focus on topics where architectural input has the most impact.
Latest Updates
Purpose: Keep all members informed about recent changes that affect architectural direction and priorities.
Scope: Shifts in strategic priorities, portfolio changes, key decisions from other governance forums, or organizational changes with architectural impact.
Why it matters: Ensures everyone has the same context before diving into discussions or decisions, reducing misunderstandings and rework.
Architectural Decisions
Purpose: Confirm and document architectural decisions made in the group or elsewhere, and identify new decision needs.
Scope: Decisions related to target state, solution fit, principles, or standards; includes tracking open items and defining ownership.
Why it matters: Prevents the group from becoming a “parking lot” for unresolved items, and ensures decisions have a clear path to closure—even if they are made in another forum.
EA Content and Deliverables
Purpose: Review the status of new or updated EA deliverables and agree on next steps for completing or refining them.
Scope: EA team work products, such as target state maps, capability models, principles, and application views.
Why it matters: Keeps deliverables aligned, relevant, and ready for use in decision-making. This slot is for status and planning—the actual deep-dive review may happen separately.
Project and Solution Architecture
Purpose: Secure early involvement in upcoming projects and maintain oversight of ongoing work to ensure architectural considerations are addressed throughout the lifecycle.
Scope: Any project or initiative requiring architectural input, from initial framing and solution overviews to impact assessments, integration design, and progress checkpoints.
Why it matters: Positions architecture as a proactive partner in shaping solutions and ensures alignment is maintained over time—reducing the risk of last-minute changes or missed dependencies.
Other EA Work
Purpose: Keep track of EA activities outside of specific deliverables or projects, and agree on next steps.
Scope: EA communications, governance model development, updates to modeling standards, improvements to EA tools, or other internal capability-building efforts.
Why it matters: Ensures foundational EA work remains visible and progresses, supporting the long-term maturity and effectiveness of the architecture function.
Architecture Reviews
Purpose: Decide which reviews to schedule, define their scope, and ensure the right participants and materials are prepared.
Scope: Reviews of change proposals, solution architectures, EA deliverables, or continuous-development checkpoints (e.g., in SAFe PI cycles).
Why it matters: Positions reviews to influence direction while change is still possible—rather than validating work after the fact.
Tracking and Follow-Up
Purpose: Monitor the group’s action and decision log to ensure nothing is lost or left unresolved.
Scope: All agreed tasks, their owners, and due dates, whether related to EA deliverables, reviews, or other work.
Why it matters: Maintains accountability and momentum. Regular follow-up prevents backlog buildup and ensures transparency.
Final Thoughts: Architecture Working Group as a Management Tool
An EA working group isn’t just a standing meeting—it’s a core part of the architecture management system. It creates a regular rhythm for alignment, guidance, and accountability.
When run well, it:
Speeds up decision-making
Improves cross-team coordination
Reduces late-stage surprises
Keeps architectural work connected to real business priorities
If you don’t have such a forum yet, start simple: invite the right people, agree on a clear purpose, and use a focused agenda. Even a small, well-run group can quickly prove its value—often within the first few sessions.
✍️ Author News
On the enterprise architecture book front, I just returned the revised proof. No major comments this time, so the final proof with indexes should be next—getting close now. Marketing is also in planning (and partly already underway), which makes it feel even more real. The book will be out in the beginning of October and already available for preorder.
On the fiction side, I’m working on my debut novel. This week I’m sending an updated manuscript back to the literary editor. Her comments really helped sharpen the story. There’s always room to improve, but at some point you have to draw the line and let it go.
🔗 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.