After hosting round table discussions at the recent Australian Architecture Forum, specifically about using Business Capability Modelling to help prioritise SOA initiatives, I am even more confused about the meaning and relevance of the term SOA (Service Oriented Architecture). It became pretty clear to me that I was not the only one.
As we dug deeper and deeper into our examination, it was evident that when you talk about SOA, it can mean different things to different people. You can’t talk about it in isolation either. The same big ticket items kept coming up again and again – IT governance, quantifying business value, business and IT alignment, IT charge back and funding models, to name a few. These are non trivial issues that need to be addressed before you jump into restructuring the way IT Services are delivered to the business.
We really need to look at the business’s strategic intent before anything else. The technical implementation of SOA is neither here nor there from a business perspective. The first thing we should do is drop the term SOA. It is over hyped and drags the conversation down to a technical implementation level. We need to describe the current and desired business state through the use of Business Capability Modelling and Business Process Frameworks, and then look at how the desired business capabilities can be best enabled through the use of Enterprise Architectures. The Enterprise Architectures consist of Business Process Models, Application Architectures (which may consist of ‘SOA’ type technical implementations) as well as supporting Information and Technical (Infrastructure) Architectures.
Ultimately, we should be striving to transform our businesses to achieving agility and efficiencies by breaking down the old technology silos. Maybe a better way of describing what we are trying to achieve here is Business Service Orientation.