Home

Awesome

Independent Service Heuristics

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. Based on some of the ideas in the book Team Topologies by Matthew Skelton @matthewskelton and Manuel Pais @manupaisable.

See teamtopologies.com for more details about Team Topolologies.

Copyright © 2018-2021 Team Topologies - Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Overview

When designing organizations for fast flow of change, we need to find effective boundaries between different streams of change. Techniques like Domain Driven Design (DDD) are very powerful for this, but can be quite involved and difficult to learn. A lightweight intermediate approach is to ask "could this thing be run as a cloud-hosted (SaaS) service or product?".

The ISH approach covers many typical situations in modern software but not all. It's designed to stimulate conversation and provide a frame for thinking, not as a perfect "catch-all" tool.

How to use

Choose an area of the organisation's focus to be represented in software: 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.

Use the checklist below to ask questions about the candidate domain / service / application / value stream. The more "yes" or "probably" answers, the greater the chance that you have found a good candidate for being a separate stream of change. This means that we could arrange one or more Stream-Aligned teams to this area.

Checklist

  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 viable service with a paid offering?
    • Would it bring recurring revenue with subscription plans?
    • 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 considering infrastructure costs, data storage costs, data transfer costs, licence costs, etc.?
    • Is this thing fairly separate, disconnected from other things in the organisation?
    • Does the organisation track this separately?
  5. Data: Is it possible to define clearly the input data (from other sources) that this thing needs?
    • Is the thing fairly independent from any data sources?
    • Are the sources internal (under our control, not external)?
    • Is the input data clean (not 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 unnecessary?
  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 (so that the team is not driven by the requirements and priorities of other teams)?

Further considerations

Detailed considerations

Resources

Acknowledgments

Thank you to the people at the DDD London meetup group for their input on an early version of the Independent Service Heuristics. 😻

Thanks also to: