Andrew Polaine, Lavrans Løvlie and Ben Reason describe the notion of service ecologies and the benefits of mapping service ecologies in their book Service Design: From Insight to Implementation. They provide relevant figures from the book here, here and here. The service ecology map has three main purposes:
1. To map service actors and stakeholders 2. To investigate relationships that are part of or affect the service 3. To generate new service concepts by reorganizing how actors work together
Polaine, Løvlie & Reason (2013, pos. 1496)
The service ecology map dimensions proposed in the first link above are well known: what, how, when, where, who and why. These dimensions and the above definition link the concept of a service ecology map directly to the scope or context layer and the business services layer of Tom Grave’s (2010, p. 37-38) enterprise canvas.
A few happy thoughts:
- The notion of a service ecology resonates nicely with previous discussions of the enterprise-as-ecosystem.
- The service ecology map, together with the enterprise canvas, provides a nice link between ‘classic’ service design and enterprise architecture (architecture of the whole and shared enterprise).
With a respectful bow to Tom Graves and his work, this leaves me with the following layers of abstraction for my service decomposition work:
- Concept (implementation-independent)
- Implementation (implementation-specific)
- Deployment (operations-specific, action-plan, resource-schedule)
- Action record (record of actions as occured)
Tom has very good reasons for designing these layers in the way he did, e.g. congruence with the Zachman framework. I really only combined Tom’s scope & business services layers into a single context layer and slightly renamed some of the lower layers. This is a pragmatic approach that I expect to work in my context–you are probably better off with Tom’s approach. References Graves, T. (2010) Mapping the enterprise: modelling the enterprise as services with the enterprise canvas. Tetradian Books. Polaine, A., Løvlie, L. & Reason, B. (2013) Service design: from insight to implementation. Kindle ed., Rosenfeld Media.
We have great problems to solve.
So we task someone to describe the problem and we task someone else to describe the solution, which yet someone else is tasked to implement. For reasons of efficiency, we let them all start at once.
The bad news is that this doesn’t work. (And it hasn’t worked before. Ever.) Most problems worth solving today don’t have obvious solutions. In fact, often it isn’t even obvious what the real problem is.
In reality, that nice process of describe problem — describe solution — implement solution looks a little more like this.
“No way!”, the lizard screams, “Our process is way more disciplined than this!” Well, maybe it is disciplined (I bet it’s not), but is it effective? Does it yield effective solutions to the real problems?
If The Squiggle is too much to stomach, let’s take a more conservative example: Where would we draw the line between the problem and the solution here?
Having a problem team and a solution team is wonderful way to foster adversarial mindsets. Instead, let’s have one team with different strengths and a common understanding of what success means. And then let’s get the -bleep- out of their way.
Also read Bob Marshall’s The Same Old Way.
I believe that the success of software development projects and many other types of initiatives could be greatly improved if we came to terms with a simple insight:
There is no such thing as a requirement. A so-called requirement actually is a design decision.
Why does this matter? First and foremost, I think we want to consciously make potentially far-reaching decisions, especially when other peoples’ lives and livelihoods depend on them. (Well, this dependency might be more pronounced in your business decisions than mine…) Second, when we see these design decisions for what they are, we can make them more effectively, e.g. by applying design methods to them.
Requirement statements are best understood as statements of stakeholders’ interests, needs or wants. Rather than taking them at face value, we ought to seek insight into the stakeholders’ deeper, underlying motivations.
For example, stakeholders frequently express perceived mechanisms for achieving desired ends as requirements. Identifying these desired ends will often lead to discovering better ways of achieving them.
Design decisions come in two flavours: decisions relating to the problem space (i.e. ultimately deciding which problem to solve) and those relating the solution space (i.e. ultimately deciding how to solve it and implementing the solution). Rushing to working on the solution may feel like progress, but this might well be progress in the wrong direction.
A request: I know that I’m not the first one to state that requirements are design decisions. Please let me know if you know who said this first (or, at least, early). Thanks.
Good reading here:
Take part in the conversation on those blogs or on Twitter.
Dean Bubley (Disruptive Dean) said the following on Twitter yesterday:
The OSI stack for networking should have Layers 8 & 9 added to it: context & purpose. That’s where the value is going.
The underlying thought seems to be applicable to other areas, including service design, enterprise / business / solution architecture and software development.
Tom Graves’ describes several layers of abstraction in his service-centric view of the shared enterprise, starting with the enterprise layer, which defines purpose, and the scope layer, which defines context.
When describing a software service, for example, I typically begin by describing its intent and depicting the service in its context (both static and dynamic).
So, when faced with a new concept or a new challenge, one of the simplest ways to start adding value is asking two questions:
- In what context?
- For what purpose?
Tom Graves has written extensively about the notions of services, functions, capabilities and assets as well as on how these interrelate and how to tell one from the other. Continue reading
In The Connected Company, Dave Gray describes a form of organisation in which (semi) autonomous pods provide services and deliver value to each other and (end) customers on a shared platform.
In this Google Groups post, Dave explains why he chose the term pods. One of the reasons was:
Pod is also a term used to describe biological things, such as an insect egg casing or a casing for seeds, it also has biological connotations.
Pod is also the name for groups of some animals such as whales and dolphins. Thinking about this meaning I started to think about the environments all beings live in. In biology, the term substrate describes such an environment. In the context of The Connected Company, the platform is (part of) just this environment in which the pods exist and act.
To me, this biology metaphor is powerful–even if perhaps not exactly what Dave originally intended when selecting the term: groups of individuals living together and acting with joint purpose in a shared environment.