|
|
| Service Oriented Enterprise |
|
|
Thursday, November 03, 2005 Judith Hurwitz on SOA With the boot camp consuming my time, I've had to queue up lots of blog posts on recent topics (SOA Maturity Models, Frankenstein, SOA Analysts, Big 5 SOA methodology / scribblings, etc.) But I thought I'd lead with a piece found at the CIO magazine - only because the Judith/CIO magazine combination influences a crowd that needs correct information. 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. posted by jeff | 4:15 AM Sunday, October 30, 2005 SOA Boot Camp: Days 14, 15, 16 & 17  It's done. Thank God - boot camp is done. 17 days of training seemed like a lot and it was. My friends were joking that I wasn't trying to train the consultants - I was trying to brain wash them. Well - perhaps I was. But it was great for them to hear different views of the same story from so many different people. By the end of the boot camp we had almost 20 different instructors participate. I really need to thank Hjalmer, Melissa, Stephen and Alex for supporting the effort. They did everything from booking hotel, air, car to making sure we got fed - to validating content. I couldn't be happier with the team effort.  Well - the boot camp ended just as strong as it had begun. We were lucky enough to have Sam Boonin from Cisco present the AON vision. I must admit that Cisco has the unique ability to make a complex topic seem simple. Their proposition for relocating functionality from the application layer to the network layer is profound. Naturally, we pushed them a bit on the standards support which was less than what we'd hoped, but it was clear that it was in Cisco's best interest to move the standards forward and that they were on the right path.  And if the Cisco vision wasn't big enough - we followed it up with Microsoft. Our discussion started with a history lesson (COM, DCOM, remoting, WSE, Indigo, WCF) and quickly led into the next generation tools. We went over the new white boarding capabilities in Visual Studio (formerly White Horse) and then was briefed on BizTalk orchestration (and next-gen human workflow). It is clear the Microsoft will be an on-going leader in the SOA space.We were also lucky to have Peter Yared and his crew from Active Grid talk to us about their next generation tools. His team has done an amazing job of enabling software developers to be productive in no time at all. Peter also made it clear that the 'service oriented' design center was core to his product road map. The last vendor session was on the SAP ESA story. Our own Scott Campbell presented the SAP vision for service enabling EVERYTHING. SAP is breaking away from their past of being only a packaged application solutions provider. With NetWeaver they are pushing infrastructure (Java, Portals, etc.) and are doing it all with an SOA facade. And naturally we went back and covered the basics - even managed to get a bit of BPEL coding in. Boot camps are a ton of effort - but at the end, you feel good about what you've accomplished - and you've made a bunch of friends. We passed out boot camp tee-shirts - and headed home to see if our wives still loved us. I declared it a success. We've opened up additional SOA consulting positions and have scheduled the next boot camp for the 2nd week of January. SOA Soldiers Wanted - the weak need not apply. posted by jeff | 3:40 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
