This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA costs, savings, & value
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
After reading Harry Pierson's comments on an SOA workshop he attended presented by Thomas Erl, and the rest of the reuse bubble growing and popping, I wanted to add some comments from my experience in using SOA in the wild.
First of all, the "reuse" is bull. In the cases where I found high reuse, I also found a function instead of a service. After some redesign, the function, and all the other "services" that "reused" it all collapsed into one, larger service. No more reuse. No need, really.
Second, about the costs of an SOA approach. They are higher. I repeat, it is more expensive to do SOA than continue what you are doing today. Developers are, by and large, not used to asynchronous programming. Doing SOA properly involves a mind-shift from the architects, through the team leaders, and all the way to the programmers. Call it a learning curve if you want. This costs. I don't know if its 30%, or more, or less. You will not be saving money by moving to SOA, at least, not tomorrow morning.
I assert that all this doesn't really matter.
The reason company's should move to SOA has to do with value. The looser coupling found in, and between, systems will decrease the time it takes to change and augment them. This translates to "business agility" (how I hate these hype-laden words). By decreasing overall complexity, the lifespan of systems will increase. In other words, you will be rewriting systems less, thus getting a higher return on investment on the systems that you've already built. Another "value-add" of the decreased complexity is that IT will be able to build larger and more powerful systems than before - integrating more processes and sharing more data across the enterprise. This, in turn, brings more of the right information to the right people at the right time, allowing them to make better decisions. You won't see all these things appearing in the cost-analysis of an SOA project I'm afraid.
Bottom line, do SOA for the value, or don't do it at all.
Previous Topic
