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?