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