July 2008 Archives
If you talk to anyone in the trade (of hawking SOA solutions, that is), their first answer to the "Why SOA?" question is usually re-use. Their second is: "Do you want to buy some (new) software to do your re-use?" If you've spotted the slightly logical inconsistency here, and are keen to recycle your current (enormous) investment in existing systems, welcome to the world of Green SOA.
In the crazy world of SOA, the future is services; and to get there you are being told to restructure and rewrite your systems to meet this new world. Huge sums of money are following the hype in writing reams of WS-* compliant .NET and Java code to provide thousands of new services to feed the SOA beast.
However, like all major IT hype cycles (sorry, trends) it is worthwhile stepping back and considering the best way to approach SOA for your organisation. There are very few cases where there are no existing systems to achieve a particular process or function. The mythical 'green field site' belongs in the same fantasy category as clean customer data or 100% server uptime. Many existing systems are imperfect, and are seen as difficult to adapt to new requirements, but tend to provide the core 80% of functionality that actually runs the business. Throwing the whole system away and starting again is a luxurious approach that few organisations can or should be contemplating, particularly in the current difficult market conditions.
Unfortunately, this is how SOA is being sold at the moment. Going back to the re-use benefit, wouldn't it make more sense to start re-use with what you already have? The two major arguments against this view are:
- Our existing applications are not service enabled
- We don't have the tools currently (ESB, service registry, process engine, etc.)
There is a third defence of general ignorance, but this is rarely admitted to.
Taking the first point, most legacy applications and packages were not built as a set of consumable web services but they will all have entry points to gain access to their data and functionality. This could be APIs, function calls, queries, screens, etc. Many of these encapsulate everything required to work as a service, i.e. defined inputs, outputs and transformation. However, because they may not adhere to a specific WS-* standard, they are not seen as SOA services. I have recently worked with a number of companies to help them understand how to service-enable their existing applications, in order to gain access to key functions that can be re-used as services to share with other processes or newer SOA builds. It has been surprising to the companies how much is potentially re-usable.
Secondly, the requirement for SOA tools should be seen in the context of a three layer architecture: conceptual, logical and physical. At the conceptual layer, you should have an Enterprise Service Bus to separate publishing of services from consumption. However, at the logical and physical layer this can be accomplished in the short term by existing technology, or, in some cases, just a logical layer with no physical equivalent. Examples of existing technology that could provide service functionality are Message Brokers, EAI Hubs, or any legacy middleware you may have lying around. The adherence to the new world of SOA may not be absolute, but you can provide the necessary abstraction using these technologies. In some cases, just using standardised API/Service calls from current or new applications can emulate the abstraction layer with no need for a physical bus, particularly for low numbers of services.
This approach may not seem very elegant, and the few architects still reading my blog after my last entry may disagree. However, in today's more pragmatic climate it would be common sense to look at re-using what you currently have rather than start from scratch.
John Moe
