myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectThe capability gaps were clear, the current state understood, the business use cases written. Ravi brought three proposals: a large SaaS platform replacing five systems, an integration layer, and a modular replacement of the two systems that addressed the gaps. Ravi favoured the integration layer, Claire the platform, Nadia the modular option. None was wrong; each was optimising for something different. Fiona evaluated them on one question: which best closes the capability gaps the architecture identified, with trade-offs the organisation can accept? This chapter teaches that evaluation: reuse, repair, buy or build; fitness for purpose against fitness for fashion; and presenting the trade-offs without recommending.
By the end of this chapter, you'll be able to:
The capability gaps were clear. The current state was understood. The business use cases were written. Now the question changed: what should Lakeshore actually build?
Ravi Kapoor brought three proposals to the working group for the student experience platform. Each one was technically viable. Each one was supported by a business case. Each one approached the problem differently.
Proposal A was a large-scale SaaS student success platform from a vendor that served over two hundred institutions. It would replace five of Lakeshore's current student-facing systems with a single integrated platform. It was feature-rich, cloud-hosted, and came with implementation support. The vendor's roadmap included AI-powered student risk prediction. The annual licensing cost was significant, but the vendor argued it was offset by the maintenance costs of the five systems being retired.
Proposal B was an integration strategy. Rather than replacing existing systems, Ravi's team would build an integration layer that connected the student information system, the advising tool, the LMS, and the career services portal, creating the consolidated student profile that the business use case required. No vendor. No new platform. Lower cost. But the integration work was complex, and the existing systems would still age.
Proposal C was a modular approach. Replace the advising tool and the career services portal with modern, purpose-built applications that addressed the specific capability gaps. Keep the SIS and LMS (which worked well). Build integration between the new and retained systems. Mid-range cost. Mid-range risk.
Fiona studied all three. Ravi favoured Proposal B because it minimised disruption. Claire Dubois leaned toward Proposal A because it simplified the portfolio. Nadia Petrov preferred Proposal C because it could be phased. None of them was wrong. Each was optimising for something different.
This chapter teaches you how the business architect evaluates solution proposals. Not on their technical merits (Ravi handles that) but on whether they close the capability gaps the architecture identified, and what the organisation gains and gives up with each option. The evaluation is design-driven: the same architecture models that generated the requirements in Chapter 3 now provide the criteria for assessing whether a proposed solution serves the design.
On the Build Site: New building materials appear every decade. Smart home systems, sustainable materials, modular construction, 3D-printed components. The building architect does not need to understand the engineering of each material. But they need to assess: does this material serve the client's needs? A smart home system that automates lighting and temperature is genuinely useful if the client values convenience and energy efficiency. It is a costly distraction if the client is an artist who needs manual control of the studio light. Fitness for purpose, not fitness for fashion.
Create a free account to access Shaping What Gets Built and start learning.