Platform Strategy: Part 1b: Capability Architectures — Defining the Boundaries
This is the second in a series of posts on Platform Strategy, check out the first one here and the third is here
The previous post focused on the problem a platform strategy sets out to address and benefit of defining business truthful software boundaries for your platform.
In this post, I share two broad categories of platform capabilities and share some approaches for defining those boundaries and examples.
Business Capabilities
There’s usually two places where one can “start” shaping the platform strategy. Solving a new business problem or decomposing an exiting monolith. Decomposing an existing a monolith is actually in a good place to start. This is because it’s likely the team understands the business domain well from the effort spent building and maintaining the monolith. The team may have some good hypothesis on where the right boundaries lie.
On the other hand, defining capabilities for a new business problem means you don’t have the technical debt baggage that comes with an existing monolith but with this case like with the monolith, we must acknowledge that our software (services) we are building is largely based off assumptions and abstractions. The benefit of these abstractions to our customers and their compos-ability is increased when they are modeled from the business perspective.
Customer Journey Mapping
My favorite approach for defining business capabilities is to start from what I refer to as “real things”. These take on the form of age old Customer/User journeys. I consider them real because we know these journeys represent real-world events. A customer journey outline the steps a customer takes to achieve a purpose they consider valuable and are willing to pay for. This is why we can confidently ground our domain modelling conversations in such artifacts. Everything else eg services, modules, components, deployments even teams are an abstraction that we create and need to conform to the real things in some way and are ultimately only relevant if they help us delivery software that supports those customer journeys.
I conduct my user journey mapping exercises between 2 or 3 participants (you start to see diminishing returns with more participants), all you need is someone who is familiar with a business problem (customer or a business SME) and someone from the product team (like a software engineer).
Once you have mapped out most of your key customer journeys; the business capabilities required to make those customer journeys possible begin to emerge. The next step I take is to attempt to create a business capability out of every step in a customer journey. After the first few journeys, you’ll begin to see repetition in the capabilities and for me, that’s a good indicator that you capabilities can be reusuable across at least 2 customer experiences. Here’s a snapshot of what I came up with for that airline client.
Verbs not Nouns
The video from the first post illustrates the mayhem that results from abstract names for your business capabilities but the question remains, what could be a better way to name these services? The approach I have found effective is to ask yourself what the capability does and intuitively call it just that. This will feel strange at first if you are new to this but I have found that getting the naming right pays dividends in simplifying communication within and across teams working on these capabilities and the customers using them.
An anti-pattern I run into is going for nouns like passenger-service or flight-service. I suspect this is a relic from object-oriented design methods. Shout-out to another former colleague John Feminella who has so eloquently called out an even more harmful anti-pattern with naming capabilities/services here. Please check out that short thread.
Verbs like booking-service are much better because they begin to describe exactly what the capability does. A teammate of mine extended this principal to object-verb naming instead of verb which is fine too. Names like flight-booking, car-reserving are even more descriptive.
Event Storming
I have been told of another approach; Event Storming that can be helpful to identify these capabilities. I have not used this approach before but it looks to me like a very expensive process as it requires a large number of participants and a great deal of facilitation both of which are in short supply in my experience. If you’re able to find the required people and a strong facilitator, I think it can also lead you to a good result.
Technology Capabilities
When one considers a platform capability like booking (the ability to reserve a seat on a specific route on a specific date), it’s easy to imagine this as simple the software application that orchestrates the ticket booking process for a customer. But when that software application is not running as expected and the team urgently needs to fix it, you quickly appreciate how much the infrastructure for deploying changes for that application is very much a part of your product. How your ability to monitor and alert the right team members when the application is not functioning as expected is a critical part of your value proposition.
It’s these parts of any software product offering that don’t represent something specific to the business domain (air-travel) but are needed for a team to deliver a software product efficiently that I categorize as technology capabilities. I have heard these capabilities also called delivery infrastructure/ecosystem or internal developer platforms.
Making a distinction between the capabilities (like app deployment) and the tools (like jenkins) that provide those capabilities helps a team understand what it is they need from each tool. I have shared more about this distinction in a previous post. Similarly to business capabilities, I define a value proposition for each capability to drive it’s roadmap. Such capabilities are usually not business differentiators so I’d default to the less costly option of buying them (with a little customization) rather than custom building them. Public cloud providers are a good place to start shopping for these capabilities.
As with business capabilities, customer journeys are still the best approach I have found for identifying technology capabilities, the members of the product teams in your organization are your customers. I have found mapping out what they need to deliver software effectively simpler than journeys for external customers because of their proximity to me as internal customers. I personally enjoy these conversations more as they are usually no “middle-people” involved like with business capabilities, just direct real-time observations and conversations with real users of the capabilities I am building.
I have iterated on this map for technology capabilities several times over the years, it can be a good blueprint for an organization to begin shaping their technology or developer platform.
Next Steps
I mentioned in my first post that strategy without execution is only hallucination (citation needed) so we need to talk about how to bring this platform strategy to life. Organizing teams to execute effectively on these platform capabilities calls for a culture shift to applying a product mindset to how one delivers and evolves these capabilities.
I share my learnings on that and the benefits I have seen in Part 2: Product Thinking.
If you enjoyed reading this, please share it. I appreciate the feedback and encouragement.
