A lot has been written about the positive aspects of service oriented architecture (SOA). This has led to a fashion that requires every self-respecting IT department to be seen with at least one SOA project underway.
However, this IT makeover requires a more balanced evaluation, based on a brief history of IT in business.
In the beginning (the 1980s) there were monolithic applications running on mainframes, controlled by geeks in jeans. Manage- ment accepted this but perceived IT staff as an unaccountable bunch, operating in a world remote from that of the business, with a cavalier attitude to risk.
To address this perception, management had to bring these IT mavericks to heel with controls, documentation, quality programmes and best practice. This resulted in the programmers climbing out from under reams of code to explain in plain English what they were doing. Not only did the techies hate this but 80% of their working day was now spent working in English, not computer code. This made them poorer programmers and so they made more mistakes. This made management clamp down by demanding more controls and documentation. And so round and round it went.
The solution to this downward spiral was the age of distributed client server. Free of all the controls that weighed down the mainframe, at last the business could get what it wanted from an IT department under its control.
Unfortunately, client server wasn't the perfect architecture either. It led to duplicated processing, inconsistent customer details, incompatible software and an inability for management to view the business as a whole.
We are now told SOA can address these problems by joining everything up again. This may be true, and thanks to web services technology, it may be a better architecture than we have ever had before, but expectations must be managed. Just as every silver lining has a cloud, there are downsides to SOA:
- Due to the fact that any service can be invoked by any application, every service will need to validate completely every input parameter. This is going to hit response times and the overall machine load. Validation is not just logic, it usually requires input/ output to external databases and calls to other services. Application-specific routines frequently bypass this overhead in safety because parameters are often generated by prior processing within the application.
- It is not humanly possible to test every combination of every condition in a complex service, so some form of automated testing package is required and must be applied in every implementation.
- A bug or corruption introduced to a well used SOA service can take out the entire system, not just a single application.
One size fits all...
lSOA's "one size fits all" approach has a certain naivety. Even in something as simple as retrieving customer details, some applications may want only a summary, some every detail, some in upper case, some in mixed case, some may want a single address, some several thousand. One service trying to serve a dozen masters can lead to spaghetti code and massive inefficiency.
- A generic service cannot be optimised for efficiency because prior and post processes are unknown. The fundamental tool for improving system efficiency is to gather all the information you need with the minimum of input/ output. If a service is invoked randomly, it is unlikely to find the data it needs already held in memory.
- If an application requires extra functionality from a centrally used service, will there be an "If it ain't broke, don't fix it!" attitude from those responsible for that service? If there is, you end up with application-specific services.
- If applications continually require additional functionality, and these requests are granted, the entire system becomes permanently unstable.
In general, SOA can bring huge benefits to the IT function in the form of code reuse, systems integration and improved responsiveness to business needs. However, the eternal battle between flexibility and efficiency exists in just the same way as it always has.
Most negative aspects of SOA can be addressed using stricter controls, documentation, quality programmes and best practice, but haven't we been here before?
Dave Overall is managing director of Redvers Consulting which supplies legacy interfaces to SOA projects
Have your say
If you have an opinion on this or any of the other articles in Computer Weekly, we want to hear from you. E-mail your thoughts to: