Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

I was reading Thomas Erl’s  “SOA – Principles of Service Design” and came across an interesting statement that I had never seen written before, despite it being so obvious.

“Much of service-orientation is geared toward producing services with long life-spans. In fact longevity is a highly desirable design characteristic of service contracts and is also a measurable success indicator as to how well service-orientation was originally applied”

I like the thought of some simple service chugging away at whatever it was designed to do months or years after creation and of an equally proud developer who knows that his original designs were so good that this service is still up and running.

Then I thought of how things change and wondered whether this life-span concept is really the case.  In cases where one of the consumers of a service changes something, a simple transformation can be applied, right? In Mule, we can use the ignoreBadInput attribute so that the other consumers can still use the same attribute.  If they all change, we could apply the transformation to all but this means that we’ve now changed the service definition to include that transformation.

I shook my head and re-read the sentence and thought a little more.  If, in a typical company, a service is still doing the same thing after a long time then the following must apply, surely:

  1. The data types are still the same.  Some industries change because they have to as anyone who had to implement changes because of the Sarbanes-Oxley act can tell you. Some industries know that they will change and factor that into their systems as financial institutions across Europe did in the 1990s when they knew that the Euro was going to be introduced.  In other case, industries change because they want to as airlines did when they introduced e-ticketing.  When will a data type remain the same for a great length of time?
  2. The consumers of the service remain the same.  If consumers changed in some way, they can transform their own output before invoking the service but this may not always be the case.  Smaller companies cannot ask their huge customers (or suppliers) to change messaging requirements or data formats.  When would this actually happen?
  3. The number of messages that the service handles remains constant, therefore avoiding the need to re-factor code to improve performance or streamline operations.  Ideally, all performance will be optimised at the very beginning but this is an expensive task and is left for later in the development stage for a good reason.  Given the huge change in the financial industry these days, we can all think of places that have lesser (or more) work now than they did in January. The lucky ones should be doing all they can to improve themselves and handle the new workload.  When would this be constant?

Perhaps the biggest annoying thing about this statement is that there is no fixed definition of “longevity”. 6 months? 6 days? 6 years?