Any conversation about enterprise integration seems to automatically end in a sales job for service-oriented architectures.
The problem of integration has been with us since the first person decided to buy a non-IBM-mainframe product, and possibly even before that. You buy a new application with specific functionality your company needs, and then you have to move heaven and earth to get it to talk to and work with your existing applications and data.
Yet, while integration is a headache for IT people who have to consider the impact on their existing infrastructures before buying the best product that meets their needs, it is a very lucrative market for service providers. The problem integration presented in the past was that the project never ended. Having made sure your systems talked to each other and understood each other's data, someone would upgrade something and throw a spanner in the fragile collective.
The industry then came up with a new set of options. Ideas such as the enterprise service bus and eventually the service-oriented architecture (SOA) appeared. Whereas the integration projects of the past were reactive exercises in the face of non-standard systems, SOA-type solutions are proactive, assuming the architecture is pre-planned and therefore has components that are plug-and-play ready (almost).
That is the theory, anyhow. Not many companies have the privilege or desire of rearchitecting their infrastructure in the hopes of easier integration in future. That said, given the complexity faced by many companies, the move to an SOA is not really an option. The world according to SOA architectures is coming, sooner than most expect.
Mark Neethling, divisional manager at Bytes Technology Group notes there is a difference between integration and SOA. "To evolve to an SOA one needs to integrate, so the one is a prerequisite to the other," he states. However, because of the unclear definition of what an SOA is, due to the fact that it is still a maturing market, Neethling says many corporates claim to have an SOA or be in the process of implementing one if they have some form of integration on the go.
CA is a prime example. Wilhelm Hamman, at CA Africa notes that having bought a number of companies lately, CA has decided that an SOA is the way forward if it is to streamline its own IT infrastructure and business processes as it integrates various companies into one. There is no other way to handle the task. The goal is to take the company's multiple applications, processes and databases, and create common processes, data and workflows to streamline the customer experience. CA is in good company, as Hamman notes that there are continual enquiries and questions about SOAs from customers.
To the basics
While CA has a clear idea of what an SOA can do for its IT and business processes, not everyone is that fortunate. Exactly what SOA is depends on who is defining it. Depending on which research company one chooses, anything between 20% and 80% or corporations out there have or are implementing an SOA, further highlighting the lack of understanding of exactly what this new animal is. The reality is probably that some form of integration fits enough of the overall definition of what an SOA is that companies feel they have taken the plunge.
In general, some opt for a technical definition of the SOA, incorporating the service bus, for example; others go the opposite extreme and define it in terms of business processes that just happen to be enabled by technology.
Oracle is in a good position to understand this as it grapples with the major acquisitions it has made in the recent past. Mohammed Cassoojee, senior executive at Oracle SA notes that the company is not trying for a big bang SOA approach for itself or its customers. He says Oracle advises a phased approach where a company identifies where it can start and what components it needs to update or buy, following the decision by implementing a step-by-step approach to migrate to a full SOA.
An important trend Cassoojee mentions is that IT decision making is moving into the hands of business. Not only are business leaders having a larger say in what happens in their IT infrastructure, they are demanding IT empowers them to be able to change business processes or implement new ones quickly without having technology holding it back. So, at the end of the day, technology will be an irrelevant utility, and whatever it is called and however it is defined, it is the business that will insist on the SOA because of the flexibility it delivers.
And this is where Lenore Kerrigan, HP software business unit manager offers a very non-technical definition SOA, saying "SOA is about creating a positive business outcome, growing profit or increasing the number of customers one has and minimising business risk. And IT's job is to support that."
This means moving beyond the complexity inherent to integrating components, data and functionality to deliver a business process. But more than simply delivering a process, it must be easy to use and change as business needs, without reinventing the wheel.
Neethling expands on this by defining SOA as 'a technology response to a business requirement'. Business wants a service, it wants it to be broadly available and it wants staff and customers to trust the service and use it wherever they are and via whatever interface they choose.
Standards and governance
CA's Hamman notes that a key aspect for business is the ability to incorporate whatever functionality and data it needs into the final business process. What this means is that vendors need to work on their applications and SOA architectures to ensure they are designed according to set standards that will allow data and functionality to interact easily with others - something often promised but seldom delivered in the past.
In addition to standards, governance is another must-have if SOAs are to deliver. HP's Kerrigan says that SOAs are hitting and will hit organisations and if the basic elements are not in place to support the greater architecture, disaster is guaranteed. Moreover, without the appropriate governance and oversight, an SOA project will end up as a combination of the worst failures of integration - which means money and efforts down the drain.
"It is a matter of risk management," says Kerrigan. "SOA is something everyone must do eventually, but without the oversight and governance processes in place it can be an enormous risk." And risk is something business leaders need to effectively mitigate if they want to keep out of trouble (and employed).
This is all the more important as we move to an era of commoditised software. Cassoojee notes we are entering a period when companies will be able to define their own hymn sheet when it comes to software components they need to create processes. They will not be hamstrung by the limitations of software today and will pick and choose from the best on offer with the knowledge that everything will slot into place without the current hassles of proprietary software. This flexibility is strongly supported by the SOA model and it demands a strong governance model to ensure trust and reliability of the final solution.
As the IT industry matures and becomes ever more strategic and integral to business, concepts such as the SOA will become common due to the flexibility it delivers. However, it is important to realise that SOA is not a technical architecture, nor is it a business process. SOA is a combination of business processes, technology and governance standards. Local industry commentator, Paul Booth warns that while SOA may be the answer, "it is not an easy answer, nor is it a short-term answer, and it is certainly not a cheap answer".