fyi WinOE Workflow Prepped For Whidbey, Longhorn, Office 12 In 2006

All:

Pointer to article: http://www.crn.com/nl/crndirect/showArticle.jhtml?articleId=57700833)

Kobielus kommentary:
Microsoft has been saying for years that BizTalk is the foundation for convergence of all of their workflow functionality (encompassing the workflow features of Exchange, SQL Server, Content Management Server, SharePoint Team Services, “Project Green,” DRM Services, and what have you). “Longhorn”’s WinOE Workflow module—in tandem with related functionality going into “Whidbey” and Office 12--is where Windows gets workflow in a serious way.

Microsoft has said that BizTalk Server will continue to be a stand-alone workflow/orchestration product, and I believe them. [Quick terminology note: “workflow,” “orchestration,” “choreography,” and “business process management” are all synonyms in my book—actually, in my actual books—“Workflow Strategies” (1997, IDG Books) and “BizTalk: Implementing B2B E-Commerce” (2001, Prentice Hall PTR)—I use the term “workflow,” whereas in my recent coverage of this space I’m tending to use “orchestration” as the catch-all term; same diff].

Microsoft hasn’t provided as much specificity as I would wish with its BizTalk roadmap. But what the article says sounds quite plausible (except for one teeny little error—can you spot it?): “The next version of BizTalk 2006, code named Pathfinder and due to go into beta by the end of the year, will continue to use the existing original orchestration engine based on Visio but its successor -- due in 2008 -- will use the new WinOE orchestration technology, sources said.” The error is that it’s absurd to say that “[BizTalk Server’s] original orchestration engine [is] based on Visio.” This is entirely apples-and-oranges: an orchestration engine is a runtime component; Visio is a flowcharting tool for business analysts to use in specifying processes to be executed by BizTalk’s runtime orchestration engine (Visual Studio and various BizTalk orchestration tools are the heavy-hitting technically-oriented orchestration modeling/definition tools in Microsoft’s arsenal).

Anyway, having written a book on BizTalk, my hunch about WinOE Workflow is that it will primarily provide the development/runtime infrastructure for person-to-person (aka human) workflows throughout Microsoft’s product family (BizTalk Server 2004 added human workflow functionality to a product that had previously been focused solely on EAI). Where does that leave future versions of the stand-alone BizTalk Server product? My guess is that Microsoft will position BizTalk Server more solidly in the middleware space as an integration infrastructure hub for application, data, and process integration (and hooking into WinOE Workflow for the presentation side of it all). Microsoft currently has no EII offering, and I suspect that BizTalk will figure into that strategy going forward. Likewise, Microsoft has no enterprise service bus (ESB) offering (which I define as integration fabrics that support flexible message exchange patterns, including hub-and-spoke, decentralized/routed, and peer-to-peer).

This “single [Microsoft] orchestration programming paradigm” mentioned in the article will be interesting to see. I doubt there’ll be a single paradigm. Rather, there’ll be orchestration visual modeling paradigms appropriate for various users: non-technical end users (perhaps using an e-mail-like routing-slip metaphor from within Office/Outlook/InfoPath/IE for process definition, and e-mail-like worklists for process participation, and calendar/task-management interface for process tracking), business process analysts (Visio-like flowcharting), orchestration process-modeling and simulation gurus (various high-powered model-driven-development paradigms a la UML, BPMN, etc., with Microsoft’s “Whitehorse” pulling the carriage), and process/system administrators (browser-based visual tracking/monitoring tools).

Just as important will be Microsoft’s orchestration-standardization push. How deeply/broadly will it implement WS-BPEL for hub-and-spoke orchestration? WS-CDL for peer-to-peer orchestration? Various WS-* standards/specs—WS-Policy, WS-ReliableMessaging, WS-Notification, WS-Eventing, WS-Coordination, etc.—to address the critical features of a federated multivendor orchestration environment (oooh..there’s a new concept—see my prior blog posting on new frontiers in federation).

Some folks are down on WS-BPEL because it doesn’t provide the be-all orchestration standards framework. WS-BPEL has its persistent "debunkers," but such attitude is based on misunderstanding of its proper scope. It's an important piece of orchestration standards picture, but it only defines the process-definition rules interchange/execution syntax for orchestrations executed at intermediary nodes such as integration brokers (such as BizTalk Server); WS-CDL provides an equivalent rules syntax for orchestrations to be implemented at endpoint nodes. Check out the Workflow Management Coalition (www.wfmc.org) for a fuller interoperability reference framework for federated orchestration (though the WfMC’s actual “standards” in this regard have been conspicuous in their absence from most commercial workflow/orchestration tools.

So WS-BPEL is only a small piece of the much broader range of orchestration standards that are necessary under the WS-* umbrella. Microsoft’s orchestration products/tools—now and future—are only a small piece of the overall orchestration federation environment for multivendor, multiplatform, multi-enterprise business processes. But Microsoft has an excellent roadmap for embedding general-purpose, standards-based orchestration (person-to-person, app-to-app, etc.) into their platform. I’d like to see other platform vendors follow suit with their orchestration roadmaps.

Jim