Service Boundaries
good fences make for good neighbors
Services emerge when a process is constrained within defined boundaries. We use language to define the boundaries of our Services. Not just any language, but carefully chosen taxonomies, forged and hardened like machine tools.
The fact that a service is defined as having a final outcome implies a system boundary. Title companies establish property boundaries by sending out a survey crew to painstakingly measure the bounds and then mark it by driving metal pins in the ground.
Establishing System Boundaries
Our survey pins are well chosen words; carefully crafted taxonomies which gives us the means to set service boundaries. When we are thorough and deliberate about our definitions, these words can be as durable as metal pins.
In process engineering, where sorting out the of mixing up of things is table-stakes for modeling, the tactics at our disposal include defining boundaries.
There is no meaningful concept of “system” or “service” without a clear articulation of boundaries. Staking the bounds is a crucial skill for a process engineer. You’re the surveyor in the systems landscape. If you’re going to convince others to respect the property lines, then you’ll be needing the right tools in your kit.
You don’t want to go out into the field with a bag of pins that will rust away with time, gone without a trace when you have reason to go back and walk the fence line. The language of services is about crafting a taxonomy for our purpose that will stand the test of time.
A First Pass at Finding Service Boundaries
An analysis of sources of work often provide a clue about the intake boundary. Prior events activities over which you have little or no control are likely outside the service. Establishing intake criteria and protocols helps establish that boundary.
An analysis of types of works usually yields some clues about the containing boundaries. Events or activities which require special capabilities, or are foreseeably disruptive, are at least candidates for consideration if they can be delegated to another work stream or simply tamed with a dose protocol and heuristics.
An analysis of expected outcomes, typically expressed in terms of enhancements to product or enrichments of experience, are a natural place to look for end state boundaries. Many services in business are networked and don’t have an archetypical end-user; instead the outcomes are intake by other services in a larger system. Lack of clear inter-process boundary is a common source of confusion and inefficiency.
Budget as Boundary
The budget often represents an important system boundary. For our service specifications to be meaningful, they need to give stakeholders real insight into process, to tell the story of the service, and its relationship and interface with other services of the system.
If an Agile Transformation Initiative is going to improve our ability to deliver value to the business, then we should be able to tell the story of that value in the P&L.
It’s only reasonable that the budget be the voice of the customer. Some of the most important work before us today is to strip away the apparent complexity around what we mean by productivity, including how to model and measure it. Service thinking supports us in staking out the process, from the Pull Request Edge all the way back to the P&L.
The concept of services described by a service specifications and delimited by boundaries helps us see the solution space in a more definite and tangible way. However, we should acknowledge that the problem space we’re confronted with is typically more open and dynamic than allows for the all of this talk of definiteness seems to imply. Admitting to the complexity of the real world brings us to appreciate that the days of process maps as a series of steps belongs to a by-gone era. The next section develops the idea of services as patterns
Douglas Hawkins — "Survey ribbon on a tree trunk"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.