Tag Archives: people

The service concept revisited #3: where are the people?

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.)

A good way of approaching this is creating a map of actors and their needs or stakeholders and their interests. See also Service ecology maps and the enterprise canvas on my old blog as well as Enterprise Design Framework: Big Picture on this blog.


A conversation with Tom Graves contributed to this post.


References

Graves, T. (2010) Mapping the enterprise. leanpub.com.

Johnston, R., Clark, G. & Shulver, M. (2012) Service operations management: improving service delivery. 4th ed., Pearson.

Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

Visual design, visual architecture, software architecture: Ruth Malan

As a software developer, software architect or anyone else who influences software, you’ll want to know about Ruth Malan. Ruth writes about software architecture and, particularly interesting, about visual design in the context of software architecture.

She runs renowned software architecture workshops with her husband Dana Bredemeyer.

Ruth has published tons of fabulous material. I think the links below make for a good start:

Ruth’s work is full of insights and — perhaps even more importantly — utterly enjoyable to read and work through.

Change mapping, tools for change: Tetradian on Patreon

I think you might be really interested in what Tom Graves (Tetradian) and Joseph Chittenden are doing on Patreon.

Their work is relevant for anyone involved in making change happen in organisations, i.e. you, me, regular people, and those in roles such as line managers, project managers, programme managers, product managers, product owners, system owners, business architects, enterprise architects, business analysts, software architects and so many others.

Liveable application landscapes

Sarah Mei published a Twitter moment titled Livable Code.

The moment’s description reads:

“The modern practice of software isn’t much like architecture or construction. The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

Sarah talks about the differences between a staged house and a liveable house, and uses this as an analogy to discuss codebases in textbooks vs. in real-life systems. Go read these tweets, although I’ll mostly just riff on the description. I’ll wait.

Let this sink in:

“The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

I still see a surprising amount of custom software development in companies, but I’m convinced we’ll see better decisions on what to build and, more importantly, what not to build in the future. Building software to “make a pre-built space [i.e. COTS software] work for [the company and its people]” can be very worthwhile, writing yet another variation of CRUD code for customer addresses or basic product information usually less so.

As a side note, “[making] a pre-built space work for whoever lives there” seems to be what a sizeable chunk of today’s practice of architecture and construction is about. In this context, I enjoyed How Buildings Learn: What Happens After They’re Built by Stewart Brand very much.

In the early 2000s when Enterprise Application Integration was all the rage, Gartner predicted that companies would begin differentiating themselves less by the features of their applications rather than by the way they integrate these applications. This statement resonated deeply with me and I’ve been waiting for it to become true ever since. (OK, so this might actually be true, but I’ve been waiting for it to become a conscious decision.)

This integration, together with modelling concepts and activities in terms of COTS applications’ data structures and functions, is what makes applications (i.e. pre-built spaces) liveable (i.e. “work for whoever lives there”).

While Sarah wrote about code, I’m convinced her insights apply equally well on higher levels of aggregation such as applications, a company’s landscape of applications and beyond the organization’s boundary into the shared enterprise (i.e. customers, suppliers, partners, and beyond).

To me, “[making] a pre-built space work for whoever lives there” is a powerful metaphor and honourable work.

Sarah, thank you for that.


Originally published on Medium.

Architecture of people-intensive systems

Bob Marshall “didn’t sign up for all this people shit“. Neither did I. But like Bob — and Tom and Stuart and Ruth and Chris and Dave and so many others before me — I’ve come to realise that talking about the architecture of software-intensive systems might be distracting me from the core of the problem of building and running effective systems (although they haven’t phrased it in exactly these terms). Focusing on people and their needs might be a more effective approach. This is tough, at least for me, and I can fail at this in the most spectacular ways.

If a classification seems necessary, thinking of the architecture of people-intensive systems might be more useful to me than thinking of the architecture of software-intensive systems.


Update 2019-03-11:

I’ve been struggling with the architecture of people-intensive systems more concretely:

It’s the process, not the product

Stuart Boardman retweeted a link to a blog post by Rob Vens: “Software is not a product“.

In this post, Rob argues that we ought to consider our (hopefully ever improving) process of creating software as the primary product of our work rather than the software itself. In this sense, he argues that software is only a by-product of our work.

Interesting. I exchanged a few more tweets with Stuart in which he observed that “product” does not mean (physical) “good”. Indeed, services are products, too, both in a general sense and in the context of Rob’s blog post.

In my experience, clients still want to buy the results of the software process (e.g. an evolving web shop) rather than the collaborative design process yielding this result. This is despite the fact that software development processes and methods can be the subject of great debate at all phases of the sales and delivery process.

But herein might lie great opportunity: What if we could shift the conversation away from that by-product of our work to that collaborative design process that creates that seemingly auto-evolving web shop?

And maybe there is a chance of actually making this happen, if Laura Colvine (via Jeff Sussna and James Rock) is to believed: “It’s H2H: Human to Human“. (Alright, so I’m quoting this out of context.)

I’m well aware that the above is a tiny step for humankind, but it has been a greater and very enjoyable one for this human. Thank you to all of you who contributed to it.

I know realise that “The process is the product” would have been a better name for this post.

De-emphasising organisational boundaries unfortunately not a silver bullet

Many smart people have written many smart things about new ways of organising work that have become feasible in the last few years. Some of these smart people are Tom Graves and Dave Gray. A key aspect of many of these new ways of organising is de-emphasising traditional organisational boundaries, i.e. in effect doing work across organisational boundaries that would have been done within organisational boundaries just a few years ago.

The opportunities this brings have been discussed thoroughly before as actually have been the risks. So the following really is old news…but I feel strangely compelled to get it out of my system:

When you depend on others for critical parts of your performance, then critical parts of your performance actually depend on others.

When operating in a network of nimble and effective organisations this might be not much of a problem—assuming you can reorganise your value stream or value network in a swift and flexible way. Traditional corporate outsourcing can produce scenarios in which several large organisations are tied together by rigid contractual frameworks and complicated operating models over a fairly long time.

In these situations, the partners may feel they cannot obtain and, respectively, provide optimal value, but tragically feel they are unable to do much about it. Sooner or later, organising essential work strictly within the boundaries of the organisation looks preferable.

That sounds like rewinding a couple of decades and starting over. I think we can do better than this.

Going with the flow

A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.

I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.

Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).

Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.

Consequences of yet-another-architecture-definition

I described my evolving thinking of what architecture is here and how someone called an architect could add value to a team here.

What consequences does this mindset bring about?

  1. Architecture is not a tangible artefact, but a social construct. (See note below.)
  2. Architecture cannot be created directly, but is the result of other activities (i.e. planning, designing, building and sustaining a system).
  3. The team creates the architecture through interaction. Someone called an architect doesn’t create the architecture by drawing diagrams for the team.
  4. Someone called an architect could promote the shared understanding of a system through conversations with fellow team members and potentially creating supporting artefacts.
  5. Someone called an architect may well contribute to making significant design decisions (sometimes called architecture in the sense of a system’s significant design decisions).

Note: I didn’t come up with the notion of “architecture as a social construct” myself. But then again, I don’t seem to be able to find a single source, so I probably mashed up some ideas from the sources on architecture I mentioned before and the notion of “software as a social construct”.

Updates

2013-11-24: Added note on “architecture as a social construct”.

What does an architect do?

I’m still uncomfortable with job titles such as architect used in software-related contexts. Nonetheless, it is difficult to ignore the fact that this title is used and adopted with apparently increasing enthusiasm.

So what do I think an architect does? Or, perhaps better, how do I think someone having the architect job title could provide value to the people she works with?

Against this mental model of architecture, Bob Marshall’s antimatter principle led me to this:

An architect attends to the architecture.

A little longer:

A system’s architect attends to folks’ needs by fostering the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

How do you do that? Well, it depends…mostly on folks’ needs.

For those who’d rather be something than do something: An architect is an attendant to the architecture.

I like this definition of attendant: “a person employed to provide a service to the public in a particular place”. And I like to understand to attend as to look after (source).

Updates:

2013-11-30: Added form, made function singular.
2013-11-08: Added characteristics to definition.