How much architecture is enough ?

Design vs. Styling

I listened to a presentation by a car designer from Landrover who defined the difference between car design and car styling.

He defined car design as working from the ground up to make sure that all the "big bits" were in the right place...his premise was that if all of theses are in the right place then the car drives well and looks good.

He defined car styling as what you need to do to a car that has poor design, you have to add bolt on parts and features to make the user believe that it is well designed when it is not....

This made me think about the world of IT where much time is spent on "styling" and not enough time is spent on good "design". It is the role of architecture to try to change this balance.

What makes a good IT Architect

Looking on the The Pragmatic Architect blog the thread on what makes a good architect brought back some interesting memories of the conversations I have had in the past on the subject.

From my experiences the answer is that anyone can be an architect because the term is used in IT to mean almost any job that is carried out….I am sure that developers (who were called programmers) will soon be called code architects.

You therefore need to qualify the term before you can describe what one is in IT. Most of the architects discussed in the Pragmatic Architecture thread are what I would term Solution Architects (in my definition these are the people who are responsible for making sure that the whole solution is effective end-to-end). The architecture types include Enterprise, Application, Functional, Data…..basically the list goes on and on……….

The key to me about a good architect (what ever the specialisation) is that they are able to think of requirements at a conceptual level first and then drive to a solutions – i.e they don’t just churn out the same design over and over again. This is what makes Normal Foster a great architect – would you make a building look like a huge phallus. Along side these architects you need good designers, structural engineers and site managers (we don’t have good words in IT for these yet) and in my opinion most “IT Architects” fall in to this category…..and a good job too as a world full for truly good architects would achieve nothing….

Farmyard SOA

I spend much of my time explaining the benefits of Service Oriented Architecture to people who just want to understand what it can do for them - most rightly don't care about the how.

Recently I was discussing this with a friend who told me about an analogy he has heard about for Business Intelligence users based on the characteristics of animals. I have taken this concept and applied it to SOA.

You have 4 basic animal types
* Sheep
* Cows
* Pigs
* Foxes

Sheep and SOA
Sheep are simple animals and will do simple things over and over again, they want simple tasks made simpler. So SOA can help here by combining process steps together into composite applications which lead the sheep by the nose through the process.

BENEFIT : Therefore it takes less time to train the sheep…but watch out sheep because the next step is to fully automate these simple tasks using Business Process Management (BPM). So BPM is a wolf is sheep’s clothing!!!

Cows and SOA
Cows are quite intelligent, having to learn when to be milked, how to get into the milking machine and can decided when to be milked. SOA can help here by collecting the process steps together and providing clear guidance on the process paths that are available, decisions are required but the choices are limited.

BENEFIT : Again this means less training is required and the cows can learn from the wisdom of the herd……eventually things can get so easy you can employee sheep (which are obviously cheaper than cows)

Pigs and SOA
Pigs are pretty intelligent but left on there own will consume everything that they can eat (access). SOA can help by collecting all the services (both transaction and information) required to carry out a task into one place – think of it like a pig pen. This means that data is only delivered in the context of other information e.g report on credit history for a customer when looking at that customers blocked order instead of running a report showing all credit histories, just in case.

BENEFIT : Once again the training required here is lower, the quality of decisions is high as they are made in context and the system resources are lower as only the information used in collected

Foxes and SOA
Foxes are very smart and will work out how to work round obstacles placed between them and the chickens – imagine chickens as business objectives. SOA can help here by giving them a vehicle to innovate new ways of doing business that enable them catch more chickens. They don’t have to run these new innovation off system and wait for IT the catch up.

BENEFIT : Now we get to the meat of SOA – this ability means you can release all of that innovative power (believe me it is there), which is being suppressed by a slow and cumbersome IT department. You can enter new markets, streamline processes (converting cows into sheep) - like having one massive Excel spreadsheet.

The reality is that most jobs are a mixture of sheep, cow and pig tasks and the beauty of well designed SOA is that it can be brought on stream task by tasks. So all you need to do is work out which animal(s) will benefit the most and start here…….my advice is to look to help the sheep first.

Introduction

I have finally been nagged into starting my own career related blog having used the media as a fun way to communicate with friends.....so thank you Sam (www.sol1.blogspot.com)

For many years I did not consider myself an architect of any kind, I was proud of my practical delivery roots that focused on delivering "real" things. Then with the help of friends I started to realise that actually I was an architect after all.....it was a bit like learning you are gay and coming out of the closet !!!

I am still a practical (or pragmatic) architect and this blog will be used to share my views on the best and worst of the architecture I see.

I currently work for SAP as the Head of their UK Business Technology Architects and before this I worked for glue:, Plaut (UK) and Conoco. The opinions expressed here represent my own views and not those of my current, prior or future employers.

So let the fun begin.......