Johnston, Clark & Shulver write about the service concept mainly from the customers’ perspective. They also allude to relevant others (specifically, ‘business leaders’) when discussing the service experience, outcomes and operations. However, this only seems to be a subsidiary concern.
Their version of a service concept does a good job of summarising key aspects of a service in an informal manner — and I use it in this way. However, more structure is clearly needed when going beyond that informal summary.
We need to think about employees (more generally, service providers) first. If we take good care of employees, they will usually take good care of customers, too. So we need to think about the employee experience, outcomes for employees, and the value a service creates for employees as much as about the customer experience, outcomes and value.
But other people are involved in or affected by the service. These may include others in the organisation providing the service as well as people external to it such as investors. Furthermore, there may be regulators, the community the organisation operates in, and even society at large (think ecological or ethical externalities).
When thinking about customers (or clients), we ought to also think about non-clients and anti-clients. Tom Graves (2010, loc. 254-256) describes non-clients as “people who are not and will probably never be customers of ours, such as people who live in a different country than one we serve” and anti-clients as “people who don’t trade with us in the normal sense but who don’t like us or what we do”. (Also see Tom’s blog posts on anti-clients here.)
My discussion of The structure of the service concept is the most popular post on my old blog On Service Design. When I wrote it almost six years ago the topic didn’t seem to get much attention. Academic services marketing and service operations literature mentioned the term frequently, but almost no-one bothered to define it or describe its structure or content.
The Service operations management textbook by Johnston & Clark (the recent edition is by Johnston, Clark & Shulver) is by far the most thorough discussion I was able to find.
I still like the idea of a service concept very much, in particular for its effectiveness. A well-written service concept can communicate a wealth of information in a very small space.
I typically use the service concept in a fairly casual form when exploring initial ideas for digital services with clients and colleagues. Interestingly, I’m back to the earlier (2005) version of the concept’s structure (although the differences aren’t huge).
It’s useful for me to revisit the fundamentals and relate it to other relevant concepts, including some of the popular design canvases. Furthermore, I want to dig into its elements in more detail. I’ll be doing this in a series of future posts.
The need for shared-value propositions makes a similar point with respect to considering a service’s value not only in relation to customers and business owners, but also in relation to employees, suppliers and even society at large
There seems to be a broad consensus that many types of software are best built and developed by cross-functional, self-organizing teams with about five to nine members using lean and agile approaches. (There are types of software and problem domains that require different approaches or need to be supplemented by additional practices, for example in health and safety related domains. I don’t focus on these here.)
Much software requires more than a single team to build and run. At this point, a decision on how to shape these teams and which responsibilities they take on becomes necessary. This decisions will have a significant impact on how the teams work, on how they collaborate and communicate with each other, and on the results they produce.
Teams shaped by functional domain
The common approach seems to be to organize teams by feature or functional domain. In this case, the teams would cover the full technology stack from front-end via services and application down to databases, storage, integration and compute infrastructure. This is certainly better than organizing teams by software layer such as user interface, application logic, underlying domain logic, and the data access layer.
In an e-commerce context, one team might take responsibility for product browsing and selection while another team might be responsible for the checkout process. A third team might take responsibility for account maintenance.
This might look something like this:
This is not unreasonable when we look at a single web application — but it may not be without problems even in this limited case. Great care needs to be taken so ensure that the boundaries between these teams do not lead to observable boundaries between these features or functional domains. For example, we do not want the user interface to subtly change when moving from product selection to checkout. (Think Conway’s Law.)
Going further, how does this approach scale to different client apps and interfaces? What if we want to add an iOS app? An Android app? Plus a public API? And support for voice assistants?
Adding people with the necessary skills to the teams is likely to cause the teams to grow beyond a reasonable size (even if individual team members are skilled in multiple areas). And the problem of ensuring integrity in these client apps and interfaces multiplies with the number of apps and interfaces.
App teams and service teams
To me it seems beneficial to separate the responsibilities for the client apps and interfaces from the services (or components) providing functional capabilities (i.e. managing access to data, implementing calculations, or implementing a business interaction such as placing an order).
This might look like this:
This allows app teams to focus on their users, the context they live and work in, their needs and preferences. Ensuring experiential and structural integrity within a single app becomes easier. App teams can also develop deeper expertise in the app-specific technology stack (e.g. web front-end vs. native mobile front-end vs. API management infrastructure).
Similarly, teams taking responsibility for services (or components) in a functional area can develop deeper expertise in this functional domain (e.g. pricing, order fulfilment, or product configuration). These teams can also develop deeper expertise in their service-specific technology stack.
Broad and shallow vs. narrow and deep responsibilities
I view app teams as having broad yet shallow responsibilities while service teams have narrow yet deep responsibilities. This refers to the breadth of functional scope and the depth of the technology stack. (I do not imply that app developers are somehow less technically adept or that their work is less technically complex than that of service developers. But in order to display a price to a user I do not have to know how to determine that price. And in order to determine that price I do not have to know when and how to effectively display that price to a user.)
I envisage these broad app teams and the deep service teams like this:
This approach to organizing teams requires collaboration between the app and the service teams to design and evolve the service API. We replace informal collaboration between team members (e.g. those focused on the UI and those focused on service implementation) with formal cross-team collaboration on an interface. This collaboration on the interface also ‘pays’ for mitigating the risk of friction at the boundaries of different parts of each app.
In this context, I’m thinking more about data-centric services (probably with a fairly generic and perhaps somewhat coarse-grained interface) rather than fine-grained RPC-style functions dressed up as a not-quite-RESTful JSON-over-HTTP interface. This should lead to increased stability (i.e. reduced volatility) of the interface and simplified dependencies (i.e. coarse-grained rather than fine-grained dependencies).
This is not “separate teams per software layer” — I think
So, I’m not — at least I don’t think I am — naïvely advocating for removing the UI layer from the application component, and thus advocating for a minimal form of separate teams per software layer. Instead, I view the different client apps and public APIs as individual products. I think that these products need to be product-managed. Similarly, I view these underlying functional services as products. The sum of their interfaces form an API (potentially, an internal API) which I view as another product. These products need — and deserve — to be product-managed, too.
What’s wrong with this?
And now, considering that this approach does not seem to be widely discussed, the Gretchenfrage: What am I missing? Why doesn’t this make sense? What would be a better principle for organizing teams in such a setting? Why is the team-by-feature approach superior?
I typically work for medium-sized to large companies building B2C, B2B or B2E products. Building significant features or functional capabilities typically requires collaboration and alignment with multiple groups within in the company. Such capabilities often depend on additional systems beyond the team’s control. YMMV.
As a bonus, the diagrams in this post show clearly that there is a difference between a visual designer and a graphic designer. Ah, well…
When I recommended Designing Delivery: Rethinking IT in the Digital Service Economy on Twitter, Jeff asked me to explain why I thought it was valuable. Jeff’s book deals with a complex subject matter and he considers a broad range of different aspects. While this makes this book valuable, it makes writing a meaningful review difficult. For what it’s worth, here we go:
Confirmation bias — well, an ego boost
From a very superficial perspective, Designing Delivery makes me feel good as it confirms a few things I’ve been having hunches about for a while. This includes a broader and more proactive role for testing & quality assurance in lean & agile initiatives and organizations, a focus on product management rather than project management, an extension of devops ideas to business operations, an emphasis on designing & managing services (or service-dominant logic) and, more recently, seeking to combine agile development and design thinking.
Unfortunately, my thinking hasn’t been as thorough, consistent and coherent as Jeff’s. I haven’t foreseen all of this years ago — on the contrary, compared to this book, my thinking barely scratched the surface…if you look really hard, you can even see some marks.
Cybernetics form the backbone of Jeff’s work in this book. I finally got the memo on cybernetics earlier this year and worked through Donella Meadows’ Thinking in Systems: A Primer. Yes, I know I’m late to the party…
Jeff introduces fundamental cybernetic concepts and applies them to software and, more generally, digital services in a very practical and approachable way. These cybernetic concepts helped me to talk and reason about behaviours I’ve seen at work and elsewhere in life. This, in turn, provides a basis for effecting change in these systems.
No software is an island
While software undoubtedly is essential to most businesses today, discussing software in isolation is insufficient: software needs to be considered in the context of the services it helps to deliver. Jeff provides a good introduction to service-dominant logic and how it applies to the digital service economy. In addition to customer-related concerns, Jeff discusses other people in the enterprise (especially employees and service providers) as well as organisational concerns. It is unsurprising that Dave Gray’s The Connected Company has a guest apperance.
It all comes together
Jeff brings together several schools of thoughts or practices that are hugely important today. In particular, Jeff shows that cybernetics (or systems thinking) and design thinking cannot only coexist peacefully but can actually be combined to yield even greater value. Furthermore, he shows how design thinking has an essential role to play in the fuzzy front-end of lean & agile software development processes. Jeff brings devops into the mix and shows how it can be relevant beyond software (i.e. service operations, business operations). He calls for operations to become an input to the design process and thereby completes the loop of designing, developing, delivering and operating software-supported services.
A crucial point in this book is Jeff’s call for a broader and more pro-active role of quality assurance in this context. He calls for a quality advocacy role that needs to go far beyond software development: indeed, quality advocacy needs to help the entire organization to deliver the right services to the right people — both inside and outside the company.
Many IT organizations are facing formidable challenges today. In Designing Delivery Jeff Sussna envisages a future for them in the digital service economy and shares his thoughts on how they can develop toward this new role.
That’s it for now
This blog post is only a start and is necessarily biased. It certainly doesn’t do Jeff’s book justice. As my thinking becomes clearer, I might update it in the future.
I have started to play with Clojure recently. Considering my object-oriented programming background, this (unsurprisingly) made me think long and hard on many occasions.
One of the things that struck me was Clojure’s rich ecosystem of (often) small libraries that are expected to play nicely with each other. A common question on the web is “How do I get started with web development in Clojure?”. A common answer is “Ring + Compojure + Hiccup”. Don’t like the way one library does its job? Just use a different one!
Contrast this with, say, Java, where you typically pick a single web application framework that often has strong views on most aspects of a web application. Using a different approach, library or framework for just an aspect of the web application is often difficult if not impossible.
Note: This is not a Clojure-is-better-than-Java post. I don’t try to advocate a specific approach, criticise a specific framework or take swings at anyone. Peace!
A framework and a library’s functions are (or, better, can be) very different beasts. A framework often does what it says on the tin: it provides a frame (a mindset, a way of doing things, a safe, delimited space that you’re not supposed to venture out of) in which to work. When you start bumping against a framework’s boundaries, i.e. often that frame itself, you’re often out of luck: there is often no simple, let alone supported, way of moving beyond that boundary.
Working on e-commerce sites, I’m being told that it is difficult and costly to fully control the path component of URLs in a specific successful platform. I find that difficult to stomach: Why shouldn’t I be able to do this easily in 2014, when this was trivial in 2004?
Composable libraries, for better and worse, do not provide such a rigid frame: the greater flexibility, the higher degrees of freedom mean that the way ahead is often not mapped as clearly as when using a framework.
Looking at the positive effects at unbundling elsewhere (say the telecommunications industry as a large-scale example), I wonder whether unbundling the services of what we used to consider single frameworks, applications or platforms may be beneficial. For me, and others, I presume, monoliths have lost their appeal long ago. But then they might have been essential in getting here from there.