31 August 2009

It's Good but is it Architecture?

We're all Architects (aren't we?)
Over the last few years the title "Architect" and its use by individuals and businesses alike to describe a variety of change activities has become increasingly popular (I would go so far as to say ubiquitous). It has therefore become extremely difficult to have a meaningful discussion about what makes a good architecture and what are the best methodologies to employ in its development. For this reason I am posting my thoughts on whether the task to be performed is actually one that requires an architecture, and if so, how complex this architecture really needs to be.

Inspection versus Intuition
It is fair to say that given sufficient time and resources, the production of an architecture that clearly articulates the future vision of the Business will always provide long term benefits. However, in the real world, time and resources are not always available, and businesses will fall back on that age old stalwart, gut feeling.

If asked by the Business to formulate a solution to a specific problem, or make a change that has already been identified as beneficial, feel free to suggest the long term benefits of a more wide reaching enterprise architecture exercise, but be prepared to abandon architecture in favour of a more immediate activity. (After all, the gut feeling of the Business may well be the right answer, and spending their money to prove them right will not be popular).

This brings us to the next question:

Repair, Renovate or Rebuild?
Before embarking on the development of an architecture, establish first of all whether the scale of the activity being commissioned justifies it. A simple bolt-on or fix to existing capability does not justify the cost of a fully fledged Enterprise Architecture. If, however, the goal is to transform the Business over a period of time then a to-be Enterprise Architecture is absolutely essential to ensure that the vision and strategy is properly articulated and all ambiguities and conflicts are resolved.

Builder, Draughtsman or Architect?
Consider carefully the role you are being asked to perform. The questions often asked by the Business require skills other than those of an architect. If asked to document current ways of working to allow others to understand and operate the Business effectively, then do not develop an as-is architecture. It is an instruction manual that is required here, and the role is better suited to technical authorship.

Remember, architecture is not always the answer to every business need.

It’s Not the Size that Counts
Even when it is clear that an architecture is required, develop a to-be architecture first (see my previous post on this matter) and resist the temptation to embark on a fully fledged, detailed model on day one. Instead, establish a skeleton architecture with breadth, and then develop the detail within specific areas to suit the priorities of the Business.

And so in conclusion, I would recommend that all architects consider first not what type of architecture is required, but whether architecture is needed at all.

The Enterprising Architect

29 August 2009

To Be, or Not To Be

This post addresses the relative merits of a 'to-be' architecture versus an 'as-is' architecture. I am assuming for the purposes of this post that the task to be performed actually requires an architecture exercise to be performed (I will cover this topic in a later post).

Where to begin?
Common wisdom seems to state that all Enterprise Architecture exercises must begin with the creation of a fully inclusive 'as-is' model, describing all elements of the business to be transformed. It is suggested that this 'as-is' model should be completed before any attempt can be made to formulate the target 'to-be' architecture.

I prefer a different approach.

The Never Ending Story
The main problem with the development of an 'as-is' model is that by the time such a model is complete the business by necessity has moved on, and the model is out of date. The model then needs to be revisited in an endless cycle. A second problem is that the 'as-is' model carries little value as it simply tells the business what they already know (and if they do not know it how is an architect going to create a correct model).

Know your Destination
My architecture activities always begin with the development of a 'to-be' Enterprise Architecture that clearly articulates the future vision and strategy of the Business and sets the direction of travel for all development activities. Such an architecture adds value quickly by converting the ambiguities of strategic vision into specific decisions. It communicates the vision to all interested parties and allows transformation activities to progress in a much shorter timescale than would be possible if time were first taken examining the status quo.

Be Pragmatic
Just like an 'as-is' architecture, a 'to-be' architecture runs the risk of becoming a cottage industry. To avoid this, focus first on the breadth ensuring that an overall framework is put in place describing the entire vision at a high level. This sets the context within which development activities can take place. Depth can then be developed on a piecemeal basis driven by specific demand according to business priorities.

Live and let Live
Always remember that the 'to-be' architecture is a living model that should be allowed to develop over time, and should be agile enough to adapt to the ever-changing business vision. Be concerned if a month has passed with no changes being required to the 'to-be' model.

Clear as Crystal
Engineering discipline is essential in the creation of the model (I would say that - I am an engineer by training after all). Remember that the purpose of the architecture is to remove ambiguity, Use of an unclear diagramming notation, or failure to use the notation in a consistent manner will simply replace one form of ambiguity with another. I will post further on what constitutes a good architecture in the future.

So When do I do an 'As-Is' Architecture?
If a business absolutely wants a high detail 'as-is' architecture, and as an Enterprise Architect you cannot convince them of the alternative approach, then you have a choice. Walk away and seek more constructive work, or develop the desired 'as-is' architecture and guarantee yourself a healthy income for the next few years - but don’t expect at the end to be heralded as an agent of change and an asset to the organisation.

The Enterprising Architect

28 August 2009

An Introduction

Who is the Enterprising Architect?
I am an Electronic Engineer by training having acquired an MEng in Electronic Engineering from Southampton University in 1989. My experiences in software development commenced prior to this and have continued to the present day in a variety of sectors including the Defence Industry, Environment Control, Document Management, Insurance, Banking and Public Sector. During this time, the industry has evolved the title of Architect and more recently Enterprise Architect to describe the activities that I undertake in my working life, and I have chosen to adopt it. In the latter stages of my career I have moved into roles that bridge the gap between business and technology and it is in these roles that I have found Enterprise Architecture to have the greatest relevance.

Why this blog?
In all of my engagements within my working life, I find that the most common initial conversation I have relates to the understanding (or more often misunderstanding) of what is meant by the term Enterprise Architecture. More importantly, I find myself explaining what Enterprise Architecture is, and what it can do for people. For this reason, I decided it might be useful for me to share this information with others, and in turn provide a forum whereby others might share their thoughts with me. More importantly, many opinions relating to the value or otherwise of architecture proliferate in literature and on the web, and I decided it was about time my voice was included in that community.

What will be covered?
My intention is to share my experiences relating to the use of Enterprise Architecture as a discipline that facilitates progress, and realises genuine business benefits. I will cover basic topics such as the structure of an Architecture, the methodologies employed, and my thoughts on what is of value and what is not. I am also hoping to prompt constructive discussion on the topic of Enterprise Architecture in order to further test and develop my own knowledge, and hopefully the knowledge of those who choose to participate in this blog, either passively or actively.

What will not be covered?
I do not intend to be deliberately controversial. I have no interest in creating arguments of a personal nature, nor am I interested in insulting or offending others in the profession. In the interests of propriety I will also not be referring directly to organisations for which I have worked, nor will I be making direct comment on the activities of specific companies or individuals (unless this is complementary in nature).

I hope you enjoy participating in this blog, and I look forward to your future visits.

The Enterprising Architect