What is SOA?

Day before yesterday I was participating in a discussion about SOA in a meeting with architects with different technology backgrounds. These backgrounds include Oracle, Microsoft, IT Infrastructure (Windows, UNIX and Linux), IBM and SAP. Generally the discussion was about what is SOA, or what worked and did not work design, implementing a SOA. Questions were raised like does SOA fulfill promises like business agility and reuse for instance?

Well last week in San Francisco I heard Rob Daigneau say business agility is a bogus claim, because of it is not quick or easy. I agreed on this so entered this remark into the discussion with an Oracle architect, who answered he disagreed with me hence his practical experience at a customer showed it can be quick and easy. Since I do not have that much experience with SOA in practice other than one project at local government organization so to speak, I could only bring in that experience, where it did take a long time and was not easy at all. So there you go different experiences, feelings and views on the matter. There was a good point made by John Evdemon session at SOA and BPM Conference, where he made a comparison between myths and facts of SOA and one of them was that SOA’s are like snowflakes (they can hardly be compared). So thinking about this, I have to change my view a bit about business agility. It can or cannot work out given a certain situation at a company, where one tries to implement a SOA to have its promises delivered directly.

My experience lies more at start of implementation of an SOA, then a full project lasting a couple of months (or years) where a SOA is implemented completely and business agility or reuse can be noticed. Although the speaker Rob has a lot experience in the SOA field, so his argument must come from somewhere (I will ask him, email probably).

Ok back to the discussion, what is SOA? In my view SOA is where functionality from any kind of system is exposed in services, which can be composed into new services that can support a process which on its turn can be consumed. Like the model I saw at Microsoft SOA and BPM conference, where the model expose/compose/consume was explained by speakers like John Evdemon and John deVadoss. An infrastructure is needed to support the exposed and composed services, which have to be available to consumers like for instance portals, mobile device and packed apps. Besides the infrastructure it will also need procedures to help with changes to services, like versioning and maintenance. I also think that my view on the matter is not complete, because there is more to SOA than I just mentioned. Future discussion with the architects in my company Inter Access will help me to get a better view on SOA and will eventually give me a full understanding on SOA. Also one architect gave me a good reference to an SOA book I have not read yet. It is written by Dirk Krafzik e.a. and gives a more pragmatic experience on SOA than book from Thomas Erl for instance. Any comments from you blog readers are welcome to this subject.


Labels: