SOA Guidance

One of the advantages of being old is that you get to see the same mistakes time and time again which means that you don’t have to think so hard, you just have to remember what happened last time! In my case I normally remember my mistakes fairly well so I end up looking pretty smart with minimal effort.

For example I can remember when component based design was all the rage and everyone was off building component based systems. We gave lots of information about a component; it is a binary standard which type’s functions into interfaces with a well known base interface etc etc. The snag was we never really gave much guidance as to when they should be used.

So one day I was phoned up by a major UK bank who had built their new customer system as a smart client (to use today’s lingo) using COM but it was running really slowly. Clearly Windows didn’t scale, sigh. Off on the train I go to visit the customer who was very proud of their all new, all component based design. Five minutes into the meeting it became clear that there were a lot of components in the system so I asked how many components there were in total. About 3000 they said! And this in a desktop system. Yikes!

I mentioned that the components were probably a bit on the small size and there were certainly too many of them. The designers pointed out, not unreasonably I thought, that no one had ever told them how big a component should be so how were they to know? Anyway after a bit of redesign (we’d call it refactoring now) we got the component count down to a reasonable level and the system worked fine.

This was brought back to me last week when I sat in a meeting about SOA. There was a lot of discussion about what SOA was: explicit boundary’s, autonomous, etc which reminded me a lot of the COM definitions but with different words. Alas there was no discussion as to what a Service should look like, how big, what level of functionality etc; this was left as an exercise for the designer. I pointed out that we needed to give guidance on what a service should look like but this was clearly not understood.

Anyway I reiterate my definition of what a service should be from my previous Blog:

     A model or abstraction

         Of independent or loosely coupled

         And business level functionalities or services

This gives a rough guide as to what should be in a service; that is a piece of business level functionality, not a function call. Please all you people building services make sure that the service is reasonably big otherwise you will have performance problems. So how big is reasonably big? The answer to that is given by Platt’s first law.

Meanwhile I wait by the phone for the first person with a 3000 services based system which runs slowly because, as we all know; Windows doesn’t scale!