Post Solutions Architecture Engagement Best Practices

Overview

An engagement is complete in the eyes of the Customer once Solutions Realization Planning concludes and the Solution Set has been handed off.

But the Solutions Architecture practice’s responsibility does not end there — three specific pieces of work remain as part of the broader Enterprise Architecture function, in a fixed order: SARB delivery to the Customer, SARB storage in the Architecture Repository, and use of the engagement’s data to improve relevant inventories and other architecture artifacts.

This order matters. The Customer’s copy of the SARB comes first, because they are the party who commissioned and owns the outcome of the engagement — the Architecture Repository and the broader EA Platform are secondary beneficiaries of the same artifact, not the primary one.

Where the SARB’s decision record includes technical debt knowingly accepted along the way, that debt should be handed off here too — the same way portfolio entries already hand off to APM and TPM — to whoever manages Technical Debt Management Best Practices going forward, not left buried in a filed-away SARB.

Best Practice: Deliver the SARB as a Genuine Handoff, Not a File Transfer

Treat SARB delivery to the Business, IT, or the external Customer as a structured handoff — walking the recipient through what the SARB contains and how to use it — rather than simply making the file available. The Customer should leave the handoff able to navigate the SARB on their own, not merely aware that it exists.

See “Who Solutions Architecture Serves: Internal and External Customers” for what else differs between an internal handoff and an external one — particularly where the engagement’s own reusable knowledge ends up afterward.

Best Practice: Store the SARB in the Architecture Repository With Real Categorization, Not Just Filing

When storing a completed SARB in the Architecture Repository, apply the categorization and organization the Repository is meant to provide — tagging it by the problem domain, the SA Dimensions it touched, and the specialized architecture practices it drew on — rather than depositing it as an unindexed file. A SARB that cannot be found or searched later provides little of the reuse value described in “How Solutions Architecture and the EA Platform Reinforce Each Other.”

This same discipline has a second, independent payoff: a consistently categorized, organized, and stored body of SARBs is what makes it practical to point an AI system at the Architecture Repository to answer questions — about past engagements, prior decisions, or already-solved problems — directly. Inconsistent or unindexed storage undermines this possibility as much as it undermines human findability.

Best Practice: Update Inventories and Artifacts Promptly, Not Eventually

Incorporate the engagement’s vetted data into relevant inventories and other architecture artifacts as one of the final steps of closing out the engagement, not as a lower-priority task to return to later. A completed engagement whose data sits outside the EA Platform for months provides no benefit to the next engagement that could have drawn on it, undermining the Architecture Flywheel Effect this document has described throughout. Where the engagement introduced a new application or technology, this includes formally entering it into APM’s or TPM’s governed inventory and advancing its lifecycle status — from Proposed to Active in APM, or from Emerging toward Approved in TPM — rather than leaving a newly realized asset ungoverned. Where the engagement’s Solutions Options went before ARB, TRB, or another governance body in Phase 3, this also includes communicating the chosen option, and any changes from what was originally reviewed, back to that body — the same close-out discipline applied to governance as to inventories.

Benefit(s)

Executing all three close-out steps well, in order, is what actually delivers the value this document has argued for throughout: a well-handed-off SARB preserves the Customer relationship and the credibility case made earlier in this document; a well-categorized Architecture Repository entry makes future-state deconfliction and reuse genuinely possible for the next engagement, rather than theoretical, and makes the Repository usable by AI systems answering questions over it, not only by human searchers; and promptly updated inventories keep the Architecture Flywheel Effect turning rather than stalling. Skipping or rushing any one of the three steps quietly breaks the mechanisms this document has spent most of its length establishing.