myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectThe Student Experience Transformation was not one project. It was five initiatives: student data integration, an advising platform, an employer partnership platform, a proactive student support system, and a student experience portal. A financial comparison of standalone business cases ranked data integration last: no direct student benefit, indirect returns, substantial cost. But the architecture revealed something the business case could not show. The advising platform delivered relationship-based advising only if the advisor could see a consolidated student profile , which required data integration. The proactive support system required academic performance data across systems, which required data integration. Data integration was not the weakest business case in the portfolio. It was the prerequisite for everything else. This chapter is about the business architect's role at the portfolio table: showing the dependencies the business case cannot see and challenging sequencing by political convenience with sequencing by capability dependency.
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 organizational attention. Her job was to sequence them so that Lakeshore could absorb the change without breaking. Marcus'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.