The cost of “SOA-fication”

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.)

Comments

• Anonymous
  February 15, 2010
  I suggest that a huge cost area that is overlooked are the operational costs. What is the operational costs of deploying and managing an large number of services? The cost of incident management which is likely - and in our experience - a much more complicated operational environment.

• Anonymous
  February 23, 2010
  The comment has been removed

• Anonymous
  February 23, 2010
  I am going to try to not give you a generic answer but it really depends on what you are trying to achieve eventually and what bottomline are you powering. I recently happened to look at your IT Operating Model and SOA post (Sorry coming up the curve) where you made the important point of same things mean different in different operating models. I would agree with Terry that operational cost is often overlooked but there are also cost with respect to regulatory and compliance which is also ignored I tried to put a quick Balanced Score card for how SOA would be if it was a business the result is here http://soanami.blogspot.com/2010/02/holistic-soa.html You can see the processes and how they play into the overall mix

• Anonymous
  March 01, 2010
  I know the article is about the cost of implementing SOA in legacy applications but it does suggest SOA is just a cost. My reason for this statement is with the cost associated with testing. We have legacy applications going back 15 years, most of which have no unit testing. The introduction of SOA can lead to much better unit testing and I found as a project manager gave me a good measure of the progress of a project. One aspect where you can find resistance is not so much cost as resistance to change, especially as it is viewed as delivering no benefit to the project. A project manager may believe all change introduces risk, risk should be minimized, hence change should be minimized.

• Anonymous
  March 16, 2010
  Just to let you know - this post was featured in a link roundup on the SATURN network blog at http://saturnnetwork.wordpress.com/2010/03/15/link-roundup-march-15-2010/