A team has an onboarding feature to deliver. Product has a deadline. Engineering has started discussing the design. Security needs to understand how identity documents will be handled. The platform team already offers part of what the team needs.
Then someone asks, “Have we involved architecture?”
It sounds like a small question. It can expose a much bigger problem. Nobody is quite sure which architect should join, what they are expected to contribute, or whether their involvement means advice, collaboration, or permission.
Job descriptions rarely answer those questions. An operating model should.
In Who Owns What? A Practical Guide to Architecture Roles, I described the boundaries between architecture roles. Here I want to take the next step: how those roles work with the rest of the organization, week by week, while real work is getting done.
Start with the work people need help with
An architecture operating model is an agreement about engagement, decisions, and follow-through. It should make it easier to answer a few ordinary questions:
- When should we involve an architect?
- Who needs to participate in this decision?
- Who can actually make the call?
- What evidence do we need before committing?
- Who stays involved when implementation changes the plan?
I would start with a federated arrangement. Enterprise architects maintain shared direction and guardrails. Domain architects help related teams make coherent choices. Solution architects work close to initiatives and delivery. Engineering teams retain meaningful authority over their own software.
This is a starting point to adapt, not a requirement to hire three layers of architects. A small organization may cover these responsibilities with a few experienced people. A larger organization may need dedicated roles. Either way, the boundaries need to be understood.
Three scopes, with direct access to the people doing the work
Enterprise architects: connect strategy, investment, and technology
An enterprise architect needs a working relationship with business leadership, portfolio management, finance, and engineering leadership. Together, they examine which capabilities the business needs, where investment is being duplicated, and what must change across the technology landscape.
That work depends on contact with delivery and operations. A principle that sounds reasonable in a strategy meeting may create months of avoidable work for a product team. Enterprise architects need to hear that early and be willing to revise the principle.
Their contribution might be a small set of useful guardrails, a capability view that informs an investment decision, or an agreed direction for a shared service. Business leaders still own business priorities and funding.
Domain architects: connect the roadmap to the systems underneath it
A domain architect works with domain business owners, product leaders, engineering managers, data owners, and operations. They need to understand both where the domain is going and what makes that journey difficult.
Perhaps three product teams are changing the same customer data. Perhaps every initiative needs a different integration with an aging system. Perhaps nobody has agreed which team owns an important business event. Those are useful places for a domain architect to spend time.
The domain architect helps make boundaries, dependencies, and transition choices explicit. They also work directly with neighboring domains. A boundary is only useful when the teams on both sides understand it.
Solution architects: stay with the problem through delivery
A solution architect works with product managers, business analysts, engineers, and the specialists needed for the initiative. Their job is to help shape a solution that meets the business need and can be built, operated, and changed.
That means discussing quality requirements with operations, trust boundaries with security, data meaning with data owners, and implementation choices with engineers. It also means being available when a dependency behaves differently from its documentation or a prototype disproves an assumption.
The solution architect should help engineers develop the design. They should also know which decisions the team can make without them.
Make the relationships specific
“Collaborate with stakeholders” is easy to put in a role description. It is harder to use on a Tuesday afternoon. The relationship becomes useful when people know what they are trying to resolve together.
| Partner | Work to do together | Boundary to preserve |
|---|---|---|
| Business and portfolio leaders | Explore capability gaps, investment options, dependencies, and the consequences of delaying change. | Architecture informs the investment decision. Business leadership owns priorities and funding. |
| Product managers and business analysts | Clarify outcomes, explore scope, and make quality requirements and dependencies visible. | Product owns product priorities. Architects explain consequences and feasible alternatives. |
| Engineering teams | Design boundaries and contracts, test assumptions, and adapt the solution during implementation. | Engineers own local implementation choices within agreed constraints. |
| Platform teams | Evaluate existing capabilities, identify recurring needs, and agree adoption or extension plans. | Platform owners manage their service contracts and roadmap. A project cannot silently commit their capacity. |
| Security, privacy, and risk teams | Examine threats, trust boundaries, sensitive information, controls, and residual risk. | Risk acceptance belongs to the designated authority. An architect's agreement does not replace it. |
| Data teams and business data owners | Agree meaning, authoritative sources, access, quality expectations, and movement of data. | Architecture does not acquire ownership of business data by drawing the data flow. |
| Operations and SRE | Define service objectives, observability, recovery behavior, support needs, and operational costs. | The designated service owner remains accountable for running the service. |
| Quality engineering | Turn important quality requirements and failure assumptions into validation activities. | A design review cannot substitute for evidence from testing. |
Not every partner needs to attend every meeting. Invite people because a decision needs their knowledge or affects their responsibilities. Give them enough context to contribute before the meeting starts.
Engage early, then stay involved at the right depth
The first architecture conversation should happen while there are still meaningful options. If the supplier has been selected, the budget committed, and the launch date announced, much of the architecture has already been decided.
Early involvement does not mean a large design exercise. It may be a short conversation about the problem, the systems affected, and the assumptions worth testing.
As the initiative moves forward, the intensity changes. A solution architect may work closely with engineers during discovery, join selected design discussions during delivery, and return for a focused review when production evidence challenges an assumption. Domain and enterprise architects join when the scope of the decision needs them.
Before release, the conversation becomes concrete. Can the team detect failure? Can it recover? Are ownership and support arrangements clear? Have the important security, performance, and integration assumptions been tested? The architect contributes to that evidence with the teams responsible for the service.
After release, actual behavior should influence the roadmap. Recurring incidents, unexpected costs, and customer friction can all reveal that an architectural assumption needs another look.
Give teams a simple way to ask for help
An intake process should make help easier to obtain. Ask for the business problem, affected systems and teams, timing, known constraints, and the decision or support needed. A team should not need a completed architecture document before it can speak to an architect.
Useful triggers include a change spanning several teams, a new shared capability, a significant trust boundary change, an unfamiliar technology, or a decision that will be expensive to reverse.
For each request, name a contact and agree when the team will hear back. Publish a response expectation that matches actual capacity. If architecture cannot respond in time, that needs to be visible to the people managing the delivery commitment.
A routine change using a proven pattern can remain team-led. A difficult integration may need a solution architect. A decision affecting several domains may need coordinated involvement from domain and enterprise architects. Revisit the arrangement if the scope changes.
Name the person who can make the decision
Many meetings continue because everyone can comment and nobody can decide.
For a consequential decision, identify one accountable owner. Then name the people who contribute expertise, the teams affected, and any authority whose approval is required. The Architecture Decision Framework provides a practical structure for recording the reasoning.
| Decision | Typical owner | Architecture involvement |
|---|---|---|
| Business priority and investment | Business or portfolio leader | Explain options, dependencies, transition costs, and long-term consequences. |
| Enterprise architecture principle | EA or designated architecture authority | Develop and maintain it with affected engineering and specialist teams. |
| Domain architecture direction | DA or designated domain technical owner | Agree boundaries and evolution with product and engineering. Funding remains a separate decision. |
| End-to-end solution design | Named SA or engineering technical lead | Coordinate the design and its trade-offs with affected teams. |
| Local implementation choice | Engineering team or technical lead | Advise when the choice affects shared contracts or wider constraints. |
| Acceptance of residual risk | Designated business, security, or risk authority | Document consequences and possible controls. |
| Production release | Designated release authority or service owner | Contribute readiness evidence and explain outstanding architectural concerns. |
This allocation needs to match the organization's actual delegated authority. Naming someone in an architecture document does not give them budget authority or permission to accept risk.
It also helps to separate connected decisions. A domain architect may recommend consolidating two systems. Product and business leaders decide whether to fund the work and how to sequence it. Recording those as distinct decisions makes the disagreement easier to resolve.
Use forums to resolve work
A weekly architecture meeting can be useful. It can also become an hour in which ten people listen to updates that could have been written down.
I would begin with a few forums and change the cadence based on demand:
- Architecture consultation: weekly office hours or an on-demand conversation for teams exploring a question.
- Solution working sessions: held when needed, with engineers, product, and the relevant specialists, to resolve a specific design problem.
- Domain roadmap review: a monthly discussion of shared dependencies, modernization, operational concerns, and upcoming product changes.
- Cross-domain decision session: convened when a decision crosses ownership boundaries. Invite the decision owner and affected teams.
- Enterprise capability review: aligned with investment planning, so architecture can influence choices before commitments become fixed.
Use existing product, engineering, and operational forums where they already serve the purpose. Architecture does not need a parallel meeting structure for every conversation.
A useful session ends with a decision, a specific request for evidence, or a follow-up with an owner and date. If nobody can explain what the meeting changes, reconsider it.
Handle disagreement and exceptions without losing ownership
Consider a team that cannot meet a launch commitment using the standard integration platform. The first task is to understand why. Is a required feature missing? Is onboarding too slow? Is the team unfamiliar with an existing capability? Each explanation leads to a different response.
The solution architect and team should document the options and consequences. A domain architect joins if the decision affects other teams in the domain. Enterprise architecture joins if it changes a shared direction or crosses domains. The relevant authority still owns the final decision.
An exception should have a reason, a defined scope, an accountable owner, an authorizer, any compensating measures, and a review or expiry date. Include an exit plan when one is needed. If the exception expires, bring it back to the owner rather than treating silence as renewal.
Repeated exceptions deserve attention. They may reveal a standard that needs to change or a shared capability that needs investment.
Keep the artifacts small enough to maintain
Documentation earns its place when someone uses it to make, implement, or revisit a decision.
| Scope | Minimum useful material | Who uses it |
|---|---|---|
| Enterprise | Concise principles, capability landscape, strategic direction, shared standards. | Business and technology leaders planning investments and cross-domain change. |
| Domain | Context map, system and data ownership, important dependencies, evolution roadmap. | Product and engineering teams coordinating changes. |
| Solution | Context and integration views, quality requirements, key decisions, validation evidence, transition approach. | Engineers, testing, security, and operations building and running the solution. |
| Shared | Decision records, exceptions, reusable patterns, and a directory of accountable owners. | Anyone who needs to find current guidance or understand why a choice was made. |
Give each artifact an owner and a reason to revisit it. Keep it near the work where possible. A solution decision record in the team's repository is often easier to maintain than a duplicate document in a separate architecture library.
The existing Architecture Decision Record template is a useful starting point. Remove fields that do not help the decision.
A customer onboarding initiative, from idea to operation
Let us return to the onboarding team. The business wants fewer abandoned applications and less manual checking. Product owns the outcome and works with engineering to shape a deliverable scope.
Discovery: find the real boundaries
The solution architect brings product, business analysis, engineers, security, and operations into the early conversation. They discover that onboarding spans customer identity, document verification, and account creation. There is no single service owner for the whole journey.
The domain architect works with the affected domain owners to clarify who owns customer identity, who owns onboarding state, and how account creation reports its result. The enterprise architect participates if the initiative exposes a broader identity strategy decision. They do not need to attend every design discussion.
Design: test what could change the choice
The platform team has an identity capability that may fit. Engineers and the solution architect test its integration and failure behavior. Security examines document access and retention requirements with the appropriate owners. Operations helps define what happens when verification is unavailable.
The team compares options using that evidence. The named solution decision owner records the choice and accepted trade-offs. If extending the platform needs additional funding, that goes to the people who own the platform roadmap and investment.
Delivery: deal with what the design missed
During implementation, engineers find that a downstream service can return a timeout after successfully creating an account. Retrying could create duplicates. The solution architect and engineers work through the contract and recovery behavior with the owning team.
The domain architect joins if several products face the same problem and a shared contract needs to change. The decision record is updated. There is no need to restart the whole architecture review because one assumption changed.
Operation: learn from the actual journey
Before release, the service owner confirms support ownership and readiness using evidence from engineering, testing, security, and operations. After release, product tracks completion and abandonment while operations watches failures, recovery, and manual interventions.
If verification delays cause most abandonment, the next discussion may concern supplier behavior, user experience, or the workflow itself. The solution architect helps investigate. The domain architect incorporates wider changes into the roadmap. Enterprise architecture becomes involved if the findings affect a shared capability or strategic direction.
The architecture continues to develop through those conversations.
Measure whether the arrangement helps
I would avoid using the number of reviews or diagrams as the main measure of architecture effectiveness. Those numbers tell you that activity happened. They tell you little about whether teams made better decisions.
Start with a few questions you can answer with evidence:
- Can teams get help in time? Track initial response time, decision turnaround, and aging dependencies.
- Are important issues found early enough? Examine rework caused by missed integration, security, or operational concerns.
- Do shared capabilities help their users? Look at adoption alongside usability, support burden, and delivery feedback.
- Do decisions remain healthy? Review aging exceptions, ownerless decisions, and standards that repeatedly cause friction.
- Do solutions behave as expected? Compare service objectives, costs, and recovery assumptions with production evidence.
These outcomes belong to several teams. Use them to improve how the organization works. Pair the numbers with conversations, because a fast decision can still be a poor decision and a justified review can take time.
Start with one real initiative
You do not need to redesign the whole architecture function before trying this.
Choose an initiative that crosses a few teams. Name the architecture contact and decision owners. Agree who needs to participate, what the team needs to produce, and how unresolved issues will be handled. Use existing forums wherever possible.
After a few weeks, ask the people involved what helped, what slowed them down, and which responsibilities were still unclear. Adjust the arrangement before extending it.
A useful operating model becomes visible in ordinary work: a product manager gets an answer in time, an engineer knows which decision is theirs, an operations team sees the design before launch, and a shared problem reaches someone who can resolve it.
That is the experience worth designing for.
Explore this topic
Part of the Architecture Practice topic collection.