A major gripe of mine about service oriented architecture (SOA) is the lack of a clear definition of the term by the software industry.
My view is that SOA is not really about technology, but rather that it is a means of solving a set of enterprise issues, mainly to do with business processes. However, the vast majority of suppliers talk about how SOA uses standard protocols, and how the use of XML enables information to be handled in a coherent manner.
The techies may like this, but are not in a position to go to the business and say, "I know I have promised you this before, but this time I mean it: there is a new technology that is great and will solve all your problems. All we need to do is rip everything out and start again."
Even though the majority of suppliers try to show how existing systems can be made to work with SOA and be used within the greater SOA scheme, it is very unlikely that many companies will show much interest based on these promises.
With this in mind, it was nice to see IBM at its Impact conference begin to focus on looking at what SOA does for a business, and at providing products that are firmly aimed at the business leader.
IBM takes five different "entry points" to SOA (business process management, people, information, connectivity and functional reuse) and presents the possible benefits of SOA in terms that should resonate from a business perspective.
For example, functional reuse is not touted as the universal answer to the developer's dream, with the developer having a multitude of functional components available to them for use within their overall system.
IBM is one supplier that has realised that this has been tried over and over again, from the mainframe days through to computer-aided software engineering tools and approaches such as Corba. Developers like developing, and as a result reuse is not as high on their list as it possibly could be.
However, from a business perspective, reuse speeds up time-to-market, improves manageability of the business environment and means that a single functional update can benefit all processes dependent on that function. This all provides definite business value and makes the sale of SOA much easier.
Another example is using master data management. This is a complex matter that technical experts are only just beginning to get to grips with. However, when it is explained to businesses as a means of ensuring that core information used commonly across an organisation and its value chains (such as customer information, product numbers and HR information) is maintained once and once only, without the need for highly complex data manipulation, business leaders begin to show interest.
When they realise that this ensures that the information the business uses will always be up to date, and that contracts will not be drawn up using dated information, it suddenly gains commercial value.
However, there are still blank looks from many business people when SOA is mentioned. Although there has been great interest in trying to understand SOA from a technical perspective, little impact seems to have been made at the business level.
For IBM, it helps that IBM Global Business Services leads much of IBM's SOA work in large organisations, helping businesses to understand the various opportunities that can be delivered using SOA. IBM Global Technical Services then helps in the implementation and management of SOA infrastructures.
This approach should have a lot of impact at management level in large organisations. But getting the SOA message through to smaller organisations remains a major issue.
Increasingly, I expect to see business functions being provided as discrete services available to the mid-market and SME through a software as a service model.
Already, Google is making functions such as Google Maps available, which can be utilised as a base for making geographic information available through combining applications.
Google is also providing more comprehensive systems such as Google Office, and has signed a deal with Salesforce.com. This partnership enables Google to provide not only Salesforce.com's helpdesk systems, but also use its Apex development platform to provide other online services.
In the end, it may not be the case that an organisation has to know that it is utilising SOA. The technology can remain like the engine in a car: drivers and passengers do not have to know that there is a differential box, a drive train and a clutch under the bonnet. They just buy the car, complete with engine, and drive it.
Similarly, organisations do not need to know about SOA, component registries, XML meta data and wrappering. All they need to do is get the composite system that supports their business application needs and use it.
That the system is then far more able to adapt to future needs is a clear benefit to business users. Again, the user organisation does not need to know how this works, it simply has to know that by ensuring support for open standards, business flexibility will be ensured for the future.
So, a detailed knowledge of the workings of SOA is the preserve of techies. A full understanding of SOAs at the technical level is not likely to become important to most business people. What businesses will benefit from is a flexible technical environment that allows users to add new processes as they become necessary.
The onus is now on the suppliers of SOA systems to get this core message across to business leaders.
Comment on this article: email@example.com