TechEd Day 2: A Workflow Manifesto

TechEd Day 2: A Workflow Manifesto

  • Comments 7
I gave another talk yesterday, this one called "A Workflow Manifesto". The objective of this talk was to get people thinking about other ways in which they could use workflow (since workflow has historically focused only on human-oriented workflow). I've blogged a bit about this topic previously but this is the first time I've focused on it for a full-on presentation. The audience seemed enthusiastic and there wasn't enough room for everyone to sit down - there is obvious interest in this topic.
 
I started out by giving a brief history of workflow and model-driven development. Workflow technologies first emerged in the mid-1970s with simple office automation prototypes at Xerox Parc and the University of Pennsylvania’s Wharton School of Business. Interest in workflow and office automation began to wane in the early 1990s until the book “Reengineering the Corporation” re-ignited interest in workflow and business processes. The reengineering trend of the 1990s gave us several books and methodologies for process analysis – unfortunately the technologies such as CASE and their ilk were immature and required significant manual intervention, exposing projects and executive stakeholders to significant levels of risk. Even worse, other “workflow products” were thinly disguised efforts to sell hardware such as scanners, printers and other peripherals. Clearly the term “workflow” was being abused to take advantage of confusion in the market (some might say that history is now repeating itself with a new wave of vaguely defined acronyms like SOA and ESB, but that’s a topic for another time). So why will we be successful this time? I believe we are better positioned to adopt workflow technologies than any time in the past due to the maturation of technology, the enterprise and the software industry over the past decade:
  • Technology maturity – Integration tools like BizTalk Server have exposed a reliable workflow capability (e.g. "orchestration") for many years. Many of these integration servers have achieved higher levels of reliability while increasing the breadth of their line of business (LoB) adapters. BizTalk Server, for example, was re-architected in 2004 to enable enterprise-class scalability and reliability. BizTalk Server 2006 built on the previous version’s improvements by focusing on management, improved messaging and web services while increasing the number and type of adapters that are included with the product. Developer frameworks like Windows Workflow Foundation (WF) enable developers to embed and expose workflow capabilities within an application with minimal effort. The flexibility of a framework like WF supports both automated and human workflows, joining the two “worlds” of workflow that have previously required vastly different tools. The extensibility of WF also supports emerging standards like WS-BPEL while enabling developers to define organization-specific or domain-specific “building blocks” (activities) that can be leveraged in current and future workflow solutions.
  • Enterprise maturity – Each year, Gartner’s Executive Program releases their “CIO Agenda” - a list of CIO business and technology priorities compiled from worldwide surveys of their members. 2006 was the second consecutive year in which business process improvement was identified as the CIO’s top business priority, based upon the 1400 global CIOs that participated in the survey.
  • Industry maturity – The IT industry as a whole is repositioning itself as an enabler instead of a constrainer business processes, partnering with both users and analysts to help define and implement processes. This collaborative approach avoids the potential risk of misalignment with business objectives (a risk that is frequently realized by adopting a typical “bottom-up” approach to software development).
Digging into the manifesto, I discussed the following topics and included many, many WF demos:
  1. Workflow is everywhere
    • User Interface (UI) Flows: Using the state of a workflow instance to configure the UI (enable/disable buttons, etc), pageflows with ASP.NET, driving a menuing system and how the Composite UI Application Block (CAB) can make use of WF in a future release. We can also use workflow to orchestrate services or develop and publish our workflows as a service.
  2. Workflow is expressive
    • Workflow models can take many forms - the three most common models are sequential, state machines and business rules (sometimes referred to as "data driven"). While there are no hard and fast rules for determining which model to use when there are some well-documented principles that help determine which model may be best for your situation.
  3. Workflow is fluid
    • We can modify, interrogate or otherwise manipulate workflows at design time and run time. I showed how we can serialize workflow state (for a long running process), modify a workflow on the fly (adding/removing activities) and modify behavior on the based a set of context-based parameters passed into the workflow at runtime.
  4. Workflow is inclusive
    • Workflow can bridge the worlds of structured data and structured processes in a system-to-system workflow with the highly unstructured data and processes typically found in a human workflow. SharePoint 2007 ships with several human workflows (built on WF), enabling scenarios such as document routing, management approval and others. The new SharePoint adapter in BizTalk Server 2006 makes it much easier to "bridge" the worlds of system-to-system and human workflows, enabling BizTalk to task a specialist address a specific exception or modify business rules based on the volume or types of exceptions that may arise.
  5. Workflow is transparent
    • Workflow is easier to visualize, understand. We can share workflow models with non-technical end-users to communicate the intent of the workflow while maintenance programmers can use the model to both understand and maintain the workflow (or service, if the workflow was published as a such). Demonstrations here included WF"s tracking mechanisms, serialization to XAML and generating the XAML on other platforms for instantiation within WF.
WF is an amazing framework for working with and embedding workflow in your solutions. There is, quite literally, nothing like it on the market today. WF's extensibility and ease of integration enables us to start using workflow in ways we may not have previously considered. This will lead to a resurgence of interest in workflow which, if we’re not careful, may result in whole new set of buzzwords and acronyms. :(
 
 
More booth babe duty today again. I need to get out and check out the other exhibitors I hear there are some cool demos on display. IBM is here with Viper - I'm interested in learning about its XML capabilities. I'll try to include a review of who's on the floor and what's cool in an upcoming post.
 
Had dinner at Stephanie's with the team.   Great food but the restaurant itself was a typical fern bar.  Go for the food, not the atmosphere.   I had to catch a cab back to my hotel in Rhode Island uh, I mean Quincy.  Its amazing how far away some of the hotels are from the convention center.
Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post
  • I enjoyed the TLC session and look forward to the progressive evolution of WF as it grows additonal roots (Office client / server suite products alike).  It's nice that anyone can host part or all of WF however they need to be mindful of scalability aspects (app domain spin up, etc).
  • Workflow 2.0 ??? Oh please no! ;)

    I would like to see a discussion within the dev community about process centric development in general. Like how we can control data access in a LRT within an instance of a process/workflow. How object/data centric development differ from this new design approach. Also, a discussion on .NET implemented activities vs web service implemented activities.
  • In terms of the SharePoint 2007 capabilities and the Adapter for BizTalk, I would love to know how this fits with LOBi, and I quote:

    "LOBi enables deep structured process integration with Office client applications, the ability for people to update transactional applications from within Microsoft Office, and the ability to more securely take structured business processes and data offline," according to Microsoft's definition of LOBi, which was part of a June 12 press release issued by Microsoft.

    To my mind, Microsoft needs to clarify which of the integration/workflow solutions makes sense when, perhaps through the use of common scenarios.

    Also, I echo the preceding comment about Workflow 2.0. There is already the nonsense of SOA 2.0 and we have 89 people signed-up to our no to SOA 2.0 petition: http://www.mwdadvisors.com/resources/stop-the-madness.php
  • Guys - the workflow 2.0 was meant as a joke (note the little frowny face above).  

    LOBi is a set of services to make make Line of Business (LOB) application data and processes accessible to information workers through extensions of the Office client and portal user experience.   LOBi's current focus is data and entities, not process.   Hope this helps!
  • Just Say No to 2.0
  • PingBack from http://paidsurveyshub.info/story.php?title=loosely-coupled-thinking-teched-day-2-a-workflow-manifesto

  • PingBack from http://insomniacuresite.info/story.php?id=5196

Page 1 of 1 (7 items)