Solutions Architecture and Governance Body (ARB/TRB) Review

Overview

Coordinating with governance bodies such as the Architecture Review Board (ARB) and Technology Review Board (TRB) — established in the Glossary as example EA Platform Services — is a concrete instance of the pattern described in “How Solutions Architecture and the EA Platform Reinforce Each Other” earlier in this document: checking with these bodies before presenting options draws down from the EA Platform, and notifying them of the chosen option afterward feeds back to it. This chapter develops the specific mechanics of that coordination.

Not every Solutions Option warrants governance review — only those significant enough to matter, the same threshold logic already established in “When a Solutions Architecture Engagement Is Needed” for whether a full engagement is warranted in the first place. Where an option does meet that bar, the Solutions Architect should bring it to ARB, TRB, or whichever governance body applies, before it is ever presented to the Customer in Phase 4 — with enough advance notice for members to actually review it, not as a last-minute formality squeezed in before the deadline.

Once the Customer has chosen a Solutions Option, the Solutions Architect should communicate what was chosen — including any changes from what governance originally reviewed — back to ARB, TRB, or whichever body was involved. This keeps governance current, supports regular review cycles, and gives the EA Platform a synchronization point beyond the close-out sequence already established earlier in this document in “How Solutions Architecture and the EA Platform Reinforce Each Other” and covered in full later in this document in “Post Solutions Architecture Engagement Best Practices.”

None of this changes who owns the final decision. Governance review determines which Solutions Options are viable to bring forward; it does not determine which one the Customer chooses. That authority, covered in full in “Solutions Presentation and Decisioning” later in this document, remains entirely the Customer’s — governance review narrows the field of viable options before Phase 4, it does not narrow the Customer’s authority to choose among them.

Best Practice: Bring Significant Options to ARB/TRB Before Presenting Them to the Customer, With Adequate Notice to Review

Where a Solutions Option is significant enough to warrant governance review, bring it to ARB, TRB, or whichever governance body applies during Phase 3, before it is presented to the Customer in Phase 4 — with enough lead time for members to genuinely review and weigh in, not as a formality completed the day before presentation.

Benefit(s)

Reviewing significant options before the Customer sees them ensures every option actually presented in Phase 4 is already governance-viable, rather than risking a Customer decision that governance later vetoes — protecting both the Customer’s trust in the process and the credibility case this document has made for Solutions Architecture throughout.

Anti-Pattern: Treating Governance Review as a Last-Minute Formality

Bringing a Solutions Option to ARB or TRB the day before it needs sign-off, with no real time for members to review it, is a common shortcut under deadline pressure. It defeats the purpose of governance review entirely — a rubber-stamped approval given without genuine scrutiny is no different from skipping the review altogether, except that it looks like due diligence was done when it was not.

Best Practice: Communicate the Chosen Option and Any Changes to ARB/TRB After the Decision Is Made

Once the Customer has decided, communicate the chosen Solutions Option — and any changes from what governance originally reviewed — back to ARB, TRB, or whichever body was involved. Treat this as a close-out obligation the same way “Post Solutions Architecture Engagement Best Practices” treats updating inventories and artifacts, not an optional courtesy — that chapter is covered in full later in this document. Where a significant course-correction occurs during Phase 5, Solutions Realization Planning, this same notification should happen immediately rather than waiting for close-out, since the decision governance already reviewed has now materially changed.

Benefit(s)

Keeping governance bodies apprised of what was actually decided maintains transparency, supports the regular review cycles those bodies depend on, and gives the EA Platform another synchronization point — reinforcing the same Architecture Flywheel Effect this document has argued for throughout, applied here to a specific kind of EA Platform Service.