What is so hard about SOA?

One of the sessions in the Cortina Software Architecture Workshop was entitled What’s so hard about SOA? In this session, Dan North tried to find out whether there is any substance behind the hype that is SOA. During this session, I had an epiphany when Dan explained the perfect SOA metaphor. Basically, it goes something like this:

Imagine you’re an employee at a large company, and you would like to take a holiday. You fill in the standard holiday form with your name, department, employee number, signature of your boss, holiday date and other stuff. You will probably fill in only half the fields, because the other fields don’t affect you, or you don’t have the information necessary to fill them in. You send this form to the Human Resource department, who take the request into consideration.

After a couple of days, you’re probably wondering whether your holiday has come through. So you call the HR department, and ask them how things are progressing. They tell you that they are working on it right now: the request has been granted. They want to know whether you want to use the company’s travel department for the trip you have planned during the holiday; you tell them no since you’ve made your own arrangements. You put down the phone, and wonder what Hawaiian shirt to wear in Barbados.

For you, the thought of your upcoming holiday made it a nice experience. For the HR department, your form resulted in a lot of work: all in a day’s job. If your worked at the HR department yourself, processing your own form, you probably had both experiences, even though it is just one form you worked on.

Now here’s the analogy: a Department in a company stands for a Service: the HR department in the example could be seen as a Holiday Service. Employees within a department are components or classes. You requesting your holiday stands for a class that uses the Holiday Service. To make the request, you follow the Service Contract: the holiday request form. The specific form you filled in for your holiday is a Service Message. You submitting the form to the HR department is an Asynchronous Request. You calling them is a Synchronous Request. Both types of request have their value, depending on the context.

The great thing about this analogy is that you can expand it further. For instance, you could add a little post-it note to the form, telling the HR department that you would like to be called back when they have more questions. Since the post-it isn’t part of the standard form, the HR department could ignore it all together. If a lot of post-its are added to form, they will probably create a new form that adds fields for all the info people have been putting in the notes: a new contract. This could mean that the old forms aren’t valid anymore, but HR will probably still accept them.

I love analogies like these, because they show that SOA shouldn’t be so hard. It’s just a form for a holiday.

One Response to “What is so hard about SOA?”

  1. Leo Says:

    Hey Arjen,

    Yes you are right on with the analogy, but from my experience the technical and functional components of a SOA based architecture are at best only half of whats needed. If on implementing you forget to give attention to the procedural and organisational aspects it is likely to fail in my opinion. So still SOA is a complex set of related tasks.

    Greetz Leo