myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectTwo weeks after the board approved the transformation, Ravi Kapoor presented his team's current state assessment. It was technically excellent: every student-facing system catalogued, rated on age, platform stability, vendor support, integration complexity, and maintenance cost. Marcus read it carefully. Then again. Something was missing. Not one system had been assessed against whether it served a capability the architecture identified as critical. The student information system received a high technical rating, but did it support the advisor-student relationship that the architecture flagged as the core gap? The career services portal received a low technical rating, but it was the only system that connected students to employer outcomes, which the architecture identified as central to Lakeshore's repositioning. This chapter teaches you how to add the dimension the technical assessment leaves out: not just what works, but what serves the architecture.
By the end of this chapter, you'll be able to:
Before you renovate a house, you survey the existing structure. You need to know what is load-bearing and what is cosmetic. You need to know where the plumbing runs and where the electrical panel sits. You need to know which walls can be moved and which ones hold the building up. A renovation that ignores the existing structure is not ambitious. It is reckless.
Marcus Chen was about to learn the organizational equivalent.
Two weeks after the board approved the Student Experience Transformation, Ravi Kapoor presented his team's current state assessment to the working group. It was thorough. Ravi's team had catalogued every student-facing system at Lakeshore: the student information system, the learning management system, the advising scheduling tool, the financial aid platform, the career services portal, the employer partnership database (Tom Beaulieu's pride), the international student application tracker, and eleven other systems that touched the student experience in some way.
The assessment was technically excellent. Each system was rated on age, platform stability, vendor support status, integration complexity, and maintenance cost. Colour-coded charts showed which systems were approaching end-of-life, which had recent upgrades, and which were running on platforms the IT team no longer had expertise to support.
Marcus read the assessment carefully. Then he read it again. Something was missing.
Every system had been assessed on its technical health. Not one had been assessed on whether it served a capability that Lakeshore's architecture had identified as critical. The student information system received a high rating because it was stable, well-supported, and recently upgraded. But did it support the advisor-student relationship capability that the architecture had flagged as the core gap? The assessment did not say. The career services portal received a low rating because it was aging and poorly integrated. But it was the only system that connected students to employer outcomes, which the architecture had identified as central to Lakeshore's strategic repositioning. The technical assessment was accurate. The business dimension was absent.
This chapter teaches you how to read the current landscape the way the business architect must: not just what works and what does not, but what serves the architecture and what does not.
Create a free account to access Shaping What Gets Built and start learning.