“SOA is super-hyped”

Service Oriented Architecture (SOA) has been around for quite a while, but what does it take to really get started? Gautham Viswanathan, Vice-president of SOA at Tibco Worldwide, spoke to Dominic K about the architecture and how to approach it systematically

Gautham Viswanathan

Are there concrete reasons for organisations to adopt SOA?

The promise of SOA is that it can transform the IT assets of a business, making it possible to do more with less, and faster. It is a key development towards the goal of a truly agile business where new initiatives can be deployed as needed—with the necessary underlying IT support—with minimal delay.

The goal of SOA is to primarily expose an organisation’s computing assets as re-usable services that can communicate and integrate more readily; it is also to eliminate the integration spaghetti that exists in most enterprises today.

An SOA provides a common communication framework (to organise and describe capabilities provided), usage policies and service provider locations without exposing the details of how the service is implemented. It is a systematic approach to integrating existing applications and developing future ones.

In addition, SOA, and more specifically Web services, is seen by many as tantamount to conducting inter-enterprise business transactions. Deploying Web services as part of an SOA will greatly facilitate the constant rate of change that is required to support B2B processes that can span numerous trading partners.

How does an organisation know when it is ready for SOA?

Many enterprises have experienced some form of SOA, although these previous attempts have likely been departmental or tactical in scope. I feel that they haven’t realised the full benefit of SOA, and will not do so until they can extend service re-use across departmental boundaries.

This is why many large enterprises are in the midst of forming enterprise architecture teams and SOA centres of excellence to establish SOA as a development discipline throughout the enterprise. Aside from installing the necessary technologies, achieving re-use as a practice through education and accountability is required if the compelling ROI that SOA promises is to be realised.

Because of the software engineering ‘feel’ of SOA, there is a tendency to look at it as delivering purely internal IT savings. However, once the more significant returns of business effectiveness and agility are taken into account, SOA looks much more positive.

Can the benefits of SOA be reaped with a partial implementation?

SOA does not need to be fully implemented and deployed before benefits accrue. In fact, SOA is ideally suited to incremental deployment, where investment can be made on a step-by-step basis tied to individual business projects. Returns also start to be realised on an incremental basis, thereby removing a major element of business risk and greatly increasing the likelihood of acceptance of the business case.

By considering these factors, it becomes possible to make a strong case for adopting SOA and deploying it in all new projects. However, in order to avoid surprises down the line, enterprises need to not only implement SOA concepts but also put into place an enterprise-class SOA infrastructure. This infrastructure makes SOA real, useful, and transforms it from being a concept into a true enabler of the agile business.

Is there an ideal way in which to go about deploying SOA and establishing an SOA governance process?

Enterprises should not go ahead with SOA as a three-year or five-year plan. It is a long-drawn process. It is a journey.

Governance provides an overarching structure to prioritise and then support enterprise business objectives on a strategic, functional and operational level. The governance model defines ‘what to do,’ ‘how to do it,’ ‘who should do it,’ and ‘how it should be measured.’

It defines the rules, processes, metrics and organisational constructs needed for effective planning, decision-making, steering and control of the SOA engagement to meet enterprise business needs and challenging targets. The SOA project team is responsible for creating this governance model.

Are there factors that help define the appropriate governance structure?

The questions to be analysed would include: What business change does the enterprise expect from SOA? Can it make better use of its existing infrastructure at lower costs? Does it target the new business and interaction models, or does it target both?

The organisation needs to examine which roles, responsibilities, structures and procedures exist to allow business prioritisation and IT funding, planning, steering and decision-making, and how it can develop skills and leadership competency. It should also consider which principles and guidelines are necessary to optimise the alignment of business and IT.

It is necessary to determine the appropriate way to structure the business-to-IT relationship while keeping consistency and flexibility to allow the organisation to quickly adapt to new changes. It also needs to consider what the appropriate level of standardisation of services will be, as well as the service definition and the description.

Some other factors to be analysed include how the organisation would control and measure services, and what business performance indicators need to be monitored. Also, who should monitor the same and authorise changes to existing services.

What do you recommend on the governance front to a CIO or IT architect planning an SOA project?

To sustain the focus on business needs, it is essential to define the strategic direction for developing an SOA. Both business and IT units need a common understanding of business strategy and objectives.

Governance principles and guidelines form the fundamental basis for any decisions. They shape the solution area and define how business and IT units collaborate. Everyone involved, from executive management to individual project personnel, should carefully understand and agree upon these principles. We believe that an accepted and formalised governance model is crucial to achieving business objectives. For fast and high-level acceptance, it is essential to start from the existing enterprise structure and adapt it to the SOA roadmap.

Are there any hurdles in implementing SOA?

SOA is super-hyped. A lot of the time CIOs want to get into some sort of SOA project execution even though few among them understand SOA and its complications. Most companies have started realising that it is not something that can be bought at the store.

Many corporations and enterprises that are shifting from client-server technologies to service-oriented architectures face technical and cultural challenges. The technical challenges arise in large-scale deployment where the complexity is high.

This can be overcome by adopting a project-based approach. Enterprises on the SOA journey also see changing roles for developers and architects, and a blurring of the lines between IT development and operations groups which is more of a cultural change. Many companies are now setting up SOA centres of excellence to overcome this hurdle.

There are foundation steps to evolve as an SOA enterprise. Enterprises need to take baby steps. Some of the steps and initiatives to enter the SOA world would be data integration, BPM (Business Process Management), initiatives on integration at the portal front, and multi-protocol message transport and communication.

The integration today is based and focussed on ESB (Enterprise Service Bus). ESB is looked upon as a problem solver for SOA implementation. Messaging continues to get interesting with EMS (Enterprise Messaging System). ESB and BPM are the two big things in SOA that organisations would be looking for.

Is it true that SOA puts power back in the hands of the IT department?

The existing IT infrastructure and how businesses establish IT requirements are both mired unnecessarily in costs. My observations currently reveal a shift in power. What I mean by this is that enterprises and corporations nowadays are dominated by various applications like ERP and CRM.

Organisations have to differentiate themselves based on the standard applications and packages they implement. To change the standard package the enterprise has to put in a lot of money and time.

Enterprises can customise most of their applications based on their business demands, and then combine all of them within the same architecture. This can be done in-house. It is what I call a shift in power.