Solutions Architecture and Portfolio Management (APM/TPM)

Overview

Application Portfolio Management (APM) and Technology Portfolio Management (TPM) govern, as ongoing enterprise disciplines, the applications and technologies an organization depends on — APM specifically scoped to the Applications technology type, as a sub-branch of the broader TPM, which governs every technology type an organization owns or depends on, including Applications, Software, Hardware, Cloud, and more. A Solutions Architecture engagement correlates with both the same way: through whichever one governs the specific application or technology a Solution Set introduces or changes.

When a Future State Solutions Option in Phase 3 proposes a new application or technology, or changes an existing one, that item is a candidate for APM’s or TPM’s governed inventories — the Applications Inventory, or the relevant Technologies Inventory — once the engagement realizes it. Both disciplines already maintain their own established connections to the Systems Development Lifecycle and to Release Management, the same two disciplines correlated with Solutions Architecture earlier in this subsection, so this is not a new relationship being introduced but an existing web of governance Solutions Architecture is stepping into.

Where a Future State Solutions Option is an Acquired solution built on a vendor product, its evaluation in Phase 3 should draw on APM’s and TPM’s own vendor management practices — vendor health and viability, license compliance, and vendor concentration risk — rather than assessing these things independently. The specialized practices already established for this exist precisely so Solutions Architecture does not need to reinvent them.

APM’s Capabilities Inventory mapping — connecting every application to the business capabilities it supports — lines up directly with the Value Streams and Capabilities Dimension established earlier in this document. Where a Solution Set touches an existing application or technology, coordination is owed to its named Application Owner or Technology Owner: the same stakeholder the SARB chapter already requires approval from when a decision affects a pre-existing construct not owned by the Solutions Architect.

TPM also maintains a Technology Standards Register: the authoritative record of every approved, tolerated, and prohibited technology in the enterprise. Where a Future State Solutions Option involves a specific technology, checking that register belongs alongside the fit and risk assessment already required in Phase 3.

Best Practice: Check the Technology Standards Register Before Finalizing Options That Introduce New Technology

Where a Future State Solutions Option under consideration in Phase 3 introduces a technology not already established in the enterprise, check TPM’s Technology Standards Register before carrying that option forward — confirming it is approved or tolerated, not prohibited, and coordinating with the technology’s named Owner where one already exists.

Benefit(s)

Checking the Technology Standards Register before finalizing options avoids presenting the Customer with a Solutions Option built on a technology the enterprise has already prohibited or is actively phasing out — a conflict better caught in Phase 3 than discovered during Phase 5 realization.