Are you doing SOP’s instead of SOA?

Hi and hope you all had a great Christmas and all the best for the upcoming year!

This is the second blog in our SOA Governance series around a report that came out detailing the ten common mistakes in doing SOA that cause it to fail. I am going to address the second reason which is underestimating the impact of organisational change.  I am very much in agreement with this sentiment and we at Oracle, while we sell SOA technology, believe that SOA is really more a state of mind than anything else.  I also do not think this key issue that gets as much airtime as it should. In fact the mis-application of SOA at the isolated project level rather than the enterprise level largely determines whether you are doing what might be called Service Oriented Projects (SOP’s) or whether you are changing the culture and organisational behaviour with a truly transforming Service Oriented Architecture.

Well let’s get started. In any business initiative that involves technology there are three things that need to work together – people, tools and methodology. This is true with SOA but with an extra emphasis on the people component.  Actually organisational change is really at the heart of SOA.  If we go back to the beginning, SOA is all about making the business more adaptable to change. Why is this an issue? Because the processes and systems we have to support us are so rigid, so slow, so difficult to modify that they have become obstacles to future success.  These process and system difficencies have been  caused by many years of “oiling the squeeking wheel”. What I mean by that is mostly no-one has been really willing to tackle the problems at the core of the enterprise – they just focus on their particular project and seek to deliver it cheaply and quickly.  That is not bad in itself its just that each project done this way adds just a little bit more inter-system dependency, a little more tight coupling, a few more duplicated modules… You get the idea I think.

Why do we take this approach? Well its simple – the metrics by which we are measured encourage us to do so. Fast, cheap, self contained projects are viewed as successful. If we get kudos for this we do it again. Its also simpler than trying to fit in with what other parts of the organisation are doing.

SOA is about changing all this isn’t it? We want to streamline the organisation processes. We want a common set of data definitions. We want a re-usable library of services. We want common tools and consistent methodologies.  The problem should be now self evident - we are talking about cultural change as much as Web Services and XML and UDDI. Guess what is easier to do – change the culture or learn the SOA technologies?  

The bottom line is this – if you don’t try and change the culture of the organisation you are not really doing SOA.  How can I say that?  Well if you use SOA technologies and basically build a point-to-point architecture (so you don’t have to worry about any other project in the organisation) then you are not doing SOA you are doing SOP's.  You are just using SOA tools to build the same things you did before.  Is there any real value in doing that? Apart from learning how to build and use Web Services, ESB’s, BPEL etc - not really.

Is this what is happening? Have people invested in SOA tools but not taken a true SOA approach? Have they then expected to see cross organisation value that didn’t appear and then said “SOA doesn’t deliver what the vendor promised me?”

Recently on Kate Carruthers blog she spoke about why reuse fails. Guess what – its because of the psychology – its about the people – its about resistance to change - its about wanting to keep my project isolated and independent of the other.  Reuse is just one aspect of SOA (albeit an often overhyped one). To really make SOA work we need to think in a process oriented way because that’s how our suppliers, customers and partners interact with us. We need to structure our organisation around  these processes and measure the effectiveness of the lines of business in supporting them. If we do this the all IT projects are subordinate to the process and must work to make it efficient, flexible, fast and available.  Then and only then will any technology – including SOA – really deliver measurable business value.