About a month ago, maybe a bit more, I wrote a blog entry on SOA; Service Oriented Architecture.  I have had many sleepless nights since then because in reading back over that article I see that I was actually pretty positive about SOA. 

There’s nothing wrong with that, of course, except for the fact that I am, as I have admitted a number of times, a cynical idealist, and my experience has been that anytime I am more or less positive about anything that can’t be eaten with a marinara sauce or drunk with crushed ice, that I am wrong.  So I have been thinking about SOA again, trying to decide if what I said was really true or if I was carried away in the moment.   And I guess I have come to a couple of conclusions. 

I do think SOA, even though it is a rehash of what was proposed in the 90’s, has merit and that it may be that technology will allow it’s promise to be fulfilled this time.  The question of course is – what is that promise?  Simply that we will develop applications using truly reusable modules that will make application development easier and more uniform.  The problem with SOA however is that once most of the people who write about SOA get past that statement they start to subvert all that is good about it. 

First, I am sick and tired of hearing the words ‘SOA’ and ‘web services’ used in the same sentence.  Once people are finished saying SOA is about reusable business modules they immediately start in on how SOA is a call to use web services to GUI-ize whatever applications you have.   I am not against a windows or browser based format, but I don’t see it being at the heart of what SOA is.   I think it is always interesting that those who see the benefits of green screen applications are always labeled as out of touch bigots but those who refuse to learn anything beyond the windows format are seen as visionaries.  Both formats have their place and value.  To cast SOA as a device to bring us all to a GUI world is to limit what SOA does and to limit our ability to respond to business problems. 

Second, I will go one step further and say that I am getting very sick of the word ‘services’ used to describe SOA.  (Yes, I know the S in SOA stands for Services but that’s the beauty of acronyms – you can just say the letters and forget what it really means.)  One recent article that I read said that SOA made use of services instead of operations.  Like that’s a good thing, where ‘services’ are something wonderful and warm that is being done for the application vice ‘operations’ which are cold, machine like functions being forced on the application.  As Orwell would have us chant ‘Services good, operations bad’, but we know how that turned out.  The simple fact is that we should be using marketing neutral terms to describe what is being done, and so I propose replacing the term ‘services’ with the word ‘thing’.  SOA uses ‘things’ to accomplish it’s mission.  It’s a computer program for goodness sake, not the Salvation Army. 

So, what is SOA?  In my mind, SOA is a way of designing modules so that the module has (more or less) one function so you can easily understand what the code is doing, with minimal coupling to the modules that call it so it can be reused easily, and it separates control from business logic from display formats to make it easier to use different display methods.   

In other words, SOA is not about the web (or green screen), it’s not about services, and it’s not about the Red Sox Nation (OK, no one has suggested that tie in yet, but as a die hard Yankee fan I am just sick of hearing about that too).  What SOA is about is small, easily digestible modules; separating control from logic from display so that you can reuse the module with the greatest ease; and allowing you to define sensible modules and then link them together using a common or at least easily understandable interface. 

That’s what SOA means to me.  Am I right, people?