Rapid Prototyping with Workflow Foundation 4.0

While working on various projects within the Configuration Manager ecosystem here in Redmond I’ve had the opportunity to work with Workflow Foundation for a couple years now. Being in the enterprise software space it is not difficult to find a spot for Workflow Foundation within a given problem space or project as it makes for a cozy home for complex business logic routinely found in enterprise software. In a new project that I’m working on related to the upcoming version of Configuration Manager I had the opportunity to swindle the team into using Workflow Foundation as a core component to support all of our business logic. At the time I was in favor of using WF as I was familiar with the benefits of the tracking, persistence, and other features of WF,. all of which already have a multitude of blogs posts dedicated to them. One aspect that I had not explored prior to this project, and which is the subject of this blog post, is ability to rapidly prototype with Workflow Foundation.

While pinning down the vision and high level user stories it became apparent that the crux of this project was getting the business logic right, and doing that would require soliciting input from various subject matter experts from more than one team. Knowing this meant knowing that whatever we use to implement the business logic was going to go through much iteration as we shopped around our current thinking and incorporated feedback.

It’s all about the Flows

The nature of the FlowChart activity and its designer allows one to easily rearrange logic and components. But most importantly the Visio-esque FlowChart designer provided two key benefits. The first was that I found it was easy to stay abreast with the changes to our business logic flying out of our design and review meetings. Applying changes were simplified by the literal way in which Visio spec docs translate into a WF workflow definition. I was able to implement core behavior and be confident that it matched what was defined in the spec by simply comparing what I saw in Visio on one monitor with what I saw in the Visual Studio FlowChart designer on the other monitor.

Secondly, it made bridging the technical/nontechnical communication barrier much easier. Since I was working in an environment that was very similar to Visio and to what PMs are comfortable with, we were able to have discussions about the prototype directly. Ergo, non-technical team members were able to contribute to discussions involving the actual implementation or the “code”. This was helpful when the specifics of the implementation inevitably exceeded the detail or fidelity of the spec docs. Or put differently, it increased the relative area of the intersection between PM land and Dev land. The same could easily be achieved while working with Sequence style workflows. The key is to be deliberate about which style you are using in your design discussions and to avoid Visio’s flexible ad hoc nature to create spec diagrams that are some sort of hybrid mash up that won’t translate into some form of Workflow Foundation artifact. This increase in common ground between the disciplines has been a real asset for our team.

Comments

• Anonymous
  January 05, 2011
  Interesting Finds: January 6, 2011