SOA: It's An And Not an OR
Arnon responds to my response about his definition of SOA by doing a NOT operation on business being a part of an SOA definition :)
I am sorry Sam, but I beg to differ, not about the importance of business drive behind implementing SOA, but about what SOA is. The culprit, in my opinion, is terminology overloading. SOA is, as I said in the above mentioned post and numerous other times, is first and foremost an architectural style - as an architectural style it offers several architectural benefits and poses several architectural constraints. This has nothing to do with business drivers
Well, I beg to differ with his beg to differ :). There is absolutely no doubt that one of the things that SOA is, is an Architectural Style. I just think its more than that or that any architecture has multiple views depending on who the conversation is with. It sure is easy to misinterpret my "That's all well and true, but any definition of SOA must encompass the business drivers and business reasons, as SOA is not really about technology." It sure sounds like I am dismissing the architectural style aspect for a business only definition. But I should have led with an "and statement" instead of sounding like an "OR." I wanted to add/and to the definition. As it stood, Arnon preferred the use of the term "SOA Initiative" and agreed on the use of business drivers there. I think some of what I wrote are "business drivers" and "SOA Initiatives" and should be separated out, but I believe some core business aspect belongs right in the SOA definition.
I like this definition [1]
"SOA establishes an architectural model that aims to embrace the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing." (emphasis mine)
It sounds like Thomas Erl's definition sounds more like mine. Then there is this definition:
"Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications" [2]
Or this one:
SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. [3]
I guess it comes down to what I discussed with Michele Bustamente when we were working on her WCF book: Little SOA versus Big SOA (sometimes known as Enterprise SOA). It came down to the Little SOA definition being Arnon's architectural style while the Big SOA definition puts things in a broader sense of IT and the overall enterprise. You know which one I prefer. I like SOA being described not only in architectural terms bit in terms of the strategic goals, business aspects and creating business services. That's when I believe SOA offers tremendous value. If one blindly follows the Little SOA side and cleanly separates interface from implementation and comes out with a nicely factored set of services that don't model the business then so what? I have seen a lot of people do this and emerge with just a worse performing version of DCOM or CORBA or RMI. The business aspect has to be a first-class citizen of what we are doing. We do want to this to fit into a "SOA Initiative" that is "about a better alignment of business and IT through business processes and services. The goal is to create a dynamic, more Agile and Dynamic IT that can respond quickly to new business opportunities and threats by quickly assembling new capabilities from putting together composite applications (and even Mash-ups) from reusable business services. "
One thing that Arnon and I are 100% in agreement with: SOA has nothing to do with technology. He said (better than I did):
By the way, SOA has nothing to do with technology either. You can implement SOA using WS-*, Atompub, MSMQ, CORBA just as much as you can implement REST with quite a few technologies, it so happens that WS-* is a common implementation technology for SOA, and that HTTP is used as a common implementation technology for REST but both styles live independently of the technologies.
Right on. That's why I said (and this is primarily aimed at the RESTafarians):
SOA is not really about technology. However, technology is not the predominant factor, neither is REST or WS-*. It has to begin with a focused understanding of what underlying business needs that have to be addressed.
[1] Erl, Thomas (2008). SOA: Principles of Service Design. Upper Saddle River. Prentice Hall. ISBN: 0-13-234482-3
[2] ^ Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[3] ^ a b c Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
