Forty Logical Components and a Six-Week Procurement Deadline
An insurer's Phase C produced a target application architecture containing forty logical application components, described by function and interface but not by product. Phase G is due in three weeks and three delivery partners are preparing to buy software. Procurement wants a solution decision within six weeks, although the original business case assumed a twelve-month architecture-to-implementation runway. A colleague points to a Payment Services building-block pair built last year for a banking client and stored in the Architecture Repository, suggesting it be reused to shorten the work. The lead architect must decide what to produce now and whether the reuse is safe.
1. What is missing from the Phase C output to support Phase G and a procurement decision?
Read the worked answer
Phase C produced Architecture Building Blocks; procurement needs Solution Building Blocks.
The distinction matters because the two are produced at different points and answer different questions:
| Produced so far | Still needed |
|---|---|
| Forty ABBs: capability, function, interface - the 'what' | SBBs and product mapping - the 'how', selected in Phase E and specified in Phase F |
| Target application architecture | Architecture Requirements Specification with measurable non-functional requirements - the basis for tender evaluation |
| Nothing on transition | Transition Architectures reconciling the twelve-month assumption with the six-week decision |
| No contractual basis | Architecture Contract and the compliance review method for Phase G |
| No decision record | Documented rationale for buy versus build and for each candidate selection |
Two consequences follow. First, three delivery partners preparing to buy software without an Architecture Requirements Specification will each buy against their own reading of the forty components, and the resulting landscape will be undeliverable to integrate. Second, the twelve-month runway in the business case is now fiction; if it is not re-baselined, the programme will be measured against a plan nobody can meet.
2. How would you evaluate the proposed reuse of the Payment Services building blocks from the repository?
Read the worked answer
Reuse is a hypothesis to be tested, and the effort required depends on which kind of building block it is.
Check the repository metadata first - source, owner, version, date, licensing and contractual constraints, and whether the artefacts are complete or were archived mid-flight. Reuse of undocumented content costs more than building fresh.
Then test fitness for purpose, not similarity of name:
- Was the banking model built under a different regulatory regime (payments regulation, data residency, settlement rules) than the insurer operates in? Different regime means different constraints, which is precisely what building blocks encode.
- Does it satisfy the requirements in the Architecture Requirements Specification - volumes, availability, interfaces, data model?
- Is the underlying technology still supported and consistent with the insurer's standards and skills?
Then distinguish the two building-block types:
- Reusing the ABB is low-risk and usually sensible: it is an input to Phase E analysis, and the gap analysis against the insurer's requirements is cheap. Adopt it as a reference.
- Reusing the SBB is a commitment: it selects a product and a design. That requires a full gap analysis and should be evaluated as one candidate among the buy options, not assumed.
Record the outcome in the repository either way - a documented rejection is as valuable as a documented reuse.
3. What should the lead architect produce in the six weeks, given that procurement cannot wait?
Read the worked answer
Do not let procurement outrun the requirements; compress the architecture, don't skip it.
Six-week plan:
- Architecture Requirements Specification, scoped to the first procurement lot. Not all forty components: pick the lot with the highest value and the strongest dependency (typically the ones with the most interfaces). Measurable requirements are the difference between three comparable bids and three incomparable ones.
- A bounded transition architecture for the first increment, showing the state after the first release. This is what lets procurement buy a slice instead of a platform.
- SBB candidate evaluation with explicit buy/build and reuse analysis, including the Payment Services ABB after gap analysis.
- A re-baselined Architecture Roadmap reflecting the six-week decision and the revised implementation runway, approved by the sponsor rather than quietly amended.
- Architecture Contracts with the selected partner before build starts, and the Phase G review points agreed.
If the six weeks proves too short, the honest options are a two-stage procurement (a bounded first lot now, the remainder after Phase F completes) or a procurement that evaluates against partial requirements with a defined change mechanism. What is not an option is awarding against forty unnamed components.