rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 300, comments - 180, trackbacks - 35

My Links

News

Archives

Post Categories

Published Works

The Road Path to Oslo

Writers note: Weeks after posting this, I realized that another blogger used this as a title for a very influential post on the same topic. Sometimes, it is very easy to inadvertently use a non-unique title or discuss a non-unique thought. As a result, I have updated the title accordingly.

Much has been unveiled in building 43 this week, and regrettably, there are not many details that I can share.

What I can do is provide some fairly abstract insights to get folks to start thinking about what's coming. Nothing here is not already available in public Microsoft messaging around Oslo, but my insights this week have helped to crystallize much of the vision.

Where Are We?

Much of the effort in moving from a pure imperative mind-set to a declarative and model-based mind-set is the shift that has to take place. I think this paradigm shift is very similar to how difficult it is for some who come from a pure OO background to grasp contract-first component-oriented programming (interface based reuse vs inheritance based reuse). Even more difficult for some is grasping the mind-shift that location transparency, interoperability and standards-based communication demands if you want to build services. This is not only a technical challenge, but it is also an economic one. If we all agree that explicit boundaries are good for coupling and reuse is good for developer economics, then we all know that attaining loose coupling and reuse is hard, or at least it isn't easy.

First, I believe that if you are a BizTalk architect/developer you are going to be very comfortably ahead. image  The reason for this, is that it turns out that EAI architects/developers have benefited tremendously by the maturity of the tools already in BizTalk. As a result, the mind-set of an EAI technologist is very well aligned with the holistic needs of the business because everything they do cross-cuts the enterprise. SOA architects/developers who have built upon EAI skillsets to extend the capabilities of platforms like BizTalk to become an SOA enabler on top of EAI and MOM already understand much of the concepts and benefits of model-driven design, as well as the developer economics & productivity benefits of using sophisticated tools to solve complex problems without reinventing the same wheels over and over again. The problem, traditionally has been how difficult it is for some to ramp up and grok the tools, and thus, realize the benefits inherent to make this paradigm shift happen.

Meanwhile, some (but not enough) System/Middle-Tier developers have groked WCF and WF, which provides a good mix of imperative and attribute-based declarative programming and thus, have become black-belt SOA practitioners by using these very surgical tools to deliver the benefits that loose-coupling and reuse yield. The tremendous productivity benefits of WCF alone, when it comes to support for WS-* and configuration semantics cannot be overstated. WCF is a quantum leap in developer productivity for realizing the creation of service oriented applications.

Where are We Going?

The reality then, is that if there is a tools divide between the BTS-SOA and the WCF-And-WorkFlow-All-The-Time-SOA camp, then there is a gaping ocean between .NET Web and Client/Forms developers. Technologies like ESBs can help accelerate SOA adoption for the enterprise, but ESBs are a Big SOA play. Big SOA is all about integrating *existing* services. Little SOA is how services "get done" so that they *can be* integrated. You really can't have one without the other. Behind the service is really where the magic happens, and having sophisticated tools to make this magic happen is key to enabling organizations to build services that can be integrated across the enterprise to support the business processes that run the business.

What is worthy of surfacing here is that all of these roles do not exist without the business, and there are interdependencies across all roles and specialities for delivering business value. Oslo will revolutionize how these interdependencies are integrated within the enterprise, but the glue, ultimately will be you, the technologies you employ today, and the foundations that you must build for tomorrow.  The good news is that all existing skillsets in .NET 2.0 CLR and .NET 3.0 and .NET 3.5 are, and will continue to be valuable and relevant, but folks with varying competencies in these areas with a gap in EAI will need to make some shifts in the way they think about solving business problems, and this will be especially true for architects who are usually responsible for sharing the responsibility of managing to developer economics and project budgets. I believe it will be easier for a hardcore BTS architect with EAI and SOA experience to grok WCF and WF to a profieciency level than it will be for an expert C#, WCF, WF architect to grok the phenomenal tooling that exists in BizTalk and is only going to get better.

Lastly, keep in mind that Oslo is a program, with a lengthy roadmap. This should both be exciting and encouraging. Exciting, because what's coming is really, really cool. Encouraging, because those who have resisted, or a re new to a model-based approach for delivering software still have time to get up to speed!

Regards from Redmond.

Print | posted on Thursday, April 17, 2008 1:53 PM | Filed Under [ WCF SOA ]

Comments have been closed on this topic.

Powered by: