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

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.

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.

The Enterprising Architect