How Solutions Architecture and the EA Platform Reinforce Each Other

Overview

The Solutions Architecture Reference Book does not only carry vetted engagement data up to Enterprise Architecture and the EA Platform — it also draws down from them, at the start of and during an engagement. It leverages what the EA Platform already knows to quickly determine what is already available for Current State, concentrating fresh vetting effort on what is actually unknown or changed. It also checks for other already-in-play Future State components or solutions elsewhere in the enterprise — made possible because the Architecture Repository holds in-progress SARBs, not only completed ones — preventing redundant or conflicting parallel work and enabling reuse of what is already underway.

This creates a continuous, self-reinforcing cycle: the data, information, and artifacts fed to the EA Platform from every engagement become the growing body that each new engagement draws from, and each new engagement further vets, feeds, and improves that same body. This is the Architecture Flywheel Effect — the more the EA Platform is used, the more valuable it becomes to the IT and Business leaders who depend on it.

The cycle completes with a specific sequence at the close of every engagement. First, the completed SARB is delivered to the stakeholders who own the problem — the Business, IT, or the external Customer, as applicable. Second, the SARB is stored in the Architecture Repository, the EA Platform’s consistent, centralized component for documented EA knowledge, distinct from the Enterprise Model’s structured data. Third, the engagement’s data is used to improve all relevant inventories and other architecture artifacts, completing the flywheel.

This effect compounds further with scale. Because Solutions Architecture is federated rather than centralized, many engagements can run concurrently across different parts of the enterprise, each one independently vetting its own slice of Current State and Future State against real stakeholders. The more SA engagements running at once, the faster the EA Platform grows, the bigger its coverage becomes, and the more thoroughly it gets vetted — a rate of growth a purely centralized Enterprise Architecture function, bottlenecked on its own limited throughput, could not achieve alone.

More parallel engagements also raises the stakes for the future-state deconfliction check described earlier in this chapter: the more concurrent work there is, the more likely two engagements are to touch related or overlapping territory, and the more valuable it becomes to actually check the Architecture Repository for in-progress SARBs before finalizing options. Parallel scaling and deconfliction discipline reinforce each other — one does not work well without the other.

Governance body coordination follows this same pattern in miniature: checking with ARB, TRB, or another applicable governance body before presenting options is a draw-down from the EA Platform, and notifying that body of the chosen option afterward is a feed-back to it — detailed in full in “Solutions Architecture and Governance Body (ARB/TRB) Review,” later in this document.

Best Practice: Query the EA Platform Before Starting Fresh Discovery

At the outset of every engagement, check the EA Platform — including in-progress work held in the Architecture Repository — for existing current-state knowledge and other in-flight future-state work before beginning discovery from scratch.

Benefit(s)

Querying the EA Platform first accelerates and de-risks the individual engagement, and the compounding effect of many engagements doing so is what gives the EA Platform its growing enterprise-wide value — a distinct benefit from the specific current-state-quality benefit described in the previous chapter.

Best Practice: Encourage Parallel SA Engagements, Without Relaxing Vetting Discipline

Where the organization’s capacity allows, favor running multiple Solutions Architecture engagements concurrently over sequencing them one at a time — the EA Platform grows faster and covers more ground the more engagements are actively vetting and feeding it at once. Never relax the vetting and documentation discipline established throughout this document to accommodate that volume: a poorly vetted engagement contributes noise to the EA Platform, not value, regardless of how many others are running alongside it.

Benefit(s)

Running SA engagements in parallel, each held to the same vetting and documentation standard, is what actually accelerates the EA Platform’s growth in size, speed, and quality — turning the Architecture Flywheel Effect from a single-engagement mechanism into a genuine enterprise-wide compounding advantage of the federated structure.