
In his recent blog series, Jeffrey Davidson has been breaking down the different types of IT architecture—conceptual, logical, and physical—and showing how each plays a role in aligning technology with business outcomes. I want to build on his perspective by introducing a parallel thread: how transformation connects with these architectural foundations.
And let me start with a confession: I don’t like the word “transformation.”
When people hear it, they picture something magical, like a butterfly’s metamorphosis. The implication is that change can be instantaneous, almost effortless, like snapping your fingers and suddenly becoming something entirely new. But anyone who has led change in an organization knows that’s not reality.
Michael Jordan didn’t become great overnight. He combined natural skill with years of fundamentals, discipline, and hard work. That’s what true transformation looks like in business and IT. It’s not about magic; it’s about doing the work.
Two Sides of Transformation
When organizations begin to grasp what transformation really requires, they often back away. That’s because it isn’t glamorous. It’s about getting back to the basics of IT and how teams operate every single day.
In my experience, transformation has two sides:
- Strategy – the plan, the blueprint, the “what and why.”
- Operational Readiness – the everyday execution, sometimes called Day 2 operations, which I’ll cover in a follow-up post.
This post focuses on the first side: strategy.
Why Strategy Comes First
Too often, technology leaders fall in love with tools. Identity management programs, virtualization platforms, project management software. These are important, but they’re just tools. Having the best hammer in your toolbox doesn’t matter if you don’t know what you’re trying to build.
That’s where strategy comes in. The most effective way I’ve seen organizations cut through complexity is with a framework called OGSM: Objectives, Goals, Strategies, and Measures.
At first glance, OGSM can seem too simple. Some clients scoff when I introduce it: “Surely transformation can’t be this basic.” But that’s exactly the point. The most effective transformations hinge on simplicity and clarity.
Breaking Down OGSM

Here’s how OGSM works:
- Objective (What): What do we want to achieve?
- Goal (Why): Why does it matter? What is the value proposition for the business?
- Strategy (How): How will we achieve it? What methods, processes, or tools will we use?
- Measures (Proof): How will we know we’ve succeeded? What metrics or KPIs define “done”?
The measures are critical. They force you to define success in concrete, quantitative terms—whether it’s reducing help desk ticket volume, improving service uptime, or accelerating feature delivery.
Start small. Pick five priorities, build your OGSM, and treat it as a living framework. As the organization evolves, you can revisit and adjust.
Why This Matters for Architecture
So how does this tie back to Jeff’s work on architecture?
If you don’t have clear objectives, goals, strategies, and measures, your architecture becomes guesswork. OGSM provides the blueprint that informs architecture: conceptual, logical, and physical. It tells you what to prioritize first, prevents “big bang” overreach, and builds confidence through incremental wins.
And just as important, OGSM helps with adoption. Humans are wired to cling to the familiar, even when it doesn’t serve us well. By framing transformation in simple, personal terms—what’s changing, why it matters, and how it benefits you—leaders can lower resistance and build momentum.
The Takeaway
Transformation is not magic. It’s about returning to basics. On the strategy side, frameworks like OGSM give organizations a clear, repeatable way to define what matters, why it matters, how to do it, and how to measure success.
This clarity not only drives project plans, roadmaps, and architecture decisions, but also builds the trust and confidence needed to move people forward.
In my next post, I’ll focus on the second side of transformation: the operational element—the everyday work that often gets ignored, but ultimately determines whether strategy becomes reality.
