myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectMarcus had been looking forward to the first solution design workshop for the student advising platform. Ravi's team had done their homework. The design was technically elegant: self-service appointment booking, appointment history, SIS integration. Then Marcus asked the question that changed the direction of the initiative: "Where is the relationship?" The architecture had identified the advisor-student relationship as the capability gap, not scheduling. Students could already book appointments. The requirements document had asked for a scheduling system, and a scheduling system was what the team built. This chapter is about the gap between what the architecture intends and what the requirements document says, the most dangerous gap in the journey from strategy to solution, because it is where strategic intent most reliably disappears. You will learn to trace the requirements hierarchy, draft a business use case that carries the "why" the specification cannot, and verify that the handoff preserved the purpose the design intended.
By the end of this chapter, you'll be able to:
Marcus had been looking forward to the first solution design workshop for the student advising platform. This was one of five initiatives in the Student Experience Transformation, and in many ways it was the flagship. The architecture had identified the advisor-student relationship as the core capability gap at Lakeshore. Students could register, attend classes, and graduate. What they could not do was get the kind of proactive, integrated advising that connected their academic path to their career aspirations and ensured they did not fall through the cracks along the way. Tom Beaulieu's Health Sciences faculty had this through personal relationships. The rest of the institution did not.
The workshop was well-run. Ravi Kapoor's solution team had done their homework. They presented a design for a student advising platform that was technically elegant. It automated the scheduling function: students could book, reschedule, and cancel advising appointments through a self-service portal. It tracked appointment history. It generated utilization reports. It integrated with the student information system so advisors could see academic records. The team had even built a prototype of the booking interface.
Marcus studied the design. Then he asked a question that changed the direction of the initiative.
"Where is the relationship?"
The room went quiet. Ravi looked up from his slides. "What do you mean?"
"The architecture identified the advisor-student relationship as the capability gap. Not scheduling. Students can already book appointments. What they can't do is get advising that connects their academic performance to their career interests, flags when they're struggling before they fail, and builds a relationship over time rather than treating every appointment as a disconnected transaction. Your design automates the booking. It does nothing about the relationship."
Ravi's response was reasonable. "The requirements document asked for an advising platform with self-service scheduling, appointment management, and SIS integration. That's what we designed."
He was right. The requirements document did say that. And that was the problem.
This chapter is about the gap between what the architecture intends and what the requirements document says. It is the most dangerous gap in the entire journey from strategy to solution, because it is the gap where strategic intent is most likely to disappear. The architecture says "improve the advisor-student relationship capability." By the time that reaches the solution team, it has become "build a scheduling system." The window faces east. It meets code. It lets light in. But the artist cannot paint.
Create a free account to access Shaping What Gets Built and start learning.