Tag Archives: services

“Designing Delivery: Rethinking IT in the Digital Service Economy” by Jeff Sussna

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

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.

 

 

Enterprise Design Framework: Anatomy

Yesterday I said how valuable I thought Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People by Milan Guenther is and talked about a few things I view and do differently with respect to the enterprise design framework’s Big Picture layer.

Today I was going to write about things I view and do differently with respect to the anatomy layer…but it turns out I already did:

Content strategy, service design and physical objects

In this context you also have to ready Mapping the Enterprise by Tom Graves.

 

 

Products and services, again

Physical products play a curious role in the context of service design, marketing and delivery. There seems to be surprisingly little thorough discussion about this topic.

Tom Graves has written a brilliant post titled From Product To Service, which significantly adds to the discussion.

I’ve been rambling about this topic here and here.

Unbundling services provided by frameworks

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.