Monthly Archives: May 2014


“Courage is not the absence of fear; rather it is the strength to overcome fear.”

Warfighting, United States Marine Corps

I’m about halfway through this little book. There is a lot of wisdom in there even for people like me whose profession is not war. In other words, if social interactions are your business, this book may well be worth reading.

Too many errors?

Udi Dahan wrote a very helpful and enjoyable paper in which he Clarified CQRS (command-query responsibility segregation). While explaining the benefits of CQRS he planted a somewhat disturbing thought in my mind:

We may be resorting too readily to reporting errors to our users.

In other words, we may be telling our users “There’s something wrong here. You deal with it!” too quickly, too often and too readily. In many cases, appropriate alternatives are fairly obvious and probably quite implementable.

(As a side note, many of these alleged error conditions can be traced back to the failure to plan for the concurrency of events and actions in real life (i.e. we’re not talking thread management here) as Udi pointed out. That’s something to think about in another post…)

Is calling a situation an error and reporting it to the user the easy way out? As developers, are we yielding our responsibility to achieve meaningful outcomes when processing user requests to readily? What do we fear in this context?

I resolve to question decisions to treat a situation as an error and report it to a user more thoroughly in the future. That may well take some courage.



Whole-of-system architecture

Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.

When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.

Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.

Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).

Having gotten the above out of my system, I can now start to sort it out. Would you care to help?

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:

Scaling down my problems

Recently someone said something like the following somewhere (on Twitter? A link would be much appreciated):

Instead of scaling up your team, try scaling down your problems.

How would scaling down large problems work? Wouldn’t we have to solve large problems by composing the solutions to small ones? Wouldn’t we need another small team for doing this composition? Wouldn’t this bring us full circle to some sort of large-scale agile approach? Wouldn’t this be exactly what we set out to avoid?

How do two-pizza teams collaborate? What about coordination? Direction? Guidance? Funding?

In brief, how do I actually, concretely, practically scale down my problems in enterprisey e-commerce environments? I don’t have the faintest clue, but I’m bloody well going to find out. I’m done with scaling up!


OOP, FP and UX

A seemingly growing band of programmers with an object-oriented programming background are beginning to take an interest in functional programming. I’m one of them.

Functional programming helps recovering object-oriented programmers to re-develop their awareness of users’  interactions that apply functions for a purpose in a given context. Well, at least it helps this one doing so. (And this is not a rant against object-oriented programming, design or analysis.)

With my new little hammer, I see nails everywhere, even in some unlikely places: In some discussions on user experience I have experienced an extremely strong focus on designing individual pages (and page fragments). I was surprised I had to make the case for exploring content architecture and content strategy concerns against some user-experience designers in some situations. What puzzles me these days is that I run into situations in which I have to make the case for exploring interactions and flows on and across pages.

Are the situation of some object-oriented programmers and the page-focused user-experience designers similar? Would such user-experience designers benefit from re-developing awareness of users’ interactions that apply functions for a purpose in a given context? Would starting with user journeys, interactions and flows be beneficial?

If this sounds like rant against user-experience designers, may I remind you of the second paragraph? I went as far astray as anyone…

Functional flow and structural composition

Architectural descriptions of software-intensive systems often begin with a description of the system’s structural composition. This technical inside-out perspective has made me feel uneasy for quite a while.

In contrast, I like to take an outside-in perspective and begin describing a system by discussing its purpose and the context in which the system will be used in pursuit of this purpose. More concretely, I like to talk about a system’s functions and how work flows through the system when exercising these functions. Working mostly on e-commerce sites, this often means describing user journeys and interaction flows.

And eventually I describe which structural elements collaborate in order to realize these functions. At times, the required mapping of functions and interactions to interacting components and collaborating objects feels tedious and strained.

As I’m learning more about functional programming, I wonder whether describing the architecture of a system built using a functional programming approach will feel more natural? Will the rift between the functional and the structural perspectives diminish as I gain experience with composing functional solutions to non-trivial problems? Or should that read functionally decomposing non-trivial problems?

Related posts

Also see Function & information: a useful duality? on my previous blog, On Service Design.

Networks of independent agents…and coffee

A few days ago, Laura Colvine said this on Twitter:

David takes on Goliath – Cups: A Coffee Startup Taking on Starbucks

The link pointed to an interesting and well-written article by Alison Griswold titled “Cups: A Coffee Startup Taking on Starbucks“.

In brief (and much less well-written than the original), the story is approximately this: Cups, an Israeli startup, offers bulk subscriptions (5, 10 or 20 cups) and monthly all-you-can-drink monthly subscriptions to customers of participating independent coffee shops. It uses mobile app technology to facilitate coffee shop discovery and location, subscription management and payment. Cups pays the coffee shops per cup, albeit at a highly discounted price, but assumes the risk associated to high consumption by monthly subscribers.

I like this idea very much: I like how technology is used to facilitate an idea that mostly plays out in the “real” world. I like how this idea seeks to level the playing field for small independent agents in a highly contested place. I like how the independent agents’  individual strengths and characteristics are preserved in this scheme. I like how this sustains and maybe even enhances diversity in this difficult environment.

(I have no problem with Starbucks or large corporations. This is not a rant against them. But I also value diversity very much.)

I wonder whether, no, I’d bet that similar approaches could work in other contexts. What type of business will be next?

Note: I understand that Cups can be understood as a shared platform and the independent coffee shops as pods in the sense that Dave Gray wrote about in The Connected Company. Cups and the independent coffee shops are participating in a shared enterprise as described by Tom Graves in Mapping the Enterprise (and his other books and his blog).

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.