Author Archives: Oliver Baier

About Oliver Baier

I work with people to design, build and run digital services…and write about it. I have realised that my more interesting insights are considered to be unfashionable by some.

What’s math got do with it?

What’s math but a second-hand emotion?

– Tina Turner, but not quite

Over on Twitter, Ruth Malan said:

She was promptly told to stop the pseudo-mathematics.

Let’s look at this in detail:

From just looking at the tweet, we can’t tell whether this claim has any merit to it — no matter whether it’s expressed as a mathematical equation or as an English sentence. If we wanted to investigate, we’d have to go to the source (directly or indirectly) and learn about the context in which Kurt Lewin made tis claim. Because, y’know, it depends…it always does and we probably want to know what it depends upon.

If we can say “Behavior is a function of a person interacting with the environment” perfectly well in English, what’s the benefit of expressing this as the formula “B = f(P, E)”?

Brevity and precision, I think. These help us see what we’re actually saying. In other words, I think it helps us see the structure and perhaps the shape or form of our statements. (Better words, anyone?)

At first sight, we might consider the English sentence and the equation to be equivalent. But are they?

The equation makes it clear that behaviour is considered to be a function of only the person and the environment — no other variables are in play. With the information we have for now, we can’t know whether this is true or not, or even whether this was what the author of that English sentence meant to say.

But we brought this into the open and can now reason about it. And argue. And agree. Or disagree.

We could have done this by analysing the English sentence, but I think the equation helps us seeing this issue in a way that the sentence does not.

We don’t know which aspects of the person or the environment are relevant here. We also don’t know what that function is, i.e. how exactly the interaction between the person and the environment determines the person’s behaviour. In other words, we don’t know the definition of that function.

But neither the sentence nor the equation imply that we know this. We shouldn’t be impressed or intimidated just because someone expresses a statement as a mathematical equation, and we shouldn’t jump to the conclusion that the underlying situation is fully understood. Instead, we could think about what the equation really means and how this meaning can improve our understanding of that situation.

For a function to be useful, we don’t necessarily have to know its definition — at least up to a point. For example, when analysing a system we might determine that some outcome (call it z) depends on two variables (call them x and y):

z = f(x, y)

We might be able to determine the values of z for certain values of x and y from analysing our system. We might be able to determine certain relations between the outcomes and the input variables: for example, we might be able to determine that z goes down when x goes up and when y goes down.

Or better still, we might postulate this from our knowledge about this system and seek to validate this empirically.

Still, we might not know the exact definition of that function…but expressing this relationship as a function can further our understanding and our conversations.

What’s more, we don’t always have to know a function’s definition in order to work with it.


f(x) = g(h(x))

and assuming a couple of math-y conditions, we know (if I remember correctly) that f’s first derivation is

f'(x) = g'(h(x)) * h'(x)

even without knowing the definition of g and h.

Now, this might not be a perfect example (after all, we know enough about the definition of f), but it seems to illustrate my point.

Coming back to Lewin, we could ask deeper questions about that statement. And I think I will and read up on this. Consider the equation once more:

B = f(P, E)

Form. Shape. Structure. A person’s behaviour is a function of that person’s interaction with the environment. If that’s true of a person — say me — it’s true for all other person’s — say you, too.

So my behaviour is a function of my interaction with the environment, where part of that environment is your behaviour, which in turn is a function of the interaction between you and the environment.

Things are getting complicated quickly, and a mathematician might be able to help us put that into an equation…which in turn might help us to better see the structure of these relationships.

Mathematicians can help us express better what we’re trying to say and help us understand better what we’re actually saying. And they might help us reason about our statements — and separate what we can safely conclude from our knowledge from what we cannot safely conclude. In other words, they can help us put more rigour in our statements and our thinking.

Now that would be helpful and, I’m sure, much appreciated.

Ulysses app and third-party Word documents

Increased productivity, and perhaps quality, too

I have recently started taking another look at the Ulysses writing app and I’m very impressed: it seems to make me more productive and the increased focus seems to increase the quality of my thinking and my writing.

It feels like these improvements are fairly significant, but I’ll withhold definitive judgment until I have a little more experience. I haven’t tried created many or very large documents yet, but the ones I created in Ulysses weren’t completely trivial either.

The problem

As an independent consultant, I often create the initial versions of (Word) documents for my clients. We usually collaborate on finalising these documents, e.g. for submission to end clients. At some point, my clients take ownership of these documents for future use and evolution.

Ulysses has been great for drafting such documents and it’s fairly easy to make exported documents visually match a client’s document templates. Ulysses has a style sheet approach to exporting documents, has a large library of export styles (and editor themes) and provides excellent documentation on customising styles.

But given the usage scenario I described, exporting a document that visually matches a client’s template isn’t sufficient. Future work on the document must be efficient and natural to client staff, i.e. things need to work just like in any other of their documents. To properly support my clients’ tooling, the document I hand over needs to use the client’s template just as if I had created the document in Word.

My solution

I have modified one of the built-in styles (Swiss Knife) and removed almost all visual styling — in particular, most font styling and paragraph spacing. I have kept some document-level basics and adjusted the indentation of lists. Where needed, I have specified the Word style names for specific Ulysses styles (e.g. “List Paragraph”).

In this way, Ulysses exports a Word document that applies the appropriate Word style to paragraphs and inline text without additional styling information: I get “Heading 1” and not something like “Heading 1 + Before: 10pt”, which is significant with regard to further editing in Word. (Note that Ulysses’ layout capabilities and flexibility are a great asset for its core usage scenario.)

The resulting document is well-formatted from a structural point of view. Visually, it looks like a document produced on a typewriter — without the flair of created by the mechanical device.

I then apply the client’s Word template to the document which results in a document with the appropriate structural and visual layout.

If the client doesn’t have a proper Word template it’s easy to create one from a sample document (via Save as Template).


This isn’t the core use case that Ulysses was built to serve: Ulysses is great at exporting well laid out documents that you don’t have to touch after export. This approach works great for documents that you don’t modify outside Ulysses, and I’m using it for this scenario.

But Indie life can be more complicated than that and so is the usage scenario I described above. It took me a little while to figure out this approach, but now it seems to work well for me. It seems both effective and efficient.

Ulysses’ documentation and its style library have been very helpful here. And so has been Ulysses’ customer support team who have been very responsive and have even provided me with a simplified export style — a big ‘Thank you’ and a shout-out to Franz!

I look forward to using Ulysses more and seeing what it does to my practice as I get more familiar with its finer details. And just so you know, I’m not getting paid to write this post and I don’t get any other commercial benefits from doing so.

Flows of material, energy and information

Living ecosystems and machines share the three flows of:

  • Material
  • Energy
  • Information

Seeing that ecosystems and machines are very different things, I wonder whether this is something more than just coincidence, i.e. whether there is something truly fundamental to these flows.

Do physicists have a view on this?

Flows in software systems

Let’s look at flows in the context of software systems. We often talk about the flow of logic in a program, but that is a different use of the term ‘flow’. Instead, let’s think about material, energy and information.

Information flow seems straightforward: information (well, data) flows into a program, is processed or transformed and flows out of this program again. As a really simple example, think Unix filters. Similar things can be said about smaller structures such as individual procedures.

At first sight, we do not seem to have flow of material in software systems. But when we look closer, we can see that not all information is the same — in fact, I think that we might benefit from thinking of some types of information (or data) as material to be processed by a piece of software. The type of information discussed in the preceding paragraph is a good example (i.e. data piped into and out of a filter).

To distinguish this material-like information from other types of information it seems beneficial to think of the latter in terms of signals. In other words, we might want to think of information flow in its generic sense as flow of signals. These signals are information that control the processing of the material-like information, such as the signals to start or stop a job or service, or any type of event notification.

Energy seems straightforward, too: software systems and the infrastructure they run on need electricity to operate, as do the facilities housing this infrastructure. The actual transmission of information needs energy, too.

But is there another, perhaps more metaphorical type of energy that is required to keep our software systems alive? With life being a state in which organisation is maintained and entropy is resisted? Software systems need to be used and their use needs to provide value to someone in order for that energy to be made available to the system. More on this in a bigger context below.

Flows in markets

Let’s take a step back and look at businesses and the markets they participate in. Market participants exchange goods and service for payment or some other type of value. They exchange information in order to coordinate their activities.

So information flow is certainly relevant when thinking about markets.

Flow of material covers the exchange of goods nicely. It also covers the logistics for stuff (a technical term) that is used in the course of providing services. It also covers the logistics of services operating on stuff, such as having maintenance done on the car. In a very abstract way it can be said to even apply to situations in which that ‘stuff’ is a living being — for example, when getting ‘maintenance’ done on the cat or myself, i.e. seeing the vet or a therapist (you figure out who goes where).

In such situations we do not want to talk about flow of material, but we should understand in which way the flow of living beings through a service is similar to the flow of material and in which ways it is very different from it. Barely scratching the surface of this topic, the cat hates to ride in the car and creates much more noise than anything else I transport. In other words, this flow creates high levels of stress — in her and in me.

On a concrete level, the flow of energy is intuitive to understand: businesses and people require energy to exist and do things. Cats, too. But, as above, is there a more metaphorical sense of energy that we should be thinking about?

Is value in its many forms a type of energy? Is payment or money a form of energy that keeps businesses alive? Or people, since it provides a means of obtaining life-sustaining energy of the traditional kind? And again, cats, too. And what about capital?

So what?

Is there value in thinking in these terms of software systems, businesses and markets? Is there value in thinking of the three fundamental types of flows — material, energy, information — in ways beyond their literal meanings?

Is there value in trying to map flows of money, capital, value to one of these fundamental types of flows — or are these something entirely different?

Contributors, responsibilities, collaborators, objects, properties and rationale

Ruth Malan and Tom Graves have influenced my thinking and my practice for years. Their influences come from different angles, but there is a lot of overlap — some of it right in my area of work. Lucky me!

Tom takes a service-oriented view of the (bigger-than-an-organisation) enterprise and suggests mapping participants and the services they provide to each other. This is not far from considering contributors, their responsibilities and their collaborators in fulfilling these responsibilities as Ruth suggests in the field of software architecture.

(This is about CRC cards as proposed by Cunningham & Beck, although they used it in a narrower contexts of class-responsibility-collaborators).

Both Ruth and Tom emphasise the importance of being clear about why we do what we do in design and architecture. In this context, Ruth extends CRC to CRC-R: contributor – responsibility – collaborator – rationale.

(You might want to make an association to architecture decision records here, too.)

In talking about service activities, Tom asks the question “What with?” and points out that the assets we use, work with and work on might be of different kinds. Information or data are certainly important assets in the field of digitally-supported services, but by far not the only kind.

I tend to call the assets objects. This works nicely when realising that the contributors (or actors) are subjects and the responsibilities are usually expressed as verbs, which leaves with with subject – predicate – object. Grammar for the win, and a hat tip to Alistair Cockburn and his discussion of use case titles in Writing effective use cases and beyond.

Update 2019-12-14: This separation of a system’s acting elements (contributors and collaborators) and the passive elements acted upon (objects) mirrors Archimate’s distinction of active and passive structure.

When we talk about doing stuff, we need to ask (and answer) the question: “How well?” In other words, we need to talk about quality of service or the properties we want in a service. This question keeps showing up in Ruth’s and Tom’s work, too. Unfortunately, it is too often neglected in situations I encounter. Various schemes of quality attributes can help in this context.

Bringing this together yields CRCOP-R. As an acronym this isn’t very catchy and as a straightforward application of prior art to an existing approach it certainly isn’t a breakthrough.

Nonetheless, thinking in such terms has worked for me — from very high-level business-focused conversations in the very early stages of initiatives via conceptual solution design to fairly low level functional and data modelling work. It might work for you, too, just keep in mind that the different aspects rather than the acronym are important.

This sloppy blog post doesn’t do justice to Ruth’s and Tom’s work…go to the source to see what they’ve been up to.

Shaping software development teams #3: autonomous teams vs. technical integrity of shared components

This is a follow-up to Initial post at

There are those day where I’m not sure why I bother writing. So I have tried—and failed—to provoke a discussion in this series of posts using quite a few words. Turns out, Simon Brown (of C4 Model fame) can do it in a single tweet:

Autonomous feature teams tend to weaken technical integrity of shared components

While the discussion on my blog isn’t happening, I hope that this Twitter thread will trigger an interesting discussion and yield valuable insights.

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.


Graves, T. (2010) Mapping the enterprise.

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.

The service concept revisited #2: service name and organising idea

Much has been written about the importance of selecting good names for things so that I probably don’t have to write much here. Just keep in my mind that the service name will be used very frequently, so taking time to find a good name or even changing an existing name to something better will pay of quickly.

The organising idea is the briefest meaningful summary of what constitutes the service under discussion. It is our first opportunity to communicate intent. A single sentence, perhaps even only a phrase, will often be sufficient.

To Johnston & Clark (2005), the organising idea is “The essence of the service bought, or used, by the customer.”

I’ve written about explicitly stating intent on my old blog before. First and foremost, it allows others to make independent progress toward a larger objective.

Live tweeting from London Lean Kanban Days 2019, Tobbe Gyllebring shared this:

That’s much nicer and much more powerful than what I used to say. Going forward, I’ll just borrow this:

Clarity of intent enables autonomous aligned action.

— Karl Scotland (paraphrased) via Tobbe Gyllebring

I like the notion of an organising idea: What is the fundamental idea that we should organise everything else around? Or even better, that we should let everything else (and everyone) organise around?

See The service concept revisited for context and for links to related posts. Interested in exploring this further? Please get in touch, I’d love to hear from you!


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

The service concept revisited


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.

I look forward to discussing how the service concept works nicely with the things Tom Graves is doing (see his Toolsets for enterprise architecture overview) and, particularly, his Enterprise Canvas.

 Watch this space for updates…but don’t hold your breath.

Interested in the idea of a well-defined service concept? Let’s talk, please!

Other posts in this series

Related older posts


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.

Not having all the answers

We thought that we had the answers
It was the questions we had wrong

 — 11 O’Clock Tick Tock, U2

I’m afraid I’ve been a bit of a disappointment to some of my clients and to some of my managers. Rather than dropping into a situation and having the right answer to the issue under discussion, I tend to ask questions. Many questions. Way too many questions. And it’s getting worse with age.

Why does he ask all these questions? Isn’t he an expert?

Truth be told, it hasn’t always been like that — but the result’s weren’t always pretty. I can provide an answer quickly even today, but this is probably not a good answer to your question. At least not to the question you should be asking.

I can’t know what that question is until we’ve had a good conversation. Even better, you might be able to decide what that question should be during or after our conversation. And while we’re at it you might be able to determine what a good answer to that question is, the one that considers the specifics of your situation — which you understand so much better than I ever could.

I’m with you all the way on this journey. I’ll try to ask smart questions, give you food for thought, identify issues and risks, but also opportunities, probably make some suggestions or recommendations. And I’ll tell stories about similar or related things that I’ve seen, of things that worked and things that didn’t.

We’ll explore a situation together and co-create insight.

I’m lucky that I meet more and more people — clients, managers, colleagues, partners — who value this approach.

Ruth Malan has a somewhat related Twitter thread right here.

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.