8 December 2009

EA Quick Start Guide (Part 3): Getting Down to Business

In part 3 of my series introducing Enterprise Architecture, I will focus on the first (and foremost) of the three layers described in Part 2; the Business Layer.

A Quick Reminder
As discussed in Part 2, the business layer of the Enterprise Architecture 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 (see the following diagram showing the business layer in the context of the full EA Grid):



Within the business layer are three key models covering behaviour, structure and knowledge, defined as follows:
  • 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).
I have already recommended that a good architect starts in the corners of the EA Grid, and following this principle, I will now describe the individual models in this order. However, it should be noted that a degree of overlap in the development of these models will be beneficial to ensure that no one model is created without the benefit of at least an overview of how the other two models are evolving.

The Services Model
Although there will inevitably be a high degree of overlap between the three models in the business layer, the most effective place to start is with the services model. It is here that the true future intent of the business can be articulated in a manner that makes sense to the business, and that focuses on the business from a customer-centric point of view. The Services model tells us exactly what it is the Business intends to “do” for its customers.

Step 1: Domains
Starting with a large blank page (electronic or physical) first define your future business in terms of service domains. These service domains are high level grouping concepts that separate the services to be provided by your business into areas of interest. Think of them simply as boxes into which you will place your services so that you and the business can find them easily in the future (e.g. “Insurance”, “Financial Planning”). A typical domain model for even the largest of organisations should need no more than five to ten domains. If your business already has a good idea of where it is heading, and there is some form of vision statement to support this, this initial domain model should take no more than an hour or two to produce.

Step 2: Services
Now start populating this model with the services that you intend to provide to the customer (e.g. “Insure my car”). Approach this in a brainstorming fashion, focusing more on what the business wants to do and less on getting the names and positions on the model right (they can always be moved or renamed later). Keep going until the ideas start drying up and then review what you have, making sure you have captured the intent of each service to avoid misinterpretation later. Take an 80/20 approach to this task; there will be plenty of time to add the services you miss as you develop the model further. Provided you have the right people involved in this process (those with the authority to formulate the future vision) it should take no more than one or two days to produce the first cut of a fairly inclusive service model.

Step 3: Tasks
To flesh out the basic service model you now need to define the individual tasks that will need to take place to provide each of the services (e.g. within “Insure my Car” you might have tasks such as “Produce a Quote”, “Agree Terms”, etc). A question that often arises at this point is “when is it a task rather than a service?” I stick to the rule of thumb that a task is something that can be performed by a single person (or team) and could be performed between cups of coffee. Focus first on those that are deemed most important to the business’s value proposition, and on those that are felt to be the most “radical” in terms of business transformation. For an average service, separation into tasks should take no more than a day at most.

Step 4: Processes
To complete the service model you now need to describe exactly what has to take place to fulfil each task. In my experience, the best tool for this is the old favourite, process modelling. Agree first on the pre-conditions and post-conditions for the task so that the start and end points are well understood, and then describe the steps that need to be undertaken to complete the task. If you have divided your services down into the type of tasks described in step 3 above, each of these processes will probably only consist of a handful of steps (typically between five and ten). Again, for an average task, the initial process should be definable in less than a day.

During each of these four steps you will find that there is a strong tendency to fall back on “what we do today” whenever the going gets tough. As the Enterprise Architect it is important that you regularly ask the question “is this what you want to do in the future, or is this what you have to do now?”

The Information Model
Closely aligned to the Services model is the Information model which describes what the business will need to know to support the service it provides to its customers. This model should approach information from a business centric point of view, and not from a more traditional IT perspective (which is typically adapted for suitability to the applications, technologies and database approaches, and has little meaning to the business). The business should be able to look at the information model and instantly recognise the content in the context of their day-to-day activities, and it is for this reason that this is often the easiest model to populate.

Step 1: Domains
Essentially, the same first step as for the services model, but this time we focus on domains that allow us to group our information according to subject matter (e.g. Customer, Financial, Products, etc.). As before, it should be possible to complete this task satisfactorily within an hour or two.

Step 2: Entities
Now start populating this model with the information entities; the things the business wants or needs to know about. (If you know anything about database techniques and third normal form please resist the temptation to impose your data modelling “experience” on this activity). Approach this in a brainstorming fashion, focusing more on the core things that the business wants to know about, rather than the fine detail (this will come later in Step 4 below). Keep going until the ideas start drying up and then review what you have, making sure you have captured a description for each entity to avoid misinterpretation later. It should take no more than a day to produce the first cut of this model.

Step 3: Relationships
Information does not exist in isolation. Now that you have captured the main areas of knowledge, refine this model by adding the relationships between these entities. Be careful to only link those entities that have a genuine relationship to one another. Do not link entities to one another simply because your business intends to use the information in a related manner. (For example, a Contact will probably be related to a Customer, but just because you intend to use your Contact History information to develop a Customer Insight Model does not then mean that these entities are related to one another).

Step 4: Discovery and Use
As mentioned earlier, the Information model is closely associated with the Services model. Revisit the tasks in your Services model, and show where knowledge is used or captured by linking the process steps to the relevant information entities. Where necessary create new entities (and their relationships) to support knowledge that is described in the processes, but has not yet been captured in the Information model.

In theory, it is possible to skip directly to Step 4, and use the your Services model as the core discovery tool from which to develop your Information model. However, in practice, you will find that your Business already has a well developed understanding of the knowledge it needs to support, and Steps 2 and 3 offer a more pragmatic and efficient approach to developing a draft Information model.

The Organisation Model
With the Services and Information model we have the basic building blocks for our business, but what we do not have is the overall structure to support this, and this is where the Organisation model comes in. This is not just an organisation hierarchy diagram; far from it. This model is more accurately compared to the London Underground map. By laying out the customer experience in the form of journeys with clear start and end points, travelling through stations representing the key business services used, we can show how these services interact with one another to create the desired result.

We can also recognise more clearly how our teams and departments may need to be organised to ensure that the customer journey is as smooth and efficient as possible, and to ensure that departmental handovers happen at sensible points in that journey. I do not recommend that this is approached as a single end-to-end activity. Instead, approach it in a demand driven fashion guided by the Business initiatives and projects whose needs are greatest. By adopting this approach you can assist with the development of projects requirements, ensure that the projects are aligned to the services in the Business Architecture, and leverage the funded resource assigned to the project.

Step 1: Journeys
The first step in joining up the pieces of our Business jigsaw is to identify and map out the journeys our customers are taken on as they use our services. Describes these as “stories” describing what the customer does, and what the Business does for them, and remember to consider the journey taken by the “virtual customer” as their information flows through our processes (not just the part of the journey visible to the customer) as this hidden journey impacts the customer experience. An example of a Customer journey might be that taken by a UK benefit recipient, which starts when they become unemployed and sign on for benefits through to (possibly) getting a new job and the benefit ending. Remember to model the journey you would like the Customer to experience, rather than the warts-and-all one they may have to take at present. Each journey will typically take a day to develop.

Step 2: Interactions
During a typical journey, a customer might interact with the Business on many occasions, and these interactions need to be identified and named. It is important during this step to recognise that although the customer journey might be unique, the interactions within it will probably re-occur in other journeys (for example, Make Complaint, Search for Jobs, etc.). Each interaction can then be modelled as a sequence of one or more business tasks from the Services model. The customer journey can now be added to the “tube map”. The journey itself represents the “track”, and the interactions are the stations along the way. Adding journeys to the tube map allows us to recognise where journeys join and separate and to understand how any departmental structures might cut across the journeys creating a more complicated customer experience.

Step 3: Organisation
As the tube map develops, there will come a point where it is possible to overlay the proposed business structure on this model. Consider the “zones” on the London Underground tube map and imagine these to be your business areas. You can now identify where it makes sense to handle customer interactions in call centres, and where expert teams need to (and can effectively) get involved. Symbols can be added to the “stations” to show where paper is created or destroyed to support your paper removal agenda (if you have one), or to draw attention to any other key events that you need to highlight. This one diagram brings everything together into a single big picture that shows the simplicity or complexity of your Business at the service and organisational level, and facilitates open discussions about the overall impacts of key Business changes.

Voila!
And there you have it. The Business Architecture; done (as Gordon Ramsey might say).

Well, no... Not exactly. What you have done is started the reaction; what you have not done is reached the critical mass necessary to ensure that this activity does not simply fizzle out.

Your Business Architecture will have significant gaps that others can use to challenge its validity. Many areas will need further work to resolve conflicting requirements and ambitions. And of course, the vision for the future is not a static thing. It will change on a daily basis, and your architecture, as an articulation of this vision, must adapt to its twists and turns.

Architecture is a living thing, and Business Architecture is no exception. You will need to continually revisit and refine to respond to the emerging challenges and the immediate imperatives for the Business.

Above all, you must use your Business Architecture, and you must make sure that others use it too. Not as an afterthought to test alignment, but as the core source of information to identify change initiatives, guide projects, and develop requirements.

You’ve just finished the easy part. From now on it gets physical.

Regards
The Enterprising Architect

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

30 October 2009

The EA Identity Crisis

As business architecture gains a foothold as a tool for enabling the delivery of business change, Enterprise Architecture (and more specifically the Chief Architect) is experiencing an identity crisis.

IT’s Coming Home
With the fairly recent and somewhat belated recognition that Enterprise Architecture is not a purely IT focused activity (the clue is in the name), architects are finding themselves more involved with the alignment of IT architecture with business strategy. In some organisations, there may even be the recognition that Business Architecture is key to this transition.

Why this is considered to be something new is beyond me. Why IT would consider alignment with the business to be an add-on or a refinement to what they currently do is extremely worrying. The history of how IT became something separate, and how the need to “align IT to the business” arose as a task that people needed to be reminded of is a vague one that I will not discuss in this post.

I need to stress at this point that I do not accept that an amorphous reference library containing all the compartmentalised business information and design in any way represents a true Business Architecture; no matter how many times people try to call it one.

The emergence of Business Architecture as a formal activity should not be in an issue in itself. It is a fairly simple matter to realign architecture to the business needs, and use existing Enterprise Architecture skills to articulate the Business Strategy as architecture, and then derive the technology oriented elements of the architect from this...

...but it is an issue.

Get your Filthy Hands off my Business!
Despite the addition of the “enterprise” qualifier, architecture is still considered in many organisations to be purely the domain of the IT department, whilst business strategy is considered to be something that IT may be interested in, but should not interfere with. It is here that the dilemma exists.

The main cause of the confusion is the alignment of many Chief Architects to the IT Department coupled with a reporting line up to the CIO. It is difficult for such an architect to be considered as anything other than an IT focused individual, and it is then even more challenging for this individual to get a seat at the business table. However, for many problems, IT forms a major part of the solution, and in developing an enterprise architecture, the Chief Architect will need to have a working knowledge of the emerging technologies that so dictate the art of the possible in the modern world.

Now we need to address another misconception. Apparently, IT people don’t understand the business. This is as unreasonable and offensive as saying women can’t drive or white men can’t dance (and more seriously, it is a form of discrimination that can damage careers). Of course, some IT people do not have the business savvy to become enterprise architects, but similarly some non-IT people do not have the engineering mentality that is core to the development of a simple, well structured architecture (and vice-versa).

However, this discriminatory belief that IT people aren’t fit for business matters, often excludes architects who have grown up through the technical ranks from contributing to, or guiding the development of Business Architecture. (I have seen job adverts for Business Architects that explicitly request that candidates must not come from a technical background).

So we have two questions to answer. Firstly, who is the Chief Architect for the enterprise as a whole, and secondly, who does this person report to?

Who Am I?
I am aware from my conversations on twitter that some people have come to the conclusion that the CEO is the Chief Architect. In my opinion this conclusion is not a practical one; despite the fact that it is supported by more than one person whose opinion I respect. For me, the CEO is chief visionary (or strategist) and of course has control over the architecture, much as he or she has control over all elements of the Business.

But the CEO is no more Chief Enterprise Architect than he or she is COO or CFO. Architecture is the next step in the process that takes the CEO’s vision and formulates it in an unambiguous and concise manner to guide the “doers”. (See my previous article What’s in a Name?). In any organisation large enough to need an enterprise architecture, for practical reasons the role of Chief Architect needs to be a delegated post.

Where Am I?
If the Chief Architect is aligned to IT through a reporting line to the CIO, then discrimination may prevent them from including Business Architecture in their remit. If the Chief Architect is outside the IT domain reporting directly to the CEO, then there is a danger that they become separated from a core function that will be involved in a large element of each business change (the IT part).

For me, there is no ideal solution, but in the current climate of business discrimination against the technically minded, I believe may be necessary for the Chief Architect to be recognised as a direct report to the CEO.

If the discrimination can be overcome, and if the business has a strong technical element within its solutions, then there is no reason why the Chief Architect should not report to the CIO, and the role of CIO be recognised as more than just an IT centric one.

What Am I?
As far as hard skills go, the Chief Architect must have a broad range of practical experience, aligned to the typical proportions found in the business solutions. Inevitably, where businesses are adopting highly technical approaches to their problems, the implication is that the Chief Architect should have a rich technical understanding, and if this means they come from the ranks of IT then this should not be seen to be a problem. As far as soft skills are concerned, here is a brief (but not complete) list of those that I feel are important:
  1. The ability to communicate at all levels and to a variety of audiences in a variety of ways.
  2. The ability to influence by recognising the needs and motivations of others.
  3. The ability to see the big picture quickly and intuitively.
  4. The ability to work with uncertainty and create certainty for others to work with.
  5. The ability to rapidly assimilate new information (no-one knows everything, but an Architect needs to know everything that is relevant).
  6. The ability to make decisions (a surprisingly rare skill).
  7. The ability to solve a problem in a manner that is beneficial to the needs of all parties.
  8. The ability to recognise simplicity at an aesthetic (instinctive) level and avoid complexity.
“But techies don’t have the necessary soft skills!” I hear you cry. There we have the generalised and unacceptable discrimination again. Of course, the Chief Architect does need many soft skills, and these skills may not be abundant in the technical community...

...but that is because as a set they are not abundant in any community. What is more, close inspection of the list should reveal that all apart from the first two skills in my list would be recognised by most engineers, technologists, and IT practitioners as core to their profession.

In Conclusion
Get rid of the anti-tech discrimination (techism?) and the problem goes away. Changing reporting lines will not solve it. Perpetuate the discrimination and you prevent a significant number of excellent candidates from contributing to a key business focused activity in your organisation.

Place all your architecture activities under one single Chief Architect and thus centralise and coordinate one of the key activities you have at your disposal to transform your business. Allow this architect to embrace all elements of the Business (IT included) to develop a truly enterprise wide, fully inclusive architecture.

Before you can truly decide who the Chief Architect reports to you need to fully understand what the true role of the CIO is (and that, my friends, is a whole new topic).

Regards
The Enterprising Architect

20 October 2009

Is it All Just Smoke and Mirrors?

Where does enterprise architecture sit in the grand scheme of organisational change?

I Have Nothing up My Sleeves
One of the most common criticisms levelled at architecture is that it resides in an ivory tower obscured by clouds. Another is that architects are just “making it up as they go along”.

I feel we can quickly dismiss this second criticism, as this is exactly what architects should be doing (or to put a more positive slant on it, making key decisions, and defining strategy in concrete terms). They should, however, ensure that they are “making things up” before people need those things to do their job. Just-in-time architecture is a good thing, but it is only a small step towards just-too-late architecture, which by definition is too late.

There are More Questions than Answers
The first criticism, however, is less easy to dismiss, primarily because in many organisations it is very much the truth, and it is this issue that is key to understanding where architecture sits in the organisation. The activity that is referred to as architecture frequently fails to deliver the key things that it must provide to be of real value, and those things are answers. And now, some brief reminders:
  1. Principles are not answers.
  2. Guidelines are not answers.
  3. Option papers are not answers.
  4. Concepts are not answers.
  5. Answers that have no basis in reality are not answers.
Real architecture is not about vague concepts; it is about concrete reality. It converts the vagaries of strategy into clearly articulated and unambiguous answers that allow the doers to get on and do. One of the key goals of architecture should be to get to the answer as quickly and as simply as is possible.

Between a Rock and a Hard Place
Real architecture sits firmly between strategy and projects and is essential in bridging the gap. If architecture looks only towards strategy it fails to drive delivery. If architecture looks only towards projects, it fails to inform and challenge strategy. In essence:
  1. Strategy tells you what you need to do.
  2. Architecture tells you how to do it.
  3. Projects have the hardest job of all; doing it.
It is for this final reason that architecture must ensure that it makes this incredibly difficult job just a little easier by removing much of the uncertainty of strategy before a project encounters it. This leads me to my concluding list:
  1. By refining strategy, architecture challenges and refines that strategy, removing the conflicts and ambiguities. It turns ideas into answers.
  2. The to-be architecture allows the business to identify the largest gaps in the delivery of its vision, and this in turn helps to inform priorities.
  3. Architecture is a revitalisation of the age old skill of back-of-a-beer-mat design. If you can’t draw it, it isn’t real.
If architecture does not do these things then it is not worth doing.

Regards
The Enterprising Architect

19 October 2009

Simplicity: Art or Architecture?

Is it useful to think of simplicity as an instinct and Enterprise Architecture as an art form?

The "Wisdom" of Crowds
There seems to be a popular "wisdom" that systems (business and/or technical) develop through a process of evolution, and evolution inevitably leads to complexity. Proponents of this wisdom use nature as an example in all its glorious variety. This in turn leads to a fatalism that accepts complexity as a necessary evil, and attempts to manage it and cater for its existence.

Well, in my opinion, wisdom is rarely common, and never more so than in this case.

Natural Selection
Evolution involves two key processes. The first is change, and the second is selection. In nature, the selection process acts purely on survivability, and takes no account of cost or complexity (why should it?). In nature there is no dominant competitive advantage that encourages simplicity. In business we have the power to create the model, and the selection criteria are under our control.

So when is the best time to remove complexity? At the point of creation, of course. We need to create a force of natural selection that weeds out complexity at source.

Architecture is the first point at which visionary statements start to be converted into realisable decisions, and so architecture should be that force of natural selection. Certainly complexity cannot always be avoided. It will always be lurking in the background waiting to sneak in as soon as we take our eye off the ball, and any complexity within the architecture will only breed increasing complexity in its delivery.

If the “to-be” architecture lays out a simple future and we ensure that delivery efforts are always directed towards that destination then it will be simplicity that will evolve instead of complexity. Essentially prime responsibility lies with the Enterprise Architect to ensure that simplicity is achieved in everything the Business does.

Simplicity should therefore be one of the key quality criteria for enterprise architects to focus on, but how should we measure this simplicity?

It’s all in the Mind
Most human beings are driven by an innate sense of aesthetics. They are drawn to that which they find pleasing to the eye. Most architects are no different, and try as they might to claim a logical basis for each of their decisions; this aesthetic drive underpins much that they do.

Do not fight this.

Aesthetics is an important factor in any architecture as it allows you to use your innate skills to produce answers far more rapidly than might otherwise be possible.

Consider as an analogy the act of catching a ball. If you relied on trajectory calculations, and information relating to the launch velocity and angle of the ball, the task would be impossible within the timescales. Instead, through practice, the human brain manages this task in a far more reflexive and responsive manner.

The Eye of the Beholder
Unfortunately beauty is very much in the eye of the beholder. Just as one persons Turner prize winner is another’s childish scribblings, some find beauty in simplicity and will strive for it whilst others are attracted to complexity, and will revel in it. If you fall into the latter category you probably will not make a very good architect, until you can curb this tendency.

Another form of beauty arises from symmetry, but the case for or against this is not as clear cut. I have experienced situations in which questionable elements of an architecture or design come into being simply to balance the diagram. I have also discovered gaps in an architecture as a result of the asymmetry that their omission creates.

However, assuming that you can tune our aesthetic sense to simplicity, and use symmetry constructively, it should provide you with a powerful tool for accelerating the development of your architecture.

Architecture as an Art Form
So, am I suggesting that Architecture is an art form driven more by creative urges than by raw logic?

Yes, I am.

There are, of course, numerous metrics and processes out there that claim to provide a scientific basis for measuring and controlling complexity, and I am not denying that some of them do actually achieve that goal in theory. In practice, however, such a method driven approach is too laborious to deliver results in the short timescales typically necessary for the resulting architecture to be of value.

We need a more pragmatic, and dare I say it agile approach. It is for this reason that I would encourage all architects to develop and trust in their innate aesthetic ability in order to ensure that their architectures are elegantly simple.

It is only through this development that they will be able to deliver effective architectures within sensible timescales.

Regards
The Enterprising Architect

16 October 2009

When is an EA not an EA?

In no particular order:

It Is NOT an Enterprise Architecture if...
  1. Your CxOs don't know what it is, and don't care what it says.
  2. Your strategic thinkers do not agree with what it says.
  3. It covers one area of the Businesss without considering the whole (and yes, IT is one part of the Business).
  4. It does not start with a single big picture that can be drawn on one piece of paper (and still be legible).
  5. There is more than one of it. (Question: "Do you have an EA?", Answer:"Oh yes! We have lots!").
  6. It tells you what the present looks like without telling you what the future is supposed to look like.
  7. It tells you how to work out the answer instead of telling you what the answer is.
  8. Using it is a burden for your projects instead of a boon.
  9. It is easier to ignore it than it is to follow it.
  10. What it says has not been agreed with the business leaders.
  11. It can be interpreted in many ways to suit many agendas.
  12. No one is looking at it and saying "That's it! That's what I wanted!".
  13. You cannot implement it in stages.
  14. It takes many people and many months to develop before it becomes useful.
  15. It is deemed to be complete. (My work here is done *whoosh*).
  16. You have to understand all of it before you can deliver a part of it.
Regards
The Enterprising Architect

15 October 2009

For Sale – Bijou Architecture in Attractive Location

I have often heard architects complaining about the amount of talking they have to do. They seem to be stuck in an endless round of communication that takes place to sell the concept of architecture to detractors, to describe content of the architecture, and to explain how it should be used.

And for those that are successful in this exercise there is the challenge “Okay! I get it now – so why haven’t you done it yet?”

Architects then hold their hands up and bemoan the obvious catch-22 situation, but are they right to complain?

Put simply, no.

It’s that Pesky 80/20 Rule Again
I firmly believe that architecture is 20% creation and 80% communication. The primary role of architecture is to clearly and unambiguously articulate future strategy, and so the one thing it absolutely must do is communicate! A badly communicated architecture is a failed architecture (no matter how good the concepts within it may be).

So how does that 80% stack up? You might think it sounds like an awful lot of talking, but let us not forget that not all communication is verbal. What is more, not all communication is focussed on selling the architecture; the content has to be communicated as well, and it is in this latter dialogue that the other forms of communication can play an important role.

The Picture on the Box
As far as possible, a good architecture should be self-explanatory, thus freeing up the architect to focus on the act of selling. Communication of content should be visual supported by descriptive text, with verbal backup where necessary to break people in gently.

Clear visual communication requires a solid unambiguous notation. It is not good enough to simply use boxes and lines of your own choosing with no consistency, as you will then fail to perform one of the key tasks of architecture – to remove ambiguity. An off-the-shelf notation is perfectly good enough for most purposes and has the advantage that you then have one less problem to solve yourself.

My preference here is ArchiMate as it is simple, effective, and specifically oriented towards architecture. I feel it also has a reasonable chance of being more widely accepted, given its adoption by the Open Group. If and when a genuine standard emerges, I would recommend its use over all other options, as a widely recognised notation is of enormous value. However, in the absence of such a standard, the actual choice does not matter, as long as the notation is easy to follow, and each symbol means one thing and one thing only.

It’s not an Exam
One of my chief hatesis when reasoning and justification are included within the architecture itself. I dislike having to trawl through reams of text that states why something is the way it is, to finally get to the actual decision.

Remember, you are not trying to pass an exam. It is the answer that should leap out at the reader, not your thought processes. If your selling activities have been successful, then the reader of your architecture should already be receptive to the content. If they are not receptive, then no amount of cajoling at this stage will win them over.

For example, if you have decided that you are going to have one central information store fronted by a set of business focused services then just say that in a simple diagram. An architecture is not a crime novel – you can tell the reader who the killer is on page one without spoiling the surprise.

Selling the Architecture
And so we come to the other element of communication. Selling. Architects generally ask three simple questions at this point:
  1. The business has hired me to do this. Why should I have to sell it to anyone?
  2. I can’t possibly talk to everyone. Who should I sell it to?
  3. I’m pushed for time. How do I get buy in quickly?
The answers are equally as straight forward:

Why? Self Interest
It is essential to remember that if people don’t use your architecture, and people don’t contribute to it, it will fail and so will you.

On a more positive note, most of the people you talk to will remember you. Not many people are offered such a genuine opportunity to network with the movers and shakers within an organisation, so make the most of it.

Who? Leaders and Doers
(This is the bit where I upset various layers of middle management).

The first group of people you need to sell to is at the top of the food chain – the true leaders. If you are lucky enough to have the ear of the CEO or CIO then you have a much smaller (but potentially more challenging) task. In most cases this will not be the case, but I would strongly recommend that you need to target those with real influence. In most large organisations this is at the Director and/or Programme Manager level.

Win over this audience, and they will tell their middle managers to follow suit.

The other group you need to sell to are those who will use your architecture in anger. These are the people who will suffer the pain of a bad architecture (and this is their fear), or more importantly these are the people whose lives a good architecture can improve. Talking to these people will really test whether what you are doing with your architecture really does deliver the benefit you are claiming, so listen to what they have to say, and show that you are reacting to their feedback. The wisdom of crowds is powerful, especially when it is your wisdom.

Win over this audience, and they will carry the torch for you, selling the use of the architecture to their middle management, and engaging with you during their day-to-day activities.

In other words, catch your middle management in an architecture sandwich.

How? It’s all About Me!
There are so many ways you could sell your architecture, and the most common is the one I call “Architecture will save the world”. In this approach architects unveil impressive lists of benefits to the organisation, the customer (and now the environment), bombarding the audience with the undeniable world shattering importance of architecture...

...and get nowhere.

These architects are failing to understand one of the most fundamental elements of human nature and motivation (one I have alluded to earlier in this post) - Self Interest. Even the most generous amongst us will instinctively resist anything that will cause us pain (apart of course for the masochists who are often already architects).

If you tell your audience only one thing, tell them this: what it does for them. Understand their pain points and their motivations, and look for ways in which you can make their lives just a little less painful. Point out how much time your architecture will save them, show them how it will help them to get buy in for their work, point out where the answers to their problems are, and don’t forget to explain how their contribution to it will gain them recognition.

Point out that the decisions in your architecture have already been agreed with senior management, and by using the architecture they will not have to justify every tiny little thing they do. Use actual examples from the architecture to illustrate your points, and better still (if you are far enough down the line), bring along a willing champion who has already used your architecture.

Oops!
What do you mean when you say, “my architecture doesn’t those things”?

Maybe I forgot to mention the first step in selling...

...make sure you have something that people want to buy.

Regards
The Enterprising Architect

5 October 2009

Find me an Enterprise Architect!

Or… how do I know that the person sitting in front of me really is an Enterprise Architect?

The Princess and the Pea
Once upon a time in a kingdom far far away, the King and Queen needed a wife for their son the Prince, but there were no princesses. One windy night, a girl arrived at their castle soaked and dirty, claiming to be a princess.

Hurrah!

But what if she wasn’t a princess?

The King called for the wise woman, and explained his dilemma. The wise woman told them to place a pea beneath the mattress on which the supposed princess would sleep. If she knew the pea was there, then she truly was a princess. Sure enough, the girl passed the test (despite ten mattresses being piled one on another). A princess had been found, and the Prince was finally married off.

If only there was a similarly straight forward test for an Enterprise Architect…

Can I see some ID, Please?
Maybe there is? If you examine the job market, it would appear that there are certificates out there that do the job. A quick trawl of the internet reveals a variety of bodies offering Enterprise Architecture certification. A sample of these organisations is listed below:
  • The Open Group
  • The Federal EA Certification Institute
  • EA Center of Excellence
  • Global Enterprise Architecture Organisation
These certificates certainly claim to take some of the guess work out of distinguishing the true Enterprise Architects from the impostors, but what exactly do they actually prove?

I have to admit at this point, that I approach this subject from a position of extreme bias. In my opinion and experience, many of these certificates can be obtained fairly easily after a quick training course followed by an exam. This very fact indicates their true value (or lack of it). You do not become an engineer in a week, nor do you become a solicitor after a quick correspondence course, so why get an architect badge in this way.

Certificates of this type are meaningless, but they do create a ready market for training companies to churn out a course to an eager market (especially if you persuade a large organisation that all their people are architects, and all their architects need a certificate). What is more, an easy to obtain certificate devalues the very profession it is trying to support.

There are more Questions than Answers
And then there is the question of what type of architect are we certificating for? Most certificates are IT related, so where does the Business Architect feature in all of this? Do we need one for each type of architect, and then by whose framework do we judge that these architects exist as separate entities. There are then certificates to support specific architecture frameworks such as TOGAF.

Collecting architecture certificates could become a full time activity, and the prospective architect might still not possess the actual certificate required by the organisation for which he or she is intending to work.

Certificates (if of use at all) are best suited to specific subject areas or activities. An example from the building trade: In the UK, plumbers can (and must) obtain a certificate that permits them to fit pressurised hot water systems. Enterprise Architecture encompasses a wide variety of activities and disciplines and can be executed using many different frameworks. Certification is not an appropriate answer.

You Have Much to Learn, Grasshopper
If a certificate isn’t the answer, perhaps there may be a more significant qualification that would fit the bill. Consider an MBA - a significant and widely respected qualification in the business community. I have also been reliably informed that there exists a one year conversion qualification in Law that entitles a recipient to practice in certain areas of the legal system. Surely something like this might make sense?

Interestingly there is already at least one such course, offered by the RMIT University (Australia), entitled Master of Technology (EA). Obviously, the title implies that this is IT focused, but perhaps this is a potential route?

I do not feel that the analogy holds true here, and I have my doubts as to whether EA is really big enough in itself to justify such a postgraduate qualification? Business and the Law are two huge topics with many strands and specialisations. The addition of a masters level qualification makes sense in this context. Similarly, a masters qualification in engineering makes sense as once more this takes a huge subject to a new level.

I would expect Enterprise Architecture to start to feature in these higher qualifications (especially the business and engineering related ones) as one of many topics to be considered, but to study it as a subject in itself does not make sense to me.

Seek and Ye Shall Find
So, if I believe that certificates are not the answer and further education does not fit the bill, then how do I propose that we separate the wheat from the chaff?

What we really need is something significant that builds on the existing higher education structure. Something that reflects the educational and employment history of the individual, and that describes their wealth of experience leading up to and including their activities as an Enterprise Architect. This needs to be backed up with a list of real references from those for whom they worked, and finally we need an assessment to ensure that the candidate is a good fit for our organisation.

Hmmm…   Isn’t that a CV and an interview process?

Regards
The Enterprising Architect

21 September 2009

Is Architecture the Enemy of Innovation?

Never the Twain...
In my dealings with those who call themselves architects and those who call themselves innovators, one theme seems to come up time and again. “If it wasn’t for those guys in Architecture/Innovation (delete as applicable) it would have been fine”. It would appear from such conversations that these two disciplines are somehow mutually exclusive, and one cannot exist while the other is allowed to flourish.

As an enterprise architect, I would like to dismiss the idea that innovation is the enemy of architecture. This cannot possibly be the case, and if it were there would be no place for architecture in an organisation, as innovation is clearly essential to its continued success. Any architect who feels that innovation is the enemy is simply a person who fears change, and is therefore, in my opinion, not an architect at all.

This leaves me with the possibility that architecture might stifle innovation. Could it be true that my chosen profession is the Delilah that cuts the hair and steals the strength from the Samson of innovation? Is it possible that architecture is an overblown Goliath that needs to be brought down by the smaller, under-funded David? Or worst of all, is architecture the immovable object encountering innovation’s irresistible force?

Absolutely not! All of these views emerge as a result of the misuse of title of Enterprise Architect by those who seem not to understand its purpose at all levels. (I have posted previously on the question of what is and what isn’t architecture in my article It’s good, but is it Architecture).

What is Innovation?
At this point, it is worth considering a definition of innovation that emerged on Twitter recently as a result of a conversation started by Malcolm Lowe (@malcolmlowe) tagged as #innovation. The resulting definition is:

    “Innovation: Something that is not business as usual and adds business value”.

The implication of this definition (which I believe is correct) is that any proposed change that comes complete with a valid business case is by definition innovation. Most organisations base their entire project portfolio on work that fits this definition. It should of course be all organisations, but it never ceases to surprise me that there are still senior players in business who do not seem to understand the importance of a business case in decision making or even believe that one can be effectively created. Why in business would one want to make any changes that do not come with a business case? How can one decide how much to spend on something, if the potential benefit is not understood and quantified?

All that Glitters...
I believe this is at the heart of many of the criticisms levelled at innovation. The problems actually arise from the unmanaged implementation of ideas based purely on the “gadget” principle. A great example is the can opener. A fine example of genuine innovation, conceived of some significant time after the invention of the can itself, but essential in its use. There are then many examples of supposedly innovative can openers that are heralded as innovative, but are better described as gadgets. They provide no benefits whatsoever over the original, and are thus not innovative as they represent change without added value. A true innovator recognises that ideas generation is simply the start of innovation, providing the raw material that drives the selection process.

A true innovator also recognises that innovation is nothing without delivery, and this is where architecture comes in. If the purpose of architecture is not to formalise, articulate and enable delivery of innovative change then what is it? An architecture is not an edifice carved out of stone, to be worshipped and adored. It is a living model that adapts to change and makes it happen.

Aspire to Mediocrity? Not Me!
Enterprise architecture is expendable as an activity if all you wish to do is tweak business as usual and keep the lights on. If, however, you want to aspire to something better and stay ahead of the crowd you need innovation to create the vision and architecture to formalise the vision and to make sure that it happens. (I’ve said it before and I’ll say it again: If your enterprise architecture doesn’t make change happen then it isn’t architecture).

There is a selfish motive as well; innovation is change, and change impacts the architecture. It is innovation that keeps me busy as an architect and it is innovation that provides me with the opportunities to show that enterprise architecture is an effective tool for enabling change and thus for adding real business value.

And so, in conclusion, far from being enemies, architecture and innovation are essential components of the same process; business transformation. In anything other than the smallest of organisations, neither can exist without the other. Many businesses now have a Strategy and Architecture department, and then somewhere else exists an Innovation Team. This approach is fundamentally flawed. What we actually need is a department that maps out the future of the business by harvesting creative thinking, incorporating the credible into visionary strategy and then weaving this strategy into a deliverable to-be architecture.

A Final Thought
Hang on a minute! Let’s return to that definition of innovation again for a moment.

    “Innovation: Something that is not business as usual, and adds business value”

I may be biased, given my profession, but doesn’t that mean that far from architecture being the enemy of innovation, for some organisations architecture is innovation (and for far too many, innovation itself is innovation)?

Regards
The Enterprising Architect

10 September 2009

Business Architecture - An End to Global Warming?

Architecture – It’s an IT Thing (Isn’t it?)
I may be overly optimistic in my assessment, but there seems to be a general awakening to the idea that the goal of Enterprise Architecture is to fulfil the needs of the Business by facilitating the realisation of business vision. This goes hand-in-hand with the recognition that perhaps Enterprise Architecture is not a mysterious activity undertaken by IT, and maybe it might actually be of interest to the rest of the Business.

And so we find ourselves discussing the Business Architecture. This shouldn’t come as a surprise; even TOGAF (despite being very IT focussed) includes business architecture as a core element, but many TOGAF practitioners seem to conveniently skip over this and carry on taking an IT centric view of architecture. Also, IT is in itself a part of the business, and if IT needs architecture why shouldn’t the overall business need it too?

The 'A' Word
In his famous book '1984', George Orwell made use of the idea that if words were removed from the English language, it would be impossible for people to discuss, or even consider a concept. This technique is being used very effectively within business to suppress architecture as an activity. We are continuously warned to avoid using the ‘A’ word for fear of confusing the business. This approach is fundamentally flawed for many reasons, but here are three:
  • If you don’t have a word for it, talking about it is extremely difficult. Imagine trying to talk about design without using the word design!.
  • It is the right English word and conveys the desired meaning.
  • If you avoid using a word it will never become familiar.
I propose from now on we call it “the thing we really need to do, but are too afraid to talk about”. This should roll of the tongue quite nicely. For me the problem lies not in the word itself, but more in the hands of those using it. People fail to explain what architecture is, and then blame the lack of understanding on the word.

Let’s get over the problem once and for all… Architecture, architecture, architecture!

Archiphobia – Myth or Monster?
I believe that the fear of architecture (let’s call it 'archiphobia') arises from the belief that it is a fundamental change to the way we all work, and requires everyone to learn new skills and behave differently. This is not the case. There is no other activity (to my knowledge) where businesses think in this way. We happily leave the understanding of financial complexities to finance people, and training is generally performed by trainers. When an organisation is pushing a new product it turns to its marketing department, and when it wants a purpose built head-quarters it calls in an architect (of the traditional kind, of course). There is no fear or panic involved in the process – it is simply accepted and acted upon.

In fact, I believe ‘archiphobia’ is a myth. Certainly IT departments perceive that there is a resistance to Enterprise Architecture, but I find that this is actually a resistance to IT Architecture, and quite rightly so. Why should non-technical people be asked to understand IT architecture, especially when their only exposure to it seems to be as a mechanism by which the IT department attempts to impose its own agenda on the wider business community? The only fear of architecture that might be genuine is better referred to as ‘tropophobia’ – the fear of movement or change.

In my experience, when the discussion moves to Business Architecture it is suddenly much simpler to explain the purpose of the activity and more importantly to convince participants of the benefits. (I will post on the issue of ‘selling’ architecture later as part of an article I am writing on communication entitled “It’s Good to Talk”).

Architecture – It’s a Business Thing
So let us assume that we are going to create a business architecture we need to keep in mind what it does for us. I will post further on what constitutes a good Enterprise Architecture in a series of future posts entitled “Under the Hood”), but in summary, I always keep the following objectives in mind:

Provide a one big picture that sets everything in context.
Every architect should have a single sheet of paper (possibly a large sheet) that they can wave in the air whenever anyone asks “where is the architecture?” Many architectures end up simply being a huge jigsaw, but what use is a jigsaw if you don’t know what the picture is supposed to be? It is essential that the overall “skeleton” architecture is created first before delving into the detail of specific areas. This is analogous to planning the structure of a novel before writing the chapters.

Ensure that the future business vision is clearly articulated.
The point of an architecture is to remove ambiguity and create certainty out of the vagueness that is inherent in a future vision. Clear articulation does not imply fine detail, but it does imply that decisions must be made and gaps plugged. Do not get bogged down in what is done today; this will introduce itself naturally into the process as you involve subject matter experts. (See my previous post “To Be, or Not To Be” for more on this issue).

Consider the What first, and then the How, Why, When, etc…
Start with the services that the business intends to provide to its external customers and then consider the internal services that are required to fulfil and support these external services. Next consider the processes that implement these services and link these processes to the business information that is used. Once you know what the business wants to do, you can start to consider what organisational structure will best support this.

Always keep the principles of reuse, modularity, and simplicity in mind.
These concepts are not the sole domain of technologists and failure to address these issues in the Business Architecture will only make the job of those who follow far harder. Complexity leads to inefficiency, and increased expenditure, not to mention an increased tendency to make mistakes. Make sure that each business service is self-contained and has a clear start and end. I use the rule-of-thumb that a business service should be resolved down to the level of individual activities that could be performed by a single person between cups of coffee.

Know when to stop.
Always keep in mind that the purpose of the architecture is to bridge the gap between the business vision and the ensuing design activities. There are plenty of people who will be only to happy to sit back and let the architect do all the work. There are also plenty of people who will take serious offence if the architect attempts to do their job for them, and will reject the architecture as a whole.

A Business Architecture that does all these things will prove invaluable to an organisation and the benefits inherent in its use will become self-evident as soon as projects are launched to implement the changes necessary to fulfil the business vision.

You Mentioned Global Warming
Oh yes… I almost forgot. Business Architecture is a good thing, but is it going to solve global warming? In all seriousness, of course not. Well… Not directly, but if an architecture exists, and if that architecture clearly embodies decisions that fulfil the green elements of the business vision, then it might just help.

To clarify, it is not simply a case of deciding that “Paper Removal” or “Energy Efficiency” is part of the vision. It is necessary to turn these ideas into a big picture that brings together organisational structure, processes, utilisation of resources and implementation decisions and that conveys this clearly and unambiguously to the business as a whole.

...And that is a job for an Enterprise Architect.

Regards
The Enterprising Architect

8 September 2009

What's in a Name?

A discussion on the use and usefulness of the title “Architect” in relation to organisations and their transformation.

I Think, Therefore I am... An Architect
It would seem that in the modern world of business transformation, and especially in the technology sector, the vast majority of individuals involved in the process are architects of one form or another. This raises two questions:
  1. Do titles really matter?
  2. We are all involved in architecture, so surely we are all architects?
From my perspective, the simple answers are Yes and No in that order.

Who Cares?
In the first instance of course, the traditional architectural institutions such as RIBA (Royal Institute of British Architects) and AIA (American Institute of Architects) care very much, as they have worked hard for their titles and have sought appropriate licensed status. Their concern is that incorrect use of the title will devalue its worth in the professional world, and I have to sympathise with them. A clear comparison can be drawn with the title of Engineer which has been steadily devalued over the years to the point where few now use it.

Having said this, I do feel that the use of the term architect is appropriate in the wider context of Enterprise Architecture as the underlying meaning is the same, and it does serve a purpose in clearly defining a role that has an important place in modern business. A correctly used title helps to define our role by setting expectations as to what we do and the value we bring.

And so, as an Enterprise Architect, I care.

(As to the related issue of certification or licensing, I will address this in a later article).

What Does it Mean?
Rather than resorting to dictionary definitions at this point, I would prefer to address the evolution of the term in relation to business development. In the good old days, there was analysis and design and a great gaping hole in between. There was also business and technology and a great gaping hole in between. Slowly, the world woke up to the idea that a single individual might be able to bridge the gap between business and technology, and between analysis and design, and that these areas were not so alien to one another as some would have us believe.

There was then the emerging realisation that once more the wheel had been reinvented. The role of the Architect had been discovered anew, and people who dealt in issues other than bricks and mortar began referring to themselves as architects. The analogy is clear; the Architect brings to life the vision of the business by resolving the key issues and conflicts, and articulating these as a single big picture. This picture is then presented in a manner that has meaning both to the creators of the vision and to those tasked with delivering it, thus bridging the communication gap. The architect understands both domains and acts both as strategist and as translator.

Why the Confusion?
For me it is quite clear. In any architecture activity there are three roles being performed; Creator, Contributor and Consumer. All three participate in the evolution of the architecture, and this is where the confusion arises. The only role that qualifies for the title of Architect is that of Creator, as this is the person who processes the raw information, identifies the common patterns and devises solutions that resolve the demands of the business vision.

The role of contributor is fulfilled by subject matter experts. (I am assuming here that the creation of the business vision precedes the architecture exercise, although in reality an Architect may contribute at this level). They provide the raw information and detail that is reflected in the architecture and gives it its relevance.

The role of consumer is fulfilled by designers and developers. The architecture provides the high level information that guides the specific design activities, and in return the consumers may discover flaws in the architecture that result in necessary change. They provide the feedback that allows the architecture to evolve and improve.

Thus it is understandable that contributors and consumers alike may believe that they are acting as architects, when in fact it is only the architect who makes the decisions regarding the required changes and resolves the conflicts that arise.

And Finally…
It is therefore clear to me that the title of Architect is important and performs a crucial role in business transformation. It is therefore essential that the title is properly used, as to devalue or confuse it will lead us back to the situation where the importance of the role of architect will be forgotten and we will return to the bad old days where technology and the business were forever separate and speaking different languages.

And more importantly, I would have to find another profession.

Regards
The Enterprising Architect