Metastorm BPM is a mature pure play BPM development platform. The main differentiators of the product are the seamless integration of forms and database storage, and the ease with which business users are able to build working systems without writing code. The system operates in a Windows environment, making it a prime candidate for integration with Microsoft products such as Office and Windows Workflow Foundation.
Microsoft Workflow Foundation
Windows Workflow is a relatively new technology from Microsoft that aims to help developers creating systems that involve long-running processes. In some respects it provides a subset of the functionality provided by products such as Metastorm BPM, but is missing features such as roles management and forms integration. Also, it is designed as a tool for developers as opposed to end-users and as such the runtime can be hosted in any application as there is no workflow engine application or service. It is therefore essentially up to the developer to determine how the runtime system will be hosted.
Windows Workflow could be used to develop a fully featured workflow/BPM system, but many of the features that Metastorm BPM delivers out of the box would have to be created by developers. The advantage is, however, that you can develop the application to exactly your needs, or reuse existing systems.
Process Mapping has considerable experience building systems using Metastorm BPM and .Net. As a Microsoft Partner, the company is also developing a Windows Workflow Foundation Framework of their own for building Process Oriented systems. Process Mapping also produces the FreeFlow .Net Framework for integration with Metastorm BPM and as such is ideally positioned to assess the suitability of integrating the two technologies.
Windows Workflow and Metastorm BPM
So how will Windows Workflow fit in with Metastorm BPM? The advantage of a BPM system is that an organisation is able to standardise on one particular technology for their BPM needs, but it seems quite likely that there will be areas for both technologies. In these situations, synchronising workflows between the two systems and getting data between the two systems is likely to be an important requirement. The Metastorm ECL Activity Library for WWF solves half of this problem as it offers a set of activities that enable hosted or third party activities to construct Workflows using Metastorm's ECL. Basically this means you can communicate from Windows Workflow to Metastorm BPM but not the other way. Hopefully the ability to communicate the other way will be added in some future release.
Several activities are provided by Metastorm, for example logging in; getting the user's To Do list; opening a folder; starting and submitting actions and raising flags. In practice it is likely that the most useful activities will be the ability to raise flags and start actions, which would be used to start a process or move a folder to another stage.
Two examples are provided. The first is a Windows Forms project which uses Windows Workflow to create a Metastorm BPM client, which doesn't seem like a particularly likely scenario but it does demonstrate how the activity library can be used. We couldn't get it to work fully, we were only able to view the lists but not open folders. We were also able to raise flags.
The second example is for Microsoft Office SharePoint Server 2007. To date we have been unable to get SharePoint to work in a virtual machine so we are not able to comment on this example.
So is it useful? It probably comes down to whether you're happier using the Windows Workflow designer or writing code. It doesn't provide anything new that hasn't been available via the .NET ECL or FreeFlow for some time. It is possible that the Windows Workflow designer could be used by a non-technical user, but we cannot see this as being likely. Setting up the activities to successfully communicate with Metastorm BPM is still fairly technical whether achieved via the Designer or via code.
One problem that will always occur when integrating with Metastorm BPM in this fashion is that the links are based on Stage, Action and form name rather than an invisible ID. Because of this, any integration piece must be refreshed whenever the process changes. If the changes are significant, re-applying the integration may be troublesome. Given the ease with which you can change such names in Metastorm, and the benefit for such systems to be 'Agile' (as Metastorm claim), these names are likely to change fairly frequently. Any integration plan will need to take this into account in order to be successful.
If the next release were to include the ability to receive data from Metastorm BPM, then it could potentially become much more useful.