BizTalk Server roadmap

Via Matt Milner, the BizTalk team have published their roadmap for the next couple of versions.  Matt seems pretty positive about the evidence of a long-term commitment to BizTalk.  From an operational and business point of view, I'm sure that's true: no doubt BizTalk will continue to be upgraded to support new Windows and SQL Server versions as they come along, and that Oslo integration will extend back to BizTalk 2006.  From a developer/architect point of view, however, I am less sanguine.  I see the post-2009 roadmap as a missed chance at best, a death sentence at worst.

When I heard the announcement of Windows Workflow Foundation from the 2005 PDC, I commented to my then boss, "I just saw XLANG shot in the head."  And I meant that as a good thing for BizTalk.  XLANG lacks even the most rudimentary concepts of modularity or extensibility.  You can't define your own orchestration shapes; you can't even build subroutines, for heaven's sake.  You can kinda write your own code, but only in this weird sort-of-C#-only-not language that always seemed to be missing the one rudimentary feature you needed at the time.  So BizTalk has this great industrial-strength fabric, held together with (and held back by) an orchestration engine with all the power of wet string.  Allying BizTalk's strengths in robustness, manageability, messaging, transformation and integration to a real workflow engine like WF would have significantly upgraded its capability, making it an immensely attractive platform for both human workflow and system orchestration.  And for the last few years, that's the direction the BizTalk team seems to have been thinking about.

In response to customer feedback, however, that thinking has changed.  The roadmap says that the BizTalk team is "committed to continued support for ... XLANG" and that "additional support for WF will be prioritised ... based on customer demand and scenarios."  So, XLANG was shot in the head, but the BizTalk team has decided to dig out the bullet, hook up the life support and stand by their XLANG.  Massive brain damage be damned.

Yes, I understand the compatibility arguments.  I understand that EAI is a long game and that we need to support BizTalk 2006/XLANG applications well into the Oslo timeframe.  I understand that customers have a significant investment in XLANG and don't want to risk having to move to a new engine.  But this decision seems to mean that customers won't even have the option to fully adopt the WF engine, with all its benefits, within the BizTalk server product.  So customers will have to choose: extensibility and ecosystem, or BizTalk.  In the past, that's been a genuine decision, because nothing else in the Microsoft stack has offered industrial-strength orchestration and adaptable messaging capability.  So there have been grounds for accepting the limitations of XLANG and the weak BizTalk ecosystem in order to get all the stuff that BizTalk does provide.

But Oslo is going to bring a new process server which promises a high level of robustness and hosts long-running WF applications communicating via WCF services.  And WF is going to be getting more investment than XLANG thanks to its shared role across Developer Tools (.NET), Office (SharePoint) and Dynamics (CRM).  All third-party effort is going to be going into WF if only because XLANG has nowhere for third parties to extend it.  Business processes in Oslo are probably going to be built out of WF activities.  By focusing on XLANG the BizTalk team are severing their product from all that investment and support, even as the Oslo process server shreds one of their major selling points and WCF shreds another.

Here's my prediction for the future of BizTalk in the Oslo timeframe if it doesn't have WF as a first-class citizen.  As soon as the Oslo process server with the WF/WCF host appears, the death clock starts ticking.  The WF/WCF/Oslo process server combination has a superior orchestration engine, an at least comparable messaging interface, and now a robust, manageable environment for hosting long-running services.  All the reasons against using BizTalk remain true; but now many of the reasons in favour of using BizTalk go away because the same features are available on the extensible platform.

What will be left to justify using BizTalk for new development?  The adapter library, for as long as the adapter vendors don't get around to doing WCF ports.  The XML message transformation engine, like there are none of those available for .NET already.  The tooling for business activity monitoring, except that this is currently pretty weak, and since WF already supports BAM-type tracking, I'll be astonished if third parties don't produce BAM tools for WF and the Oslo process server (in fact I'll be surprised if nobody is working on WF BAM tools already).  So within a couple of years, almost all of BizTalk's differentiators will have gone away, and unless the BizTalk team does something about it, BizTalk will be legacy except for a few niches where the adapters haven't been ported to WCF.

If BizTalk is to survive and flourish in Oslo, its role should not be to deliver a complete stack in itself -- that is, to compete with the WF/WCF combination at the engine level -- but to add value on top of the core WF/WCF/Oslo process server stack, through services and capabilities such as message transformation, service brokering/ESB, extensive adapter support (especially in business-oriented specialised domains such as EDI, health, RFID and LOB applications like SAP) and business tooling.  Persisting with XLANG not only takes resources away from these areas where BizTalk can add value, it drives customers and third parties towards extensible, modular WF/WCF solutions, accelerating the erosion of BizTalk's value-adds as vendors see opportunities to sell equivalent components into the WF/WCF market.  WF and Oslo could and should be a huge opportunity for BizTalk to expand its horizons, become a much more developer-friendly platform and focus on adding value further up the stack; but this roadmap threatens to blow that chance.  Let's hope the team keep their options open.