It has been quite a while since I blogged something about SOA - ( SOA - more then just hype(5/2005) , SOA - Part 2 (11/2004) , Service Oriented Architecture (SOA) and other stuff ... (11/2004) and SOA revisited(12/2004)) but I recently read this great posting from Udi Dahan about SOA costs, savings & value.
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 interesting read is this one - BPM, BPEL & SOA - A comedy of errors - it's key message :
BPM, BPEL and SOA are frequently mistaken for each other. Having “process” in two of the three acronyms certainly doesn’t help matters. But at a more fundamental level people confuse the business centric perspective, which BPM is supposed to bring to the enterprise, with the IT centric perspectives which SOA and BPEL embody.
As well as SOA transformation and IT culture shock
SOA is a loosely coupled model with higher level abstractions – at a business-service level versus a class level. SOA is actually more like component-based development (CBD). The CBD and SOA similarities include reuse through assembling components, interface definitions and loose coupling.
And last but not least - this article about SOA antipatterns - with the most recognizable antipattern #1 - "The same old, same old" Phenomenon.
I come across this antipattern often during my course of interviewing architects for various organizations. These architects claim to be well versed in SOA on the basis that SOA is the "same old" technology that they have been using for years, simply wrapped up in a newer and fancier package. Upon being challenged, they start flailing within a few minutes. That's because, while many of the good architecture principles (such as high cohesion and low coupling) still apply to an SOA, there are quite a few differences between SOA and its Object-oriented (OO) and Component-based architecture precursors. Probably the biggest difference is in 'what' you are modeling in each style. In the OO and component world, you are modeling the physical world in terms of things (i.e. nouns) while in an SOA you are modeling the same physical world in terms of processes (i.e. verbs).