October 13, 2009

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!

October 5, 2009

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:

f:x\rightarrow x^2 + 1

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'?

September 8, 2009

Graphics in BiZZdesigner 9.1.x and up

Good visualizations of models are essential in communication. I'm currently working in a multi-disciplinary project. One of my tasks is to write process models. Unfortunately, models are becoming increasingly complex (I hope to be able to simplify them again soon) so I was looking for a way to make some things a little more clear by adding visual effects to the BiZZdesigner models.

One of the things I wanted to do is to change the icons of triggers that are time-related to a clock. In the 9.1.0 version I found the following solution:

step 1: preparations
First, create a profiles-folder ...\BiZZdesigner-profiles. The documentation explains that this folder should contain an nls folder which, in turn, should contain folders named nl and eng.

step 2: TimeTrigger.mpd
In your profiles folder, create a TimeTrigger.mpd file with the following content:
PROFILE TimeTrigger {
assignable to Trigger;

string Documentation;
};
the documentation is not strictly necessary but seemed like a good idea.

step 3: editorsettings.mpd
Locate your BiZZdesign installation directory (usually in c:\ProgramFiles) and copy the editorsettings.mpd file from the data subdirectory to your profiles directory. Change the line
HIDDEN PROFILE EditorSettings{
to
HIDDEN PROFILE MySettings extends EditorSettings{
now locate the section named "Hidden Presentations". Update this section to read:
// add visualisation of time-triggers
{ name:'TijdsTrigger',
font:{ nm:'Arial', pt:10, i:false, b:false, u:false },
foreground:{ R:0, G:0, B:0 },
background:{ R:255, G:255, B:255 },
iconfile:'Time.png' }
step 4: update the metamodel
From the local installation directory, copy the MetaModels folder to your profiles directory. Create the following directory structure in the Amber subfolder:
Amber\
..\Viewpoints\
..\data\
..\res\
..\nls\
..\en
..\nl
dump an image called Time.png in the folder named res. Make sure this file is not too big (I'm not sure yet what the maximum size is but I found out the hard way that this matters, a lot). Now you're basically done:

Step 5: test!
Fire up your BiZZdesigner application and make sure the profiles are loaded (check the application settings). Once they're loaded, create a trigger. In the properties, under profiles, select 'TimeTrigger" and watch the magic! Here's an example image of the result

August 18, 2009

On the definition of architecture

I've recently blogged about my view on (enterprise) architecture (see e.g. here and here). In this article I'll investigate the definition aspect of enterprise architecture in more detail. As a word of warning: I'm not going to propose yet another definition for the concept of enterprise architecture. For those who find such a discussions interesting, have a look at thispost on Erik Proper's blog, and make sure you notice the comment by Hans Bot.

The IEEE 1471-2000 definition of architecture is as follows:

Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.

In this presentation, Richard Hill gives a good definition for the terms used in this definition:

  • fundamental organization means essential, unifying concepts and principles
  • system includes application, system, platform, system-of-systems, enterprise, product line, ...
  • environment is developmental, operational, programmatic, … context of the system

Defining these things so strictly gives us, architects, the feeling that we're doing something rational. That terms mean the same thing to everyone. That Enterprise Architecture is, somehow, objective. To many, architecture is indeed about providing rational arguments about enterprise transformation. It is how I use the concept of architecture in my work as consultant - at BiZZdesign - also. However, theoretically this does not add up. As a scholar, I find that disturbing. The point is that architecture, by definition, is subjective. Here's why.

First of all, when adopting IEEE 1471-2000, we assume that all enterprises to be systems. I've recently had a few interesting debates with systems-thinkers who indeed assume the world to consist of systems, be it closed technical systems or open social systems (as a side note: in western society this seems to be the predominant view of the world indeed. However, why not see enterprises as organisms?). The question, then, is: what is a system?

Following the FRISCO report (highly recommended), a system is defined as follows:

A system is a special model, whereby all the things contained in that model (all the system components) are transitively coherent, i.e. all of them are directly or indirectly related to each other form a coherent whole. A system is conceived as having assigned to it, as a whole, a specific characterisation (the so-called "systemic properties").

In other words, a system is a model. FRISCO defines model as follows:

A model is a purposely abstracted, clear, precise and unambiguous conception.
A model denotation is a precise and unambiguous representation of a model, in some appropriate formal or semi-formal language.

Thus, FRISCO makes a distinction between abstract models, and 'tangible' model representations. A conception, in FRISCO, is:

A conception is a special actand resulting from an action whereby a human actor aims at interpreting a perception in his mind, possibly in a specific action context.

The list of definitions goes on and on, building a solid framework for 'thinking in terms of systems'. Summarizing, FRISCO asserts that people view the world (perception), make sense of it (conception) and through the process of summarizing, focus, et cetera, form (mental) models. Even more, systems are defined as a special case of models.

Coming back to the topic of this blog post: the above implies a second layer of abstraction. First of all, seeing the world in terms of systems is a choice. Secondly, systems are 'in the mind of the observer' and therefore inherently subjective. Surely, by communicating about our mental pictures of the world, we can attempt to 'synchronize' our world views but still.

To complicate matters further, there's a third layer of abstraction involved here. IEEE 1471 asserts that architecture is about the fundamental organization of systems. What is fundamental is, of course, also in the eye of the beholder. This means that, when discussing architectures, we're really working at an abstract³ level.

The practical consequences and relevancy of this blog post may seem low. Admittedly, the post is theoretical indeed. The point, however, is that architects should be very aware of the fact that they're working on an abstraction of an abstraction of an abstraction of something in the real world. Changing a line in an architecture diagram, or inventing a new principle doesn't alter the real world!


August 7, 2009

How Google’s strategy fits the architecture of my life


Some claim, with reference to many recent product launches, that Google is hardly affected by the current economic crisis. Whether this is true or not, I did recently realize that Google is a big part of my (digital) life. In this blogpost I’ll briefly explore “the architecture of my life” and relate it to Google’s strategy.

Enterprise Architecture

The concept Enterprise Architecture (EA) means different things to different people. In an earlier post I already briefly explained my view on ‘architecture’ as a concept. Summarizing:


· Definition dimension - Following the ANSI/IEEE Std 1471 :: ISO/IEC 42010 standard: system have an architecture, whether we choose to document it or not. To put it differently: architecture is a property of the system, most notably its ‘fundamental organization’ as well as ‘the principles underlying its design and evolution’.

· Documentation and communication dimension - Architectures may be documented. Typical forms of architecture documentation consist of models (diagrams) and principles. The Archimate language has recently been adopted by the Open Group as a standard language for architecture diagrams.

· Use dimension - Insight in the architecture of systems can be used in changing systems; either using an organic (bottom-up) approach or a systems engineering ( top-down) approach. This implies that clear goals must be articulated for architects. Frequently these goals pertain to effectiveness criteria.

· Process dimension - In changing systems (according to predefined goals), architects tend to follow a specific approach. This ‘way of working’ aspect frequently involves figuring out what the current (IST) architecture of the system under consideration is, what the to be (SOLL) architecture of the system should be, and planning ‘migration’ from one such state as another. The TOGAF ADM, also by the Open Group, is considered to be the industry standard with respect to this dimension. However, it has also attracted a lot of criticism, mostly pertaining to the fact it ignores the social complexity of enterprise systems (i.e., the human factor).

My life from an architecture perspective

Describing my life from an architecture perspective could be an interesting task indeed. Following the above mentioned definition, this would require – among other things – to answer questions such as: what is the fundamental organization of my life? What are the principles governing my life? Since this could potentially require quite a bit of explanation, I’ll stick to the short version here (more info can be found on my personal website).


The above diagram illustrates, in the Archimate language, some aspects of my life. First of all, I am married. This is modeled as an assignment of the actor ‘Bas van Gils’ to the ‘husband’ role, which is part of the ‘marriage’ collaboration. The joint responsibility of husband and wife (we have two kids) is modeled as the assignment of the marriage to the function ‘take care of kids’. In a similar fashion, the fact that I’m also an academic who writes paper is modeled using a role which is assigned to the process ‘write papers’. Surely, scholars sometimes read papers as well, but I’ve left this out of the model for now.

Furthermore, the process also includes some information about my use of technology. In the process of paper writing, I use two types of functionality which are modeled as application services: ‘bibliography management’ and ‘digital library’. For the former I use the ‘BiBTeX’ application, for the latter I use ‘Google Scholar’. These relations are modeled using the ‘realization relation’ from Archimate. Similarly, the diagram also shows that I tend to use ‘online communicaton’ services (most notably Google Mail and Google Talk) as well as ‘telephony’ services. For these I use the devices ‘work phone’ and ‘home phone’.

Obviously, this is only a limited subset of what I am all about. It does not, for example, include my love for the bridge game, or my interest in many different types of music. Nor does it show that I used to fiddle with linux technology a lot in an attempt to stay in control. In terms of architecture terminology, I used to adopt the principle that I should install and maintain software systems with respect to online communication whenever possible. As a consequence, I had my own web server with a private domain, hosting a blog, E-mail, photo gallery and so on.

I still have the server, and it still hosts a (personal) blog. Coming back to the central theme for this post, though, I’ve noticed that Google has taken over many of these functions as illustrated in the above diagram.

This brings me to the central theme of this post: why is that? Why have I abandoned the above principle in favor of the principle Use Google’s services rather than doing it yourself or seeking other alternatives. In the next section I’ll firstly present a brief overview of my understanding of Google’s strategy. After that, I’ll relate this discussion to my personal situation.

Google’s strategy

Like (enterprise) architecture, strategy means different things to different people. It is frequently equated with ‘plan’, as in ‘a strategy to get from here to there’. In the field of strategic management, however, strategy relates to positioning the firm with respect to its environment (side note: yes, I know that the two interpretations are strongly related. In order to conquer / maintain a certain competitive position one has to execute certain actions which can be planned. This, however, is the crucial point: strategy is frequently incremental and can only be analyzed in hind sight).


The above figure shows (my interpretation of) the business system of Google. The business system concept (as explained in the book “Strategy Synthesis”) is relatively straightforward. The central concept in business level strategy is ‘sustainable competitive advantage’. In order to study the sources of competitive advantage, one studies the business (product x market combination) in terms of resource base, activity system and product offering.

The figure shows that Google has a huge list of products associated with its advertisement business. These products include search, google mail, blogger, etcetera. The revenue model for this business is simple: place relevant advertisements in the tool that is used. For this, Google mainly uses its AdWords program. According to its financial statement, more than 99% of Google’s revenue comes from its advertisement business. This implies that less than 1% of its revenue comes from selling (business) software and such.

There are many synergies to be reaped between the two businesses. For example, at the resource base level Google can easily use shared infrastructure (such as its data centers and impressive network all over the world) as well as its staff (side note: people are not assets, as Tom Graves recently explained. However, in the business system model they are positioned in the resource base). With respect to synergies at the level of its product offering, it is interesting to see that Google appears to be mimicking Microsoft’s strategy in the 1990s … but with a twist. In the 1990s it seemed that Microsoft was all too happy that many people used its software (windows and office) at home – not always legally. As popularity grew, more and more people wanted to use the same software at work which resulted in more business licenses sold and, hence, the dominant position of Microsoft in the area of office software.

Similarly, to many ‘home users’, using Google’s products is free. My guess is that Google wants to build a strong reputation, get people hooked to its products (and sell a lot of advertisements in the process) so that, hopefully, in the future many licenses for its other tools can be sold.

Google’s strategy & the architecture of my life

Having briefly discussed the ‘architecture of my life’ as well as my interpretation of what’s going on at Google, it is now time to address the central question for this post: how does Google’s strategy fit my life. To answer this, I’ll briefly go into some of the principles I attempt to adopt as well as Google products that I like.

First of all, notice that there already quite a few Google products in the Archimate diagram above. I wondered why this is the case. After all, I used to ‘do everything myself’. Some examples clarify why I switched. I’ll readily admit that I am pretty much an E-mail junky. I check my E-mail several times per day. Usually every hour at least. I really wanted to have access to my E-mail no matter where I am. Since it is not always possible to log into my own computer (using ssh) and use my favorite mailer (mutt), I was desperately seeking alternatives. Given Google’s incredible spam filter, an alternative was quickly found. Added advantage is the mobile Gmail application, making it possible to check my E-mail on my cell phone.

Similarly, I used to host our family picture album on my own server. However, I noticed the security aspects of this system were seriously flawed. Even more, I found out that I was quickly running out of disk space. A switch to Google’s Picasa solved this for me. The list goes on.

One of my recent annoyances is the fact that I’m constantly carrying two mobile phones around. The basic principle is simple: I carry one phone only for business and personal communication including voice and SMS. I quickly learned that dual-sim phones are rare, no solution to be expected there. Again: enter Google. Google recently announced Google Voice: an impressive service which allows you to route phone calls and SMS messages to any desired phone depending on who is calling, time of day, and so on. Just what the doctor ordered as it helps me follow the above principle. Unfortunately it is not available in the Netherlands just yet.

Another interesting aspect of digital life is document management. I currently story my (personal) documents on a secured repository (using subversion) to be able to easily synchronize between computers. Not an ideal situation but it works. It’s no big secret that Google is on the edge of the cloud computing movement. It’s online office suite is far from perfect but it has the advantage of (a) having all your documents online, and (b) being able to easily synchronize using Gears. And to top it all off, the upcoming Google Wave tool integrates all of the above.

Referring to the earlier analysis of Google’s strategy, it does seem that Google develops the tools that makes “everyone’s” life easier and offers them for free. In the process they make a lot of money. Sure. Eventually, they’ll probably also sell a lot more software. Also, a lot of the privacy pundits are all over Google as they’re worried that Google ‘knows too much’ about our lives. Good, it keeps Google on its toes. From my point of view: I’m happy that Google helps me live my digital life.

July 9, 2009

book review: enterprise architecture - models and analysis for information systems decision making

I have just finished reading the book Enterprise Architecture - models and analysis for information systems decision making. Several people have recommended this book to me in the past. The book is interesting indeed, even though I think the main title (Enterprise Architecture) is pretty much off. The subtitle is more relevant: the book covers "informed decision making" relating to the information systems of an organization.

The first few chapters give a rough overview of the history of computing which is a good read. Next, the methodology of the book is introduced and presented in more detail in the later chapters. Roughly speaking, the authors take the point of view that decision making about information systems can / should be rational which is defendable. Following this line of thought, a graphic notation that supports decision making (based on causal analysis) is introduced. A small example from the book is included below:

In this notation, the diamons represent goals and the ovals represent 'chance nodes'. The notation also includes rectangles which represent decision points. As for relations, the arrows represent causal relations (a influences b) whereas the relations with a filled diamond represent composition.

The notation reminds me somewhat of the quality scenario's that are developed by the SEI. E.g.

This notation is applied to business goals, information systems goals, IT organization goals etcetera. It is quite interesting to see how this works. Also, the relation to Enterprise Architecture is obvious, eventhough I think the point isn't made explicitly in the book. A missed opportunity.

All in all I think the book is a good read. It is well written and covers interesting topics despite the misleading title.

June 11, 2009

PRET'09

Today was the Practice-driven Research on Enterprise Transformation working conference in Amsterdam, held in conjunction with the CAiSE conference. This working conference was presented as an 'industrial event' and a good attempt at bringing together academia and industry. In my opinion, we should do that more often to prevent the two world drifting apart too far.

One of the most interesting presentations was by Will vd Aalst on BPM. He presented research (with a demo) where he showed that process models can be constructed automatically by examining log-information from live information systems. This allows for similation and even TomTom like functionality (where am I in the process, what is the expected time to finish?). Good stuff.

I got several interesting new research ideas out of the conference. Stay tuned: I hope to publish them here soon.