I'm a card carrying member of the SOA skeptics club, but I'm going to push for a dose of SOA thinking to my current client. I do understand the potential benefits of things like BAM, BPM, and flexible orchestration if the entire enterprise were really Service Oriented, but I generally think of SOA as a kind of fool's gold for ivory tower integration architects who desperately want to play God without ever getting their hands dirty (my advice for these folks is to go get a copy of Civ IV). For the most part, the SOA initiatives I've seen have only led to extra complexity and reduced productivity in development without ever coming close to the orchestration nirvana envisioned by the architects.
As I see it, the positive goal of a Service Oriented Architecture is to eliminate duplication of effort in software projects across the enterprise by reusing existing code assets and reducing the cost of changing the behavior of software to keep pace with evolving business needs. As I've stated in other posts, it's usually easier and generally less risky to create new behavior by writing brand new code instead of breaking into existing code to make modifications. Call me Pollyanna, but I firmly believe that those very goals can often be achieved at a lower cost by a relentless focus on creating well-factored code backed up by a healthy dollop of test and build automation (SOA certainly doesn't abrogate the need for good code behind the service points, but that's a gripe for another day). Aw, but here's the rub: the mass majority of the code out there in production is of dubious quality and the kind of test and build automation that enables change simply doesn't exist for most systems.
So back to the usefulness and appropriateness of an SOA solution, there's a phrase I've often heard or used in regards to exposing services to a nasty legacy codebase to try to extend the usefulness of said legacy code that's particularly applicable to my current project — "Lipstick on a Pig."
This piggie needs some lipstick
Here's the scenario, you're building a new client application or work process automation solution that needs to integrate or use an existing legacy server application with oodles of business logic and functionality. What can you do? I can think of three options off the top of my head:
- Write the new client as part of the legacy system. In our case the legacy system is in a niche language, and they are committed (justifiably so IMHO) to producing all new clients in either WinForms or Swing. This option is not on the table.
- Reproduce the necessary functionality in the new application. This is the approach that we ultimately were forced to choose, but nobody is, or should be, happy with this approach. Reproducing the existing functionality made the project take much longer, and add considerably more risk to the project, than was envisioned when the project was launched. I say risk because we're still not exactly sure what the correct business logic should be because the original code is not entirely readable or documented. We have also increased my client's maintenance costs considerably by duplicating functionality without retiring the existing legacy code. Anytime this functionality needs to change, they'll have to change and test both sets of code. Because all of the integration happens through a shared transactional database, the implicitly tight coupling between our new code and the existing code is not obvious.
- Find a way to use the existing legacy code in place as it is. In effect, they could desperately use a service layer of some sort between their legacy code and newer client applications to avoid the duplication. In terms of design, decoupling the legacy code enough to slide in a service layer is going to be difficult (I'm betting most of the functionality is in the 2-tier UI clients), but in the end I think it'll provide a heck of a lot more value to them. Once the service layer is in place, new development work should get easier because they can just hook right up to the services with a well-defined contract. Even better yet, the service layer should provide the ability to go to work on the service backend and start moving code over to a better factored codebase in a mainstream platform. Putting lipstick on this pig will generate business value.
This piggie needs to go home
Some of my attitude on SOA originates from my days inside internal IT in a Fortune 100 manufacturing company that really is a quite logical fit for a rational SOA approach. On a particular project, we were tasked with making significant improvements to the nasty, failure prone shipping system (as in "shuts down the factory lines when it goes down). A senior enterprise architect was given the responsibility for determining the overall architectural changes. His entire plan pretty well came down to replacing the existing integration points with webMethods. The point of his strategy was to decouple the clients of the nasty legacy application from the details of the legacy application first, then make improvements to the server system at some later point. He was perfectly honest in describing his plans as "Lipstick on a Pig." I've always been primarily an applications guy, so I was flipping out that we were spending a lot of energy that wouldn't result in a single, observable improvement in terms of uptime, performance, functionality, or reduced support costs. Worst was the fact that the business was told they were paying for overdue structural improvements to eliminate downtime incidents. I even expressed an opinion that the new webMethods integration infrastructure would only add network chatter to an already chatty system and further degrade the already deficient performance. To this day, I don't think anything far short of a full rewrite would have represented a significant improvement (and they did replace it after I was gone). Lipstick wasn't going to help this pig at all.
And no, I don't necessarily think SOA is a bad thing, but done badly or unnecessarily, SOA is a blight upon the land.