Intended Audience

This document is designed for solution architects, project leaders, system integrators, and business managers who have a requirement to understand the positioning of a fully featured BPM product such as K2 against the native developer-focused capabilities provided in the .NET framework by Windows Workflow Foundation (WF). In many instances customers request this reference material in order to help them understand and position these technologies to the business.

Summary

K2 is a fully featured process automation product comprising a scalable server architecture, multiple graphical process designers, routing and tasking, integrated security, data and line-of-business integration, process administration and management, process visualization, escalation management, KPIs and reporting.

Windows Workflow foundation (WF) is a core component of the .NET 4.0 framework.  WF is a developer-based technology aimed at applications that contain “workflow-type patterns”. The entry point for anything Workflow Foundation-based is Visual Studio and is inherently the space of professional developers.  K2 makes extensive use of Windows Workflow Foundation as foundational building blocks at the execution level of its workflows.

Clearly building workflow applications on native WF is possible. However, when considering business solutions that encompass the concepts of process or workflow projects, it is essential to understand that products like K2 are designed to deliver completed low / zero code business solutions in weeks. K2 has 10 years of workflow R&D, works closely with the Microsoft product teams including the .NET WF team and continues to build on the core architecture that Microsoft continues to evolve.  The end result of this is a platform that is targeted at solving business issues, as opposed to a technically focused experience available with WF.

Purpose-built products such as K2 have moved significantly beyond the “proving stage”.  Building workflow applications today in code would be similar to building an email server using the System.Net.Mail namespace also available in the .NET framework.  A custom built email server is indeed possible and chances are that the end product may even do specific things for your organization that are not available in Exchange. However, economics dictates that organizations are no longer in the business of coding this kind of functionality. This same set of economics applies to business process management and workflow.

For the full white paper, please download the PDF using the link on the right.