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

No comments:

Post a Comment