Ready, Steady, Stop - SOA gets in the way

Imagine your a supplier of software. You have invested in developing your software offerings over a decade or so and now you want to know how to respond to the move towards SOA among your customers. This is the problem facing a company I visited this week. They had two problems. The first is that they have several software offerings sold individually and in combination. Currently, these systems are not integrated and each time they sell a combination they hard wire them together afresh. The IT Department believes that the integration requirement is the same every time, but the implementers disagree.

The second problem is how to present themselves externally. If their customers are moving towards an SOA architecture, they are wondering if perhaps they should offer a loosely coupled integration option via web services.

The IT department is proposing that they adopt an SOA strategy and that they integrate their existing software systems using web services and offer web services as the means of integrating their products into their customers IT environments.

Unfortunately, this is a loose loose option. The first point is that adding a few web services to the existing software has nothing what ever to do with SOA. Adopting an SOA strategy would require them to re-build all their software from the ground up. Using web services simply as a means of integrating existing lumps of software is not only nothing to do with SOA's but also will not prove to be an advantage over using an EAI approach. Web services are slow and intended for inter company links where traffic volumes are low.

Unfortunately, the argument for using them for integration with the customers existing software systems is even weaker. With no advance knowledge of the system to be integrated with or how it has been implemented, it is unlikely that a pre-conceived web service will work any time let alone every time. Add to that that the traffic volumes involved are often very large and you have a recipe for disaster.

The Immediate problem for this companyis that the decision by IT adopt the use of web services and present it as an SOA strategy is blocking all attempts by the company's divisional management teams to address their immediate needs for a better way to meet their integration needs

Integration hub v ESB

I know several vendors of software products who are debating the same question: Should they go all out to use Web Services as the only primary interface for integration? Each of them sells software products that have to be integrated with other systems, often legacy systems in already in use at their customers.

This question raises two important issues plus one interesting technology question: The first is just how real is the movement towards SOA's i.e how long will it be before the big majority of their customer operates an ESB with which they can contract? The second is how important from a marketing perspective is it that they be seen to be ready to participate in an SOA?

The interesting technology question is: How good are Web Services for integration tasks anyway?

To give a view on the first question - there is a lot of activity in the marketplace. SOA's are the subject of the moment. That said, there are very few implemented examples of any meaning and the jury is definitely still out on whether or not the approach will give an adequate return on investment.

The answer to the second question - how important is the market perception of a products SOA credentials - paradoxically this seems to be very important. So here we have a conundrum. In practical terms there are very few ESB's in use. The majority of customers of these software's will need an alternative to Web Services for several years yet. But purchasers will want to be reassured that when and if they do get there their vendors will be ready for them

The more difficult question concerns Web Services themselves as the technology of choice. Being XML based they are slow - very possibly too slow for integration use where traffic volumes are high and/or each transaction is very broad.

Being practical, in the short term vendors will be forced to offer rules based EAI or, if their customers will wear it, individually hard coded integrations. Wouldn't it be good if there was a solution out there that offered its users the option to start will a rules based EAI approach and phase in an ESB solution when the customer was ready using the same suite of software?

Trend goes live with SOA solution

Trend Communications has gone live with a ground breaking on-line quotation and order entry system. Developed using EdenAgileIT (www.datadialogs.com).You can view it at

http://83.138.140.161:7734/TrendProto.html)

the solution consists of 150 re-usable services developed using Eden's codeless modeler and orchestrated with a combination of Eden's ESB and JAVA designer. The resulting Rich Internet Application revolutionises the way Trend does business through its distributors.

The approach Trend adopted was to leave their legacy ERP system alone rather than trying to expose any legacy functionality as services and the create the entire customer facing process set from scratch. Quotations under development are stored in a separate SQL Server database and only when an order is confirmed are the details of the assemblies required, with their bills of material passed into the ERP system (Infor's System21on an i-series) so limited are the options for using this ERP system within an SOA architecture that Trend decided not to try and literally Poke the data directly into the ERP systems database (This turned out to be much easier than the vendors scare stories would have Trend believe)

Web services were not used because the large volumes of data involved made them too slow. That's the third time this month I have encountered SOA developments electing to not use Web Services. It looks as though We Services are best suited to inter-company collaborative developments where high volumes are not an issue