The SOA Camel

April 16, 2008

There’s a well known saying: “a camel is a horse designed by committee.” The saying has been attributed to Sir Alec Issigonis the car designer responsible for the hugely successful Mini. Design was his chief concern – as it is for Enterprise Architects – so it pays to heed his warning.


There are plenty of people with the word “architect” in their job title: information architects, business architects, infrastructure architects, software architects, solution architects and enterprise architects – just to name a few. There is no doubt that each of these people has a unique skills set and speciality. When you’re building something as complex and far reaching as an SOA it pays to consult with everyone you can to make sure you’ve got all the bases covered. In other words, the process of designing your SOA should be inclusive. But there is a fine line between being inclusive (which is good) and designing by committee (which is bad).

When you get a bunch of highly skilled technical folk in a room “groupthink” is definitely not a problem! Each person passionately explains why his area of expertise is the most important issue. The Information Architect says “it must be about the data!” while the Infrastructure Architect says “we must be able to manage this – that’s the most important thing!” If you try and reconcile the disparate view and try to reach a consensus you”re on your way down the “design by committee” path. The resulting design will be needlessly complex – and the whole process will take an excessive amount of time.

So how do you leverage the valuable knowledge of everyone concerned and keep everyone on-side, while actually delivering a design that is more like a thoroughbred racehorse and less like its fellow ungulate – the lumbering camel?

A colleague of mine came up with a brilliant solution to solve this problem. Rather than debate each and every decision he decided to spend some time devising a “Decision Framework”, which is basically a list of criteria for resolving conflicts. He was working in the software design space with senior developers and I’ll use his examples but the same could be done with architecture decisions in a room full of architects.

Criteria 1: Consistency and readability of source code is important so we will standardise on the coding standards used by Microsoft.

This means all arguments on the naming conventions of classes, projects, variables, namespaces and the like are avoided.

Criteria 2: We will use standard libraries from Microsoft”s Enterprise Library.

This means (for example) that all arguments on the “best” way to connect to a database and execute commands will be nipped in the bud. We will do it the way the Enterprise Library does it. We wont roll out own code and we wont download other toolkits or libraries. It will also avoid arguments about exception handling, caching, logging, security and everything else covered in the Enterprise Library.

You’ll note that the criteria in the decision framework are clear and unambiguous. No fuzzy “motherhood” statements which are open to interpretation such as “we shall use best practice”. Also, the criteria are hard to argue against. You can’t argue that “Microsoft is wrong.” You may have a personal preference which contradicts Microsoft but that doesn’t make Microsoft’s idea wrong.

Once you have a decision framework in place you need two things. Firstly, you need to get everyone to agree that the criteria in the framework are sound. This ensures that any decision made with reference to the framework will be well thought out and logical – and cannot be accused of being a “whim” or “personal preference”. Secondly, you need strong leadership to make sure everyone follows the “rules”. When there are opposing views, they are each measured against the decision framework. And the “winning” opinion is the one the most closely resembles the criteria in the framework.

Advertisements