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 and rated on age, platform stability, vendor support, integration complexity and maintenance cost. Fiona read it carefully. Then again. Not one system had been assessed against whether it served a capability the architecture identified as critical. The student information system rated highly, but did it support the advisor-student relationship? The career services portal rated poorly, but it was the only system that connected students to employer outcomes. This chapter teaches you how to add the dimension the technical assessment leaves out, and how to read an application reference model to see which capabilities have no system support at all.
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.
Fiona Lavoie was about to survey the organisational 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 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.
Fiona read the assessment carefully. Then she 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 ageing 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.