Something old, something new

In another discussion recently about SOA, it still surprises me a little that people, technical people, don't get that there's not much new here. For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.

Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call. If you're already supporting message-oriented applications using MQ or JMS, these messages are now HTTP requests. The process of decomposing the application into reusable services is essentially the same.

The real point here is, if you already have a modularized architecture and you're having problems with application crashes, a switch to "SOA technology" is not going to help you. My first guess is that (lack of) testing is the problem. These problems will not go away in your big "SOA" rewrite unless you figure out a way to test better. Or you could be having problems scaling your infrastructure. If anything, a switch to a web service solution will increase the number of messages being passed around your network.

My advice, instead of following the knee-jerk reaction that your technology is old and needs a major upgrade, write tests first to determine:

1. the functionality (behavior) of your application is tested (start by testing the "problem" areas of your app. first)
2. your infrastructure can handle the current transaction load.

******

If you're reading this and haven't read Chad Fowler's Big Rewrite series, you should check it out.