Finding good stream boundaries with Independent Service Heuristics
By Rich Allen and Matthew Skelton
When designing organisations for a fast flow of change, we need to find effective boundaries between different streams of change in order to ensure that we create good team boundaries. This can be achieved by identifying potential boundaries across services, domains, applications or streams. This article looks at how you can do this using a technique called Independent Service Heuristics (ISH).
Watch Matthew Skelton and Nick Tune discuss the Independent Service Heuristics at DDD EU 2022.
Identifying boundaries with Domain Driven Design
When we first think of the terms “domain” or “boundary” in a software context it is likely that our first thoughts may be of Domain Driven Design (DDD). The book by Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software” published in 2003, has stood the test of time and provides significant insights into how to structure software that can be aligned with existing business domains. The high-level definition of the practice is “an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of core business concepts”. With the introduction of terms like “bounded contexts” and “ubiquitous language” it provides a vast library of practices and techniques to help the practitioner tame the complexities of modern software development. Since the original publication, there have been numerous others that have attempted to simplify and make the concepts more digestible, for example, titles like “Domain-Driven Design Distilled” by Vaughn Vernon and “The Anatomy of Domain-Driven Design” by Scott Millet and Sam Knight.
There have also been many contributions from the wider DDD community including new techniques such as Event Storming. The DDD Crew have a great set of resources available which includes a DDD Starter Modelling Process, Core Domain Chart examples, Context Map Cheat Sheets, Event Storming Glossary Cheat Sheet, Bounded Context Canvas and many more. The value and benefits provided by a DDD approach are clear and taking the time to learn each of the techniques will be a sound long-term investment. However, many people struggle to get started adopting the practices as they can often be seen as overwhelming.
Taking a different approach: Independent Service Heuristics
Independent Service Heuristics (ISH) is a technique invented by the authors of Team Topologies, Matthew Skelton and Manuel Pais, and subsequently refined by others including Team Topologies Valued Practitioners (TTVPs) and members of the wider DDD community. You can find more information via the Independent Service Heuristics GitHub Repository which is openly provided via the CC BY-SA license.
ISH is an intermediate approach that can help to introduce the principles of DDD without some of the abstract terminology that can often be a barrier to the adoption of DDD.
ISH are simple rules-of-thumb or clues that can be used to identify candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. It is intended to stimulate conversation and provide a frame of thinking about basic domain concepts and does not attempt to be a perfect “catch-all” tool. After using ISH to identify potential domain boundaries or value streams it often makes sense to then delve deeper into the problem space using other DDD techniques if required.
Exploring boundaries using Independent Service Heuristics
Independent Service Heuristics (ISH) starts with a simple question, “Could this thing be run as a cloud-hosted (SaaS) service or product?”. On the surface, this almost seems too simple. How can that one question start to provide answers that help us to uncover potential domain boundaries and value streams? The terms Cloud and Software as a Service (SaaS) have been in the public domain for long enough that most people will understand what we mean when we ask the question and the answer to the question is often either yes, no or maybe. We can then follow up with a series of clarifying questions to determine whether the area under focus could truly be a potential domain boundary.
Choosing an area of focus
In any process or methodology, getting started and taking the first step is normally the hardest part and in the case of ISH, that first step is deciding where to focus your attention. Essentially we just need to choose an area of the business that needs to be represented in software. This could be a user journey, a “product”, a possible business domain, a software service, an entire software application, a set of tasks for a single user persona, a possible value stream, etc.
The important thing here is that we actively choose an area and get started. The process is quick enough that we won’t waste too much time if we happen to choose an area that does not naturally fit a domain boundary but at least we can discount it and move on to the next candidate.
An Independent Service Heuristics example
Imagine a fictional company called Footprints Tours which offers ‘alternative’ walking tours of cities exploring their social and cultural history. They provide both guided and self-guided tours and have implemented a monolith website and mobile application to serve all of their customer needs. The flow of development has slowed down significantly as the code base has grown over time. Using Independent Service Heuristics they are looking to understand how they might re-organize the teams, and therefore the applications/services, to improve flow and alignment with the needs of their customer. The first step would be to capture some possible fracture planes such as those shown in the image below.
An example of potential fracture planes for Footprints taken from one of our Guided Discovery Workshops
Uncovering potential domain or service boundaries
Once a candidate domain, service, application or value stream has been identified, the next step is to go through a series of questions to identify whether we have found a good candidate for being a separate stream of change. The high-level checklist of questions is as follows (as of January 2022):
1. Sense-check: Could it make any logical sense to offer this thing "as a service"?
Is this thing independent enough?
Would consumers understand or value it?
Would it simplify execution?
2. Brand: Could you imagine this thing branded as a public cloud service (like AvocadoOnline.com 🥑)?
Would it be a viable business (or "micro-business") or service?
Would it be a compelling offering?
Could a marketing campaign be convincing?
3. Revenue/Customers: Could this thing be managed as a viable cloud service in terms of revenue and customers?
Would it be a viable business (or "micro-business") or service?
What would a subscription payment include?
Is there a clearly defined customer base or segment?
4. Cost tracking: Could the organisation currently track costs and investment in this thing separately from similar things?
Are the full costs of running this thing transparent or possible to discover? Consider infrastructure costs, data storage costs, data transfer costs, licence costs, etc.
Is the thing too interconnected with other things in the organisation? Or fairly separate?
Does the organisation track this separately?
5. Data: Is it possible to clearly define the input data (from other sources) that this thing’s needs?
Is the thing dependent on lots of data from multiple sources? Or fairly independent?
Are the sources internal (under our control) or external?
Is the input data clean or messy?
Is the input data provided in a self-service way? Can the team consume the input data "as a service"?
6. User Personas: Could this thing have a small/well-defined set of user types or customers (user personas)?
Is the thing meeting specific user needs?
Do we know (or can we easily articulate) these user types and their needs?
7. Teams: Could a team or set of teams effectively build and operate a service based on this thing?
Would the cognitive load (breadth of topics/context switching) be bounded to help the team focus and succeed?
Would significant infrastructure or other platform abstractions be needed?
8. Dependencies: Would this team be able to act independently of other teams for the majority of the time to achieve their objectives?
Is this thing logically independent from other things?
Could the team "self-serve" dependencies in a non-blocking manner from a platform?
9. Impact/Value: Would the scope of this thing provide a team with an impactful and engaging challenge?
Is the scope big enough to provide an impact? Would the scope be engaging for talented people?
Is there sufficient value to customers and the organization that the value would be clearly recognized?
10. Product Decisions: Would the team working on this thing be able to "own" their own product roadmap and the product direction?
Does this thing provide discrete value in a well-defined sphere of execution?
Can the team define their own roadmap based on what they discover is best for the product and its users, or is the team always driven by the requirements and priorities of other teams?
Answer these questions for each of the candidate streams you have identified. The more 'yes' or 'maybe' answers a possible stream has, the greater the chance that you have found a good candidate for being a separate stream of change.
N.B. The questions on Dependencies, Impact/Value and Product Decisions were added to ISH in December 2021 as a result of working closely with the team at Zalora after some of our workshops. See below for more details of how Zalora used the ISH approach.
Sample ISH answers taken from one of our Guided Discovery Workshops.
The highly visual style of the ISH exploration grid helps to facilitate discussions among stakeholders from different parts of the organisation.
Delving Deeper with ISH
Answering these initial questions about the service should help to uncover potential candidates for separate streams of change, but it may be useful to further consider other aspects too, such as where the language used to describe services is the same or different, or where services are currently tightly-coupled.
Case Study - using the Independent Service Heuristics at Zalora
ZALORA is the leading fashion & lifestyle destination for South-east Asia, carrying an ever-expanding line-up of local and international brands. In 2021, as part of a drive to enhance customer experience and reduce time-to-market as the team scaled over 60%, Zalora began exploring the use of Team Topologies ideas and practices. During a multi-day workshop with a wide range of attendees (led by Team Topologies co-author Matthew Skelton), Zalora stakeholders were introduced to the Independent Service Heuristics. They learned how to use the ISH approach to find candidate flow-aligned boundaries and interpret the results, allowing the insights to guide and inform conversations with different parts of the business.
After the workshop, Zalora ran further internal sessions, expanding the use of ISH to find further possible flow-aligned boundaries. The straightforward language of ISH helped to facilitate conversations between many different parts of Zalora including: technology, product, warehouse, logistics, and business strategy. The Independent Service Heuristics acted as a frame or “lens” through which to talk about priorities, flow, and ownership. The very visual style of the ISH exploration grid provided a way to frame conversations:
Screenshot of the results of an expanded Independent Service Heuristics discovery and discussion at Zalora.
Zalora used the ISH questions so extensively that they contributed three new heuristics to the ISH collection: Dependencies, Impact/Value and Product Decisions.
“We first used the Independent Service Heuristics as part of Team Topologies during our workshop with Matthew Skelton in August 2021. The framework and shared language the ISH approach provided us with was transformational to the discussions we later had about our organisation and team structure. Not only did this approach help us discover and align on new stream-aligned teams, but it also helped us redefine other teams as platform, complex-subsystem, and enabling teams. Thanks to the Team Topologies and ISH framework our team structure is more autonomous, meaningful, and productive.
We were able to take this simple but powerful framework in its visual, grid-based format and have further discussions which led to us expanding the scope to reflect additional angles that we knew would be essential for sustainable team boundaries. It was great to be able to contribute our updates to the ISH code repo so others can make use of our insights!”
– Liam Hutchinson, Group Director of Product, Zalora
Summary - use ISH for rapid results and alignment across the organisation
The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. The ISH approach is a “rapid results” approach, and complementary to the approaches from Domain-driven Design (DDD). In particular, ISH is very suitable for conversations with people without an engineering or software background, enabling important discussion and alignment across organisational boundaries.
If you would like to learn more about how to apply Independent Service Heuristics in your organization, why not take a look at our P827 - Find good boundaries for flow using Independent Service Heuristics workshop