Platform Strategy: Innovation Through Harmonization PDF
Document Details
Uploaded by Deleted User
2024
Gregor Hohpe
Tags
Related
- Week 3: Strategies for Two-Sided Markets (Eisenmann et al., 2006) Article PDF
- Entrepreneurial Strategy PDF
- Economic Approaches to Organizations (6th Edition) PDF
- Session 7_Digital Strategy Execution_Students PDF
- IM1044 Humans on Demand: Coople's Staffing Platform at a Crossroads PDF
- Platform-Mediated Networks: Definitions and Core Concepts PDF
Summary
This book, "Platform Strategy", describes how to build and use platforms for rapid and incremental software delivery. It covers understanding platforms, creating a strategy, designing in-house platforms, implementation, growing platforms, and organizational structure for platforms. The book uses various examples and emphasizes the importance of a clear strategy for platform initiatives.
Full Transcript
Platform Strategy Innovation Through Harmonization Gregor Hohpe This book is available at http://leanpub.com/platformstrategy This version was published on 2024-08-30 Platforms enable rapid and incremental software delivery. It only seems appropriate to embrace the same principles when writing a...
Platform Strategy Innovation Through Harmonization Gregor Hohpe This book is available at http://leanpub.com/platformstrategy This version was published on 2024-08-30 Platforms enable rapid and incremental software delivery. It only seems appropriate to embrace the same principles when writing a book about platforms. That’s why this book started out as a Leanpub book with early releases that improved based on reader feedback. You are now reading the result of this iterative process. © 2024 Gregor Hohpe Contents About this Book i Part I: Understanding Platforms 1 1. Standing on the Shoulders of Giants 2 2. The Fab Four of Technology Platforms 15 Part II: A Strategy for Platforms 27 3. Formulating a Strategy 29 4. Becoming a Platform Company 41 5. The Platform Paradox 51 6. Mapping Platforms 63 7. Addendum: “I ACED My Strategy” 73 Part III: In-House Platforms 77 8. In-House IT Platforms 78 9. IT Platform and IT Services Are Antonyms 92 10. Mechanisms, Not Magic 103 CONTENTS 11. Do You Have an Opinion? A Mind of Your Own? 113 12. Making Platform Decisions 122 13. Procuring a Platform 130 Part IV: Designing Platforms 138 14. The 7 “C”s of Platform Quality 139 15. Fruit Salad or Fruit Basket? 144 16. Cantilevered Platforms 151 17. Will Your Platform Float or Sink? 160 18. Beware the Grim Wrapper! 169 19. Build Abstractions Not Illusions 179 20. Failure Doesn’t Respect Abstraction 190 Part V: Implementing Platforms 196 21. Platform Anatomy 197 22. Platform Orchestration 208 23. Ownership and Tenancy 219 Part VI: Growing Platforms 227 24. Platform Evolution Is a Cube 228 25. The Shape of Platforms 237 26. Visualizing Platforms 248 27. Charting a Platform Roadmap 259 28. Tiering and Slicing 270 Part VII: Organizing for Platforms 281 29. Platform, Inc. 282 30. Multi-sided Platform Teams 293 31. The Customer-Centric Platform Team 302 32. Platform Teams Without Platform 310 Author Biography 322 About this Book My prior role as chief architect of a global financial services organization placed me in the middle of several major transformation programs. A major goal of those programs was to accelerate software delivery without compromising quality or security—two aspects that were believed to be at odds with each other. Undeterred by existing beliefs, we set out to deploy something called Agile Delivery Platform, which made software delivery “fast and compliant” and placed the broader IT organization on a trajectory toward a modern operational model. Reflecting back on our work, several important questions remain. Did we truly build a platform as the name suggested, or were we just naming it creatively? Assuming the former, which characteristics or capabilities qualified it as a platform? Could we have achieved the same results without a platform? Was building on a third-party product the key aspect of providing a platform? Would any “agile delivery mechanism” inherently be a platform? Were related initiatives like the “digital backbone” or the “digital core” also platforms but simply didn’t include the term in their name? Deep in our minds, we might have had plausible answers to those questions, but articulating them clearly would have been rather difficult. I freely admit that we chose the name without deep consideration; we mainly wanted to express both the project’s purpose (to enable agile delivery) and the mechanism (a common platform for all software projects). Both “Agile” and “Platform” also sounded like noble and useful things to us. A few years later, I benefited from two advancements: Internal Developer Platforms had become a “thing”, and I helped build one for the Singapore Government’s GovTech division. Making software delivery more efficient across government agencies, we were convinced that we were actually building a platform, perhaps helped by the inherent fuzziness of the term. However, diving deeper into the design trade-offs of developer platforms also raised a slew of new questions and design decisions that had to be made. Running our internal platform on top of commercial cloud platforms only added to the list of questions: what aspects should be part of our platform versus the About this Book ii cloud platform? What if the cloud launches a feature that makes our function obsolete? Who should own the services that our platform provisions? Should our platform handle billing? Eager to get to the root of it all, I joined a major cloud provider and spent several years working with customers to get the most out of that platform. Although one might expect that powerful cloud services would have made building in- house IT platforms superfluous, I observed exactly the opposite across large customers; they were building or deploying some sort of in-house platform, or often multiple platforms: developer platforms, data platforms, business platforms, digital platforms, multicloud platforms, and many more. And, unsurprisingly, they faced many of the same questions about their platforms. After assisting many customers with their platform strategy, I took the Architect Elevator further down into the engine room to develop serverless products, which are widely considered the canonical example of a modern compute platform. So, once again I found myself deep in the mechanics of making platform decisions: what technical details can be safely hidden from the user, and which ones should be exposed? How can services be independent while also being constituent parts of something that’s bigger than just the sum of its parts? Which aspect should be common across services? Is duplicate functionality across services a convenience or a design flaw? It seemed that the deeper I dug, the more questions arose. Expecting a single book to answer all questions about platforms would be naive. Instead, I set out, aided by formidable contributors, to structure the questions and define decision models that can help you answer those questions for yourself. After all, you have more information about your undertaking than I would ever have, and thus you can make better decisions. That’s why you won’t find simplistic 1-2-3 recipes in this book. Instead, if you’re new to the concept, you will find a smooth on-ramp, whereas if you’re experienced, I may test and challenge your current thinking with novel viewpoints. The Lure of Platforms Over the past decade, platforms have fueled some of the most successful busi- ness models, yielding companies with never-before-seen market valuations. Although they come in various shapes, all platforms share an “amplifier effect” that makes them enormously successful but deceivingly difficult to replicate. About this Book iii Marketplace platforms get their boost from the “flywheel” effect: more sellers provide a wider selection, thereby attracting more buyers, which in turn attract more sellers. That’s the mechanism that propelled platform powerhouses like eBay, Uber, and Airbnb to success and astronomical valuations. But the magic of the platform business model doesn’t end there. None of those companies keep any expensive inventory, because the platform’s value proposition doesn’t depend on directly delivering goods or services but on facilitating an exchange across an ecosystem of third parties. IT also loves a multiplier effect for its investments and therefore values plat- forms as a shared foundation on top of which diverse solutions can be built. Operating systems and cloud platforms hide underlying complexity, allowing developers to focus on delivering business value instead of toiling deep down in the engine room. The need for higher levels of developer productivity in fast-moving environments has made in-house platforms a staple of modern IT strategies. Outside of IT and online marketplaces, platforms already have a fairly long history. The automotive industry, for example, has long employed platforms to better amortize the heavy engineering investments required to build a safe and reliable car. Because few of the engineering elements like engine, transmission, or suspension are visible to buyers, they can be reused across models that differ in styling and interior options to attract different tastes and demographics. Yet, equating platforms with the act of combining all common elements and placing differentiators on top would be far too simplistic. Building IT Platforms Lured by the apparent benefits and successes of both platform business models and in-house platforms, many enterprise IT departments discover that building and financing your own platform is far more difficult than it might have initially appeared. Many platform initiatives consume multiyear investments just to be already obsolete or not accepted by users by the time they launched. Do such misfortunes invalidate the platform concept and value proposition? Surely not. But they highlight the value of a clear strategy and a deep under- standing of the constraints and assumptions that are baked into the platform. Instead of leaving implementation details for later or, worse yet, with a provider, platforms want to be built incrementally with a keen eye on value delivery. About this Book iv This book lays out the elements of a platform strategy, highlighting critical decisions and trade-offs to help platform teams become innovation drivers in enterprises. What Will I Learn? This book condenses years of experience building and using platforms into a mental framework for platform development. Covering technical, orga- nizational, and financial aspects, it is structured along the journey that an organization might take toward becoming a platform company. Part I: Understanding Platforms When people say “platform”, they may mean different things. That’s why it’s wise to first look at the history of platforms, catalog different types of platforms, and highlight their benefits. Part II: A Strategy for Platforms Building platforms requires a sizable investment and a clear strategy. That strategy must turn the objectives into an actionable path defined by meaningful decisions. Part III: In‐House Platform Most IT organizations experience platforms when they set out to build one. This part looks beneath the covers of such platform initiatives to highlight important characteristics. Part IV: Designing Platforms Platforms hide complexity, but building one isn’t nearly as simple as it looks from the outside. This part employs metaphors to illustrate platform design decisions. Part V: Implementing Platforms Diving deeper into the engine room, this part investigates platform anatomies and proposes common platform blueprints. About this Book v Part VI: Growing Platforms Platforms have to be rolled out across the organization. They also require deli- cate care and feeding over time so that they don’t fall victim to excessive entropy or become a bottleneck. This part shows you how to do this successfully. Part VII: Organizing for Platforms If you are building platforms, you’ll likely need a platform team, which is dif- ferent from typical application delivery or operation teams. This part describes how to build and manage a platform team. What About the Architect Elevator? This book is the second title in a growing series of “Architect Elevator Guides”, based on the novel role of architects defined in The Software Architect Elevator. Targeting architects and technical decision makers, these guides don’t get hung up on buzzwords and don’t try to provide simplistic one-size-fits-all answers. Rather, they combine decision models that exert architectural rigor with real-life anecdotes from the daily grind of corporate IT. In line with this approach, the books carry two “warning labels”; first: This book doesn’t tell you what to do. It teaches you how to come up with the best answer yourself. You know your situation best. Many things in IT can be copied from Stack Overflow, but strategy isn’t one of them. So, instead of giving you a fish, I want to teach you how to fish, that is, how to analyze your unique situation and selectively compose learnings from other organizations into a suitable strategy. And, second: You are bound to leave with more questions than you came with. But you’ll also be better prepared to answer them. Asking the right questions is a necessary first step for any successful strategy. I hope you enjoy the read and appreciate having more questions! About this Book vi Do I Need to Read All Chapters in Sequence? Just like the internet, my books are interlinked with cross-references between chapters and titles. Each chapter stands on its own, allowing you to skip ahead or start with a chapter that’s particularly relevant to your situation. The Architect Elevator guides, despite their titles, address a much broader audience than just architects. IT executives and decision makers may skip the technical details in Parts IV and V but will hugely benefit from the remaining parts. Folks leading a platform team may focus on Parts III, VI, and VII, whereas platform developers may skim Parts I through III and dive deep into Parts IV through VI. Architects will enjoy taking the elevator from the top levels down into the engine room across all parts. Do I Need to Read the Other Books First? The books in the Architect Elevator series are self-contained so that you can be consume them independently. That’s why it’s totally fine to start with this book. Cloud services are platforms, so you also might want to read Cloud Strategy, but you can do so before or after you read this one. The books in the series refer back to the “umbrella” book, The Software Architect Elevator, which introduces the way of thinking that we use to dissect complex domains like cloud computing or IT platforms. There is only minimal duplication across the books, so owning the complete collection is a great asset for any modern IT architect. What’s With the Jellyfish? Each book in the Architect Elevator series for IT leaders and architects features aquatic animals on its cover. Sea and river creatures are incredibly diverse and beautiful, so I expect to run out of content before I run out of images. All photos are my own. I felt that jellyfish make a suitable metaphor for platforms. Just like IT systems, they carry some complexity but function without a central nervous system (or a very rudimentary one). Unlike some IT landscapes, they are amazingly well- coordinated systems and beautiful to look at. About this Book vii Getting Involved My brain doesn’t stop generating new ideas just because the book is published, so have a look at my blog to see what’s new: https://architectelevator.com/blog Also, you can follow me on Twitter or LinkedIn to see what I am up to or to comment on my posts: http://twitter.com/ghohpe http://www.linkedin.com/in/ghohpe To provide feedback and help make this a better book, please join our pri- vate discussion group at https://groups.google.com/d/forum/cloud-strategy- book Acknowledgments Like my prior books, Platform Strategy benefited from the involvement of a wide range of people. I won’t be able to give due credit to everyone who provided valuable input, but I would like to call out Luca Acquaviva, Omar Khawaja, Manuel Pais, Johannes Seitz, and Clemens Utschig-Utschig for their insights and support. Special thanks go to HandyMaus for keeping everything working along the way. One entity I don’t intend to credit is AI. This book was entirely handwritten; no content was generated through GenAI technologies. Alas, I was tempted to make a bold statement here that the book is AI-free, but I realized that this doesn’t entirely hold. For example, modern spell checkers are AI trained, rendering the book AI assisted, perhaps, but nevertheless 100% human authored. Part I: Understanding Platforms There must be something about platforms. According to a report compiled in 2020, 7 of the 10 most valuable companies in 2018 based their success on a platform business model. Ten years earlier, in 2008, that number was zero. Many technology companies provide technology platforms, such as cloud platforms, that enable other businesses with modern IT infrastructure. Either type of organization might use internal developer platforms to increase their development speed, and a data platform to make business decisions. And virtually all of them operate on the internet, which is perhaps the ultimate innovation platform. As we quickly discover, the term “platform” is overloaded and can mean differ- ent things in different contexts. It is therefore beneficial to look at what makes platforms different from prior approaches such as frameworks or common ser- vices, when something should actually be called a platform, and how platforms deliver benefits for your organization. This part considers the platforms both in the business and technology space to set the context for diving deeper into designing successful platforms: Standing on the Shoulders of Giants examines the history and key prop- erties of platforms. The Fab Four of Technology Platforms catalogs different types of plat- forms that you are likely to encounter. 1. Standing on the Shoulders of Giants Do you really see further or is the air just thinner up there? If I have seen further, it is because I used a telescope Platforms are a common sight in daily life—they are normally a structure that you stand on; for example to catch a train or to get a better view. Generally defined as a raised level surface on which people or things can stand, technology platforms also appear to be raising things up a level or two. A platform model powers many successful companies, while cloud platforms have transformed modern IT operations by democratizing access to compute resources. Platform effects are not new. In their like-titled book, Kim et al.1 link the success of the Roman Empire to an open ecosystem strategy enabled by 80,000 kilometers of roads. They created a multisided market that spanned much of 1 Kim, Song, Im: Platform Strategy: a new paradigm for a changing world. World Scientific Publishing; 2020. Standing on the Shoulders of Giants 3 Europe and reduced the friction for interaction between (not always voluntary) participants. The old saying that all roads lead to Rome seems to equally apply to large modern platform companies. An eloquent—and widely cited—metaphor for using platforms are the words commonly attributed to Sir Issac Newton (although traced back to the 12th century): If I have seen further, it is by standing on the shoulders of giants. Many platform businesses have become giants, and architects have a keen desire to see further, so let’s begin by taking a look at the concept of platforms and their various flavors. Platforms Elevate A raised platform elevates you. This applies to train platforms as much as to product or technology platforms: building on top of a technology platform means you don’t need to start from scratch but can build on top of what others have created. Using a marketplace platform gives you instant access to a large set of merchants or customers. Publishing content to a social-media platform can elevate you to millions of participants consuming your content. As powerful as platforms are, so elusive is their precise definition. Perhaps that’s why Kim et al. resort to cataloging platform definitions spanning more than a decade. In his course on platform strategy for MIT Sloan’s executive education, Zach Church aims for a definition of platform strategy: A platform strategy is an approach to entering a market which revolves around the task of allowing platform participants to benefit from the pres- ence of others.2 2 As you will discover throughout this book, entering a market is only part of a successful platform strategy, with many technology decisions and trade-offs to be made along the way. Standing on the Shoulders of Giants 4 Most definitions portray platforms as amplifiers: they create something bigger than just the sum of their parts. This characteristic helps explain the popularity of platforms, but also leads to another insight: Platforms generate value through the interaction between their participants. A platform without participants isn’t providing value. It’s like a farmers market that’s lacking farmers and customers. To offset your instant enthusiasm for such a powerful model, Church quickly reminds us that building a platform is “really, really hard”. So, before you decide to jump on the platform bandwagon (there’s a fundamental flaw in that mix of metaphors that I am intentionally overlooking), you should take a closer look at common types of platforms, their characteristics, challenges, and benefits. Platforms: Faster, Better, Cheaper. Really? The popularity of platforms in both business and IT domains is easy to grasp when you see the outstanding results that platforms deliver. Just like any major buzzword, platforms are also subject to hyperbole and re-labeling. My bank is now a financial platform, the local bookstore has become a content platform, and the supermarket has evolved into a marketplace platform. If you take the words from marketing departments at face value, you might even believe that without a platform your business is utterly doomed. Let’s put our feet firmly on the ground (or the platform, so to speak) and dissect the buzzword to understand the benefits platforms provide in different contexts: Platforms enable Platforms generate value by allowing participants to benefit from the presence of others. Those participants can be buyers and sellers in a marketplace who gain access to a wider range of goods or prospects, respectively, and can transact more easily and safely. They can also be users of common technology platforms like cloud computing, which encourages experimentation with a consumption-based charging model. Content creators and consumers participate on social-media platforms to share and interact globally. Standing on the Shoulders of Giants 5 Platforms democratize Successful platforms make it easy for participants to join thanks to low barriers. For example, modern e-commerce platforms allow independent sellers to join with much less friction than trying to supply a major supermarket chain. Many influencers and content providers on social- media platforms started with a low initial investment, which would not have been possible in a traditional media model. Likewise, users can access powerful cloud platform services for pennies an hour. Platforms self-perpetuate Platforms that enable the exchange of (virtual or physical) goods between sellers and buyers appear to provide a form of perpetuum mobile: more buyers make it attractive for sellers to sign up for the platform, which in turn leads to a wider selection, which attracts more buyers. Walmart has known for a while that having one store carry everything is a promising business model. Modern platforms do so without the endless aisles and long checkout lines. Meanwhile, onboarding a new participant carries a near-zero cost: Airbnb doesn’t need to build a hotel room to increase its inventory. Such near-zero marginal cost business models are a key tenet of fast-scaling digital business model success. Platforms accelerate IT platforms and marketplace platforms alike handle common but labo- rious tasks (“undifferentiated heavy lifting” in the parlance of a major cloud provider). By making this toil go away, platforms allow their users to focus on innovation and differentiation, whether it’s an application that they are developing or social media content that they are uploading. Platforms don’t constrain Many approaches that promise acceleration rely on a “my way or the high- way” model: users benefit from lower friction if they abide by the rules of the framework. Platforms accelerate without constraining: Airbnb and other marketplace platforms offer more types of properties than tra- ditional hotel chains, and cloud platforms allow users to build virtually anything on top. Having been sold snake oil for decades, enterprise decision makers might look at these effects with a healthy dose of skepticism. Should we file platforms along with “model-driven architecture”, “executable design models”, and “seamless portability” in the large drawer of past technology ideas that not only sounded too good to be true, but actually were? Are platforms, in the words of a recent Standing on the Shoulders of Giants 6 Twitter user, just reinventing the wheel? Not so fast! Platforms are for real and are here to stay. Established Platform Models The success of platforms comes at a price: the label is used for numerous, quite different constructs. Although they share similarities, the mechanisms behind the different types of platforms are quite diverse. On the upside, platforms aren’t an entirely new concept—it’s just a common IT misbelief that we invented everything. Extraordinarily successful platform examples from automotive manufacturing, e-commerce, media, and IT will put the power of platforms in context. Automotive Platforms I am well known for car analogies, so I take great pleasure in reporting that au- tomotive manufacturers have been using a platform concept for many decades (see Wikipedia). Those companies realized that a huge amount of engineering effort went into a vehicle’s technical and safety components, such as engine, transmission, suspension, and anti-lock brakes. However, these engineering marvels are rarely visible to a prospective customer visiting the dealership. Even though the customer will consider safety ratings, power, and fuel consumption, which do result from the underlying components, purchasing decisions are often made based on the shape of the car, the interior finishing, the suppleness of the seats, or the badge on the trunk (boot). It was a logical move, then, to reduce cost by conducting the base engineering effort once and reusing the chassis and its components across models. Following this strategy, car manufacturers could offer a variety of car models, targeted at different customer segments and often under different brands, without ex- ploding engineering costs. Those cars exhibited a distinct look and feel despite sharing many components “under the hood”. Standing on the Shoulders of Giants 7 Automotive platforms boost innovation both inside the platform and on top These kinds of platforms are often referred to as “product platforms” or “inner platforms” to distinguish them from external platforms that involve customers or partners. The initial incarnations reused a complete chassis and many body parts, leaving relatively little room for customization. Some manufacturers described this approach as placing a “hat” (the car’s body and interior) on top of the shared technical platform (the chassis). Volkswagen, which began using automotive product platforms in the 1970s, evolved the platform concept into several modular platforms, such as the Volk- swagen Group MLB platform. Roughly translating into “modular longitudinal toolbox” (longitudinal referring to the engine orientation), it forms the basis for an amazing range of vehicles, from the Audi A4 all the way to the Bentley Bentayga SUV (using the so-called MLBevo matrix). Volkswagen’s new MEB platform is looking to achieve the same for electric cars. Against common belief, standardizing on shared platform elements didn’t re- duce choice or stifle automotive innovation. It achieved the exact opposite by boosting product diversity and technical innovation. BMW, for example, expanded its model range from a handful of series (3, 5, 7), to eight sedan series, eight SUV/crossover series, seven electric car series, several M series, plus a range of Mini vehicles. Such model diversity would not be economically viable without a platform strategy. Automotive platforms amortize large engineering investments across a diverse range of models. Harmonizing those elements boosts diversity and innovation in others. Standing on the Shoulders of Giants 8 Common platforms provide better economies of scale for engineering inno- vations such as anti-lock brakes or autonomous driving. The standardization achieved via the platform (coupled with componentization) boosts innovation, one of magic properties of platforms. With platforms, as with many other things, too much of a good thing can become an issue. The history of automotive platforms teaches a lesson about how much can be unified into the base platform and how much differentiation should remain on top of it. Based on the initial success, US car manufacturers took the platform idea a little too far in the 1980s by manufacturing essentially identical models that differed just in a few options or cosmetic elements. At its extreme, only the brand and model badges were different—a technique referred to as “badge engineering”. Relabeling is not platform engineering Although tempting, this approach negated a key platform benefit: supporting diverse models and boosting innovation. Unsurprisingly, these attempts largely backfired, immortalized by the Cadillac Cimarron, which was positioned as a luxury car but was virtually indistinguishable from a fully equipped economy- class Chevrolet Cavalier. Its abysmal market response earned it a place on Forbes’ list of Legendary Car Flops and its only contribution to the automotive world was lending its name to the “Cadillac Cimarron Effect”. Automotive history teaches us that both what’s in the platforms and what’s on top matter. Near replicas don’t work. A critical success factor for platforms is defining which aspects can be harmo- nized and which ones must be kept variable. Standing on the Shoulders of Giants 9 E‐Commerce Platforms When speaking about platforms these days, many people refer to digital ecosys- tems as embodied by companies like Amazon, eBay, Gumroad, Alibaba, and the like. These marketplace platforms connect buyers and sellers or people sharing a common interest. A suitable definition that captures the intention of these business models can be found in Reillier’s book, also titled Platform Strategy:3 A business creating significant value through the acquisition, matching, and connection of two or more customer groups to enable them to transact. Not all marketplaces are platforms. An analogy from the retail business helps find the delineation. A supermarket connects buyers with goods to be sold while holding its own inventory and being directly involved in the purchasing transaction. In contrast, a farmer’s market connects buyers and sellers directly, letting them handle the transaction and maintain inventory. Whereas a farmer’s market is a “multisided platform”4 , a supermarket is— strictly speaking—not. Farmer’s markets democratize and enable transactions between farmers and consumers (the two sides), whereas supermarkets actively manage—and control—their supply chain. Physical marketplaces and e-commerce platforms enjoy broad flexibility in their pricing models: They can charge buyers, for example by charging admission to a trade fair or farmer’s market. Likewise, online platforms can charge membership fees to buyers, often pegged to premium services like fast or free delivery. They can charge sellers, for example by asking a fee for a farmer to have a stall. In the online world seller fees can be listing fees, transaction fees, membership fee, or any combination thereof. 3 Reillier B and L: Platform Strategy: How to Unlock the Power of Communities and Networks to Grow Your Business. Routledge; 2017. 4 Hagiu A: Multi-sided Platforms: From Microfoundations to Design and Expansion Strategies. Harvard Business School; 2006, working paper 07-094. Standing on the Shoulders of Giants 10 They can monetize through third parties, for example by inviting sponsors or selling advertising space, both in the physical world or the online counterparts. They can also monetize the data they collect by selling it to third parties. This flexibility allows e-commerce platforms to offer services “for free” to select groups of the multisided market. Shifting pricing between participant groups or subsidizing specific types of transactions enables platforms to balance supply and demand, to drive growth, or, inversely, to moderate growth to uplift the quality of content or goods. Despite the risk of backlash, changes in pricing models are fairly frequent. Meetup provided a dramatic example by losing some 95% of their listings, but drastically improving quality, after starting to charge fee to organizers5. As the platform enables direct interaction between participants, it steps into the background—just like a real-life platform that’s underneath the real action. Online platforms may be barely visible because they allow retailers to operate as white-label shops; for example, on Shopify. Likewise, when you visit the farmer’s market you might notice the organizer’s presence only by a banner at the entrance and a small organizer’s booth. This is quite different from a supermarket where you are keenly aware of whose “ecosystem” you are in. Major e-commerce platforms such as eBay, Amazon (which is careful to label itself as a marketplace), or Airbnb have harvested the perpetuating scale effects cited at the beginning of the chapter. Amazon refers to this virtuous cycle as The Flywheel, inspired by the model presented by Jim Collins in Good to Great.6 This wheel includes two positive feedback loops. The first occurs over the number of buyers and sellers, which fuel each other’s participation: more buyers attract more sellers, who carry a wider selection, which attracts yet more buyers. A secondary loop lowers the cost structure with increasing scale, which in turn allows lower prices, which then further fuel growth. 5 Parker, Van Alstyne, Choudary: Platform Revolution: How Networked Markets Are Transforming the Economy. W. W. Norton & Company; 2016. 6 Collins J: Good to Great: Why Some Companies Make the Leap and Others Don’t. HarperBusiness; 2001. Standing on the Shoulders of Giants 11 The Marketplace Flywheel Such feedback loops are behind the tendency of e-commerce platforms’ toward a “winner takes all” scenario in which a single platform dominates its respective market segment. That’s the power of platforms and positive feedback loops. Media Platforms A close relative of e-commerce platforms are social and media/streaming plat- forms like Facebook, TikTok, Netflix, Twitch, and many others. Like their cousins, they operate a multisided market that connects providers and con- sumers of services, in this case, social data (photos, posts, events) or media such as audio and video streams. They enjoy a similar flywheel effect that attracts consumers to the platform with diverse content, which in turn attracts content providers because they’ll get more eyeballs. They may lack the outer loop of lower prices (their cost of goods tends to be near zero) but that hasn’t dampened their growth in the least bit. The internet bubble of 2000 was driven by the obsession with “eyeballs”, replacing traditional metrics like revenue or profit with the number of viewers. Two decades later, platforms have figured out how to scale and actually monetize those eyeballs. The primary revenue streams for these platforms are advertising or subscription fees. Some media platforms play the role of both the platform operator and a Standing on the Shoulders of Giants 12 platform participant; for example, producing their own video content (“Netflix originals”) but also distributing third-party content. Platform companies enjoy a large amount of flexibility and tend to experiment all the time. Cloud Platforms Cloud computing has perhaps been the most significant IT innovation of the past two decades, being challenged just recently by the rapid rise of AI and large language models (LLMs). The cloud also gave birth to a hugely successful technology business models, with just the top cloud service providers (CSPs) generating combined $200 billion in annual revenue. The collection of on- demand IT services provided by these companies are commonly labeled as platforms, with Google’s cloud offering proudly carrying the label in its name: GCP—Google Cloud Platform. The original motivation behind cloud platforms resembles that of automotive platforms. Just like cars, software requires a lot of heavy-duty engineering that isn’t directly visible to the end user. Underneath a successful piece of software lies a vast array of compute infrastructure like data centers, global networks, servers and storage, software delivery pipelines, monitoring and failover mech- anisms, synchronizing data stores, backup and disaster recovery, and regulatory compliance reporting. Those aspects can consume a large portion of a software project’s timeline and budget before the first line of application code is ever delivered. Combining those elements into common components that can be reused across many software projects allows developers to focus on providing customer value and differentiation; for example, through rapid feature delivery, unique func- tionality, or ease of use. They leave the heavy engineering work to the cloud platform providers, who have better economies of scale thanks to their broad customer base. IT departments consume those services in a low-friction way via a so-called cloud console (Web interfaces) or API calls that provision service instances to be used by custom applications. Standing on the Shoulders of Giants 13 Cloud platforms allow application teams to focus on differentiation Although they follow similar approaches, cloud platforms also differ from automotive platforms in several ways—after all, they are software. First, usage and application diversity are much broader. Whereas an automotive platform supports a handful of models for a specific automaker, cloud platforms support software development across a vast variety of use cases. It’s the equivalent of using Volkswagen’s chassis, engine, transmission, and suspension to put your custom interior and bodywork on top. Although this model exists as so-called “kit cars” (which generally modify a finished car to simplify registration), it’s a small fringe business and large-scale automotive platforms lack such flexibility.7 Bits and bytes are more malleable than steel. Second, cloud platforms allow developers to use the common components easily without any welding or assembling. A platform’s value isn’t just defined by what’s inside, but also by how easily its functions can be accessed. This is where cloud platforms shine. Even though they might look like traditional IT outsourc- ing from far away, the interaction between platform provider and platform user is notably different: month-long contract negotiations are replaced by an API call and near-instant provisioning. Last, cloud platforms offer more fine-grained components than automotive plat- forms possibly can, offering several hundred individual services to customers. The only possible challenge remains an abundance of choice. The success of cloud platforms is nothing short of phenomenal, creating a quarter-trillion-dollar market (according to Gartner) in just a decade-and-a- half. That’s no surprise when you consider that cloud computing has fundamen- tally transformed IT—from months of infrastructure planning and provisioning to running an automation script and waiting a few minutes. 7 Volkswagen will, however, sell you a kit to convert your classic into an electric car: https://www.volkswagen.de/de/besitzer-und-service/magazin/elektromobilitaet/classic-cars-turn-into-electric- vehicles.html. Standing on the Shoulders of Giants 14 Business Platforms Business platforms aim to elevate what cloud platforms achieved for IT in- frastructure toward business applications. Starting off as powerful applica- tions, these products added more capabilities for customization by splitting common functionality from specific needs, much like automotive manufac- turers did. Prominent examples include SalesForce for Customer-Relationship Management (CRM) and SAP for Enterprise Resource Planning (ERP). The SalesForce application sits on top of the “Force.com” (now SalesForce Platform) development platform, whereas SAP features a Business Technology Platform (BTP), both allowing customers to build their own business applications and customizations. The critical progression from a feature-rich business application to a platform is twofold. First, the vendors transitioned to a Software as a Service (SaaS) operational model that vastly lowers the friction of both user adoption and platform evolution. Second, configuration settings, which often constrained customers, gave way to custom applications, which utilize the application domain’s data model but don’t place any constraint on the code developed on top. The combination is indeed powerful. Cloud computing platform vendors haven’t been oblivious to the power of business platforms. Virtually all of them offer business capabilities as services, such as Amazon Connect for contact center management and the Microsoft Dynamics suite for accounting and related business applications. The Platforms of Giants There are valid reasons that platforms seem to be everywhere these days. Many platform providers are indeed giants, whether it’s automotive giants, e- commerce giants, or internet giants. That doesn’t mean, though, that there’s already a platform for everything or that you have to be a giant to build one. Let’s go on to catalog widely-used technology platforms, including those that are commonly built in-house. 2. The Fab Four of Technology Platforms Technology drives business models. The stars of modern IT The examples from the automotive, e-commerce, cloud, and enterprise software domains cited in Chapter 1 hint that there are different flavors of platforms. Architects don’t like fuzzy terms and generally aren’t content with enumerating examples as a replacement for a well-structured ontology. So let’s add a bit more structure and catalog common types of technology platforms. I can’t quite promise that we’ll arrive at a universal ontology, but at a minimum, we’ll gain vocabulary that we can refer to for the remainder of this book. Technology Platforms There are many ways to slice the platform universe, and whichever way you do it, you’re bound to exclude several varieties or leave gray areas in other The Fab Four of Technology Platforms 16 places. Narrowing down the field to technology platforms provides some relief. Platform business models are well documented in books like that by Reillier,1 allowing Platform Strategy to mainly zoom into what it takes to build a technology or business capability platform, including the architecture decisions and trade-offs one will face along the way. We will discuss platform business models mainly to provide context or to delineate those platform models from technology platforms. To sharpen the vocabulary the book will be using, we’ll distinguish four types of platforms that a typical organization would encounter in its strategy plan: Types of platforms used in the context of IT Combinations are commonplace because the platform types reside in different layers of the IT stack. For example, a large organization could be a participant in a third-party marketplace, build its in-house developer platform on top of a cloud base platform, and provide business capabilities to ecosystem partners. Let’s look at common use cases for each platform type, how users interact with it, how they can be implemented, and some considerations to keep in mind. Marketplaces As highlighted in the previous chapter, marketplaces facilitate transactions between customer groups such as buyers and sellers of physical goods, or consumers of services like media, car sharing, or accommodation. The mar- ketplace appears to step into the background during the transaction but is a critical facilitator of the connection between seller and buyer or producer and consumer. 1 Reillier B and L: Platform Strategy: How to Unlock the Power of Communities and Networks to Grow Your Business. Routledge; 2017. The Fab Four of Technology Platforms 17 Common Use Cases This is the domain of e-commerce platforms like eBay, Amazon, Etsy in the US; Tokopedia, Carousell, Mercari, or Taobao in Asia; and mobile.de or Allegro in Europe. The same model is used by “match-making platforms” for ride-sharing (Uber, Lyft, Grab, Didi, Careem), accommodation sharing (Airbnb), or dating (Tinder). Most of them follow the farmers’ market model by enabling providers and consumers to transact directly while the platform handles search, advertising, reviews and ranking, fraud detection, and sometimes payment services. The marketplace benefits from not having to maintain inventory, which keeps op- erating costs down and reduces the marginal cost of onboarding a new seller or buyer to near zero. The marketplace can generate revenue in a variety of ways, including seller listing fees, placement fees, member fees, transaction fees, or advertising fees. Interaction From a technical perspective, participants interact with the marketplace plat- form via a web browser, mobile app, or application programming interfaces (APIs). Marketplaces commonly provide sellers with functionality beyond listing goods to also define their own storefronts, often without any custom programming effort, to further reduce onboarding friction. Balancing low friction of joining against assuring the quality of services and minimizing fraud is a major aspect of building consumer trust in the platform. Implementation The majority of major marketplace platforms are custom built and thus propri- etary. The primary reason lies in the enormous scale and transaction volume that these platforms handle, coupled with rapid growth. These companies’ state- of-the-art data analytics and machine learning technologies help them battle fraud, prioritize high-quality listings, and manage ad placements. They are mostly developed in-house because they are the company’s key assets and often ahead of what’s available on the open market. Luckily, not everything those platforms produce remains proprietary. Several marketplace engineering teams have published open-source projects that are The Fab Four of Technology Platforms 18 based on their in-house developments: Airbnb’s Synapse, Uber’s Jaeger, Spo- tify’s Backstage, or Netflix’ Chaos Monkey are just a few examples. These projects are engineering tools that can be used across industries and don’t give away the marketplace’s secret sauce. Still, they allow other organizations to benefit from the giants’ engineering efforts. Becoming a marketplace is less of an IT decision—it’s at the heart of your business strategy. Often classified as a B2B2C model, meaning you as a business (visibly) provide a service to other businesses to better serve their customers, marketplaces look easy to build, but they are extremely difficult to scale. Suc- cessful marketplaces have taken investments of more than $1 billion, highlight- ing the massive resources that are needed to grow a platform business. Considerations Marketplaces, despite several runaway successes, have well-known challenges. For example, the positive feedback cycle between buyers and sellers can flip into a chicken-or-egg problem at launch. Also, the apparent flexibility in pricing models is subject to balancing supply and demand. For example, if the platform lacks suppliers (sellers), imposing seller fees will further impede the platform’s growth. The challenges of growing a new platform contribute to the “winner takes all” nature of established marketplace platforms. Base Platforms At the other end of the spectrum, further down the IT engine room, are base platforms. These platforms provide technical products and services to support developers and IT departments. They are one sided in the sense that the platform operator creates all services to be consumed by a specific user group. Still, base platforms often harvest the power of multisided markets by including a software marketplace for third parties. They have thus become a hybrid between a base platform and a marketplace. Things are rarely clear-cut in this space as companies continuously experiment with new products and revenue streams. The Fab Four of Technology Platforms 19 Common Use Cases The most common base platforms in current enterprise IT are cloud platforms such as AWS, Microsoft Azure, Google Cloud, Ali Cloud (Aliyun), or Huawei Cloud. Consuming software from third parties is nothing new in IT, but base platforms differ in several aspects. For one, they provide services that tradition- ally would be done in-house, such as provisioning servers, storage, and network hardware. Second, these platforms aren’t a single product like an accounting system or a Customer Relationship Management (CRM ) system; they are a collection of services on top of which customers can build applications. Base platforms can be layered as well. For example, the Kubernetes ecosystem is widely considered as a base platform on top of which developers deploy applications. One might even credit it with converting traditional on-premises IT into a base run-time platform. Similarly, many open-source data analytics products act as base platforms, although they more likely label themselves as engine (following the automotive platform nomenclature, an engine should be part of a base platform). The dividing lines are rarely super crisp, with many large software vendors labeling themselves as software platforms these days. We’ll dive into those nuances later. Interaction Base platform users generally interact via several means: Online consoles, which actually aren’t consoles in the Wikipedia sense, but rather web interfaces that allow users to provision and configure resources. Command-line interfaces (CLIs), which support direct interaction or scripting for automated execution of platform instructions. Web APIs that can be called directly from applications. Cloud platforms feature automation languages in the form of Infrastructure-as-Code (IaC) tools (for example, Terraform, CDK, or Pulumi), which in turn interact with the base platform’s APIs. Base platforms aim for feature parity across all those access channels, meaning the same features are available regardless of which approach a user chooses. Platform users are developers or IT professionals, leading to higher onboarding The Fab Four of Technology Platforms 20 effort than with an e-commerce marketplace or social media. Reducing the cognitive load for new platform consumers (and thus the friction) is a major theme for cloud providers as they are looking to keep scaling their platform to more users. Implementation Just like marketplaces, base platforms tend to have proprietary implementations due to the enormous scale and complexity of provisioning resources on demand around the globe. The level of customization extends down to the hardware with cloud providers now providing custom CPUs (e.g., AWS Graviton), custom AI accelerators (GCP’s TPUs or AWS Trainium), custom hardware architectures (e.g., AWS Nitro), or security chips (e.g., GCP Titan). Platform services can be based on open-source projects, aided by proprietary run-time extensions to integrate with the platform’s control plane to handle provisioning, billing, monitoring, and so on. Considerations Constructing such a broad platform is a rather involved topic, which we won’t address here. Cloud Strategy provides a detailed description of how to success- fully consume cloud base platforms. Base platforms’ comprehensive capabilities can lead to high user expectations, which challenge in-house platform teams with much more limited resources. Cloud platforms also highlight one of the most fundamental dynamics of plat- forms: How users access your platform is at least as important as what’s inside. Cloud providers initially offered virtual machines, storage, and queues—nothing new, really. But the way users could consume those services was dramatically different and spawned a trillion-dollar market. The Fab Four of Technology Platforms 21 Developer Platforms In-house developer platforms are built by IT departments, generally to provide reuse of common IT services, to boost developer productivity, and to assure compliance with operational guidelines. These platforms support the in-house Software Development Lifecycle (SDLC) that development teams follow to de- liver custom software. Part IV is dedicated to the detailed design considerations for such platforms. Common Use Cases In-house platforms come in a wide variety of flavors, essentially covering the entire SDLC. Software delivery platforms enable autonomous development teams, run-time platforms provide deployment and observability functions, and data-analytics platforms manage access to shared data. Backstage is a widely used tool to build in-house developer portals and tools. Many organizations aim to shield developers from the specifics of the base cloud platform, driven by the desire to reduce vendor lock-in and also boost productivity. Sadly, more often than not, those platforms end up restricting developers’ choices and hinder productivity— clearly the opposite of what a platform should do. Several companies have externalized portions of their internal platform. Ama- zon Web Services (AWS) and Kubernetes are prominent examples. AWS evolved from supporting Amazon’s e-commerce marketplace (an in-house platform) into one of the largest base platforms for IT services. Kubernetes was specifically built to be shared as open-source software, but incorporates many of the features of Google’s internal Borg workload management ecosystem. Both products were part of the provider’s overarching platform strategy. Interaction In the best case, application developers interact with in-house platforms much like they would with base platforms; that is, through well-designed web consoles or APIs. However, in-house platform teams might lack the capacity to provide feature parity across web consoles, command lines, and APIs. The Fab Four of Technology Platforms 22 Although in-house platforms typically coexist with the underlying base plat- form to give developers direct access, others intentionally restrict such access to avoid dependencies or developers circumventing governance coded into the in-house platform. The latter are prone to running into the Grim Wrapper symptoms. Implementation In-house platforms commonly reside on top of one or more cloud (base) plat- forms. They might span public cloud and on-premises data centers to give enterprises (a semblance of) a uniform development and deployment model across modern cloud providers and existing on-premises environments. Part IV and Part V dive deeper into implementation aspects. Considerations In-house platforms live in an exciting but also hotly contested space between base platforms that are developed by large-scale providers with ample resources, widely available open-source projects, and development teams. Therefore, they have to consider their scope and positioning very carefully and have to live up to the expectations set by external developers. Even though they are not offered on the free market, in-house platform teams are tasked with supporting a variety of internal customers. They may find themselves surprised that they need internal marketing, consulting, support, and related functions that makes them resemble a company within a company. A large portion of this book dives into these decisions. Business Capability Platforms Whereas developer platforms largely contain technical tools for developers, business capability platforms expose functions from the business domain. The delineation is easy to understand by the fact that a bank, a retailer, and a ride-sharing company could use the same developer productivity platform but have very different business capability platforms that reflect their respective domains. That’s also the reason why we see a lot of sharing via open source in the former but not the latter. The Fab Four of Technology Platforms 23 Business capability platforms are often built and maintained in house but can be made available to external parties to enable a provider ecosystem. Examples range from digital identity services in the public sector to payment APIs offered to enable embedded finance in the Fintech industry. Externalized platforms can evolve from in-house services that are augmented and hardened to allow them to be accessible from outside the organization. Externalized business platforms can in turn serve as base platforms for develop- ment inside ecosystem participants, highlighting the layered—or even fractal— nature of the overall platform ecosystem. Common Use Cases Business capability platforms can be found across industries. In fashion e- commerce the About You Commerce Suite evolved from a proprietary imple- mentation of a fashion e-commerce marketplace. In financial services, you’ll find platforms like Allianz’ now defunct Syncier spin-off, which made Allianz’ core insurance system available as a software platform for other insurance companies. Its marketplace of third-party solutions, described as Insurance- as-a-Service, was spun off and acquired by Munich Re. Other enterprises offer collections of lighter-weight APIs to grow external ecosystems. For example, banks (like DBS Bank’s Developer APIs or Standard Chartered’s Axess) have encouraged the development of third-party applica- tions that make use of their payment APIs. For other payment providers like Stripe, the business capability platform is the core business. Cloud providers also play in this space by offering higher-level services in addition to traditional IT services such as compute or storage. For example, AWS provides call center services with Amazon Connect, whereas Google Cloud includes medical imaging services. Interaction APIs are the key enabler for business capability platforms as integration fre- quently occurs across organizational boundaries. Externalized platforms allow higher degrees of integration and customization, usually at the cost of higher friction for adoption. This additional friction of onboarding can counteract the “platform-ness” of such offerings and position them closer to the traditional The Fab Four of Technology Platforms 24 model of large, customizable software packages like SAP. Just exposing your internal application via an API in a multi-tenant model does not automatically make it a platform. Implementation Business capability platforms are developed like regular software products but have additional provisions for external usage, such as public APIs, multi- tenancy, or scalability. Those aspects make them well suited to be built on top of a cloud base platform. Operational aspects like data security or legal considerations tend to play a larger role due to the business-to-business nature of the relationship between platform provider and platform consumer. Considerations Although offering business capabilities to third parties might benefit direct competitors, it also opens up new revenue streams and market opportunities. For example, About You or Amazon could have considered their internal tooling a competitive advantage that they prefer to keep to themselves. In AWS’ example that would have meant to forgo a $100 billion opportunity. The old slogan, “When there is a gold rush, sell shovels,” appears to apply here: successful companies don’t just compete as a business but also benefit from selling tools to others. The capability platform approach thrives in environments like fash- ion retail because the existence of diverse niche markets and spe- cializations reduces the risk of a platform provider receiving direct competition from its platform customers. One of the underappreciated benefits of offering an in-house product as an external platform is the insight one gains into how others use the platform. Such insight can in turn be used to improve in-house products and operations, gaining a critical market advantage. That’s why Simon Wardley calls platforms future sensing engines. The Fab Four of Technology Platforms 25 Four in a Row We can compare and contrast the platform models as follows: Model Common Value Interaction Implementation Examples Proposition Marketplace Airbnb, eBay, Facilitate Browser, Proprietary Amazon, transactions Mobile App, Mercari API Base Cloud Rapidly Console, CLI, Proprietary providers provision IT API, plus open resources automation source Developer Portals, cloud Increase speed, Portal, Composed “wrappers” reuse, command line from open governance source Business Allianz Build an open APIs, custom Proprietary, on capability Syncier, ecosystem integration top of base About You platforms Many people initially associate the word “platform” with marketplaces or mul- tisided markets. Given the ample coverage of marketplace platforms, this book acknowledges the overloaded term but focuses on the platforms that large-scale IT most commonly creates: developer and business capability platforms. Combinations Encouraged Strategy books prefer classifications to be MECE or Mutually Exclusive and Collectively Exhaustive, which makes them well suited for decision trees: all options are distinct and jointly cover the available solution space. This approach doesn’t work well in the almost fractal-like, layered world of platforms. Many platform companies engage in multiple options: marketplaces are routinely built on cloud base platforms. In-house platforms can be externalized later, perhaps even evolving into a base platform like Amazon has done with AWS. Similarly, a business capability platform can help its customers build a marketplace plat- The Fab Four of Technology Platforms 26 form, as commonly observed in fashion e-commerce. That’s why our list of platform types is decidedly non-MECE. Primus Inter Pares? Providers who pursue multiple models tend to boost their credibility by high- lighting that they are both a platform provider and user (“We don’t just build for the market. We are part of it.”). Those organizations must carefully consider feature parity across their in-house and the externalized platform. The famous antitrust case against Microsoft was partly based on allegations that their base platform, the Windows operating system, included undocumented features and APIs to enhance Microsoft’s own software products like Internet Explorer versus market competitors. Microsoft subsequently agreed to publish those Windows APIs as part of the settlement in 2004. So, although it’s good to be your own customer, it’s even better to play fair. Part II: A Strategy for Platforms Platforms can play a pivotal role in IT transformation by reducing complexity, harmonizing software delivery, and stabilizing operations, all the while reduc- ing cost. It’s no surprise, then, that they have become a staple in today’s IT and business strategies. But launching a multisided market business model, building an in-house developer platform, or even using a cloud base platform are major strategic decisions that require significant investments in both technology and organizational change. That’s why success with platforms rarely results from an IT department’s effort alone. Bridging both IT and business strategy is a key aspect of a successful platform strategy. Any gaps in this area can become the source of expensive failures. “Strategy” as a term sadly doesn’t stand far behind “platform” when it comes to fuzziness and overuse. So, this chapter starts by recapping what it means to define a strategy before zooming into platform strategies. Strategy will never be a “paint by numbers” exercise (nor should it be), but organizations can benefit from common building blocks and recipes harvested from successful platform strategy definitions and executions. The following key elements play a critical role in defining a platform strategy: Let’s first describe what constitutes a sound business or IT strategy for large organizations. Becoming a platform company requires organizations to rethink their existing ways of working 28 Platforms can overcome apparent opposites such as innovation and har- monization. Wardley Maps are excellent models to understand what drives platform adoption and how platforms drive innovation. Writing a strategy document can lead to writer’s block, so it’s good to have a mental framework. 3. Formulating a Strategy Strategy is the difference between making a wish and making it come true. Based on this classic information hiding strategy… Given the power of platforms, whether internal or external, one-sided or multi- sided, it’s natural to want to include them as part of your IT strategy. Unsur- prisingly, merely adding a line item to your list of ambitions won’t do much to lead your organization to platform enlightenment. So, it behooves us to revisit what makes a meaningful strategy. Strategy Is Hard Good strategies look simple in hindsight. However, defining one and document- ing it well is anything but simple. The opening statement of A.G. Lafley and Roger L. Martin’s book Playing to Win: How Strategy Really Works, captures the challenge well: Formulating a Strategy 30 Strategy is not complex. But it is hard. It’s hard because it forces peo- ple and organizations to make specific choices about their future— something that doesn’t happen in most companies. Meaningful strategies must connect the dots between long-term vision and short-term tactics, between business and IT, and between quantifiable success metrics and beliefs. Platform strategies are no exception. Strategy Is Hard to Argue Against Strategy as a term operates in similarly fuzzy territory to “architecture” and “platform”. Still, hard data confirms that it’s become a rather popular term over the past half-century, as demonstrated in the illustration that follows. Mentions of the word “Strategy” Strategy’s popularity might be fueled by reams of business books, aided by the need for an anchor point in an ever-changing and increasingly complex world. Apparently, I am not above the trend, having chosen to suffix my entire book series with the magic word. Life writes the best stories, and any cynic finds ample fodder in two familiar places: professional services and large enterprises. When working in consulting, I found the term “strategy” frequently applied to justify actions that eluded any rational argument: Any potential engagement in an undesirable location that was unprofitable and required scarce skill sets was routinely labeled as “strategic” by the sales team. A strategy seems difficult to argue against: it lays out a compelling vision that might materialize sometime in the future and therefore can’t be proven or Formulating a Strategy 31 disproven so easily. Although some amount of speculation can’t be avoided when predicting the future, that shouldn’t be a license to disregard current reality. Good strategies “think big” but are meaningful only if they can lay out a credible path starting from the here-and-now. Make Your Platform Wishes Come True This book is the second title in a series on IT strategy. Volume 1, Cloud Strategy, describes the power of a strategy rather vividly: A strategy is the difference between making a wish and making it come true. A strategy lays out a path that makes important decisions and trade-offs so that the vision won’t remain just a wish but can become reality. This isn’t a book about strategy (the virtual shelves are full of those), but it’s helpful to highlight the foundations of a good strategy for IT transformation: You Can’t Copy‐Paste Strategy Many of today’s enterprises are transforming their IT to better compete with digital disruptors and remain competitive in a fast-changing world. Naturally, they’re reviewing other organizations’ experiences within their industries or are looking to learn from those companies that are considered role models for success in the digital world. Although it’s good to consider what other organi- zations have done, a meaningful strategy will be unique to each organization. A sound strategy depends on your organization’s unique assets (such as brand, people, intellectual property, equipment, cash, technology), its constraints (such as resources, labor contracts, regulatory environments), and its environment (such as competitors, market positioning, price pressure). That’s why I often remind my customers of the following: The goal of your transformation isn’t to copy someone else’s success. It’s to maximize the return you achieve from your assets. Formulating a Strategy 32 Organizations are hardly carbon copies of one another, so their strategies also shouldn’t be. A strategy should amplify your organization’s success as opposed to becoming like XYZ Silicon Valley company. Or, as my colleague (and serious foodie) Mark Schwartz pointedly stated, “Becoming the Amazon of seared Foie Gras isn’t a meaningful strategy”. IT and Business Strategy Form a Two‐Way Street In traditional organizations, the technology strategy derives from a business strategy because the role of technology is to support the business. Successively zooming into more detailed strategies sounds like a rational approach: A customer once shared that to define their cloud strategy they are waiting for their business strategy to be in place, which will allow them to define an IT strategy, which will include an architecture strategy, that will be vital input into the cloud strategy. This one-way dependency is no longer applicable. For one, the traditional sequential approach blatantly ignores the cost of delay: the world isn’t standing still while you are waiting for these documents to materialize. Divisions will forge ahead and trade a well-thought-out but slow strategy for fast but uncoordinated activity. More important, though, technology now also drives business strategy. Tran- sitioning from selling physical assets to providing a service is a major shift in business strategy. The power of such a shift is highlighted by cloud computing, which sells compute hours as opposed to shipping physical servers. But such business strategies are only viable thanks to advances in modern technology. A manufacturer of large power generators might transition from selling pieces of equipment to pricing by the MWh produced. Like- wise, a train engine manufacturer could sell a transportation service, priced by person-kilometer traveled. Both shifts in business strategy are enabled by a technology strategy. Service models place additional demands on a business: a broken locomotive can’t generate any person-kilometers and hence no revenue—maintenance is Formulating a Strategy 33 now the responsibility of the provider. Keeping outages to a minimum requires modern technology, especially if you aim for zero outages thanks to predictive maintenance. Sensors, Internet of Things (IoT), edge computing, analytics, and machine learning are some of the technologies that enable predictive mainte- nance, capacity management, or dynamic pricing. Without them, a service- based business strategy isn’t viable. Likewise, selling compute capacity as a service, as modern serverless cloud offerings do, requires sophisticated technol- ogy to manage security, isolation, load optimization, failovers, and much more. The following simple test helps reveal the two-way relationship between busi- ness model and technology: If this is such a great idea, why didn’t everyone do it 30 years ago? In the majority of cases the answer is clear: we didn’t have the technical capabilities, or at least not at the needed price point. In some cases, we did do it 30 years ago and just forgot how poorly it went. Think in the First Derivative Platforms enable, for example, base platforms and in-house developer platforms enable faster software delivery, whereas marketplaces enable the exchange of goods. Rolling out a platform is therefore not driven by the wish to achieve a predefined, static target state. Rather, it is to allow the organization to grow or to change more quickly. Platforms define the rate of change, not a target state A platform strategy, therefore, should think in the first derivative, in the rate of change, as opposed to a static target state. As elaborated in Cloud Strategy, this aspect makes building a platform different from a traditional IT project, which Formulating a Strategy 34 assumes that a well-defined target state is reached by the end of the project. Platforms, in contrast, keep on evolving. And because they help platform users evolve faster, one can understand platforms only with a dynamic view. Documenting a Strategy A successful strategy consists of two accomplishments: capturing key decisions and documenting them well. Much of this book is about the former, but a few pieces of advice for the latter are valuable, as we’ll see in the subsections that follow. Aim for Emphasis Over Completeness A like-titled chapter from The Software Architect Elevator reminds us that complex topics require abstraction, omitting details to amplify the important aspects. Naturally, this hints at an important skill: Defining what’s most relevant is a critical step toward devising a strategy. You will see the forest only if you don’t concern yourself with every single tree. “What is not included” can be the most important chapter near the beginning of a strategy document. Also, remember that you are writing for human readers, not a large language model. Humans tend not to read dictionaries from cover to cover, but too many strategy documents look like one. Including a seemingly endless and arbitrarily arranged list of strategic elements, each described in excruciating detail but in complete isolation, will make your strategy look more like a legal text and vastly reduce its audience. Use Conceptual Models The picture that first enters many people’s minds when thinking of strategy is a 2x2 matrix (you can see a few throughout this book). A staple of management consulting slide decks, for example as a SWOT matrix, they also have a promi- nent appearance in Eben Hewitt’s useful book Technology Strategy Patterns.1 1 Hewitt:Technology Strategy Patterns: Architecture as Strategy. O’Reilly Media; 2018. Formulating a Strategy 35 The central picture from the defining book on enterprise architecture, Enterprise Architecture as Strategy,2 is a 2x2 matrix that correlates the IT operating model with business process standardization and integration. The enormous resources that IT vendors invest into earning a spot in industry analysts’ “magic quadrant” (a 2x2 matrix across complete- ness of vision and ability to execute) indicate how many IT decisions are based on 2x2 matrices. A 2x2 matrix is a very popular and extremely effective example of a conceptual model, which Wikipedia defines as follows: Conceptual Model: A representation of a system, made of the composition of concepts which are used to help people know, understand, or simulate a subject. Quite a mouthful, but indeed helping people know and understand is something a strategy must do. To do so, complexity—the greatest enemy of that objective— has to be tackled with models that clearly communicate concepts without losing essential information. The simpler the model, the better job it does reducing complexity. The Yardstick. At the Singapore government we developed several simple models to help us make more informed platform decisions. A particularly effective one was “the yardstick” that visualized which part of a problem has already been solved, what needs to be built as a common platform, and what’s left to individual teams. Despite, or perhaps because of, being about the simplest model you can imagine, it proved immensely useful in our IT decision boards. Wardley Maps are a powerful model that depicts the evolution of commodity and bespoke elements. 2 Ross, Weill: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press; 2006. Formulating a Strategy 36 Show the Path and the Terrain A good strategy covers three dimensions, perhaps in the figurative, not the purely mathematical sense (see Thinking Strategy? Add Dimensions!): 1) A point: Where do you want to go? 2) A path: How will you get there? 3) The Terrain: What happens when you step off that path (or the ground shifts underneath you)? Some strategies stop at the first item and aren’t strategies at all—those are the mere wishes cited earlier. Actual strategies must lay out a path that will take the organization from here to there. Two common mistakes plague such strategies. First, the path might not connect to the organization’s status quo. This typically happens when a strategy is adopted from another organization or a success story that worked off different preconditions. Needless to say, a path starting from somewhere else isn’t a very useful option. The second pitfall is a path that considers only the happy-day scenario. Assum- ing an ideal and predictable world won’t last very long in the face of today’s uncertain reality. Events of 2020 have made it clear that the environment in which your strategy operates can shift suddenly and more vehemently than often assumed. The shape of the terrain represents your strategy’s risk profile; in other words, how resilient it is to unforeseen changes. Are you walking on a narrow ridge or gentle slopes? A narrow ridge might be the shortest path, but it doesn’t tolerate any missteps or shifting terrain. Without considering the terrain, the shortest but riskiest path will always seem attractive—until you actually get there and see you’re heading for Angel’s Landing. Credible Roadmaps Strategies should be concrete and actionable, but that doesn’t mean that they can define a simple linear path—that’s simply not what the world looks like. Formulating a Strategy 37 Pretending a linear sequence of predictable steps is the classic fallacy of a misleading roadmap, as is nicely illustrated in the following diagram:3 Misleading roadmaps versus strategic roadmaps (© Pavel Samsonov) Misleading roadmaps look convincing on paper but rarely last past the first stages of execution. I have seen enough of these strategies that I tend to describe the inevitable failure as follows: When reality doesn’t match the plan, we blame reality. Seeing the future as uncertain forms an honest roadmap and is a big step ahead. But giving in to uncertainty doesn’t make for a very meaningful strategy and runs the risk of “we’ll figure it out as we go along.” A strategic roadmap therefore anticipates decision points, possible paths to be taken, and the data needed to make those decisions. The diagram we just looked at was originally aimed at product roadmaps, but as we will soon see, platform evolution shares a lot in common with product evolution. From Strategy to Execution Now that you are intellectually pumped up about strategy, you need to translate the learnings into an actionable execution plan. Too many strategies jump straight from lofty goals into technology buzzwords—this is where the concept 3 Used with permission. Source: https://twitter.com/PavelASamsonov/status/1296818042928861184 Formulating a Strategy 38 of the Architect Elevator can help bridge the gap and connect the dots, depend- ing on which metaphor you prefer. Technical staff will nonchalantly rattle off platform benefits like au- tomation, open APIs, reduced cognitive load, cohesion, undifferen- tiated heavy lifting, decoupling, abstraction, autonomy, knowledge sharing, and innovation. Structuring this laundry list into a logical sequence of goals and mechanisms makes the difference between wishful thinking and a strategy. A common antipattern for strategy documents is the dangerous “IT Hourglass” described in Cloud Strategy: they start wide with exciting claims like “faster innovation at lower cost”, then become very thin in the middle, and conclude with wide-ranging funding and headcount requests, following the shape of an hourglass. Although strategy is never a paint-by-numbers exercise, structuring your strat- egy document into four distinct but connected layers can help you steer clear of the IT Hourglass: Context describes why you are following a platform strategy in the first place. This part assures the aforementioned alignment with the business strategy. If this part isn’t clear, executives will stop reading right there. Objectives are business benefits that your strategy is intended to deliver. Reducing costs or speeding up innovation are worthwhile business goals. This section should place a clear emphasis on the top objectives instead of listing all possible benefits—too many items will weaken your strategy. Mechanisms are well-known techniques that help deliver your objectives. Increasing code reuse or enabling team autonomy are suitable mechanisms. The strategy needs to explain how these mechanisms support your objectives. Poor strategies look like an hourglass by falling for buzzwords like DevOps or microservices instead of elaborating. Design decisions denote specific trade-offs that you need to make during implementa- tion. For example, you might mandate that all developers use the same Formulating a Strategy 39 programming language to make it easier to reuse other teams’ code. Alternatively, you might look to achieve the same by wrapping all code assets behind standardized service APIs—more complexity but also more choice. A good strategy describes these more “technical” considerations such that they can be followed by all stakeholders. The following table summarizes these four levels of a strategy with examples from typical platform strategies: Level Description Key Activity Example Context Why you are Link to business Increasing creating a strategy competition Objective What you want to Prioritization Speed up delivery achieve Mechanism Common ways to Translate objectives Increase code reuse get there Design decision Trade-offs you are Explain well Standard APIs making Although this recipe sounds simple enough, numerous strategies fall into the “hourglass” trap: Poorly defined strategies tend to go heavy on the objectives (that’s how you get funding), trade mechanisms for buzzwords, and pro- pose design decisions without a clear linkage to the other two. The Architect Elevator can be a useful antidote by ensuring a solid connection across the layers. As so often is the case, the connection is as (or more) important than the boxes (layers). Strategy Is a Winding Road A strategy defines an overall direction, not the exact steps that you will be walking. This means that tactically you might be doing something that looks Formulating a Strategy 40 like it doesn’t line up with your strategy. As long as it is done deliberately and achieves the overall strategic objective in the long term, that’s alright and unavoidable. A strategy doesn’t imply climbing the hill in a straight line When you’re walking up a hill, few people go straight up. While you are traversing, a person lacking context may challenge why you’re moving sideways instead of toward the peak. A proper linkage between tactics and strategy reveals that hikers climb the hill very well by using switchbacks. Even though they traverse the mountain, they understand and follow the strategy. 4. Becoming a Platform Company Transformation can’t be understood from the end product. It’s time to build on a more stable foundation Platform plays are frequently considered in the context of an IT transformation, and for good reasons. For one, to fully benefit from modern base platforms, such as cloud platforms, an organization has to fundamentally change—or transform—the way it is working. Otherwise, you get the same old problems just in more modern packaging. Second, platforms help businesses overcome past constraints and effectively compete with digital disruptors, something that they would not be able to achieve otherwise. More Than Meets the Eye In presentations about enterprise transformation, I cite the example of the dis- ruption of the US automotive industry by Japanese automakers in the 1970s. The “big three” automakers—Ford, Chrysler, and GM—enjoyed a fruitful oligopoly until their Asian counterparts introduced cars into the market that were of Becoming a Platform Company 42 higher build quality, more reliable, better equipped, less expensive, more fuel efficient, and by many accounts visually more appealing. When someone’s product beats yours in all categories, it’s called a disruption—derived from Latin disrumpere, which means as much as breaking apart. You can’t see the transformation from the end product The natural reaction of the incumbent automakers might be to purchase one of the clearly superior cars, learn why it is so much better, and build comparable car.1 Sadly, they would not find much. That’s because the essence of this transformation took place in the product philosophy, which changed the way of working, far before the finished product. The essence of the transformation cannot be seen from the outside. US manufacturers subjected each car to “quality assurance” at the end of production. This phase was essentially a euphemism for rework. Japanese manufacturers, led by Toyota, followed a very different philosophy: they re- alized that quality must be built-in, not added on at the end. It makes little sense to replicate a systemic defect 50,000 times over on the production line. They therefore did what would have been unimaginable in US plants: when they encountered a problem, they would stop the production line (using the famous “andon cord”) to investigate, so that they could correct it once and for all. Quality was built in, not added on. This fundamental shift cannot be seen nor understood by looking at the finished product. 1 A similar approach took place when European car manufacturers first encountered the Tesla. Becoming a Platform Company 43 Don’t Burst the Boiler Companies that try to replicate other companies’ success without seeing how those companies in a fundamentally different manner are subject to the “burst- ing the boiler” effect, which plays off another disruption in the transportation sector that took place half a century earlier: the transition from the steam locomotive to the electric train engine: If you’re running a steam engine and an electric train easily passes you, you’ll want to speed up to remain competitive. So, you do what has worked before: you put more coals on the fire and increase the boiler pressure. This might initially speed you up, but it won’t lead to a transformation—it will lead to a burst boiler. Increasing the pressure is an attempt to optimize the way you are currently working. But one cannot optimize their way out of a disruption: Disruption means that someone has changed the rules of the game. Those who play by the old rules have already lost. To transform you must think and work differently. Platforms are like electric train engines—they change the rules of the game by removing past constraints. And you can’t see that just by looking at the end product. Classic IT Conflicts Modern CIOs are known to be living between a rock and a hard place. Upper management routinely demands more efficient IT operations based on harmo- nization and complexity reduction. Meanwhile, in uncertain times only agile organizations that innovate through experiments can be successful. This way of working requires modern tools that create more diversity and thus work against harmonization. Similarly, the business demands faster feature delivery to better compete in a fast-changing world while regulatory environments prescribe ever-increasing levels of transparency and compliance, which threaten to slow down delivery. Becoming a Platform Company 44 Rarely has this tension been more pronounced than during the pandemic of 2020/21 during which many IT budgets were being frozen or actively cut at just the time when organizations were forced to pivot from physical to e-commerce distribution. Naturally, such a shift has a major impact on IT requirements, scale, and operational needs. Lasting change isn’t something that you can buy. It derives from a new mental model or a different worldview. There’s no shortage of vendors or consultants peddling tools or giving advice on how to overcome these IT pain points. A battle-weary CIO can choose from a wide menu of Agile frameworks and certifications, DevOps approaches, Lean methods, low-code or no-code frameworks, VM-to-container conversion tools, and out-of-the-box machine learning frameworks. But lasting change is rarely something that you can buy. Opposites Attract The previous example is typical for a mental model that considers innovation and harmonization to be opposite ends on a one-dimensional spectrum: har- monization stifles innovation and rapid innovation drives entropy and chaos. Sadly, organizations using this mental model can’t find a happy place: either they reduce diversity and complexity but become too rigid to innovate, or they are innovative but have a giant operational mess on their hands. The transformation happens when the worldview changes to a two-dimensional model (yes, we will encounter numerous 2x2 matrices in this book!). In such a model, harmonization and innovation aren’t diametrically opposed but are two dimensions on a single plane. The old way of thinking would be represented by a straight line. The diagram illustrates that no matter where on the line you are, you are in the unhappy zone. Becoming a Platform Company 45 Thinking in more dimensions Now you can think about the problem differently. The line doesn’t have to be straight; it can be a curve. Can you shift the curve to drive more innovation without giving up harmonization? Higher levels of automation or new cost allocation models that better support small experiments could achieve such a shift. More dimensions widen the solution space Importantly, you can now discuss not just the position of the curve but also its shape: can you invert the curve, so that higher degrees of harmonization actually increase innovation, just like the automakers did? In software architec- ture, common API standards harmonize communication but boost reuse across diverse programming languages. Likewise, common software platforms boost innovation. Becoming a Platform Company 46 Two-dimensional thinking reveals the power of platforms. Removing constraints is a key innovation driver. In my transformation work- shops, participants brainstormed properties that used to be opposites but have turned into two independent dimensions. The list of items that are no longer opposites is quite impressive, even though it is far from complete: Characteristic Perceived Enabling Mechanism Opposite Standards Innovation Platforms, interface standards Speed Quality Automation Cost Agility Modularity, iterations Economies of scale Economies of speed Cloud platforms Openness Monetization Professional open source Low risk Change Automated tests, Continuous Delivery Control Chaos Transparency, automated governance Short-term gain Long-term gain Adaptability, low friction The list also includes the primary mechanism that allows these items to no longer be opposites. For example, automated testing and deployment allow us to deliver at higher speed and quality. Likewise, professional open source has shown that open sharing of your product can still leave room for a public offering. Transforming by Seeing More Dimensions Some of these old, one-dimensional mental models have been around long enough that they’re codified in popular slogans. For example, speed and quality have been seen as at odds with each other for long enough that doing things “quick and dirty” has become a de facto law in IT management. People will Becoming a Platform Company 47 routinely debate if they should cut corners (be “dirty”) to speed things up. I tend to challenge this assumption as follows: If I were a subversive developer who’d want to sabotage a software project, injecting a few very nasty and difficult-to-find bugs into the system would all but guarantee a major delay. The notion that compromising quality somehow speeds things needs a major overhaul. If you think like the US automakers in the 1970s and see quality as an extra phase that you can cut, perhaps this might seem logical to you. But we learned how that way of thinking led them into a major disruption. Why c