Solution provider takeaway: Solution providers should follow three key steps to make their way to SOA implementation work.
Most businesses do not develop all their own software -- heck, most don't develop any at all. Instead, they rely on acquiring and fitting together systems from vendors. Their ability to conduct their business, then, relies on their ability to integrate business systems, and they often rely on outside solution providers to perform or help with that integration.
Companies of all sizes are seeing service-oriented architecture (SOA) as the new key to easier, faster integration. According to Nemertes Research's Service-Oriented Architectures and Applications benchmark study of SOA deployments at companies of all sizes and across a broad range of industries, 70% of participants said they have a SOA rollout under way (most are a long way from complete). The desire to speed and ease integration, with the concomitant benefits for mitigating the fragility of complex traditional integrations, was the No. 1 reason they gave for adopting SOA.
What companies of all sizes hope to get out of SOA for integration is a less fragile way to tie their disparate systems together. A SOA, after all, is built in part on the premise that systems should be loosely coupled: that the components that make it up should not have to know anything about one another's internal workings, that all information they need to share will be shared through their external interfaces. While pretty much all systems integration already relies on this at one level -- the level of the data exchanged -- at another level, a lot of systems integration represents very tight coupling indeed. A system knows specifically how to ask another for the information it needs, and that technique may have little in common with how data is exchanged with any other system, and may change with any modification to either of the systems involved.
In a SOA, the metho
To continue reading for free, register below or login
To read more you must become a member of SearchSystemsChannel.com
d for requesting information is much more uniform, and more importantly, the interface behind which the data resides is far less likely to change, so the integration through that interface becomes less fragile. Participants spoke of having been able in some cases to completely replace the system behind an interface and with none of the adjacent systems noticing or caring.
SOA is delivering for these folks, too. A majority (about 55%) can bring new services online more quickly as a result of using SOA for integration, and over 61% have seen a decrease in their integration costs as a result.
The majority of SOA adopters do not rely solely on internal resources in undertaking their transition. After all, like other IT shops they are expending the bulk of their time and energy on keeping the existing system going. Nearly 75% are not adding staff to help cope with SOA, either. Instead, they are turning to systems integrators and other professional service providers to close the gap. Of those implementing SOA, 69% are using such services.
So with 70% of enterprises as potential customers around SOA, and with nearly 70% of them using outside help to get the project rolling and keep it humming along, what should those outside solution providers be doing? Here are three key steps.
1. Develop fundamental SOA skills.
First and foremost, they should be getting their own staff trained on the principles and practices of SOA implementations -- how services find and speak to one another. There is the choice of specializing in either Web services standards-driven SOA (driven by the WS-I) or Microsoft .NET-driven SOA, or trying to cover both. Most enterprises wanted to maintain a WS* focus even when integrating Microsoft products, so emphasizing standards-based efforts is a good idea. Being able to provide core implementation and integration services, as well as to provide key advice and skills transfer are key selling points to a company implementing or expanding its SOA.
2. Understand key SOA infrastructure.
Second, there is the matter of core technologies such as enterprise service buses (ESBs) and service registries. Not every SOA implementation has an ESB, but a great many do and so integrators and professional services providers should train their own staff in how to use them. And although most SOA users are not yet deploying registries as they have so few services to keep track of, an important service an SI can provide is helping them know when to do so, and how to, when the time comes! Familiarity with infrastructural tools that may be entirely new to the enterprise opens another opportunity for engagement.
3. Focus on enterprise applications.
Third, there is the center of mass in the majority of SOAs: the enterprise applications that are the key focus of integration efforts, the things to which most other systems are connecting. This may be Oracle or SAP enterprise resource planning (ERP) applications, or it may be IBM databases, or some industry-specific system common to companies in a particular vertical, such as an insurance policy or medical records management system. An integrator or professional services company with a vertical focus should be looking at how to integrate the apps peculiar to that vertical in a SOA: Does the vendor provide a services interface? Does a third party? Does one need to be developed? Expertise that is centered on their core businesses is a key to building long-term relationships with many companies, especially midsized ones.
Whether by providing essential and basic skills, infrastructural expertise, or domain-specific knowledge, integrators and others have tremendous opportunities in helping enterprises make real the benefits of SOA-based integration. The enterprise is moving ahead, is not hiring to do so and needs all the help it can get!
About the author
John Burke, principal research analyst, worked in academic IT for 18 years before joining Nemertes Research. He has worked as an end-user support specialist, programmer, systems administrator, database programmer and administrator, network administrator, network architect and systems architect. As an analyst, John draws on his experiences as a practitioner and director of IT to better understand the needs of IT executives and the challenges facing vendors trying to sell to them.
