Architecture in Action @ LAC 2008

Over the last few days I have been at the LAC 2008 which proved to be very interesting and inspiring. The LAC conference is 10 years old this year which resulted in several gifts (books!) for the participants.

Day 1 started with a very interesting talk by Daan Rijsenbrij, presenting his perspective on (the history and future of) enterprise architecture. What struck me particularly was the fact that he argued the case for distinguishing architects from engineers. I couldn't agree more. I also followed a series of 3 presentations on the value of architecture. No big news there, yet interesting to see the case studies that were presented. Unfortunately I missed the last plenary session due to other obligations.

On day 2 we saw several interesting presentations  by Jan Truijens and Frank Baldinger. I rather liked the critical attitude they have towards what architecture is, what the value of architecture is, and how we should teach architecture to students and practitioners. My persional opinion is that architecture is still in its infancy and that it will take a few more years before we as a community have shared understanding of our field. After that it will take another while before people in the boardroom understand what we're up to. A lot of challengies lie ahead us.

It was interesting to see that many LAC-participants share this idea. There was a lot of talk about the relation between architecture and strategy, the value of architecture for business and so on. Hopefully the debate on this topics will make it to the architecture community at large and therefore lead to interesting publications on the web and in print.

Dimensions of (enterprise) architecture

One of the issues that keep popping up when discussing (enterprise) architecture is the question: what is it? Unfortunately it seems necessary to keep discussing / refining / extending definitions, not only when two architects converse, but also when starting a new architecture project in a firm. I've seen situations where it took several months to agree on a definition of EA in one department of an organization when we found out that other departments had an entirely different approach. This is pretty much regrettable. As Hans Bot puts it eloquently at the Weblog of Erik Proper:

It's amazing the debate is still going on … Why is it, that in IT, we tend to hijack a word from another industry, and give it an altogether different meaning? … The IEEE working group did a very good job in defining those terms back in 2000. Architecture is a property of a system reflecting its internal cohesion; its harmony with its surroundings and its design principles … If only IT people would accept (and practice) the difference between an architecture description, a view as part of the architecture description (either made during the design of the system or afterwards) and the architecture itself, much confusion and mystification would be prevented.

I couldn't agree more. In teaching EA, though, I've found that it makes sense to distinguish three dimensions of enterprise architecture to guide the course, the discussion of the subjects et cetera. In the course "Enterprise Archtiecture in Practice" I used the following slide to introduce these perspectives:

The first dimension deals with the question "What is enterprise architecture?". As Hans put it, architecture is a property of a system. In the case of EA, the system under consideration is an enterprise (thus assuming that architects have a systemic view of enterprises). Paraphfrasing the FRISCO report, it can be argued that since each architect has a unique perception of the enterprise under consideration, each architect sees the architect of this enterprise differently (in FRISCO terms, an architecture is a special model which exists in the mind of a human actor). Therefore, it is essential to communicate about architectures. This is also argued in e.g.  the Archimate approach. 

This brings us to the second dimension: documentation. This dimension deals with the question "How are architectures documented?". In my opinion, this is where most of the big architecture frameworks and architecture languages come on. Think IAF, Zachman, Archimate et cetera. It appears that there are two main aspects of architecture documentation. First of all, there is the style of architecture blueprints in the form of (semi) formal models. This is what most people expect from architects: walking around with A0 sized plots of e.g. the application landscape. The second style pertains to architecture principles (ignoring the distinction that is sometimes made between 'principles' and other types of regulations such as 'rules', 'guidlines' etcetera). Neither style is right or wrong, in my opinion. Both are equally valuable, depending on what one wants to achieve. For example, the blueperints tend to provide a lot of information and insights which may be used for decision making whereas principles may be used in Project Start Architectures to guide projects within the enterprise.

This brings us to the last dimension which pertains to the question: "What is an architecture used for?". This refers back to the comment by Hans Bot. In my experience, more and more organizations start working under architecture. This means that they use the EA way of thinking  for governing the enterprise with a strong focus on brining together the worlds of what traditionally is called 'business' and 'IT'. Probably the most succesful and widespread use of EA is the Project Start Architecture. 

Splitting up these dimensions and discussing them seperately has worked well in practice, at least in a teaching setting. As long as there is no widely agreed upon feel for what EA is, especially outside the architecture community, it may be necessary to continue to discuss these dimensions with each new architecture initiative. This is unfortunate, as it is more important to get the work done.

LAC 2008

The LAC 2008 event (Landelijk Architectuur Congres) event will be next week. On the 26th and 27th of November to be precise. This is the 10th edition of the LAC so it will be special. I'm looking forward to attending the event and hooking up with old and new friends. The general program can be found at the LAC 2008 website. As for the different tracks, I intend to go to:

• wednesday: the role of enterprise architecture in business transformations
• thursday: enterprise architecture, strategic specialism for informed governance 

Please send me an E-mail if you want to get in touch during the event.

Enterprise Architecture as Strategy

A while ago I read the book Enterprise Architecture as Strategy (by J. Ross, P. Well, and D. C. Robertson. See the book's website for more information). This book presents an interesting perspective on Enterprise Architecture provides useful tools for "doing EA" in practice. 

The basis for the books is the foundation for execution which is defined to be the IT infrastructure and digitized business processes automating a firm's core capabilities. Three steps in defining this foundation for execution are:

1. Operating model: the necessary level of business process integration and standardization
   
2. Enterprise Architecture: organizing logic for business processes and IT infrastructure, reflecting the operating model
   
3. IT engagement model: system of governance mechanisms that alignment with strategic objectives
   

The following figure outlines the general approach

The operating model is characterized using two dimensions: the level of business process integration and the level of business process standardisation. This leaves room for four types of operating model, most notably:

		standardisation
		low	high
integration	high	coordination seamless access to shared data	unification standardized integrated processes
	low	diversification independence with shared services	replication standardized independence

Each cell (i.e., each type of operating model) has unique characteristics. For example, for replication it holds that there are few shared customers between businesses,  business units are operationally similar, and there is centralized control over business process design, etcetera.

The next step is the definition of an enterprise architecture, which is defined to be the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the companies operating model. The key to defining an effective EA is presumed to be the identification of process, data, technologies and customer interfaces that take the operating model from vision to reality. An EA is documented using a core diagram in a semi-formal language. This diagram is a one-page overview of process, data, and technologies constituting the desired foundation for execution. For example:

This diagram is intended to show the "operational pipeline" of Delta at the top. This maps, to some extent, to the notion of a value chain. The middle part of the diagram shows  the supporting "nervous system" which consists mainly of the databases that Delta uses. It also shows some of the interfaces to this data. Finaly, the bottom part of the figure shows different aspects of the "customer experience". I like this type of picture, as it is easy to make and easy to understand. However, since it is so informal it may also lead to confusion (this is where tools like Archimate come in handy).

One of the more interesting aspects of the book are the EA maturity models which are defined as follows:

• Business silos: maximize individual business unit needs or functional needs
• Standardized technology: provide IT efficiencies throgh technology standardization and centralization of IT management
• Optimized core: companywide data and process standardization
• Business modularity: manage and reuse loosely coupled, IT-enabled business process components while enabling local differences

The underlying assumption is that firms will go through these different stages as follows

For each of these levels / stages, learning requirements are defined. I'm all for maturity models, as it gives managers and architects some guidance in figuring out how to let the organization evolve in a natural way. In this case, however, I'm not convinced that this will actually work for all/most companies. On the upside, the authors acknowledge that companies ought to think out a maturity strategy for themselves. E.g., some companies belong in the diversification quadrant of the above table. Others will want to grow from diversification via replication to unification, whereas others will want to grow via coordination to unification. It all depends on the unique situation of a firm. 

Last but not least, the engagement model is discussed. A very useful section as it is nice to have a good theory, but more interesting to actually implement it in practice. The engagement model is outlined in the following figure:

The nice thing of this engagement model is that it relates business and IT on the horizontal axis, while distinguishing between the project / business / enterprise level on the vertical axis. As such, it paves the way for a enterprise-wide governance model for IT. IT governance encompasses major decision areas related to the management and use of IT in a firm and should be driven by the operating model.

In my opinion, the good aspects of this book are:

• the authors have combined their extensive theoretical knowledge with their experiences from practice 
• there is a strong focus on governance
• the book leaves plenty of room for adaptation to the individual situation in firms

Somewhat less positive points of this book are:

• the book is written solely from the IT-perspective / discusses IT-related topics
• the book but seems to miss the point about strategy (in the sense of strategic management) at times. For example, discussions on synergy, competitive advantage etc. are missing. 
  

PRET'09

An interesting challenge for practitioners and academics is to maintain a good balance between academic rigor and practical relevance. An often heard claim is that academic research is hardly relevant (especially in CS), and that consulting lacks academic rigor.

Next year's CAISE conference (Computer Aided Information Systems Engineering) will be held in Amsterdam. CAISE is one of the conferences that has always maintained a very high standard in terms of academic rigor. This year's CAISE conference will also host the PRET workshop (Practice-driven Research on Enterprise Transformation). The list of accepted papers / chapters should be published soon. It promises to be an interesting workshop!