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…
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.)
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.
Our SOA effort also involved creating a "single view of the customer", which drove home the fact that folks can't even agree on what a customer is. For example, the customer of one product of a division of corporation may be a prospect from the perspective of another division. The semantics were absolutely killer. We had to spend a lot of design time making sure the nouns and verbs were well-defined.
These are all design concerns, which you included, but I would personally call out this set of costs separately as they can be addressed as separate track and are often overlooked as a minor part of developing the interface contract.
Beyond the semantics, if you are replacing multiple current implementations of a service with a single service, don't underestimate the time it will take to reconcile process differences.
Regardless of how unrelated to the bottom line a function may be, each division will feel it does that function "the best" and will feel slighted if some other division's model is selected. You either have to spend the time to reconcile the processes or you have to have a strong political arm to dictate the direction.
Finally, make sure you factor in the cost of building in resiliency. If you add an integration layer between two functions which previously communicated "in process", you have to clearly understand who is responsible for retrying if a failure occurs. You may need to add in some form of queueing that previously did not need to exist at that step in the chain of execution. You may (worst case) have to back the error all the way to the user or system that submitted the transaction, depending on the nature of that transaction. None of this is rocket science, but in our experience, this is where the costs pile up beyond what you already listed.
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
You can see the processes and how they play into the overall mix
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.
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/