Updated: Updated: Strategy
A Platform for Delivering Delivery Platforms
I came to think about writing a book on platforms over 3 years ago. Git tells me that I committed the book skeleton in June 2020, and the first chapter in that skeleton was based on a blog post from 2019 when I was still writing Cloud Strategy. I had a feeling that procrastination would pay off later.
The trigger for my interest in platforms was my work as a Smart Nation Fellow at the Singapore Government where I worked closely with the team building the SHIP-HATS Engineering Productivity Platform, which folks might now call Software Delivery Platform or IDP, Internal Developer Platform. Whichever acronym we chose, it’s the thing that makes developers’ lives easier and has the word “platform” in it because it sounds neat. Building such a platform involved many decisions and trade-offs, both for the platform design (can it be a fruit basket or should it be a fruit salad?) and the team’s roll-out strategy. My job involved crystallizing the trade-offs and helping the team make disciplined decisions. Great stuff for an architect (or fellow)!
This wasn’t my first time dipping my toe into platforms, though. Back around 2015 my team (including the contributors to this book) built an Agile Delivery Platform for a large financial services organization. My efforts (and struggles) to transform a large IT delivery organization at that time formed the basis for the book 37 Things, but I didn’t speak or write much externally about our internal product.
An IT Strategy Bookshelf
With that experience under my belt and a head full of stuff, I jotted down some ideas, and in December 2020, with Cloud Strategy just having launched as a printed edition, I proudly proclaimed to be writing a series of books for serious architects, worded in an Amazon Press-Release style no less (the Kool-Aid works).
My ambition was to create a set of books that every serious large-scale architect would want to own (and hopefully read). My mental picture was that of The Art of Computer Programming, but I wouldn’t say it out loud because Don Knuth is a million times smarter than I. But, hey, I was told to think big (more Kool-Aid), so at least I try.
Sadly, with a demanding new job and a pandemic, which wasn’t good for writing despite being locked up at home for much of the time, the work stalled. Commits became much more sparse after Summer 2021 and took an 18-month hiatus from January 2022 until mid-2023. As you can tell from my blog, I dove into the depth of serverless integration and cloud automation during that time, so it was well spent.
Plentiful Platforms
Luckily, not all things in IT move quite as fast as we like to believe, so platforms are still the talk of the town, or perhaps even more so. Dave Farley recently proclaimed that he’s not a fan while PlatformCon was drumming up excitement and enjoyed strong participation. Scoring the most-viewed video in that series convinced me that developers and architects do want to hear about floating and sinking platforms and gave me the courage to push the book forward.
A major challenge rested in the fact that platforms are far from a linear subject, but a book has to be. I wanted to give a broader treatment of platforms to set the context but without duplicating the work of prior books that focused entirely on platforms and multi-sided markets as a business model (and share the title). So, I had to find a way to balance speaking about marketplaces, data platforms, and cloud platforms, and developer platforms without excessive forward references.
Piling Left: Platforms to the Rescue?
Part of platform’s recent popularity is due to the fact that modern application delivery approaches “shift left” many steps of the software delivery lifecycle. This makes sense because it shortens feedback cycles and avoids finger-pointing between teams. But it also means that development teams now not only do design and coding, but also distributed systems architecture, operations, and security design, causing a giant mental pile-up among those teams.
For this to work, modern teams would either have to be much smarter than before, or they would have to rely on better tooling, like–drum roll–Engineering Productivity Platforms that reduce the cognitive load for the teams. In my view the latter can work, but building such platforms isn’t easy, and not nearly everything labeled as platform would pass as one.
Catchy Metaphors and Nuanced Advice
Enter Platform Strategy: In true Architect Elevator spirit I attempted to get to the root of the topic, e.g. by teasing apart when something can actually be called a platform, by explaining why good abstractions are so elusive and we often end up creating illusions, and by resolving the mystery of sinking and floating platforms.
The book is released but not finished. The content is about 70% complete, but lacks editing polish, consistent diagrams, and the occasional refactoring. Good software relies on early releases and feedback, and books are no different. So, I will follow the proven progression from a Leanpub ebook that’s easily updated, to a Kindle Direct release for print and eBook, perhaps early next year.
And with a little luck, folks will get used to the fact that fish and sea creatures on a book cover are a clear indicator of serious content for architects, packaged into lively anecdotes. Make sure you get the full collection of Koi carps swimming upstream (for completeness’ sake only, 37 Things evolved into The Software Architect Elevator), fish swarming to look like a bigger fish (or a cloud), and jellyfish resembling a distributed, autonomous system!
Make More Impact as an Architect
My book The Software Architect Elevator helps architects and IT professionals play at the intersection of technology, organization, and transformation by sharing the real-life journey of a chief architect. Buy it on Amazon US, Amazon UK, Amazon Europe
