Strategic thinking for the Microsoft Cloud
This essay has been one of my more ambitious—and challenging—pieces, so in publishing it I’d like to thank first and foremost Ana Demeny together with whom I have spent hours chewing through these ideas in the spare moments between occupying our daughter, and also both Keith Whatling and Sam Smith who have been fantastic collaborators in some of the topics that I’ll address.
I want to explain from the outset how much I have struggled writing this piece, not because the ideas weren’t well formed in my mind, but because I have come to understand strategic thinking as more art than science. Strategy is surely informed in part by data, but I find that our society in general and the technology industry specifically too often confuse data and wisdom, that we foolishly (though understandably) seek heuristics or processes so that we can turn the art of strategic thinking into a game of color by numbers so simple that anyone can do it. I am reminded of one of my near-lifelong favorite quotes whose author I cannot recall (please message me if you recognize it) but to whose ideals I have always aspired:
The commonest thing in the world are people who have been taught more than they know, know more than they understand, and understand more than they have the wisdom to use. Make sure you are not one of them.
I have, for this reason, come to prefer frameworks and lenses—which to me imply context for independent thinking—over processes and heuristics. In other words, when it comes to strategic thinking, better that we seek methods of framing our thoughts rather than shortcuts to the answers themselves. So in this piece I have sought to offer practical approaches to injecting strategy into your organization’s Cloud journey, indeed, a selection of the same approaches I take with my clients, though admit that in so doing I may at times stray into process creation at the expense of gazing through a proper lens. Writing this piece has as a consequence been a rather excruciating balancing act between the two.
A bit of context…
A colleague recently asked me what I felt was the big Microsoft Cloud story of 2023. I laughed and asked, “Aside from AI?”, which—I should say for anyone living under a rock—has sucked all the attention away from seemingly everything else lately. He laughed and said, “Yeah, what’s the big idea that people aren’t yet talking about?”. I thought for a moment and answered that I see the mainstreaming of AI capabilities and another far more subtle story converging on the same conclusion.
To address the elephant in the room, Microsoft’s big investment in Open AI and its subsequent, rapid moves to integrate this and related technology into its product portfolio are part and parcel to a couple of trends that have been evolving now for several years. To understand this we really need to abstract the cool tech side of the story from the “what does this mean more broadly?” question.
First, as I was bantering about with Steve Mordue on LinkedIn last week… If we think about major technological waves since the advent of the public internet, for a while we were running on eight to ten years between wave periods. Just off-hand, let's use the ".Com Era" (that sounds funny now, doesn't it?), followed by "Web 2.0" (remember that?!), and then "The Cloud". These wave periods have now really shortened to something more like four to five years with Cloud, followed by “platform-first”, followed by the AI wave we currently see breaking ashore. The big takeaway for me is that the grace period for organizations to get their act together and position themselves for the next wave is growing much shorter, the margin for error much more narrow. When I think about the non-technical barriers that so many organizations can't seem to get over when it comes to platform-first, I really wonder how many will miss out on the AI wave because they lack the wisdom or the willpower to make the most of it.
Second, AI is yet another—albeit massive—brick in the wall of our collective transition from activity-based to system-based value. See, ChatGPT represents a massive leap forward in AI’s ability to perform activities, be it finding (and, increasingly, assimilating) information, or building apps as Kunal Mukerjee explained in our recent LinkedIn exchange. Put another way, we’re seeing the truly meaningful impact of what humans can do moving from performing activities to understanding, constructing, and building systems of strategic value. Something like moving from assembling information to creating a framework to understand as-yet-unknown information, or moving from building an app to architecting an ecosystem, a topic about which my friend Chris Huntingford has recently been obsessed. The real action is increasingly in working with a sense of strategic imperative to assemble pieces of value across whatever system in which you which you are dealing.
Which brings me to that other, far more subtle story at play in the Microsoft Cloud right now, despite hearing so few people breath two words about it:
We’re moving from Governance to Strategy.
From circa 2018 to some time in the fairly recent past, governance was all people wanted to talk with me about. Governance, governance, governance. Over time this became a particular obsession for the Power Platform community where governance—or the risk of a lack thereof—was top-of-mind for IT staffs rightfully terrified at the prospect of business users run amok. I remember sitting in a room at a conference in Amsterdam with Lee Baker, Lucy Bourne, Manuela Pichler, Keith Whatling, and a crowd of others in March 2019 the day I think “Power Platform Governance” was born: A moment of strangers assembled to compare notes and find a way forward that eventually produced the Power Platform Adoption Framework, CoE Starter Kit, and a host of other tools, patterns, and best practices. Those were good times. Other Azure technologies have had their love affair with governance, too, and all rightly so.
But here’s the thing: Governance is just table stakes, now. If you don’t have it, you’re nothing. Whether as technology vendor, partner, or customer it has become a basic requirement to sit at the table in the Cloud. So whilst succeeding at governance is and will remain a critical success factor, it’s hardly news worthy. It’s a basic necessity, not a news maker. And perhaps most importantly, governance does not in itself produce value. Like the rule of law on an uninhabited island (enjoy the video ;-), a well-governed platform that lacks apps + data that are themselves producing value produces no value at all.
…which is why we’re moving from governance to strategy.
This is perhaps the essential realization I had in my recent work alongside Dana Siegal, Josh Darragh, Suzy Agi, and Dave Milton in what became our Tyranny of the Deliverable (and other short stories) concept that you can read more about here. In that way, what follows below can be thought of as the flip side of the same coin, though now we are talking about a strategy and concordantly prescriptive approach to overcoming the Tyranny of the Deliverable (among other things) as it so often exists across the Microsoft Cloud in organizations that are really serious about doing so.
In any case… Let me just sum up and connect some dots before I move on.
AI is the obvious big news in the Microsoft Cloud, though my favorite massively under recognized trend is the move from governance to strategy. These are obviously not anywhere near to one another in terms of macro-economic and societal impact, but for technologists and IT practitioners (geeks like me) they converge upon similar conclusions, suggesting that organizations need to become far more strategic in the way they employ their Cloud technology:
Wave periods between big paradigm shifts in tech are shortening, and…
We are moving from activity-based to system-based value, i.e., the truly successful individuals and organizations are those that can assemble ecosystems rather than master discreet activities, and…
Governance—though critical and arguably more so as we figure out how to “govern” AI—has become table stakes and is no longer a winning theme unto itself.
The journey we’re traveling
So with the above philosophizing out of the way, I want to devote this piece from here to framing the discussions I am having with CIOs and their staffs in the form of practical guidance as to how organizations can think—then act—more strategically in their cloud adoption and employment of the technology.
We first must define who this is for: Organizations that are committed to undertaking a program of transformation across the Microsoft Cloud, including technologies labeled as Azure, Power Platform, and Microsoft 365 in conjunction with (usually) or absent from (rarely) third party technologies.
I have chosen my italicized word “labeled” carefully, because too many organizations and individual practitioners have made the mistake of placing these three technology families into separate buckets when in reality they are (a) all Azure or subsets thereof, and (b) meant to be used in tandem with one another. The technology plane is far too vast for any one person to be deeply skilled as an engineer in all of the above, but if you’re organizing around them as discreet product lines then you’ve already lost the plot on your strategic approach.
Let’s then continue by considering the journey that these organizations are traveling to secure, sustainable, and scalable success. Now, the way that I describe this has evolved over the years, but this graphic shows you where I’ve landed as of writing this piece. I am sure it will continue to evolve. To quickly summarize:
The first three stages (shown in blue) are the strategic table setting and progressive transition to execution that I’ll dive into more deeply in a few moments;
Our singular objective is to get the organization to a continuous, renewable and thereby never-ending cycle of innovation that I’ve defined here as the twin processes of solution building and platform maturation (shown in yellow);
Operations and maintenance (shown in green) is about transitioning mature components to stable, cost effective, ongoing operational status (think of it like hot and cold storage, remembering that you can always take something out of cold storage and get it back in your building and maturation cycle later, as needed).
The above context of the macro journey established, I’ll devote the rest of this discussion to the three “blue” stages of Inspiration, Co-Design, and Landing Zone where so much of the strategic table setting happens. I’ve summarized six considerations, activities, or exercises for each stage in the following diagrams, below which I will explore several in greater depth where I think further explanation is warranted. That further discussion is not to say which items are more important than others. Rather that my intent is to provide additional explanation where needed, say, around the concept of building an “Ecosystem Map”, whilst conversely I am not seeking to create a manual around well-worn tactical subjects such as, say, developing proofs of concept.
Stage 1: Inspiration
Executive Vision
I’ve tried in vain over the years to accommodate workarounds demanded by various organizations with whom I’ve worked. Alas, I’ve reached the same conclusion each time: Technology adoption really does not succeed without executive vision. The transition to platform-first approaches over the last several years is simply too challenging for most organizations to do absent long-term supported vision. You simply must define the organizational direction of travel for the technology at the CXO level to guide technical adoption. So I am going to linger a bit longer here given its importance to everything that follows.
Many CIOs will have already thought this through to one extent or another, by which I mean that their current thinking will fall somewhere into a large gap between “We need to do something! I don’t know, anything!” and a well crafted vision for their organization (joking, to an extent 😉). Regardless, when I help organizations refine their executive vision I am really trying to help them answer four questions…
What are we thinking about?
I am intentionally vague about this because we’re usually ranging from the informal “what or who is on your mind?”, i.e. what’s been in the news or things keeping you up at night, to the more formal “what are the stated, pre-existing business and IT goals?”. All valid. It’s important to have a solid grasp of your own thoughts here (collectively, as an organization, I mean). As we think this through we almost always start to see clusters of similar ideas emerge.What’s our philosophy or set of guiding principles for the technology?
Those clusters of ideas above become guiding principles that together establish our philosophy for use of the technology at hand. We’re trying (italics because it’s tough to do) to think a bit higher level here, avoiding specific references to specific technology. For example, we might establish a guiding principle to embrace platform-first approaches over more one-off point solutions without (at least yet) making any references to specific technologies or techniques for achieving this. Three to five of these guiding principles are the sweet spot, and whatever we decide on, we will make it a point of sharing these everywhere going forward (personal intro slides at front-of-deck are out, guiding principles are in!).What outcomes do we seek?
To make these guiding principles a bit more concrete, we need to turn them each into one to three outcomes that are as measurable as possible, without confusing them with metrics. I cannot overemphasize, though, that we are not talking about deliverables (see The Tyranny of the Deliverable). Outcomes, rather, provide us with ways to evaluate how well we are doing living up to our guiding principles. They range from the more vague “improve compliance for external audit and regulations” or “rein in shadow IT” to more specific “fully retire Lotus Notes from the organization” or “evacuate ABC data center”. I’ll also add that it’s often helpful that we revisit our original “what’s on your mind” items at this point, because some will invariably be good outcomes towards which we will strive.What are our must-haves?
Whereas outcomes are something towards which we strive, must-haves are things we can’t live without. Take care that you don’t confuse must-haves in this context with baskets of requirements (must I keep linking to The Tyranny of the Deliverable?), rather what we’re talking about here are more-tactical-yet-still-high-level considerations like “The CISO must bless this” or “our legacy HR system must go!” or “Lotus Notes really needs to be gone by XYZ date, for real, we are not joking”. Compelling events (the last Lotus Notes expert we have is retiring in December, and by the way, really sorry to keep trashing Lotus Notes here for it is but an example) and regulatory considerations make great must-haves. To be sure, there’s a lot of overlap between must-haves and outcomes, but again in general an outcome is a positive thing towards which we strive, whereas a must-have is a driving force that we can’t change.
Taken together, our guiding principles, corresponding outcomes, and can’t-live-without-’em must-haves form our executive vision that should drive everything downstream. And, most importantly, if we can’t justify that something aligns strongly to our executive vision we should be asking ourselves if it’s really necessary to do, or if we’re missing something big from our vision.
Introductory Education
I will dwell here least of all, for this is an exercise in getting the close participants in this journey on the proverbial bus by educating them in two things:
The executive vision we have just created, that is, the strategic intent with which we are taking the journey (plaster this everywhere and revisit again, and again, and again…)
Specific technologies in play and their capabilities (both at a high level) so that our major participants feel confident in at least a basic understanding of what we’re discussing here.
Record this. Make it available for later. Don’t spend endless cycles on awareness-level content.
Workload Prioritization
Workload is not a throwaway word. It is rather a specific word that I use precisely because I value its imprecision (I’ll give you a moment to untangle that sentence). App-centric people speak in terms of apps, integration-centric people speak in terms of integrations, etc. Workloads cover it all. They are, simply put, a collection of one or more apps, integrations, bots, reports, data models, VMs, etc. working towards the same end. I wrote nearly two years ago about the One Thousand Workloads concept specifically as it related to Power Platform, and it’s still a useful read in and outside of a Power Platform context if you care to go dust it off.
Our goal in workload prioritization (also known as “workload roadmapping” or “app rationalization”, depending on which circle you’re running in) is to create a prioritized roadmap of specific workloads to be migrated, modernized, or built anew via your platform-first approach. How an organization prioritizes them is largely up to its own specific circumstances (hello guiding principles, outcomes, and must-haves!), but my colleagues Paul Voss, Siddharth Singh, Sven Sieverink, and I recently assembled a battery of criteria from which we’ve seen most organizations choose to consider when they prioritize:
Alignment of the workload to the desired guiding principles or outcomes defined in your executive vision;
Legacy location in that where the workload lives today (e.g. the data center on the third floor of your headquarters) may significantly impact how high a priority it is for you to move, re-engineer, etc.;
Qualitative Assessment, that is to say the nexus of complexity and business value (see One Thousand Workloads), its scope, or impact on the business;
Integrations with other systems and data sources, which will itself drive how you assess complexity (see above);
Telemetry such as monthly or daily active users, last active use, data volume (remember to consider both structured and unstructured);
Security or compliance risks that exist in whatever systems or processes you are currently employing relative to a given workload (i.e. is our current model too risky for the organization?);
Legacy technologies in that you may, for example, highly prioritize dealing with workloads whose retirement will allow you to sunset, for example (sorry to beat a dead horse) Lotus Notes (or something else);
Target technologies in that you may highly prioritize workloads that are targeted for the same or similar technologies, i.e. if you’ve just made a significant license investment that you’d like to maximize.
There are likely more considerations, but these are my favorites towards which I like to guide the organizations with whom I work.
Ecosystem Map
I’ve introduced this concept to nearly all of the organizations I work with, and am always surprised by (a) how uncommon it is, and (b) how helpful the ecosystem map becomes. Uncommon because an ecosystem map sits between a truly functional story and a deep architectural diagram, so it becomes an act of technical story telling with which many do not have experience. Helpful because it pulls us out of use case or point solution thinking to refocus us on visualizing (and scrutinizing) how the organization’s entire cloud ecosystem (or a subset thereof) will piece together.
Let’s consider a few examples to convey the point. Really important to caveat here, though, that an ecosystem map does not replace deeper technical design such as integration architecture diagrams or entity relationship diagrams. As such, most ecosystem maps (particularly those of increasing complexity) gloss over or omit some critical technical details in order to convey a larger story about how the pieces of the cloud ecosystem fit together. This is a feature, not a bug. In time you will likely create deeper technical designs for each individual element shown on your ecosystem map(s).
The first diagram shown, Enterprise cloud platform in banking, is the more prototypical ecosystem map that I find myself drawing most frequently. It depicts a plethora of different Microsoft and third-party services integrated together as follows:
Core business systems including core banking, ERP, CRM, a portfolio of enterprise applications built primarily with Power Platform, and venerable SharePoint primarily geared towards document management but invariably housing some amount of structured data as well;
ERP and CRM solutions being Microsoft Dynamics in this case, they in combination with the enterprise-grade Power Platform solutions store their data in Dataverse; this is a good example of that glossing over where a more detailed technical architecture will sort questions about environmental architecture vis a vis Dataverse, dual write, etc.;
Data from the core business systems is aggregated in a “Data Landing Zone” (DLZ) in this case a Data Lake, with data in turn processed using a variety of services including Cosmos, Synapse, and SQL which in turn make data available back to the core business systems (see the sneaky arrow running along the bottom and reference my piece from January 2021 Power Platform in a Modern Data Platform Architecture), as well as to downstream “Analytical Consumers” relying primarily on Power BI, and…
In this ecosystem we are also making a selection of data available to external consumers such as branch and teller apps or banking partners via a middleware layer built primarily with Event Grid, Service Bus, Logic Apps, and Azure Functions pushing through an API Gateway out to the world;
Finally, the ecosystem map shows that the platform will be managed by a combination of data, infrastructure, and application management services including Purview, Azure Active Directory, Azure Monitor, Notification Hubs, Security Center, and Managed Environments.
The second diagram I’ll share here, Platform-first approach to enabling law enforcement, highlights a different approach from the first in that for the most part it prefers describing workloads in a more functional sense than referencing specific technologies. We have a number of different macro-level business activities being executed here, but broadly speaking this diagram shows:
Recruiting and onboarding facilitated through an external “Recruit and Hire Portal” built in Power Pages with authentication facilitated via Azure Active Directory B2C and data stored in Dataverse;
A “Single Source of Truth” established in Dataverse for personnel data including HR records, on and off boarding, security and vetting, pay and benefits, as-yet undefined “emerging needs”;
Solutions to manage medical functions, employee performance, and training and curriculum integrated with HR data and put in the hands of the workforce (as needed based on job role);
Operational planning, facility security, retirement and off-boarding workloads that draw on the aforementioned “Single Source of Truth” regarding people (people are really central to this specific ecosystem, just given the nature of the organization);
Real or near-real time reporting made available to decision makers using Power BI.
This second ecosystem map glosses over almost all technical details because the story it is telling is far more functional, which leads me to an important caveat that some situations may call for both approaches. Again, in practice, I find that I spend more time with the first approach.
Regardless, both of these ecosystem maps help us to connect vision and individual workloads in a way that hang together as “platform-first”, and they allow us to tell a story about where the organization is taking the technology long-term. Some nodes are more foundational to the others whilst some are less critical to the whole, a realization that in turn helps us to set priorities that move the proverbial ball in the direction of our strategic big picture.
Solution Co-Design and Proof of Concept (POC)
I’m not going to linger here for long, but to point out that I hope the progression in our thinking and our action is becoming apparent. We began with vision before identifying and prioritizing our workloads—a specific roadmap of what we hope to achieve as we turn vision into reality—before assembling our biggest puzzle pieces into an ecosystem map helping us to understand how those discreet workloads will fit together into something greater than the sum of its parts. Co-designing and then building a POC allows us to evaluate a thin slice of this in action, and importantly, resolve some lingering questions around technical feasibility.
I’ve come to value two important characteristics of a successful POC:
Time boxed, in that the best POCs don’t seek to achieve too much and in so doing avoid lingering on and feeding the Use Case Death Spiral (something between two and six weeks is just right);
Interdisciplinary, in that the best POCs test some of our most complex or tenuous assumptions across the domains of (primarily) apps, data, and integration, and (secondarily) infrastructure.
As you decide which elements of our strategic thinking to “light up” first, think with a bias for these two all-important characteristics, and don’t allow your technical practitioners to POC in their IT Tower of Babble.
Stage 2: Co-Design
Progressing into Stage 2: Co-Design we find that we’re transitioning from strategy to execution with increasingly specific designs through which we turn vision to reality.
Technical Nuts and Bolts is about answering (mostly) obvious yet sometimes vexing questions about how prepared the organization is—again emphasizing from a technical perspective—to actualize the strategy. Obvious examples in a Microsoft context are about bread-and-butter IT services in and around your Microsoft tenant (i.e., do you have one, and in what state do you presently find it?), identity management (how are you doing this today?), application lifecycle management (how—or are—you doing this today? with which tools?), etc. These are important questions through which a more complete understanding of pre-requisites is gained. Don’t neglect them.
Somewhat related to technical nuts and bolts in its need for specificity is our Security Assessment, through which we are determining which steps need to be completed in order to achieve whichever security accreditation is necessary such that the organization’s information security team will be satisfied with the envisioned technologies operating in a production state. This is best though of as a journey, as well, in other words by asking “what steps must we complete along the way to make all of this acceptable?”
Co-design of your Reference Architecture takes this further, essentially tying together what’s been learned from our technical nuts and bolts activities, what’s been agreed to in our security assessment, and what was envisioned through our ecosystem mapping. This is the more technical architecture that will define the platform foundation that must be built in order to deploy all of which follows. Microsoft has for several years had this well covered from an Azure perspective broadly, whilst finding any sort of similar depth lacking for Power Platform last year I took it upon myself to do likewise for those components of the Microsoft Cloud as well. These increasingly ought to be built alongside one another maximizing the use of shared services particularly around platform management, App Insights, etc.
Data Ecosystem Mapping is a bit of a throwback to our original ecosystem mapping exercise, and with good reason. Much of what we catch here may already have made an appearance in the earlier map, but this is our big chance to more fully understand the nodes in the organization’s data ecosystem for which we must account in order to build an integrated whole. Think systems of record, pre-existing master data management, data warehouse, lake, or lake house, myriad unaccounted for specs of data that are—apparently—more important than you knew. Map them. Prioritize them. Treat them as workloads.
Oft overlooked, particularly the more technical our bent, Community Planning begins to make our strategic thinking more real for our colleagues (and, potentially, third parties) who have not thought about it as deeply as we have (that is to say nearly everyone). I learned an important lesson about this years ago as a leader in a major (I cannot overstate how major) Azure app migration and modernization with a majorly large organization. This multi-year effort did quite a good job of what I’ll call “business onboarding”, essentially a programmatic approach to making Azure services generally available to specific business groups within the organization, opening its component services for migration to and use of, etc.
I will end this section with the final act in our transition from what began with executive vision to what will progress next with actually building and deploying technical services upon which we will actualize that vision: creation of our Enterprise Management Backlog. I have toyed with calling this a “Landing Zone Backlog”, but ultimately decided against this because an enterprise management backlog goes beyond building a landing zone. Here we are distilling much of we have done to date—our technical nuts and bolts, security assessment, reference architecture, data ecosystem nodes that are not otherwise covered as a specific workload, and our plan for our community—into a backlog of work that can be prioritized, assigned, and tracked to completion. The backlog turns increasingly specific ideas into executable packages of work. Some of it will be completed as part of the landing zone (next stage), whilst some will be deferred to the later, ongoing stage maturing the platform.
Stage 3: Landing Zone
I’m going to give this topic (which is highly tactical) minimal treatment in this piece (which has focused on strategic thinking) other than to describe it as the moment when we really start building in earnest. Thinking back to the original diagram I shared, your IT organization will have ideally organized its enterprise management backlog around the high-level themes of platform management, enterprise architecture, application lifecycle management, mature security model, and user empowerment. Like the landing zone concept itself—which began as an approach to getting started with Azure—I’ve imported these themes (pillars?) from the Power Platform Adoption Framework. I find this one Microsoft Cloud symmetry to be pleasing 🙂.
The one non-negotiable that I will cite here is that of our “Proof of Value”, which I earlier defined as an effort to “build the previously developed POC solution into a minimum viable product to be deployed for users”. We cannot declare the success of our landing zone until it contains at least one high-value element of our ecosystem that is actively delivering that value to the organization, whether in the form of apps, automation, data intelligence, or an exceedingly helpful AI model. I have seen too many organizations wax eloquent about vision, yearn to travel their workload roadmap, dream big about their ecosystem, build landing zones or runways or heliports or whatever aviation-themed technical foundations they please and then completely miss the mark on all of it because they lost the plot on why we’ve done any of this to begin with: Creating value that promotes our organization’s mission, which no amount of plans, infrastructure, or governance can do.
…which is why we’re moving from Governance to Strategy. Governance is done. Long. Live. Strategy.
Epilogue
A funny thing happened when I wrote my first book: My editor told me that the penultimate (second to last) chapter was the great ending, and insisted the I reverse it with the original last chapter.
Looking at the last paragraph above, I could argue the same is true of this tome. But my blog doesn’t have an editor, so indulge me whilst I indulge myself with one last thing thing.
Much earlier I shared that blue, yellow, and green diagram of the journey we’re traveling as we translate strategic thinking into long-term value through the use of Microsoft Cloud technology. But strategic thinking is not linear, and all strategies must be renewed (and wiped away entirely when they’ve sufficiently aged past their time).
So allow me to offer the amendment shown here, which adds an urging to regularly revisit our strategic thinking whenever our organization’s dynamics seem to dictate, and to refresh at least annually. We need not halt progress maturing and building, nor blow the entire thing up each year. But in returning to one of my original theses above, organizations that are likely to re-position themselves to catch waves whose periods are decreasing are those who possess the wisdom and the strategic intent to reconsider their prior notions and continuously build for whatever is next. Make sure you are one of them.
