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 brought three proposals. Proposal A was a large-scale SaaS platform that would replace five systems with one. Proposal B was an integration layer -- no new platform, lower cost, but complex. Proposal C was modular: replace the two systems that addressed the capability gaps, keep the ones that worked. Ravi favoured B. Claire leaned toward A. Nadia preferred C. None was wrong. Each was optimizing for something different. This chapter teaches you how the business architect evaluates proposals: not on technical merit, but on whether they close the capability gaps the architecture identified. The reuse/repair/buy/build framework. The questions that distinguish fitness for purpose from fitness for fashion. And how to challenge the vendor demo that dazzles the room without serving the design.
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.
Marcus studied all three. Ravi favoured Proposal B because it minimized 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 optimizing 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 organization 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.