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. Their primary goal was to accelerate software delivery without compromising quality, security, or compliance—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 proved 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.

As time passed, Internal Developer Platform and Platform Engineering became household terms. I also helped the Singapore Government’s GovTech division make software delivery more efficient across government agencies. The result convinced us that we were actually building something that should be called “platform”, but it also raised a slew of new questions and open design decisions, multiplied by the fact that we were building on top of commercial cloud platforms. What functions should be part of our platform versus the cloud platform? What if the cloud launches a feature that supersedes ours? Who should own the services that our platform provisions in the cloud? Should our platform handle billing?

Eager to get to the root of it all, I joined a major cloud provider where I spent several years helping customers get the most out of that platform. One might expect that powerful cloud services would have made building in-house IT platforms superfluous, but I observed exactly the opposite: virtually all large customers were building or deploying an 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.

Still looking for answers, I took the Architect Elevator far down into the engine room. Developing serverless cloud products, which are widely considered the canonical example of a modern compute platform, got me deep into the mechanics of platform decisions: what technical details can be safely hidden from the user, and which ones should be exposed? How can services be used independently while also being constituent parts of something that’s bigger than just the sum of its parts? What 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 know more about your specific undertaking than I ever could, 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 of platforms, you will find a smooth on-ramp, whereas if you’re experienced, the book aims to broaden your current thinking with novel viewpoints.

Over the past decade, platforms have fueled some of the most successful business models. Although platforms come in various shapes, they share an “amplifier effect” that makes them enormously successful but deceivingly difficult to replicate.

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 platforms 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.

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 understanding 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.

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.

This book condenses years of experience building and using platforms into a mental framework for platform development. Covering technical, organizational, and financial aspects, it is structured along the journey that an organization might take toward becoming a platform company.

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.

Building platforms requires a sizable investment and a clear strategy. That strategy must turn the objectives into an actionable path defined by meaningful decisions.

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.

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.

Diving deeper into the engine room, this part investigates platform anatomies and proposes common platform blueprints.

Platforms have to be rolled out across the organization. They also require delicate 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.

If you are building platforms, you’ll likely need a platform team, which is different from typical application delivery or operation teams. This part describes how to build and manage a platform team.

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:

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:

Asking the right questions is a necessary first step for any successful strategy. I hope you enjoy the read and appreciate having more questions!

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.

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.

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.

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

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.