myBusinessArchitectmyBusinessArchitectmyBusinessArchitectmyBusinessArchitectBefore you can choose what to do, you have to answer a harder question: why do you exist? This chapter shows what happens when five leaders give five different answers to that question, and none of them are specific enough to guide a single decision. You will learn why starting with solutions before validating purpose is the most expensive mistake organisations make, and how to build the evidence base that tells you whether your organisation is delivering value or just staying busy.
By the end of this chapter, you'll be able to:
Marcus took Diane's advice. He started with Discover.
He scheduled a two-hour working session with the leadership team and opened with a single question: "Why does Lakeshore Polytechnic exist?"
The room was quiet for a moment. Then the answers came, and they were all different.
Sandra Mwangi, VP Academic, went first. "We exist to provide accessible, high-quality post-secondary education to the people of this region."
James Firth, VP Finance, offered a correction. "We exist to produce graduates who are employable and contribute to the regional economy. That's what the government funds us to do."
Tom Beaulieu, Dean of Health Sciences, was more specific. "We exist to prepare people for careers where they're needed. In my programs, that's healthcare. Our graduates fill roles that would otherwise go unfilled in hospitals and clinics across the region."
Priya Sharma, Director of International Education, added another dimension. "For our international students, we existed as a pathway. Not just education, but a new life. We were their entry point to this country, to a career, to a future. That's what we meant to them."
Aisha Okafor, the Student Association President who'd been invited at Marcus's request, said the most uncomfortable thing of all. "I've been here four years. I couldn't tell you why this place exists. I can tell you what it does: it runs programs, collects tuition, and issues credentials. But the 'why' behind it? I've never heard anyone say it out loud, and I'm not sure the answer would be the same for domestic students as it was for international students."
Five people. Five answers. None of them wrong. None of them specific enough to guide a single decision.
Marcus wrote all five answers on a flip chart. "This," he said, "is why we can't agree on a recovery plan. We don't have a shared understanding of why we're here. Every proposal we've generated is someone's answer to a question we haven't agreed on yet."
The room was uncomfortable. That was the point.
Every Design4 cycle begins here, with Discover. Not with strategy. Not with solutions. Not with a list of initiatives or a technology roadmap. With purpose. And not purpose as preamble or motivational poster. Purpose as an active architectural element: tested through evidence, validated against stakeholder outcomes, and treated as an active constraint on every subsequent choice.
This sequence is deliberate, and violating it is the single most common reason that well-intentioned organisations build the wrong things. We call this the Solution Trap: the impulse to jump straight from a perceived problem to a solution, skipping the hard work of understanding why the organisation exists, who it serves, and what those stakeholders actually need.
The Solution Trap is seductive because it feels productive. Brainstorming solutions, launching initiatives, building roadmaps: these activities generate energy and the appearance of progress. But progress towards what? Without a clear, validated understanding of purpose, stakeholder needs, and environmental context, even the most impressive execution is just efficient movement in the wrong direction.
The Discover phase exists to prevent this. Its governance question, "Are we getting the benefits?", forces the organisation to start with evidence rather than assumptions. Before asking "What should we build?" or "Where should we invest?", Discover asks: "Do we understand what value we exist to create? Do we know who our stakeholders are and what they need? Do we have evidence that we're actually delivering that value? And what external forces shape what's possible?"
These questions aren't a one-time exercise. Every turn of the Design4 cycle returns to Discover, because stakeholder needs shift, environmental conditions change, and yesterday's purpose may not be tomorrow's. The Business Architect's role in this phase is to collect the "dots" from the external world (purpose, stakeholder expectations, environmental constraints) before attempting to connect them internally through strategy, capabilities, and operations.
Think of Discover as the launchpad. Everything that follows (every strategic choice in Define, every capability investment in Develop, every operational design in Deliver) must be traceable back to something discovered here. If it can't be traced back, it shouldn't be built.
In Practice: Lakeshore's emergency response was a case study in the Solution Trap. The institution jumped from "We have a $38 million shortfall" to a long list of proposals without pausing to ask who Lakeshore existed to serve and what those stakeholders actually needed. The proposals weren't bad. They were unanchored. Marcus's purpose exercise didn't produce a recovery plan, but it produced something more valuable: the realization that a recovery plan was premature.
Create a free account to access Closing the Strategy to Execution Gap and start learning.