The cost of “SOA-fication”

  • Article

No, Virginia, there is no SOA Santa Clause.  SOA is not free.

That said, if I’m changing a system to meet new needs, and I’m substantially refactoring a section of the code to deliver to those needs, SOA doesn’t have to be wildly expensive either.

The myth of “expensive SOA” is just that: a myth.  If you have an existing system, and you are refactoring it anyway, it may make sense to spend a bit more money for “SOA-fication” (the process of turning a “closed system” into a system based on Service Oriented Architecture principles… if you can’t get all the way to “based on SOA,” I’m happy with “plays well with SOA.”)

Of course, that cost is not trivial to estimate.  This is where I’d like to ask the community for your input.  What drivers have you seen to drive the additional cost of “SOA-fication” of an application?

Here’s what I’ve observed…

  • “SOA Security” (Auth/Auth) - to insure that there are no additional risks to the enterprise through the availability of a previously inaccessible system feature.
     
  • Design and Design Review – to insure that the services being developed are truly worth investing in.  That means that the services exhibit good behavior for enterprise SOA services wherever possible (non-chatty, independent, transactional, reliable, traceable, etc.)
     
  • Testing – to insure that the interface is stable, meets the stated business needs, and can realize the stated design goals.
     
  • Monitoring – to insure that the service can be discovered / tested / validated and, depending on the service, that it correctly and reliably participates in Business Activity Monitoring and Workflow scenarios.

 

Gentle Reader: Do these “dev cost drivers” coincide with your experience in turning legacy applications into SOA applications?  What “pitfalls” come to mind that are not listed?

(I’m interested in actual experiences.  Please share.  There are no wrong answers here… just good people helping one another.)