Platform Strategy Part 1a: Capability Architectures —back(end) pains

This story is the first in what I think will be a 3 part series on how one can shape their platform strategy. But first a couple of acknowledgements and disclaimers.

I am sharing about this because it’s a subject I get asked about a-lot so I am attempting to put my thoughts and experience down for wider sharing.

I can almost say with certainty that in this like in all my writing, there is little to no originality. I am only sharing what I have learned from the community around me. I have relied heavily on Domain Driven Design and my experience working within the Digital Platform Strategy teams at ThoughtWorks. I would be remiss if I did not call out Ryan Murray, his inspiration and guidance have been foundational to my own views on Platform Strategy.

Lastly, Strategy Without Execution Is only Hallucination; if you are serious about executing on your platform vision then you’ll need more than the knowledge of what I share here. You’ll need hands-on help from people with the right skills and experience. I have worked and still work with such people and can introduce you to them. Contact me.

Let’s talk about the problem

The problem digital platforms seek to address has been stated in several ways but it all comes down to the friction standing in your way of achieving speed and scale for business or team or organization. There’s a short “comedy” sketch on Microservices helps drive the point home because to most of us .. it’s not really a comedy sketch, it our reality.

Microservices sketch by Youtuber Krazam

You can pause here and take a moment to write down what you observe as the problems. But I’ll focus on what the developer rightly calls out as the main issue only 10s into the video.

“It’s the design of our backend”

In the fall of 2015, I joined an client in the air-travel business. This was really the beginning of my journey building digital platforms. The client was experiencing the customer “demands” from the fallout of the smart phone revolution that was hitting the whole industry. So they had set out to expand their booking, check-in and flight change experiences beyond the desktop website and into mobile channels.

The backend seemed much simpler to design when their customers only needed to be served via a desktop website. Now their customers expected to be able to on smart phones, those same things they did on deskstop. The team I joined was attempting to set up the first mobile channel on iOS and was expected to expand into more teams for Android and mobile Web channels. We were experiencing growing pains that I later learned were rooted in 3 major areas;

• No coherent strategy for delivering their current business capabilities to customers across multiple channels
• A lot of communication overhead required to understand which teams to engage with to deliver a new capability to customer
• Key business capabilities are duplicated across several services and applications making it difficult to maintain, evolve and reuse them

There had been a lot of effort invested in designing the right level of service abstractions for the backend but these abstractions still lead to frustrating conversations like the one in the sketch. This is because the design of these abstractions were disconnected from the business (and customers) they intended to serve. Services like Bingo, Papaya and Racoon are good examples of this problem from the sketch above.

Business Truthful Abstractions

Photo by Jr Korpa on Unsplash

Two years later, I got introduced to Domain Driven Design(DDD) and learned of an approach based on DDD that could help guide one’s thinking around defining boundaries within a growing complex software-business ecosystem. This was not the approach I used at that airline client but has been the the one I have applied on several engagements there after to define and evolve a platform strategy for my clients.

I first heard the term business truthful abstractions used by Ryan Murray. And I think it brings us to the heart of the matter. How can one draw software boundaries in their “system” that are set them up well to support the business as it evolves and scales. This is the concept of a digital platform in a nutshell. It’s a set of abstractions exposing business capabilities via APIs and allows for composition of those capabilities to deliver new experiences for constantly changing customer needs and wants.

• Designing, naming and evolving these abstractions based on business needs is your secret source to making it simpler for a growing organization to communicate about them.
• Making them self-service APIs will reduce the friction between teams required to compose new experiences.
• Designing them to be independently deploy-able and releasable as products in their own right allows the teams that own them to deliver them faster and reliably.

The process of defining these capabilities is both intuition (from people with a deep understanding of the business domain) and science (from experience of those who have delivered software at scale) but the goal is the achieve the cohesion, self-service and compos-ability needed to service one’s customers.

Next Steps

This site is not a blog, it’s a digital garden so it’s likely this post and others that will follow will receive significant updates as incorporate feedback I get and as my understanding of what I am looking to share here improves. However, here’s my current thinking of where I will go from here.

Part 1b: Capability Architectures: Defining Capability boundaries
Part 2: Product Thinking: Applying product management practices to deliver, scale and evolve platform capabilities

Part 3: Operating Model: Implications on team and organizational structure and collaboration patterns.

If you enjoyed reading this, please share it. I appreciate the feedback and encouragement.