myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectThe Student Experience Transformation was five initiatives, and a financial comparison of standalone business cases ranked data integration last. Fiona's dependency map showed it was the prerequisite for everything else. Claire, the portfolio manager, saw a hard sell to the board. Then Fiona's own logic hit its limit: she insisted the full integration finish before any advising work began, Claire ran a small pilot anyway, and the advisors' feedback improved the design. Architectural dependency is real; architectural rigidity is a different thing entirely. This chapter is about the business architect's role at the portfolio table: showing the dependencies the business case cannot see, sequencing with the portfolio manager rather than against her, and choosing how each transition happens.
By the end of this chapter, you'll be able to:
A large house is not built all at once. The foundation goes in before the framing. The framing goes up before the envelope. The mechanical systems (plumbing, electrical, HVAC) are roughed in before the walls are closed. The finishes come last. This sequence is not arbitrary. It is structural. You cannot hang drywall before the wiring is in the walls. You cannot pour the second floor before the first floor can bear the weight.
The same structural logic applies to a transformation portfolio. Some initiatives must come before others, not because the schedule demands it, but because one capability depends on another. Build the advising platform before the student data is integrated, and the advisors are looking at the same fragmented picture they have today, just through a newer screen. Deploy the student experience portal before the underlying capabilities are in place, and the portal is a storefront with empty shelves.
Claire Dubois understood this in principle. In practice, she had five initiatives competing for the same budget, the same IT capacity, and the same organisational attention. Her job was to sequence them so that Lakeshore could absorb the change without breaking. Fiona's job was to ensure that her sequencing respected the capability dependencies that the architecture revealed. These two jobs were not the same. But they had to work together.
This chapter teaches you how the business architect works with the portfolio manager to sequence, fund, and govern a portfolio of change. Not as competitors. As partners who see the same landscape through different lenses.
Create a free account to access Shaping What Gets Built and start learning.