On relation types in ArchiMate

ArchiMate is quickly becoming the industry standard for creating enterprise architecture models. Its meta-model revolves around 3 layers (business, information/application, and technology/infrastructure). The language is well suited for expressing the 'structure' part of architectures of enterprises. For example:

• actor is assigned to role
  i.e. an actor is is able to fulfill a role
• role is assigned to process
  i.e. actors fulfilling a role execute the assigned process (or possibly: are allowed to execute that process if that is the preferred interpretation)
• application component realizes application service
  application service is used by process
  application components offer their functionality to the (business) environment by means of services. The used by relation expresses that (actors involved in) processes use the functionality described by these application services

By using different types of components and different types of relations, architects should be able to craft fairly precise models on how the enterprise is structured architecturally. So far so good. But what if a relation type is missing? I.e., you want to express something for which there is no natural ArchiMate'ish expression?

Naturally, ArchiMate is setup to be a language that can easily be extended, either by adding concepts / relation types or by using profiles to add meaning to concepts / relations. However, in consulting assignments I have found that people are reluctant to do so, and tend to stick to the default set of concepts and relations.

Last week I ran into a situation where I was doing a session on the ArchiMate metamodel for a specific client. We ran into two situations where a "governs" relation type was required:

• actor governs actor
  to express the fact that, for example, one department governs another, which is intended to mean that it oversees / facilitates the other department
• process governs actor
  to express the fact that, in a context where most processes are executed automatically by a machine (computer system), one process governs the other. More specifically, it triggers, pauses, updates information, reads status information, etcetera

other uses for the same relation type are easy to come up with. The question I am struggling with is: how would you model this, using default ArchiMate?

The meaning of 'organization'

A little while ago I was faced with a writing challenge. I had to use the word 'organization' in two different meanings in a single document. As I got stuck, I asked a renowned colleague - Tom Graves - for help. On his blog, Tom posted the following response to my question. As I figured it would be interesting for a broader audience we decided to cross-post.

---

Had an interesting question come in today from one of my Dutch colleagues, Bas van Gils:

I have to write a document and I’m kinda stuck. The issue with the document is that I want to make a distinction between ‘the organization as in: “the way in which some system / department / enterprise is organized” and “the organization as in: the legal entity”. I’ve had this issue before and I can’t figure out how to deal with this properly in documents. It just feels awkward to say Organization (with capital) for meaning one and organization (without) for meaning two…

Any thoughts?

This is a real doozy of a problem that really shows up the limitations of English as a language. It’s hard enough for native English speakers to resolve, let alone those who only use English as a business-language…

I ain’t no linguistics specialist, but as I see it, the respective contexts for the two meanings are as follows:

• Meaning 1 (’the way something is organized’): a nounal expression of the verb ‘to organize’, moving from the present-participle (’organizing’) to the adjectival past-participle (’organized’) to the verb-as-condition (’organization’) [there'll be a proper linguistic term for this nounal form, but I haven't a clue what it is ]
• Meaning 2 (’the legal entity’): a label for an abstract entity that is structured (’organized’) in some defined way

To me, Meaning 1 is still more related to the verb, a temporary condition of something dynamic (”the act of organizing”), whereas Meaning 2 is definitely a noun, something static. In Meaning 1, the structure could change – the outcome of a ‘reorganization’ – and it would still be ‘organization’; whereas Meaning 2 is defined and delimited by its legal boundaries, so if those were to change, the previous ‘the organization’ would cease to exist.

[A quick check at AudioEnglish.net throws up a total of seven meanings: Bas's 'Meaning 1' is somewhere between their 1 ("a group of people who work together") and 2 ("an organized structure for arranging or classifying"), whereas Bas's 'Meaning 2' is probably closest to their 3 ("the persons or committees or departments etc who make up a body for the purpose of administering something"). The built-in thesaurus in MS Word isn't much help, either. Overall, it's all too obvious that English is a confusing mess. ]

I would probably try to juggle the phrasing so that I can avoid having to put the two meanings together in the same sentence, but I can see plenty of circumstances in which there’s no way to get round it.

If I did have to use both meanings in the same sentence, without any other option, I might well use Bas’s capitalisation kludge, though I would capitalise Meaning 2 rather than Meaning 1: “the organization of the Organization”. But as Bas says, it’s awkward and ugly: and whilst, to a native English speaker, the alternative uncapitalised “the organization of the organization” would probably be clear enough, it might not make sense to native speakers of other languages.

But as Bas again indicates, it gets messy when we try to distinguish the two meanings once we’ve bundled them together. And going back to the present-participle – “the organizing of the organisation” – is probably uglier still, although technically correct in English.

So the short answer is that I don’t see any easy way round this one. Sorry…

Anyone else have any better suggestions?

Archimate and type-instance

A while ago I blogged about why Archimate needs type-instance. The "specialization relation" already exists, but I hardly ever see it used consistently at the business process level. However, it can be quite convenient to use this type of relation when modeling generic processes which can be specialized for specific circumstances.

For one of my clients I am currently working with a group of architects who wish to model such a thing. The problem they face is the following:

• clients of the organization report changes in their situation (e.g. moving abroad, getting married, etcetera). This is called a "customer event" and is modelled using the business event type in Archimate
• customer events are always dealt with in a similar manner. In other words, there is a generic "handle customer event" process
• depending on the event, different products may be applicable to the client. This implies that, depending on the event, different versions of the handle customer event must be assembled

I've been working on different ways of modeling this. What I've come up with so far is this solution:

The model uses a color-view to show which processes / events are generic and which are specific. The idea is that specific events (e1, e1) trigger specific processes (handle e1, handle e2). Even more, specific delivery processes are "plugged in". The type-instance relations between events and the different processes are "modelying hygene" that, for example, make sure that the plugged in processes are connected to their generic counterpart (process event).

Note: in more realistic settings I wouldn't use this view to inform stakeholders as it probably contains too much detail. It does show the structure that I'm thinking off, though.

Google vs news corporations

"Information wants to be free" is an adage that is frequently quoted these days when discussing the question: should we (the public) pay to see information online or not? I guess the information itself doesn't really care whether it is free or not. After all, information is in the eye of the beholder and, thus, an interpretation of online data.

Up until now, it seems that Google has taken the position that its search engine should show searchers whatever it can find on any given topic, whether access to the source is free (as in: available without registration) or not. As of yesterday, it seems that Google has changed its policies and has given in to the powerful lobby of traditional media. See e.g. this article from the L.A. Times

To make this more concrete, consider the case where you're searching for the string "google access news media". Let's say that there are 100 webpages available on this topic, half of which require a subscription. Let's consider this situation from different perspectives.

From the perspective of searchers: whether you want to see the 50 pages that require a subscription depends on your personal preferences. Some searchers wouldn't mind subscribing to see a well-written article by the NewYork Times. Others would. In other words, the aptness of the NewYork Times article - which requires a subscription - depends on the individual searcher (see e.g. my dissertation on the topic of Aptness on the Web for more details).

From the perspective of news agencies: news agencies have traditionally operated from a business model where selling (access to) content is the primary revenue stream. This originated from the old days where physical newspapers were sold. The transition to the Web has been difficult as the competition from ‘free’ news items (in the Netherlands from e.g. nu.nl) is high. Search engines and other portals with access to news are, to say the least, a major source of concern for the traditional news media.

In short, the old business model doesn’t seem to work anymore and should be replaced. Having not yet found a good new business model, news agencies hang on to the old way of doing things.

From the perspective of Google: Google is in a tight spot. On the one hand, searchers benefit mostly from high quality content which may include (references to) news items which require subscription. For example, some searchers may not want to see articles that require subscriptions at all, whereas others wouldn't mind as long as it's obvious that they have to subscribe in order to see the content. On the other hand, Google benefits from a good relation with news agencies which may be a source of revenue in the form of advertisements.

It appears that Google has bent for the power of the dollar, resulting in limited access to content that used to be free. Several interesting questions remain:

• What will be the impact on user perception? J. Random Searcher has grown accustomed to the fact that Google is a one-stop-shop for online content, be it in the form of websites, blogs, or news.
• Will newspapers really benefit from the new situation? I personally doubt it as, in my busy life, I just don’t have the time to surf to the websites of many different news agencies to search for a specific bit of news.
• On a more technical level, what will Google do with its cache? So far, the cache made it (sometimes) possible to see content which may have required a subscription in its original form. What will they do now? One option would be to provide access to cached versions of news after e.g. 2 weeks.

So far I’ve seen many blogposts and media cover this story. The topic seems to be buzzing on Twitter and other social media also. I’m not convinced that this is a good move by Google. But then again, I prefer (access to) information to be free! I can't help but feel that Google trails behind 0-1 in the 'battle' with news corporations.

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!