What architects can learn from kids

Introduction
As my kids start growing up (in a hurry!), one of the things that amazes me is how well kids can deal with complex situations such as learning to speak, learning to walk, jump, and ride a bike, or how to interact with others. Even more, kids seem remarkably resilient in dealing with changes and manage to find ways to adapt to new situations. Of course there are exceptions; we all know the kid who crawls in a corner and hides in the face of change. Generally speaking, this does not seem to be the case though. Having kids of 2 and (almost) 6, it is amazing to see how easily the youngest seems to wrap everyone around his little finger, and how well adjusted the oldest is already when interacting with adults. Well, most of the time. And it gets better over time.

Upon closer examination I have learned that the same applies to the inverse situation: I noticed that (my) kids also seem to be able to change / influence their environment when new and interesting possibilities present themselves. For example, when one of my kids found a large box of approximately the size of the DUPLO-house he wanted to build he quickly managed to get rid of its contents and use the box for its own purpose. Good to see that he used the opportunity; but not so good for what was in the box… Also, changes in the setup of our furniture are immediately used for new games (hide and seek) and so on. It’s also fun to see when they deliberately seem to steer conversations in a direction and thus create opportunities for themselves. Interesting, and challenging.

In this blog post I’ll explore this further, and translate this learning process to the world of (enterprise) architects.

Dealing with change
One of the first times I noticed a “smart move” with respect to changing things had to do with building some structure. Big wooden blocks were stacked on top of each other the form something that seemed like a random pile to me, but definitely had meaning for my kids. Due to the way the pile was ‘built’, though, changing it turned out to be a challenge. Basically it boiled down to un-piling the blocks and re-piling them to form a structure better suited for the game at hand. One point for the good guys.

Add a few months and introduce a new form of blocks: DUPLO. When building a structure (such as a house or farm), my kids quickly figured out that there’s two ways of building: (1) built to last and (2) build to adapt to new situations. The first involves stacking the blocks as if they were bricks of a house (i.e. nice masonry). The second involves building separate “walls” which are then placed in the desired form and “glued” together with extra blocks. This makes it easier to re-structure everything by simply removing the glue-blocks. Another point for the good guys.

The next step up involves little electric trains. Unfortunately my kids aren’t old enough to play with that sort of things yet. Soon, I hope. Either way, the thing about playing with trains is that you need rails. These rails come in two types: straight, and bent in a fixed curve. Therefore, given any number of rails-parts, there are only so many forms you can make without the trains ever dropping off the tracks. In itself designing a nice setup for trains is a challenge in itself. This can be learned however. It becomes more interesting when the tracks are placed such that they have to be (re)moved when mum wants to sit at the table to enjoy dinner. The first time this happened I noticed that the situation led to a big argument because the kids were reluctant to remove the tracks. In the end they managed to negotiate that mum carefully put her chair in the middle of the setup and sits real quiet during dinner (in return kids would do the wash up after dinner). Smart move.

The design challenge becomes slightly more complex when things like tree houses are involved since this requires some planning. It wouldn’t be the first time that I’ve seen a tree house built at 2.50m off the ground only to find out that the rope which was supposed to hang down (making it easier to climb in once we get rid of mum’s household ladder) is too short. Oops. Another interesting variation on this theme occurred when a group of kids found out too late that it’s pretty hard to haul certain heavy stuff up into a tree house once “walls” and a “roof” are in place. Oops.

After several attempts, though, I noticed that the group hat split into two groups. The first group had given up and rather than going “up” they went “down” and dug a hole in the ground which was to become their fort. The first group, though, had mastered the skill and went on with even more complex projects still.

This leads to an important distinction: social complexity versus technical complexity

When the going gets tough
Most of the challenges so far have been technical / design challenges. These may be difficult, but they can also be learned. For example, my youngest son has learned to ask for my help when he has stuffed a toy in some other toy and can’t get it out again. Another characteristic of this type of problem is that it is usually possible to recreate the starting conditions. For example, a tree house can be un-built and the materials reused etcetera.

The next step up, I guess, is dealing with situations where we can’t recreate the starting conditions, or where we can’t ask for help for a quick fix.

A first example of this is when more people (and, in our “grown up world”, each with a different stake) are concerned. Consider again the tree house. At first sight, when a group of kids sets out to build a tree house, one might expect that chance of success to be bigger than the situation where only 1 or 2 kids try to do the same thing. This is partly because the bigger group has access to more tools, materials, and insights. This is as much part of the solution as it is of the problem. Any number of things could go wrong: the group can disintegrate on the first sight of failure, kids can withdraw themselves from the project because they simply want to go and do something else, materials can be removed for the same reason, or because parents figured out their tools are suddenly went missing etcetera.

The only way to learn how to deal with these situations is “learning by doing”. Listening to stories told by older / more experienced people (us, the parents!) might help, but only to some extent. Even more, notice that the starting conditions cannot easily be recreated. When a group splits in two, the social dynamics have changed. Next time the same group attempts to build a tree house, the kids that finished the first project will be weary and closely monitor those who dropped out earlier.

Some lessons
The above stories are based on real situations that I’ve seen. Things like this happen around us every day. However, in many cases the “kids” were enterprise architects. The projects didn’t involve building tree houses or train structures, but involved complex IT systems or projects which involved introducing a new way of working and thinking in large organizations.

From what I have seen, most enterprise architects have an engineering frame of mind. Most architects are good at engineering / designing / architecting large complex structures. In other words, it seems that technical complexity is not so much the issue. Social complexity is, at least in our field of work, harder to manage especially since most projects related to enterprise architecture tend to have both high technical complexity and social complexity. Not an easy combination to manage!

On business functions

While reading the book Business Process Management – Concepts, Languages, Architectures (Mathias Weske, 2007. ISBN: 9783540735212) I was once again confused by the term business function which is used differently by different authors in different contexts. In this blogpost I’ll describe my attempts to come to grips with this term. Before diving in, though, I must say that the above book is interesting and very well written. I like the structure and style of writing. I particularly like the fact that quite a few pages are spent giving an overview of (selected parts of) the field from a historical perspective. Given the strong focus on IT, I wouldn’t recommend this book as a first introduction into the field of BPM, though. However, the books seems very useful for IT-professionals who wish to gain a deeper understanding of conceptual analysis of business processes (e.g. IT managers, process architects, developers, JBoss specialists, etcetera).

To divein: to understand the concept of ‘business function’ we must come to grips with the words ‘business’ and ‘function’ first. To me, the word ‘function’ has a mathematical connotation. In mathematics, a function is a special type of relation which couples an element from one domain to exactly one element from another domain. For example:

is a function that maps real numbers to real numbers. I.e., f is a function that transforms a real number into exactly one other real number. It seems hard to apply this notion of functions to business functions, regardless of the definition of the concept 'business' (which is an interesting discussion in itself; it probably does not mean a product-market combination as is common in the field of strategic management). It is likely that 'function' in 'business function' should be interpreted along the lines of "something that achieves a specific goal".

Weske starts his exploration of the concept of business function with Porter's Value Chain Model (see e.g. Wikipedia). In this model, activities are characterized as being either primary or secundary/supporting.

Weske claims that these activities are typically dubbed business functions in BPM literature; a value system consists of a value chain which contains business functions. Business functions can be detailed further using the concept of business processes. This seems similar to the way the business function concept is used in e.g. the NOVIUS method for architecture as well as the ArchiMate language.


In ArchiMate a business function is defined as "a unit of internal behavior that groups behavior
according to, for example, required skills, knowledge, resources, etc., and is
performed by a single role within the organization". This definition implies a second meaning for the business function concept, as illustrated by the following ArchiMate fragment:

this snipplet shows that a business function (A) can consist of one (or more) business processes, and also illustrates that business processes can use business functions (B). An example of the former would be the observation that the business function "financial settlement" has a "collect premium" process. An example of the latter would be the observation that the "collect premium" process uses a "billing" business function.


As always, using terminology can be tricky. I guess that both interpretations work in practice and have no strong preference for either. Has anyone encountered other uses of the word 'business function'?