Independent Service Heuristics (ISH) is a technique invented by the authors of Team Topologies, Matthew Skelton and Manuel Pais. 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.

Independent Service Heuristics

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.

Uncovering potential domain or service boundaries

<ul><li>Would the cognitive load (breadth of topics/context switching) be bounded to help the team focus and succeed?</li><li>Would significant infrastructure or other platform abstractions be needed?</li></ul>

7. Teams: Could a team or set of teams effectively build and operate a service based on this thing?

<ul><li>Is the scope big enough to provide an impact? Would the scope be engaging for talented people?</li><li>Is there sufficient value to customers and the organization that the value would be clearly recognized?</li></ul>

9. Impact/Value: Would the scope of this thing provide a team with an impactful and engaging challenge?

<ul><li>Is this thing independent enough?</li><li>Would consumers understand or value it?</li><li>Would it simplify execution?</li></ul>

1. Sense-check: Could it make any logical sense to offer this thing "as a service"?

<ul><li>Would it be a viable business (or "micro-business") or service?</li><li>Would it be a compelling offering?</li><li>Could a marketing campaign be convincing?</li></ul>

2. Brand: Could you imagine this thing branded as a public cloud service?

<ul><li>Would it be a viable business (or "micro-business") or service?</li><li>What would a subscription payment include?</li><li>Is there a clearly defined customer base or segment?</li></ul>

3. Revenue/Customers: Could this thing be managed as a viable cloud service in terms of revenue and customers?

<ul><li>Is this thing logically independent from other things?</li><li>Could the team "self-serve" dependencies in a non-blocking manner from a platform?</li></ul>

8. Dependencies: Would this team be able to act independently of other teams to achieve their objectives?

Decide where to focus the 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.

Choosing an area of focus

<ul><li>Is the thing dependent on lots of data from multiple sources? Or fairly independent?</li><li>Are the sources internal (under our control) or external?</li><li>Is the input data clean or messy?</li><li>Is the input data provided in a self-service way? Can the team consume the input data "as a service"?</li></ul>

5. Data: Is it possible to clearly define the input data (from other sources) that this thing needs?

<ul><li>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.</li><li>Is the thing too interconnected with other things in the organization? Or fairly separate?</li><li>Does the organisation track this separately?</li></ul>

4. Cost tracking: Could the organization currently track costs and investment in this thing separately from similar things?

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 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”

Identifying boundaries with Domain Driven Design

<ul><li>Is the thing meeting specific user needs?</li><li>Do we know (or can we easily articulate) these user types and their needs?</li></ul>

6. User Personas: Could this thing have a small/well-defined set of user types or customers (user personas)?

“Could this thing be run as a cloud-hosted (SaaS) service or product?” ﻿

Exploring boundaries using Independent Service Heuristics

Footprints Tours 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 first step would be to capture some possible fracture planes.

An Independent Service Heuristics example

<ul><li>Does this thing provide discrete value in a well-defined sphere of execution? </li><li>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?</li></ul>

10. Product Decisions: Would the team working on this thing be able to own their own product roadmap and the product direction?

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).

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.