The majority of SOA initiatives that are launched over the next three years will end in disappointment – some initiatives will end in complete failure, while others will simply not deliver the flexibility, reuse and efficiency that SOA promises.
This wont be because of any shortage of cool technology. These projects will fail because to many of us will forget the importance of creating a proper framework backed by methodology that not only supports the creation of services but also makes it possible to find them, understand them and reuse them.
Trendy terms like “ESB” (Enterprise Service Bus) don’t help matters; in fact they make them worse by emphasising the technical aspects of the creation of services without properly focussing on the broader framework within which they should be deployed.
SOA: Same Old Architecture, same old mistakes
No-one with any experience of middleware or integration would deny that the notion of “services” is new. In the 80’s and 90’s we talked about DCE Services, CORBA Services, and Tuxedo Services. We have to understand why past attempts failed, in order to avoid simply repeating past mistakes.
One of the key weaknesses of past attempts to deliver SOA lay in their complexity, coupled with the failure by vendors to implement genuinely interoperable versions of those standards. There is an implicit warning here for web services – as web services standards proliferate two dangers emerge; firstly the chance of multiple vendors all creating genuinely compatible implementations declines and secondly the complexity associated with developing service enabled applications rises sharply.
But even simplicity wont result in the massive re-use that “services done right” should bring; the most significant reason for past failures was the lack of support for the level of best practice, patterns, and tooling that a successful move to SOA requires.
Remember the “A” in SOA stands for Achitecture
A failure to properly consider the “A” in SOA will result in our making the same mistakes we’ve always made when it comes to software and reuse. But even this is not enough – there is a silent “M” in SOA; services oriented development has to be supported by Methods that encompass best practice in service design and reuse. Adopters who ignore the “A” and silent “M” in SAO will inevitably be disappointed.
It is not enough to deliver the technology, or indeed the technology plus an architectural framework. To achieve its potential, adopters need to combine the technology and a services oriented middleware framework with
What do users have to do to make SOA work in practice?
Think about reuse from the outset
The ability to re-use services is one of the key advantages of moving to SOA, but for re-use to take place you have to set the following things in place;
- A repository of reusable services that provides enough information (in a standard form) to enable developers to discover and understand services
- A training and incentive programme to encourage developers to reuse. Developers need to be motivated to look for something and reuse it.
Build out a complete Services Oriented Architecture
Remember that all of the middleware and “ESB” offerings of the different vendors provide a framework for SOA, not a solution. The key here is that a “framework” is “something that hasn’t been finished yet” – you need to build on it in order to establish a workable SOA.
You need to:
- Put the core middleware in place
- Build on the necessary services to support your applications at run-time
- Build on the necessary services and facilities to support your developers at design-time
Create and enforce development standards
If you do not define a set of development standards you will soon find that you have a myriad of different forms, conventions and “styles” of service. This diversity will make it harder to find, understand and reuse web services. These standards should cover;
- Naming conventions
- Message structure
- Service documentation
- Interoperability
Unless you establish common ways to describe services, how can you expect your developers to find them, understand them and then re-use them?
Manage the deployment of services centrally
If you want services to be reused across your organisation, they have to be managed on an organisation-wide basis. If you don’t control the deployment of web services within your organisation you the result will be dozens of overlapping services that have confusingly similar names. One of our clients discovered that it had 24 services that were all called “Account”, several of them were more or less identical (and therefore redundant and unnecessary) but, even worse, many of them were completely different. This confusion isn’t just an irritant, it can be very dangerous. For example, it’s very important (if you’re a bank for example) that you know whether “balance” means the average balance over the last month, the balance as at the close of business last night or the balance as it stands at this minute.
Invest in design-time infrastructure to make it easier for developers to find and re-use services as well as creating new ones
Ultimately, re-use only happens if it is considered at design-time. Developers aren’t great at “doing the right thing” and dutifully searching for things to re-use. Successful re-use depends on design-time infrastructure (in the form of tools and repositories) that make it as easy as possible for developers to look for things they can re-use and to share things that could be re-used by others.
SOA has the power to transform the way we build and integrate software
Despite my concerns, I believe passionately that SOA can change the world of software development and integration, and today’s service oriented middleware represents the best platform yet for SOA. But unless we add Methodology and Architecture to our services mantra, we’re all going to be deeply disappointed – Once again.
