The Solutions Architecture Reference Book (SARB)

Overview

The Solutions Architecture Reference Book (SARB) is an IF4IT original concept. It is not one document among several candidate artifact types — it is the organized and governed container that holds all other related governed artifacts produced across a Solutions Architecture engagement. At minimum, it holds the problem statement (vision, mission, goals & desired outcomes), the current state representation, assessments and analyses — including risk assessments — the options considered, and — critically — all decisions made throughout the engagement, and by whom.

This decision record goes beyond Architecture Decision Records alone. It also captures decisions affecting pre-existing constructs — an existing application, or existing data & information, for example — that may not be owned by the Solutions Architect working the engagement, and any related decisions must be vetted with, and approved by, the stakeholders who own those constructs. This is what makes the SARB a governance artifact, not merely a knowledge repository: it establishes accountability for who decided, and who approved, what.

Without the SARB, there are rarely any good architecture documents or systems to turn to that capture this complete story — the problem, the solution, and every decision made along the way. Done well, it is one of the more comprehensive documentation sets delivered by any area of IT, and like the Solution Set and the Solutions Architecture Framework itself, it scales with the size of the problem: a SARB can run from tens of pages to thousands, depending on the engagement.

The SARB’s relationship to the EA Platform — drawing on it to accelerate and de-risk an engagement, then feeding vetted results back once complete — is covered in depth in “How Solutions Architecture and the EA Platform Reinforce Each Other” earlier in this document. What happens to a completed SARB at the close of an engagement is covered in “Post Solutions Architecture Engagement Best Practices,” later in this document.

Significant decisions made through Phase 3 and Phase 4 accumulate here as the engagement proceeds — including any Solutions Option knowingly chosen despite the technical debt it introduces — giving this engagement its own body of Architecture Decision Record-equivalent entries without needing a separate artifact type to hold them.

This also means capturing each content category the same way from one engagement to the next, not only capturing the same categories. Consistent structure is what makes a SARB fast for ARB or TRB to review without relearning documentation conventions each time, and structured enough for its data to actually feed downstream systems such as the Enterprise Model or a CMDB, rather than requiring manual re-entry.

Best Practice: Treat the SARB’s Completeness as a Governance Requirement, Not an Optional Nicety

Populate every content category — the problem statement, the current state, the assessments, the options considered, and the full decision record — not only the final decision reached. Pay particular attention to decisions affecting pre-existing constructs: these require a documented approval from the stakeholders who own them, not just a note that the decision was made.

Benefit(s)

A genuinely complete SARB is what makes it trustworthy as an audit trail and a knowledge asset — both for the Customer reviewing how their problem was solved, and for the Architecture Repository and EA Platform that depend on its comprehensiveness once the engagement concludes.

Anti-Pattern: Treating the SARB as an Afterthought or Optional Nicety

Producing a thin or incomplete SARB — capturing the final decision but not the options considered, the current state, or the assessments behind it — is a common shortcut when time is tight at the end of an engagement. It leaves the Customer and the broader EA Platform with no real audit trail, undermining the governance function the SARB exists to serve.