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!

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

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

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!

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.

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.

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.

Why archimate needs type-instance

Today I attended a very interesting archimate usergroup meeting. The topic of the meeting was ‘modeling across layers in Archimate’. This is a topic that I’ve been wondering about myself for quite some time as somethings are hard to model in Archimate to say the least.

The example problem that we tried to tackle is to model the situation where a company sells books over different channels (web, bricks ‘n mortar) to its customers. One of the things you need to realize before tackling this problem is that different stakeholders require different information and hence different views on the model. But still, as an intellectual exercise it is nice to try to represent the entire model in a single Archimate diagram. A first take results in the classic layered view of a product being offered to customers. The product (a service, in Archimate) is realized by a process which in its turn uses application functions that are realized by some ERP package. So far so good.

Considering the channels, it seems logical to model the ‘physical’ version (where a customer simply wanders into the store to order a book) as a collaboration between the customer role and the internal sales role (associated to a desk clerk). The sales role uses some graphical interface on the ERP system to do her work. Nothing too difficult.

It seems logical to model the web channel as a business interface that is assigned to the product offering (I admit that I used the 1.0 specification for inspiration here). This interface can be assigned to a role (websales) which In turn is assigned to an actor. Moving to the application layer is relatively straightforward: the websales role uses the portal function.

I don’t consider this particularly elegant, but it seems to be the best way to make the web interface explicit as well as connecting to the ‘order book process’. Also, it is more or less symmetrical with the ‘physical’ channel. Another option would have been to let the ‘order book’ service use the portal interface directly. This solution has the problem that it is harder to see the relation with the order book process.

In reviewing this simple example, I learned two things:

· Modeling things like portals where customers (in the environment) interact directly with systems (in the application layer) is tricky if you want to link to in between ‘logical’ processes. More specifically: it seems particularly tricky if you want to represent it in one view.

· The other thing is that there is a lot to be said for ‘type instance’ relationships. In my view, the ‘type’ is the product offering which uses some process which in turn uses some ERP system. The ‘instance’ is the detailed version using some specific channel. As this example shows, it is not easy to do that in archimate currently.

Enterprise architecture as organisational Zen

This is a cross posting from my normal blog, based on a request by Bas. If you would like to post any comments other than for educational purposes, then please do so at the location of the original blog entry.

The way I have learned to understand Zen, is that it is about concentration and focus. By means of meditation, Zen teaches us to focus on the things you really want to focus on, meanwhile allowing us to obtain insight into our inner drives as well as our imprinted reflexes. Whenever we, as average beings, are put under stress, our imprinted reflexes tend take over, taking us away from the things that really matter to us. Instead, we start worrying about how good we are in our jobs, whether our boss likes us, threats to our status in society, et cetera.

Zen helps us in focusing on what is important. It does so by improving our mental discipline by way of meditation. This improved discipline allows us, in our daily live, to be more aware of situations where our mind starts wondering off. Especially when we are put under stress, and the mental reflexes that are imprinted in our mind (based on past experiences and shadow beliefs) take over. Once we have learned to observe such behaviour, we can chose (not) to act upon it, and regain our focus. In doing so, it is also important not to judge ourselves. It's a process of learning and forgiving.

So what does Zen have to do with enterprise architecture? Well, a lot in my opinion. An enterprise architecture, as in, the architecture of the enterprise and not just enterprise-wide IT architecture, is an elaboration of the enterprise's strategy. As such, it can be regarded as an operationalisation of what the enterprise wants to focus on. Using models such as collections of architecture principles, specific design models in e.g. ArchiMate, et cetera, the enterprise's strategy is made more operational. The desired focus is elaborated, and possibly translated into a sequence of intermediary stages offering a short-term to long-term perspective.

This all sounds very nice, you might say, but in practice transformation projects are hard to keep on track with regards to the architecture. More often than not, projects are not in compliance with the focus as articulated in the enterprise architecture. There always seems to be a business driver that allows a project not to comply to the architecture. Usually due to a clash between short-term and long-term interests. Architecture governance is a difficult task indeed.

Interestingly enough tough, there is a strong parallel to the goals of Zen meditation. What does it mean if parts of an organisation allow a transformation project to produce results which are non-compliant to the enterprise architecture? Isn't the wise thing to do in such a case, to identify the discrepancy and then use it to grow as an enterprise? No blame-game, but a trigger to improve the governance needed to execute the enterprise's strategy. Does the architecture really focus on what is essential to the enterprise's strategy? Isn't the architecture too elaborate/restrictive? Is the non-compliance of projects based on a 'reflex' of the sponsors/stakeholders or are they the indication of a shift in strategy/focus? Or is it 'simply' due to a lack of discipline, and is more 'training' necessary (e.g. by means of stricter governance)?

Needless to say that the current economic crises brings about a multitude of organisational 'reflexes' leading to several responses that are not in compliance to the architecture (and strategy). Does this imply a stronger focus of the architecture on the enterprise's strategy, a shift in the enterprise's strategy, or .. is it just a panic-driven reflex? There is a lot to learn at a time of crises!

Traditionally I've viewed enterprise architecture as a means to direct enterprise transformations. I still do, but I now propose to treat non-compliance of projects not as a problem but as a way for the organisation to better understand its focus and improve its ability to stay focused on the things that matter. Enterprise architecture as organisational Zen.

Discussing EA

Several months ago I posted a framework for "thinking about EA". This posting was mainly inspired by my work for the Enterprise Architecture in Practice (EAP) course that I teach for the Hogeschool Utrecht, but also based on several scientific publications that I had read back then. Last week (i.e., several months later) I was discussing this approach with Tom Graves as well as the new group of students following the EAP course and found that this framework missed a key point: there should be 4, not 3 dimensions of enterprise architecture:

This framework is mostly theoretical in nature and can well be used to "talk about EA", e.g. in a teaching setting. In my view, it may also help explaining what EA is and does to prospective clients. Here's how it works.

One of the discussions popping up frequently (not only among architects, but also with other practitioners, researchers and even customers) is the question "What is EA?". Hans Bot already pointed out in response to a blogpost by Erik Proper that we should "stop talking about it and get work done". I couldn't agree more with the possible exception of a teaching setting of course. Hans refers to the IEEE 1471-2000 definition of architecture of software intensive systems which is, indeed, the mother of all definitions. Inpsired by the way xAF distinguishes between a theoretical and practical definition of EA, I observed that "what EA is" seems to depend on which of the other three dimensions is dominant:

• Studied in its own right: the IEEE definition indeed captures the essense of what (the) architecture (of a system) is.
• When taking the documentation / communication perspective, architecture can be seen as a collection of models, principles etcetera. The Open Group Archimate 1.0 standard is important in this respect.
• When taking the process / way of working perspective, architecture can be seen as a way of working to achieve organizational goals. The TOGAF ADM is relevant in this respect.
• When taking the goals / use perspective, architecture can be seen as a consitent way of working (process), documentation and communication to achieve business goals (stated in terms of e.g. efficiency, effectiveness, redesign of processes, business functions etcetera). In this perspective, OMG's BMM is a relevant standard.

I have found that these four dimensions of enterprise architecture form a sound and logical basis for discussing architecture. Questions and suggestions for improvement are welcome!

Process standardization & EA

The april edition of Harvard Business Review (HBR) had an interesting article with the title "when should a process be art, not science?". One interesting aspect of HBR articles is the fact that they have an "idea in brief" section. For this particular article this reads:

• Ironically, process standardization can undermine the very performance it's meant to optimize. Many processes work best when they're treated like artistic work rather than rigidly controlled.
• To decide if a process should be more scientific, look for these conditions: inputs to the process are variable (for example, no two pieces of wood used in making piano soundboards are alike), and customer value variations in the process output (each pianist appreciates the distinctive sound and feel of his piano)
• If a process is artistic, invest in giving employees the skills, judgement, and cultural appreciation to exel in variable conditions. Ritz Carlton, for example, recaptured its reputation for unrivaled service when it empowered employees to iprovise their responses to individual guests' needs.

This idea seems sound, yet not terribly novel. Still, I think it is important to keep this in mind, especially for enterprise architects, especially since architects tend to see (process/ information system / infrastructure) standardization as the holy grail.

Another interesting aspect of the article is the way artistic processes are identified. According to the authors, processes with high variability and positive value of output variations to customers are artistic (the three other types identified in the classic 2x2 matrix are: mass customization, mass processes, and nascent of broken processes). Unfortunately, the article prescribes a 3-step process to deal with artistic processes...

As a side-note: software development is identified as an artistic processe wince writing code for a new application often involved iterating with customers to learn how to refine the program to adress their needs, as well as decisions on which corners can be cut.

An interesting question in this respect: what do architects bring to the table to deal with processes which should be treated as "artistic"?

Getting results

One of the frequently debated topics in many companies is the question: what do architects really do? This is partly the result from the fact architects tend to work with abstractions. Another important aspect, however, is the fact that "doing architecture" has the connotation of a lot of talk resulting in a stack of obscure diagrams. These are, of course, important but they shouldn't be confused for being the architecture. Simply put, all systems have an architecture, whether it is documented or not. Diagrams "only" document some aspect of the architecture (most notably: diagrams tend to document the 'fundamental organization' of the system). Hence, diagrams are means to an end.

Having established this role of architecture diagrams, it makes sense to consider the question why one wants to make these diagrams in the first place. A popular take on this is "informed decision making" (see e.g., this post). As far as I can see by a review of literature on architecture, most architecture approaches see the enterprise as a closed (technical) system which is largely deterministic. Architecture diagrams are then used to gain a deeper understanding of the working of this system and to guide decision making with respect to the system. 

Seeing enterprises as open (social) systems is increasingly popular in the field of enterprise archtiecture (see e.g. the weblog of Tom Graves). One approach that is built around this view of enterprises is SqEME. In SqEME - as I understand it from the 2008 version of the book - doing architecture is seen as a social process; it is about building a shared understanding of what constitutes the enterprise. Diagrams are used as a means of communication / tool to achieve this shared understanding. 

SqEME defines four windows on enterprises, most notably:

• constitution - what are the essential characteristics of the enterprise?
• chemistry - what makes the enterprise tick?
• construction - how is work facilitated in the enterprise?
• correspondance  - how has the enterprise performed/

From an architecture point of view, the constitution window is likely to be most relevant (however, it most be noted that the windows on the enterprise form a unified, holstic picture of the organization!). The constitution of the enterprise is documented using key result areas which are further analyzed using activities (verbs) and messages (nouns). The diagram type is an a version of the SADT / IDEF0 language which is both simple and intuitive. These diagrams are not intended for "implemtation" (i.e., change the diagram first, then change reality accordingly); but rather to reinforce a synchronized view of the big picture of the enterprise. 

Abstracting from SqEME for a moment: doing architecture in practice should be seen as a social process and aims at developing a shared understanding of what constitutes the enterprise. As a corollary: all people invovled in the enterprise are stakeholders in the architecture process. It may therefore be interesting to experiment with "web 2.0 tools" to explore how large groups of people can be involved (in)directly in the process. E.g., using wiki's to define the meaning of the verbs and nouns of the organization, use clickable / navigatable diagrams (i.e., when using 'leveled diagrams') that are available ubiquitously, etcetera. 

Question: any interesting experiences to share in this area?

Kodak

While browsing the Web I stumbled upon a great post on Kodak. It is a good read and highlights the strategic issues that Kodak faces / faced. The issue that is described is also interesting from an architecture point of view: from the user / customer point of view, Kodak's service has remained the same for years (hand in foto, get prints in return). The underlying technology (film, digital) has changed. Interesting case to use in class / lectures / papers.

New paper

Recently I have been thinking a lot about similarities between (a) the tension between business and IT in general, and (b) the tension between strategists and architects that you see in many companies these days. This is, obviously, one of the key topics for this blog. I think part of it has to do with C.P. Snow's observation that tensions of this type are mostly cultural. I have recently finished a paper on this topic that I will present at the PRET conference in Amsterdam. As a follow-up, I also wrote a short paper (in Dutch) for the .EGO magazine, which I highly recommend. The title of the paper is "Business & IT - waar zijn we nou helemaal mee bezig". The PDF version can be found here (note: paper is not accepted for publication yet, stay tuned for updates).

Book idea

I have recently met with Tom Graves, independent consultant and author of many excellent books (some of which happen to be on enterprise architecture). We visited Erik Proper at Capgemini and Jos van Oosten at Q-tips to discuss our views on enterprise architecture.

After Tom's visit in the Netherlands, we've decided to start working on a book together. The theme of the book is the use of a common (meta)model for assessing and improving the effectiveness of organizations, generating strategic options, and doing real enterprise architecture work. 

We are currently in the progress of crafting a book proposal and welcome thoughts on the above mentioned theme. If you have any relevant materials (books, articles) or case studies (e.g. results from consulting jobs) then please get in touch.

Alignment 2.0

Yesterday I attended the vijfmaart symposium organized by SBIT at the University of Tilburg. There were several intersting presentations and many old friends to connect to. Interesting to see that several of my former classmates ended up in jobs which somehow relate to strategy, alignment, architecture etcetera.

One of the speakers was Eric Sluis, CIO at Achmea/Interpolis. He discussed several interesting things. What really caught on, for me, was the model that he uses for enterprise architecture. This model is called "the delta method" and is developed/used by novius. The good thing about his way of thinking is pretty much in line with what several architects have claimed in the past: the method doesn't work. Select a method, adapt it to what works for you and get to work.

Another interesting speaker was professor Venkatraman (a.k.a. Venkat) who did some groundbreaking work with Hendersson on Alignment in the 1980s and 1990s. Alignment is an important aspect of the information management curriculum at Tilburg University, which exists 25 years this year. Venkat was asked to look back on the last 25 years and present his latest insights on alignment. He started with a brief overview of the original view on alignment issues:

After explaining the basics of this way of thinking, we discussed several recent trends such as Moore's Law, Metcalfe's Law, the bandwith law, but also changes in the business context such as increased (pressure for) agility. Central to his latest insights on alignment (dubbed alignment 2.0) are two observations:

1. IT (and business IT alignment) is a shared responsiblity by business and IT
2. Business are increasingly focussed on balancing the need to innovate with IT on the one hand and to implement and leverage their innovations on the other.

This leads to a new 2x2 matrix and 4 new perspectives on alignment:

• For cost centers, the focus is on creating a best class global IT infrastructure. The driver for the business case is the lowest delivered cost benchmarked against external referents; activities are not directly connected to business strategy yet it is seen that IT is necessary to run the business.
• For profit centers, the focus is on spporting current business operations. The driver for the business case is the contribution to customer value creating and delivery by achieving current profitability levels. This is achieved by supporting all aspects of the enterprise operations.
• For growth centers, the focus is on shaping future growth trajectories through new business model innovations. The driver for the business case is the exploration of different avenues for growth with IT, and examining the transformational changes required to rebuild the business models.
• For invetment centers, the focus is on influencing the future rowth trajectories through selective experimentation. The driver for the business case is allowing for experimentation of how IT could create and shape new business models.

Symposium

This Thursday there will be an interesting symposium at Tilburg University (see here). There are several interesting talks, one of which includes an overview of "25 years Information management and technology". Should be interesting, as this the place where it all started for me. I'll be there all day so let me know if you'd like to hook up.

TOGAF 9 - what's new?

The new version of the Open Group's enterprise architecture framework TOGAF was launched earlier this month. So what's new that it offers enterprise architects, and how can we use it in practice?

TOGAF is almost the de-facto standard for the enterprise-architecture industry. There are plenty of other frameworks around, such as FEAF, DoDAF, MoDAF - and of course Zachman's ubiquitous taxonomy - but TOGAF is one of the few that combines framework and method in a single package.

Three years of hard work has gone into the new version, and it shows: compared to version 8.1, it's much easier to navigate your way around in the new modular structure, and find the information that you need. There's a lot more information, too: the book version is now almost 800 pages of fairly dense text and graphics. In addition to a cleaned-up introduction, it now has six distinct sections:

• Architecture Development Method
• ADM Guidelines and Techniques
• Architecture Content Framework
• Enterprise Continuum and Tools
• TOGAF Reference Models
• Architecture Capability Framework

The last two sections are carried over almost unchanged from the previous version, with the 'Capability Framework' as a much better-structured container for all the information on architecture governance and the like. There's a useful new chapter on setting up the architecture capability, but that's about it for that part of the revision.

The Enterprise Continuum section is also much the same as before, with its description of two parallel frameworks: the 'Architecture Continuum', which holds the information about abstract architecture in a spectrum from generic and industry-standards to enterprise-specific needs; and the matching 'Solutions Continuum', which holds an equivalent spectrum of implementation standards and patterns. Here again there are a couple of new chapters, one on architecture partitioning in 'federated' enterprises and the like, the other containing an overview of what needs to be included with an architecture repository.

Most of the new work has been in the first three sections. The well-known Architecture Development Method (ADM), with its eight phases in a 'crop-circle' layout, has been retained from the previous version, but the detail content has been cleaned up and extended, with most of the secondary information - such as chapters on architecture deliverables and building-blocks - moved to the new 'Architecture Content Framework' and 'Architecture Capability Framework' sections. The section on guidelines and techniques for using and adapting the ADM - such as the chapters on security architecture and service-architecture - is almost all new, as is the chapter on metamodels in the Content Framework.

If you haven't used TOGAF, the core idea is the ADM - a structured method for developing 'architectures', identifying opportunities for change, and implementing them through portfolio of projects following a defined 'roadmap'. It's a cyclical, iterative process, centred around requirements. In the first phase we set up the plan for the architecture cycle. Then in the next three phases we respectively explore 'Business Architecture' - which, to be honest, is mostly about business impacts on IT - followed by 'Information Systems Architecture', looking at data and applications, and finally 'Technology Architecture', which is about the physical infrastructure for ICT. We do an assessment for 'as-is' and 'to-be' in each case, followed by a gap-analysis.

In the next three phases, we build our 'roadmap', develop a migration-plan, and shepherd each project through to implementation. The final phase returns to architecture again, with a lessons-learned review, and an assessment of any changes in the business or technical environment that might call for another architecture cycle.

It all looks good, and the hard work that's been put in to this revision really does show. There are a few significant quibbles, of course: several of the new sections feel more like useful overviews than actionable guidelines; the descriptions of roles and responsibilities - especially in the implementation phases - can often be muddled and confusing, with the enterprise architect at times apparently responsible for everything from detailed solution-design to overall portfolio management; and the 'new' techniques of 'business scenarios' turn out to be all but identical to good old-fashioned business-analysis. Some of those concerns are fairly trivial, though, and could no doubt be fixed in a future point-release.

There is, however, one serious problem. As it stands, TOGAF is excellent for IT-architecture, and for the early stages of enterprise architecture which do revolve primarily around IT. But that strength in IT soon becomes a serious weakness when we try to apply TOGAF beyond that rather narrow scope. For industries that are not centred on information, or for later-maturity enterprise architecture in any industry, the present structure of TOGAF soon becomes more of a hindrance than a help. This is a major disappointment for those of us who work in those latter business contexts - the kind of architecture work that may still be rare in seemingly IT-obsessed countries such as Britain or the US, for example, but is almost routine now in many other countries such as Australia, South Africa or the Netherlands. Even though the new version has been billed as an evolution rather than a revolution, we had hoped for more from this redesign.

It's true that some parts of the new version - such as the chapter on Capability Based Planning - do break out somewhat from the rigid IT-centrism of Version 8.1, but overall it's still not enough to make a significant difference. The metamodel in the Content Framework, for example, would in practice be usable only for IT-architecture; it also has no support for any form of versioning, which rules out its use for the kind of Agile-style development that's essential in later-maturity architecture. And the fixed IT-oriented scope inherent in the current ADM - with 'business architecture' still essentially a random grab-bag for "anything not-IT that might affect IT" - actively thwarts any attempt to use the method for anything with a broader strategic or whole-of-enterprise scope.

As I've documented in my own enterprise architecture books - such as "Bridging the Silos: enterprise architecture for IT architects" - there are ways to work around these structural flaws in TOGAF. But given that there is an increasing consensus that enterprise architecture must move beyond its roots in IT, that fact that these known problems were not resolved in the new version represents a missed opportunity that could well haunt the profession for many years to come. A pity - to say the least.

In summary, TOGAF 9 is a definite leap forward - for IT-architecture. But whilst the new version is definitely useful beyond IT, enterprise architects may still have to look elsewhere for the methods and frameworks that we really need.

Iterative architecture development and tooling

I have recently blogged about the work on enterprise architecture by Tom Graves, an independent consultant from Tetradian. Tom has authores several books, including Real Enterprise Architecture - Beyond IT to the whole enterprise (see the books section of Tetradian). I had briefly scanned this book before, but I'm currently reading it cover to cover and must say that I'm increasingly enthousiastic about it.

The core assumption in the book, as in many books on architecture, is that the enterprise is a system. Architecture, then, is a property of the system: 

Architecture is the integration of everything the organization is or does.

As many books on architecture, this book also uses a framework. This one, however, focuses not only on results (e.g. Zachman) or process (e.g. TOGAF's ADM) but on both. So far the meat of TOGAF has always been the ADM. I'm not exactly sure how good the content-framework of TOGAF 9 is as I haven't studied it in detail yet. More on that soon. Either way, a other strong points about this framework are the iterative nature, allowing several degrees of freedom in developing architecture, considering architecture maturity as part of the framework etcetera. The core of the approach is illustrated by the following figure:

Requirements (with respect to the architecture) play a central role in the framework. Even more, 5 distinct views on the architecture are considered to derive / structure these requirements. These 5 views are dubbed the 5 p's: People, Purpose, Preparation, Process, and Performance. As architecture is assumed to provide a holistic view on the enterprise, each of these views includes, within itself, a sense of all perspectives as illustrated by the following figure:

This "sensse of all perspectives" has a slight twist, leading to the keywords Elegant, Appropriate, Efficient, Integrated, and Reliable. This leads in total to 25 perspectives on the enterprise architecture, each with its own theme. For example:

• Purpose - Appropriate : focuses on the goals of the architecture function in the organization
• People - Elegant : focuses on the composition of the architecture team
• Preparation -Effective : focuses on the effectiveness of the archtiecture efforts in the context of the organizational goals (mission/ vision/ straegy)
• Performance - Reliable : focuses on the rol of real-time scoreboards / dashboards 
• Process - Integrated : focuses on managing services in the broadest sense of the word.

For each of the perspectives the role with respect to deliverables is discussed. This got me thinking: there are a lot of architecture frameworks out there (Zachman, FEAF, IAF, TOGAF, DYA). Most of the mare "cell orriented". Different stakeholders of the architecture require different views on the contents of these cells (to put it differently: filling the framework is the 'homework' of the architecture team. The team should also prepare different views on the framework for specific stakeholder groups). It isn't always apparent how the contents of the cells are "transformed" into deliverables by the architecture team. 

Working with different views on data is relatively well research in e.g. the database community. Even more, transforming information / documents is also relatively well researched (see e.g. my dissertation Aptness on the Web). It would be interesting to see how these two fields can be combined in the context of enterprise architecture documentation. 

(Perhaps this is a nice topic for students to work on as it contains a practical component as well as a theoretical one. If you're interested, please leave a comment or send me an E-mail!)