Service Aversion to Service Orientation

Well I have a slightly different take on Service Averse Architecture. It is based on my experience with Banking Financial Services and Insurance (BFSI) industry and may not be generalised to other industry segments. The information technology (IT) was introduced in BFSI to improve operational efficiencies. If you look at the value chain, within BFSI, viz. manufacture-market-sell-service-retire a product or a service, IT was primarily required to take care of ‘service’ part. As long as IT expenditure was less than the operational efficiencies it provided, enterprises were happy, notwithstanding delays and budget overruns. Since IT was not commoditized then, whoever could cross the barrier to entry, benefited from IT (despite cost and time overruns of IT).

Interestingly enterprises within BFSI were always ‘Service oriented’ in their business. They did provide specific services to their stakeholders. The problem was always with the information systems they used to support these services they provided. There was a big mis-alignment between services that business provided and info systems they used to provide these services. These info systems were always monolithic and closed. It was these info systems, which distorted underlying service culture of business. And these ill-fitting information systems were result of what Todd would call ‘project culture’.

Interesting point is how business which itself operated services for its stakeholders, was taken over by this project culture and created ‘service averse architecture’ in information systems. It was mainly due to, aura and geeky culture associated with IT. The business leaders did not understand IT, but understood its importance. So they gave a free reign to IT leaders. Initial IT leaders did not have much understanding of underlying businesses, so they were in the mode, “Tell us exactly what you want done, and we will do it!” Unfortunately what business wanted done was always a small piece of big puzzle. Hence multiple monolithic closed information systems, handling parts of services that business was delivering to its stakeholders, were developed.

Now that IT is commoditized and barrier to entry is lowered considerably (well buying a mainframe used to be a momentous decision for CEO and now any IT related decisions are hardly made by CEOs), cost and time have become important. And, IT has penetrated the other aspects of value chain, notably market, sell and even manufacture (which uses business intelligence tools). So IT has become more important to business at the same time business has become less tolerant of IT’s pitfalls.

Also, over the years IT folks started understanding business in more details and they started asking “Why do you want it done this way?” rather than just following orders. It is, what my friend Ravi would call a shift from output oriented to outcome oriented mindset. So when business and IT finally started coming closer to each other, they started appreciating need for alignment between two. SOA in my opinion is vehicle for that. SOA helps IT recast itself, in business terms.

Most of the organisations out there have ‘Service Averse Architecture’ within their information systems. And the organisations that are doing transitions to SOA are the ones where the IT leaders have made that paradigm shift from output to outcome-oriented mindset. These are the leaders who understand importance of business and IT alignment and how SOA can help achieve that.

Unfortunately leaders buying into SOA vision is just part of the story. It would mean enterprise is willing to make transition to SOA, but whether it will be done successfully or not, depends on changing entire organisational culture from undue competition to more of trust and co-operation.

Commitment v/s involvement

A recent conversation with one of the project managers tasked with delivering services for enterprise (SDT -services delivery team), reminded me this old adage about commitment and involvement. The project manager said, "He is delivering to agreed project requirements and has put in a change control in place to handle the churn in requirement." So he believed SDT was totally involved with project for success of project and SOA initiative. The old adage goes thus, "In a breakfast of ham and egg, the chicken is involved but the pig is committed". What we need is not involvement but commitment (kind displayed by pig) from SDT.

The requirement for a project invariably change. The service delivery team, being a subcontractor ro project team, is going to be last team to know about the changed requirements and the first one expected to be delivering its part due to changed requirements. So the SDT is going to be the fall guy for all the problems the project team is going to face, because SDT will not be able to deliver after being placed in such a precarious position.

So what we need from SDT, is commitment to project than involvement with project. Knowing and anticipating changes to requirements, from services perspective will be a key challenge. The major reasons for requirements changes I have seen in past is becuase,

• Wrong people giving requirements
  
• Strategy not getting properly articulated down the line, leading to wrong requirements
  

The first part is addressable by project team by involving all stakeholders, appropriately. Its the later part which results in major problems. Most business projects are result of some strategic decisions from executive. The way startegy gets articulated from top executive down to people executing projects, is nothing better than 'chinese whispers'. Every link in the chain adds their own spin, and overloads elements of strategy with their own agenda. The SDT, being an enterprise wide intiative, should be able to rise above these spins. So SDT needs to be committed to project success by being on par with projects, rather than being happy with a subcontractor status. Thats the only way a SDT approach will work in a large enterprise. SDT should be treated as one of the startegic projects undertaken by business, than a mere service provided by IT for rest of the projects.
This will guarantee SDT's commitment (of pig variety).