Granularity: A quick guide for Workflow, Use-Cases, and Components

Below are some tips on how to manage granularity within workflow diagrams, use-cases, and component creation. Each of these work products are notoriously difficult to size.

A partial list of the work products that lead to system components are:

[requirements]
CONCEPT MODEL: A model of the concepts in the business, sometimes presented as a glossary.
WORKFLOW: How work moves through the business and what processes are performed to accomplish the work.
USE-CASE: The activities and interactions with the system required to do the work.
[System Components]
MANAGER: Encapsulates the complexity within the scope of a core use-case.
ENGINE: Encapsulates the complexity around work performed within the use-cases.
RESOURCE ACCESSOR: Encapsulates the complexity around accessing resources.

Granularity is subjective. This makes analysis and communication about granularity difficult. Subjective topics need conext. Let’s add the context by examining the perspective we should view each of these work products:

CONCEPT MODEL: Perspective of the BUSINESS.
USE-CASE: Perspective of the ACTOR.
WORKFLOW: Perspective of the WORK.
MANAGER: Orchestration of the use-case.
ENGINE: Work to carry out the use-case.
RESOURCE ACCESSOR: Work at the atomic business verb level.

Each of these perspectives should help us with sizing or granularity. The granularity should match the perspective regardless of project’s size and complexity. Here are some metrics.

Concept Model: The concept model is from the perspective of the business. If the business has multiple business units or lines of business you likely need multiple concept models. The concept model should include any concept used in a workflow or use-case or in a business rule.

Use-Cases: If it feels like a use-case should have multiple actors then your use-case is too big. Also, if two use-cases feel like they could be done at the same time by the same actor then they can likely be combined into a more granular use-case.

Workflow: If a node in your workflow tackles multiple types of work it’s too big. Split it into more nodes. If the work is too small (chop onions) then you might combine it (chop vegetables) to make a more granular bit of work (mise en place, or “chop and measure ingredients”). The work in each node should commonly be accomplished by one actor (or group) at one time. In the example here it’s likely that the actor chopping the onions is also chopping the other vegetables so their work can be combined.

Manager, Engine, and Resource Accessors: These are discussed in the book, Righting Software, but in general the granularity of the managers and engines will match the use-cases and the resource accessors will match single, atomic business actions.