Judith Hurwitz presents her 'ten principles of SOA' in a piece on SOA: Battle of the Titans. My comments follow.
SOA is real. It is not a quick fix. It is a ten year journey (or longer) that requires considerable planning. It is also as profound and far reaching as, for example, e-commerce.
Agreed.
SOA is build upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry. SOA embraces all these aspects of computing and takes them into account.
Agreed.
SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources. Scalability within SOA will come from managementÂ?not development.
It was funny listening to all of the vendors at the boot camp. Each one told us what to lead with - 'Lead with the Registry!', 'Lead with Mediation!', 'Lead with security!'. Now Judith might be talking about SOA Manageability or about general governance - it's impossible for me to comment on what she meant. Regardless, I'm comfortable stating that you should lead with SOA strategy and incorporate a closed loop infrastructure. All of the components must complement each other - no one component is at the heart.
SOA will only work if it is implemented within a business process context.
SOA is predicated on leveraging business services that constitute the component parts of your business.
Yea - this is wrong. It is common for a newbie to watch a demo of BPEL/XLang/BPML orchestration and think that they just saw the future of computing. Better yet, they grasp the concept of a 'business service' but fail to realize that this is the ONE thing in SOA that will see the LEAST amount of reuse. Don't get me wrong - there will be some instances whereby SOA enables process-driven applications, but this is merely one of a dozen or so benefits.
SOA requires a container that creates a composite application.
I'll remind Judith that she characterized SOA as working in "highly distributed computing environments". Service based applications come to life by activating services in well known sequence. The composition (or invocation) of these services are distributed. The app server/container metaphor takes on a new meaning. Service oriented applications have 'invocation points' or 'composition points' at multiple layers in the architecture (virtual business service, business service, virtual data service, data service, etc.) The key here is to not accidentally use the term 'container' in the singular. How about, "Composition of service based applications is usually distributed, with no central composition point or single container."
SOA requires standards that can be depended upon across all vendors implementations of SOA.
The ONE truth about SOA is that we CAN NOT DEPEND on standards across all vendors implementations. If you don't understand this, you don't understand SOA. The reason that SOA will work is because we have factored out the non-functional concerns and created transformable protocols, formats and identifiers of the standards which are MEDIATED.
SOA assumes that you will begin to write applications differently as a series of tightly defined services implemented in a loosely coupled manner.
I guess... :-)
SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards.
Agreed. They just don't have to be the 'Web Service' standards, nor do they need to be ubiquitous. They just need to be federated, virtualized and mediated.
SOA dictates that change is the norm since this approach to software mimics the way a business operates and evolves.
SOA is a pain in the ass that, in the short term, will slow down your ability to rapidly deliver software to your customers. SOA doesn't provide rapid change but it does provide a framework for 'scaling capability'. As the number of enterprise concerns rise (consistent data, consistent logic, fulfilling regulatory mandates, process as a first order concern, one-face-to-the-customer, etc.) we need a framework to allow us to change EXTREMELY complex systems. SOA enables the insertion of capabilities in an incremental (and almost linear) manner.
SOA is complex. Explaining it to CIO's is even harder. I wouldn't expect Judith to go to the detail that I just did for the audience she was catering to. However, the amount of poor advice provided is, in my humble opinion, disappointing.
No comments:
Post a Comment