resilience in the face of continually changing circumstances
Services are adaptable patterns which describe the core of the solution to a problem in such a way that you can use this solution repeatedly under continually varied circumstances.
To begin on a journey of Strategy through Design, we need to unmask existing services which are hiding in plain sight, concealed by the terrain of our business landscape. Once they are effable, they become subject to management, susceptible to improvement; a pliable medium for establishing productive patterns.
Clarity of concept clears the devil from the details.
— Majid Iqbal
Clarity of Concept
The attempt to sort out the various services lurking in a larger process starts with analysis. We begin by seeking out the parts, dependencies and interactions. We’re often tricked into not seeing real objects that are plainly before us, so it should come as no surprise how easy it is to overlook critical aspects of the thought machines we call services.
The eye sees only what the mind is prepared to comprehend.
— Henri Bergson
It is very easy to transpose what we suppose should be for what we’re actually seeing; we conflate actual observation with a desired future state. The line between as is and to be is a boundary in need of delineation.
Before we get too deep into labeling things, we should first make a pass to see if we can simplify the problem space.
Clarity Proceeds from Simplicity
Complexity is a common lament of our times, but before becoming resigned to the fate of some rustic sojourner tossed in the seas of modernity, it might be worth asking if the problem is really so multi-faceted, or if it is just something poorly understood. Because that later case is something we can more easily remedy.
Every situation, not matter how complex it initially looks, is exceedingly simple
— Eliyahu Goldratt
Every service is a system of interconnected sets of elements that are coherently organized in a way that achieves something. We can use the vocabulary from well-defined taxonomies to squeeze the complexity out of a process. Often, what we perceive as complexity is actually multiple intertwined or entangled threads. Untangling the cord into singular and discernible strands reduces the risk of mistaking one thing for another.
ART Value Streaming can be a useful exercise, but what we’re after is something more durable. Value Streams are a physical domain metaphor, a Lean Manufacturing concept adapted to the digital domain. A word of caution is in order. Value Streams of the physical domain are more knowable, because, well, they’ve got physics to keep them in line, if nothing else. Services in knowledge work are more purely conceptual, lacking actual physics to tame the imagination. The rules that govern imagination are not so clearly understood as those that apply to applications in steel, glass or wood.
A Pattern Language
The mental model of a Service is only going to be useful to the extent that it is durable; that it holds up under the full battery of circumstances encountered over the course of time. Services have to be more robust than what a typical Value Stream mapping exercise offers, because of the manifold array of possible artifact-event combinations that the process will need to navigate in order to realize objectives. A durable Service is the model of a machine with the capability to recombine elements on the fly to ever-changing patterns that yield preferred outcomes.
Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to the problem in such a way that you can use this solution a million times, without ever doing it in the same way twice.
— Christopher Alexander
Alexander’s specification for “pattern” begins to show us the difference between yet-another Power Point proposal and a proper Service specification. People like to turn to Lean Manufacturing paradigms to explain this stuff, without taking into account how profoundly different Services are in knowledge-work domains.
Physical domain processes are more susceptible to being hammered into sameness. Henry Ford punished his competitors through his dogged pursuit of uniformity on his Model-T assembly line. Clearly, uniformity can unlock great power. However, when the variation actually encountered in a processes overwhelms the limits of analysis, the magic of uniformity fails us, no matter how carefully we craft boundaries to constrain the scope of activities. In fact, the farther we go down the rabbit hole of dependency management, the less control we have over the crux of the problem, which Deming called understanding variation.
The Toyota Production System laid the groundwork for understanding modern services by adapting the assembly process for variation, abandoning economy-of-scale best practices, not because it seemed like better idea, but because the practices that guided all successful automobile manufacturing up to that point were pushing Toyota toward bankruptcy. Changing circumstances had made contemporary best practices at that time, in that market, obsolete.
Being Responsive to Actual Demand
There circumstances were this — there was no demand in Toyota’s market for large numbers of the same car model. Lack of market at scale defined the unique circumstances of time and place that Toyota faced, in an era when economy-of-scale was the dominant mental model of the industry.
There was demand for small production runs of many different models, something that couldn’t be done profitably under prevailing practices. The principles of uniformity of process and economy-of-scale were so deeply rooted in managerial thinking that they went unquestioned, taken as Gospel, as the saying goes. The “best practices” that Ford and others pioneered were outdated, inappropriate, unworkable and in a word, disastrous, for the reality that Toyota faced.
Taiici Ohno’s innovation was to model the assembly line as constantly reconfigurable, on-the-fly.
The innovative practices of just-in-time delivery and pull-based Kanban modeled the assembly line as sets of elements subject to ongoing ad-hoc reconfiguration. The TPS assembly line was transformed to produce what appeared to the casual observer as homogenous products, such as 4 door passenger cars, but the distinguishing characteristic of the Toyota line was the variation they were able to subsume in the process, while operating at scale, meeting the diverse demands of the market while returning value to their shareholders.
When Toyota was eventually able to sell models in volume, the cost and quality benefits resulting from their unique production system were as a bonus. The capability of subsuming variation in process was an important part of what made them formidable competitors.
W. Edwards Deming laid the groundwork for understanding variation in terms of process management in his book “Quality, Productivity and Competitive Position”, eloquently making the case that piling on yet-more carefully considered specification will not result in either improved quality or productivity. SAFe culture tends toward vanquishing variation, instead on understanding its sources and causes.
Throughout the development here of the concept of services, we’ll be pursuing the goal of an unambiguous service specification, but the detail of specification can never be taken as more important than understanding, accommodating and subsuming variation. This a theme we’ll return to often, because it’s something that we can’t just wish away.
A functional Service is responsive to actual demand. Writing Service specifications requires that we lay out process steps and sequence activities, but we’re usually not asked to build something with the uniformity of Ford’s Model-T. The uniformity of process depicted in a Power Point slide is typically an illusion. Sources of work are always much more varied than implied. The possible progression of events is ever more diverse than the flow diagram depicts. The devil is in the details.
“Services are solutions that can be more difficult to describe than manufactured products of equivalent value”
— Majid Iqbal
The point is not that we need to map out every detail; quite the opposite. Service specifications need to “describe the core of the solution to the problem in such a way that you can use this solution a million times, without ever doing it in the same way twice.”
To realize that goal, we need to avoid static specification and instead frame the service to be unambiguous while preserving optionality. How we go about framing the problem will big factor in how successful we are.
Thus, Service Frames is another mental model we can add to our kit; one for discovering and designing constantly reconfigurable work streams. Frames provide a means of constraining or “framing” the solution space to keep the focus on desired outcomes without being prescriptive. Subsuming variation requires that we preserve options. Properly framed problems are constrained by specifications and functional boundaries without curtailing optionality.
Artur Tumasjan — "Magic Mike :D"
Aditya Wardhana — "Vision"
RAEng — "Vision"
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.