Solutions Architecture Team Structure

Overview

Throughout this document, “the Solutions Architect” and “the Solutions Architecture team” both refer to the same thing: the Solutions Architect or Solutions Architects accountable for a given engagement. This is distinct from the specialized architecture practices established in “How Solutions Architecture Relates to Other Architecture Practices” — Business, Data & Information, Technical/Technology, and Security Architecture. Those specialists remain external contributors the team draws on, coordinates, and orchestrates; they are not members of the Solutions Architecture team itself, however central their input is to a given engagement.

Team size scales with the engagement the same way the Solutions Architecture Framework itself already scales, covered in full later in this document in “The Solutions Architecture Framework (SAF)”: a problem one engineer could resolve may need only one Solutions Architect, while an engagement the size of a merger or acquisition may need several working in parallel across different parts of the problem. This is a direct corollary, not a separate scaling rule — the same forces that make the framework flex in duration and staffing make the team flex in size.

Any engagement staffed with more than one Solutions Architect requires a designated Lead Solutions Architect. The Lead is accountable for the SARB’s overall coherence — ensuring the problem statement, current state, options, and decisions read as one consistent account of the engagement rather than several disconnected contributions — and serves as the Customer’s single point of accountability on the team. This does not change who owns the final decision: as established in “Solutions Presentation and Decisioning,” that decision belongs to the Customer, not the Solutions Architect, Lead or otherwise.

Where a team includes more than one Solutions Architect, work commonly divides along the SA Dimensions covered in full later in this document — one architect concentrating on Data & Information and Security concerns, another on Business and Technology concerns, for example — with the SARB serving as the single point of consolidation regardless of how many contributed to it. The SARB’s own definition already anticipates this: it is the governed container that holds all other related governed artifacts produced across an engagement, not a document written by one person.

Best Practice: Designate a Lead Solutions Architect Whenever More Than One Solutions Architect Is Staffed

As soon as an engagement is staffed with more than one Solutions Architect, formally designate one as Lead — do not leave accountability implicit or assume it will resolve itself as the engagement proceeds. Communicate this designation to the Customer at the outset, alongside the other key stakeholders identified in Vision Development.

Benefit(s)

A formally designated Lead prevents the specific failure of a multi-architect engagement producing a fragmented SARB and an unclear point of contact for the Customer — the same coherence problem a single Solutions Architect never has to solve, made explicit and assigned before it can occur.