26 November 2009

EA Quick Start Guide (Part 2): The Big Picture

In this, the second in my series introducing Enterprise Architecture, I describe the layers of what I consider to be a well formed and pragmatic EA model, and what constitutes the "big picture" so often referred to in architecture circles.

The terminology used is my own, and although it bears similarity to concepts conveyed in other architecture frameworks there are differences (there are, after all, only so many words in the English language that are suitable for certain concepts). For those readers already familiar with established architecture frameworks, it is therefore worth approaching this material with an open mind in order to avoid attaching existing preconceptions to the content.

Please keep in mind at all times that in my architecture approach, the model you are creating first and foremost is the future model (often referred to as the “to-be” architecture). Starting with the “as-is” model, in an attempt to record the status-quo is, in my opinion, unproductive in the absence of the “to-be” model. (See my previous article http://theenterprisingarchitect.blogspot.com/2009/08/to-be-or-not-to-be.html for a more detailed explanation of this position).

The EA Grid
Essential to an architecture is a “big picture” that brings together all the concepts into a single easy to understand starting point. An Enterprise Architecture is made up of several self-contained, but inter-dependent architectures, and thus the EA is made up of several “big pictures”, as shown in the following diagram:



The EA Layers
The EA is first divided into three layers (down the left hand side of the diagram) defined as follows:
  • Business Layer
    Focuses on the future needs of the business by describing what the business intends to provide to fulfil the needs of its external and internal customers.
  • Application Layer
    Describes the high level solutions that need to be provided to support the future intent described in the Business Layer.
  • Infrastructure Layer
    Describes the raw infrastructure elements that will need to be provided to support the solutions described in the Application Layer.
It is important to note that although the terms “Application” and “Infrastructure” are commonly used to represent IT concepts, there is no implication that these layers should contain only the IT elements. For example, in a retail environment it is perfectly reasonable to expect to see the components of the distribution network (such as the vehicles, warehouses, etc.) in the Infrastructure Layer.

The EA Models
The layers of the EA are then divided into three model types (across the top of the diagram), defined as follows:
  • Behaviour Model
    Describes how each element of the architecture will behave in isolation and how they will expose this behaviour.
  • Structure Model
    Describes how the elements of the architecture will all fit together to form a coherent whole.
  • Knowledge Model
    Describes what will need to be known, and how this knowledge will be grouped and categorised.
The EA Pictures
Inevitably this grid results in nine “big pictures”. Nine big pictures might sounds like a lot, but considering that this presents the model for an entire enterprise this is a relatively small number of pictures. Also, each performs a specific job, and many people will be interested in only one or two of these pictures. The intent of a big picture is to convey the overall concepts in one single place that can be easily understood and digested before the reader dives into the underlying detail. For this reason, the techniques used to draw these pictures may be different dependent on the environment, but as a starting point the following descriptions should work in most circumstances:
  • Services (Business Behaviour)
    Shows the business services to be provided to the internal and external customers to fulfil the business vision and objectives, and models these services as well defined and self-contained processes.
  • Organisation (Business Structure)
    Shows how the proposed business services fit within the target organisation model, and how these services interact with one another to create the desired customer experience.
  • Information (Business Knowledge)
    Shows the information as understood by the business as a set of entities and includes the relationships between these entities. This information model needs to be supportive of the business services described in the Services model (and vice versa).
  • Capabilities (Application Behaviour)
    Shows the internal application services needed by the business (including IT) to allow it to undertake the processes described in the Services layer.
  • Solutions (Application Structure)
    Shows how the application services interact with one another to fulfil the needs of the Organisation model and thus provide the desired customer experience.
  • Data (Application Information)
    Shows the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the Capabilities model (and vice versa).
  • Components (Infrastructure Behaviour)
    Shows the individual infrastructure components available to the business to perform its daily activities. In a COTS (Custom Off The Shelf) environment which adopts a “buy not build” strategy, there may well be a great deal of similarity between this model and the Capabilities model.
  • Systems (Infrastructure Structure)
    Shows how the infrastructure components interact with one another to fulfil the needs of the Solution model.
  • Sources (Infrastructure Knowledge)
    Shows the sources of the raw data described in the Data model. In an ideal world, these sources will be derived directly from the Data model, but in reality sources may duplicate data, or separate related data as a result of the choices made in the Component model. This model should therefore identify how the duplication and re-combination of data will be handled.
Where to Start
But that is a lot of pictures to consider, and we have to start somewhere. The majority of “traditional” organisations start in the centre by developing the Solution model. This task often falls to IT alone, acting on a variety of unaligned instructions from many interested parties. In my opinion, this is where many of the problems associated with “Big IT” originate.

It is far better to treat the EA Grid as a jigsaw. Start with the corners, then fill in the edges, and finally complete the centre. The corners allow us to better understand how the edges fit, and the edges give us a better understanding of how the middle needs to look. However, as for a jigsaw, if you find a piece that you know fits an area you are not yet working on, don’t just ignore it; put it where you think it belongs.

It is also best to start with the top left corner (the Services model) in keeping with the service oriented approaches that many architects adopt, and then work left to right and top to bottom (still focusing on the corners first and foremost).

Joining the Dots
The full Enterprise Architecture only makes sense if each of the models links to its neighbours to form an overall joined up picture. It is therefore important to ensure that for each type of model (Behaviour, Structure and Knowledge) there is clear traceability from the Business Layer to the Application Layer and from the Application Layer to the Infrastructure Layer to demonstrate how the needs of the business are being fulfilled, and by what.

This concludes the second part of the Quick Start Guide. The overall Enterprise Architecture has been described as a set of interlinked and mutually supportive big pictures, and an initial indication of the purpose and content of each model has been given.

Further articles will follow describing each of the models in more detail, but from this overview a strong architect should be capable of developing models of whatever flavour they choose that fit into, and fulfil the intent of this approach.

And remember... One of the problems with architecture is that when you describe it in words, it always sounds more complex than it actually is in practice. This article simply applies one of the core concepts of enterprise architecture to itself:
Divide and conquer
Regards
The Enterprising Architect

16 November 2009

EA Quick Start Guide (Part 1): How to Set Up an EA Practice

This article is the first in a sequence providing an introduction to Enterprise Architecture suitable for those starting out in the profession, or for those outside the architecture profession interested in what the fuss is all about.

In this first article I would like to address an issue that has particularly bothered me recently; the setting up of an EA practice. Much is made of the activities required to establish such a practice, but in my opinion, the advice given is at the heart of why others are frustrated with the lack of value delivered by Enterprise Architecture in the early stages of its adoption.

What Not to Do
Firstly, let me address what not to do. Common “wisdom” seems to believe that the initial steps should be as follows:
  1. Identify the fundamental principles that the architecture will support.
  2. Establish the governance framework that will ensure compliance with the architecture.
  3. Establish the architecture framework that the EA practice will adopt.
  4. Start to engage with projects.
“What's wrong with that?” you might ask. It sounds reasonable enough at face value, but this approach is unlikely to result in quick acceptance of EA as a valuable activity.

Firstly, of what use are principles to anyone? They are usually a re-articulation of the obvious, and stating them (or more importantly, wasting time word-smithing them) will simply establish right from the outset that your so-called EA practice has every intention of being a talking shop that makes a profession out of navel gazing. What is more, what exactly is anyone else supposed to do with these principles? They can try with all their might to conform to them, but at the end of the day, they are simply words with many possible interpretations.

Principles may be useful in guiding your architects in the development of the architecture, but they are no more use to the recipients of that architect than a set of coding standards (without any code) are to a tester. In reality, principles in isolation are simply ambiguous tools that self proclaimed architects can use to impose their opinions on others.

…And this brings me to the second step. What are you doing establishing a governance framework when (a) you have nothing against which to measure compliance, and (b) you have not yet established the credibility or respect to demand that others do as you say. Establishing a governance framework at this stage also sends out a very strong message that the primary intent of your practice is to block progress, rather than enable it.

The third step is not so contentious, but I would consider it to be too burdensome to undertake during the emergent phase of your practice. In my opinion, frameworks are useful sources of reference information that can be dipped into and cherry-picked as work progresses on your architecture. Use them as you would a dictionary or encyclopaedia. As for the fourth step; engaging with projects at this stage will simply destroy any credibility you may have had, as you will simply be exposing your lack of real deliverables to a sceptical audience. What is more, you will be dragged into the day-to-day point solution world of the project, and become just one more design resource. This will take your architects away from the bigger picture, and prevent your EA from being developed.

What to Do
So what should we do? The hint is in the previous paragraph. The one thing that the organisation needs you to do as an EA practice is develop your Enterprise Architecture. Until this starts to happen, you cannot provide any real guidance or value, and you certainly cannot justify what you are saying if it is not clearly recorded. You will, instead, always appear to be “making it up as you go along”.

For me, the ideal first steps in establishing an EA practice are:
  1. Ensure you have the right people.
  2. Establish basic working practices.
  3. Start building your architecture!
Those are the basic steps. The following sections give some guidance on how best to perform them.

What Makes a Good Architect?
Enterprise Architecture is a skilled, specialised activity, to be performed by a small number of people. One weak link could fundamentally undermine your effectiveness. (This should be obvious, but for some inexplicable reason EA practices more than any other area of business are set up from a random selection of people, rather than those selected for their previous experience, or potential to be architects. Some key attributes required by an architect are:
  1. Ability to communicate verbally, visually and textually.
    Architecture is (roughly) 80% communication. Bad communication will frustrate others and negate the effectiveness of your architecture.
  2. Ability to listen and quickly assimilate new information.
    Architects are always dealing with the future and thus the ability to learn fast and think fast is essential. What you know today will almost certainly be out of date with respect to a true “to-be” architecture.
  3. Ability to influence and enthuse.
    For your architecture to be successful it must be followed, and for this to happen others must be bought into, and enthusiastic about your architecture. This will only happen if your team have the presence and ability to make it happen.
  4. Credibility.
    Some people have it, some do not, and worse still, some have at some point in the past lost it. There is no point in starting with a disadvantage.
  5. Ability to see the big picture.
    An architect must be able to consider the organisation as an entire system. Those who prefer to focus on point solutions or drill down into the detail of one thing at the expense of the rest are not suited to architecture.
  6. A natural preference for simplicity.
    The best architecture is the simplest possible one that can fulfil the business vision. Those who gravitate towards, and enjoy complexity do not make good architects. Those who abhor complexity and take please from finding the simplest possible solution to a problem are the ones you want.
But what about specific business or technical knowledge? For me, it is not specific knowledge that matters, but a demonstrable ability to adapt to new situations, and understand new ways of working, and new enabling technologies at the drop of a hat. Those with specific in-depth knowledge generally measure their own value in terms of the relevance of that knowledge. As a result these people often fear change, as it may negate that value, and thus negate their importance. They are not best placed to view the future from an unbiased point of view. Unfortunately, businesses too often focus on finding people with the specific knowledge to support their current position, and then wonder why these people bring nothing new to the table.

What are the Right Working Practices?
When setting up an EA team, the best working practices are those that will allow you to both engage with projects and continue to build your architecture, without the demands of one impeding progress on the other. You need to quickly establish who will support projects, and who will build architecture, and then you need to ensure that these two groups retain a close working relationship as each will feed the other.

Your working practices need to support a proactive approach where the build activity seeks information regarding the future strategy, (and in turn helps to guide future strategy) and quickly articulates this information as future architecture.

You also need to support a reactive approach that allows the architecture to engage with projects at an early stage and either feed them with information already recorded in the architecture, or re-prioritise build activities to focus on the areas of the architecture that will fulfil the needs of the project.

How Should We Build It?
Build it? That’s the scary bit, isn't it? This brings us to the heart of the problem. So many EA practices spend time avoiding the really important bit because they are frightened of it. I strongly believe this is why so many processes for establishing an EA practice start with a sequence of what I feel are little more that prevaricating steps. In a consultancy led world, an outside “specialist” can use this approach to provide a significant amount of content without actually having to get involved in building anything.

In the early stages you need to recognise that initial demand will come fast, and will come from two sources; above and below. From above, you will need to engage with the business to articulate the future vision in the form of a Business Architecture. From below, in-flight projects will start to demand guidance relating to low level implementation decisions. You will need to have the courage to make some decisions relating to future technologies with very little guiding information, and articulate these decisions in your Technology Architecture. Some of these decisions may turn out to be wrong, and you must be willing to accept this, adapt your Technology Architecture accordingly, and help projects to absorb these changes in a pragmatic manner. Remember, that sometimes the simple act of making a decision and sticking to it is what makes that decision the right one.

(I will cover what goes into an Enterprise Architecture in terms of levelling and content in later posts in this series).

It is this build focused activity that guides your engagement with projects, and more importantly with those who set the vision and strategy of the organisation as a whole (and yes, that does include you as an architect).

And the Rest?
Let’s now return to the original steps that I declared to be the wrong ones. They were:
  1. Identify the fundamental principles that the architecture will support.
  2. Establish the governance framework that will ensure compliance with the architecture.
  3. Establish the architecture framework that the EA practice will adopt.
  4. Start to engage with projects.
Am I suggesting that these are not important, or can be ignored? Of course not, but what I am stating is that these are not the very first things you need to do. Once you are up and running and developing the architecture (and thus hopefully providing some real value) you can address these other areas on an as-needs basis.

Principles can be recorded if you like, but remember that your architects, if properly selected, will already naturally apply sensible principles to everything they do. Do not expect others to act on these principles however. They need you to act on them and provide an architecture that fulfils these principles.

A governance framework will be important as your architecture develops, but you must start in a spirit of cooperation and assistance to win support and credibility. Once this has been established and you have some content in your architecture you can start to introduce more formal governance mechanisms based on this content and the trust you have already established.

An EA framework is also important, but it should be your own, and it should be adapted to and derived from the unique circumstances that exist within your own organisation. Once again, attack this on a just-in-time basis, cherry picking from the various reference frameworks those features and details that you find you have a need for, and always consider carefully whether it really adds value to what you are doing. (Roger sessions wrote a good article on EA framework comparison available for download at http://www.objectwatch.com/whitepapers/4EAComparison.pdf).

Is This the Only Way?
Of course this is not the only way. You are an architect, and you are in charge of your own approach. If you cannot set your own direction of travel, then you need to question whether you can set the direction for others to follow. The intent, however, should always remain the same:
To start producing an Enterprise Architecture and to become a useful addition to the organisation in as short a time as possible.
The longer you take to do this, the more likely it is that someone will decide (correctly) that you are surplus to requirements, before you even get started.

Regards
The Enterprising Architect

5 November 2009

I Don’t Like Architects

The title of this article may seem strange, coming as it does from someone who declares himself to be an Enterprise Architect (EA). Let me explain...

Bad EA = EA Bad?
One of the greatest frustrations as an EA is that my first meeting with most people in the work environment is one of distrust and open criticism. Before I can make any progress, I first have to answer one or more of the following questions:
  1. What is EA?
  2. What's in it for me?
  3. Why is it going to work this time when it hasn’t before?
  4. Why waste time with EA when we could be getting on with the real work?
  5. Why do you architects insist on slowing things down?
The first two questions are no problem at all. They get to the heart of the issue, as the questioner is recognising (1) that they need to understand EA before they can judge it, and (2) that EA should be contributing to what they are doing and I as an EA should be able to justify what that contribution is.

It is the remaining questions that frustrate me; not because they are being asked, but because the person I am speaking to has had to experience EA in a way that leads them to ask these questions.

Is EA fundamentally flawed as an approach, and if so does it need to be rethought or renamed? Absolutely not.

Is EA an academic concept that is simply not pragmatic enough, in the day-to-day pressures of modern business, to be of practical use? Again, absolutely not.

Good EA is a simple and effective tool that forms an essential step in the journey, and what is more it accelerates the journey rather than slowing it down. Why then is EA viewed with such scepticism and disrespect?

Seeing is Believing
For me, this is a people problem, not a process problem, and it is the same problem that “Big IT” suffers from.

People have a tendency to gravitate towards “the next big thing” and for a while this was IT. (In my father’s day it was the newly emerging field of electronics). Everyone and their dog was suddenly in (or trying to be in) IT regardless of aptitude or experience. This in itself was not a problem, but companies then employed these people in the bizarre belief that it was something anyone could do (an attitude they would never apply to their own profession).

The result was runaway inefficiency, with the many who claimed to be able to do IT getting in the way of the few who could really do it. Management then looked at the resulting decrease in productivity and decided that more people were required. Finding the necessary resource to be scarce they became even more sure that the solution was to hire even more non-IT people in the hope that they would become effective over time.

When increased resource didn’t help, the focus then shifted to greater analysis and design, increased testing, and increased release management to try to overcome the poor quality of the systems being produced. The result? Even greater inefficiency, and the widespread (and mistaken) belief that IT was by nature big, expensive and time consuming.

Then came EA and architecture in general. Jobs advertised under the name of architecture carried higher price tags than the traditional designer, developer & analyst roles seemed to carry. Naturally everyone started to call themselves architects, regardless of activity or ability...

...and this is why I don’t like architects (or to be more accurate bad architects). The majority of people who claim to be architects are quite simply no good at it. They may be excellent at what they used to do, but what they are now doing is not architecture. By claiming to be architects they simply devalue it by either doing it badly and making it look bad, or by doing something that is already being done elsewhere and making it look redundant.

These are the people I do not like. They make my job twice as hard, and force me to start from a position of disrespect in my interactions with new contacts. I dislike them as much as I dislike bad leaders, bad public speakers, bad programmers and bad politicians.

The Moral of this Story
In conclusion, when you discuss the problems of architecture, think carefully about whether what you are really discussing is the problem with the people claiming to be architects. After all, the fact that you have experience of one or more bad plumbers, does not imply you can live without plumbing.

A Message to Architects: Consider the five questions at the start of this article. If you cannot answer all five to at least the partial satisfaction of the questioner, then perhaps you are one of those Architects to whom I am less than enamoured.

A Message to Leaders: You select your architects. If they prove to be ineffective, consider the possibility that the problem lies in your selection of architect rather than the validity of the activity itself.

A Message to Innovators: Defend your ground. Given the current (justified) enthusiasm for innovation, I am sure you will soon find yourself surrounded by would-be innovators keen to jump on the bandwagon, and devalue the perception of your expertise and value.

Regards
The Enterprising Architect