Workpoint Comparison

Today, many organizations interested in implementing enterprise-class BPM technology will consider open-source options, such as jBPM or Microsoft development using the Windows Workflow Foundation. For the edification of our visitors, the following captures the differences in these technologies, contrasted against the functionality provided by Workpoint’s enterprise BPM:

To access a printable PDF version of this comparison, please click here.

Workpoint vs jBPM

Enterprises seeking Java BPM will find some similarities between jBPM and Workpoint, but a thorough evaluation reveals that these two products are quite different in terms of maturity and scope of solution.

Workpoint is a comprehensive process management solution. In contrast, jBPM is a service orchestrator. In other words, jBPM only orchestrates services (i.e., Web services or well-defined API’s) because it is a development-only integration tool. jBPM is representative of other open-source offerings, as it is available at no initial cost from Red Hat. However, "free" ends abruptly as users must pay for support, development costs and often most dearly in terms of time-to-market. Essentially, BPM tools such as jBPM and other basic open-source solutions place organizations in the BPM development business for the long term. Changing application requirements dictate continuing BPM development and associated QA of the platform itself, in addition to the underlying applications. Therefore, what first started out as "free" will eventually result in a significant investment in terms of QA and development costs.

The table below further details the key differences between jBPM and Workpoint. Keep in mind that, comparatively speaking, most jBPM features are fundamental in nature, with implementation and development of advanced features left to the expertise of skilled Java developers.

	Workpoint	jBPM
Product maturity	17 years	3.5 years
Graphical process designer	YES Applet & thin client Drag/drop Separate IT/business analyst views & priveleges	YES Eclipse development IDE plug-in module requires JAVA technical skills to install and use
User interface	YES Portal Generator (SPRING-based with .NET controls)	YES JBoss Seam based on Java Server Faces
Reporting	YES	NO
Orchestration events	YES	YES
Cross-instance milestones	YES	NO
Dashboard	YES	NO
Business activity monitoring	YES	NO
Appserver support	All J2EE + .NET 3.0	JBOSS
RDBMS support	All	JBOSS Hibernate MySQL
Transaction support	YES Transaction management	NO
Data versioning	Accessed in place	Attached to process
Model and instance persistence	YES	YES
Update executing instance	YES	NO
Graphical application integration environment	YES	NO
Product support	YES	Available
Business analyst tool	YES	NO
Transition rule execution	YES	NO
Transition upstream (looping)	YES	NO
Remote client APIs	YES	NO
Out-of-box notification	YES	NO
Process-centric	YES	NO Workflow-based or screen-based navigation
Security infrastructure	YES	NO
Graphical form builder	YES	NO Requires WPF development

Workpoint vs Open-Source

Open-source BPM vendors offer free access to software and documentation, as well as free reign to modify that software. Several vendors now offer open-source tools, which has some organizations asking, "Why would I pay for BPM when I can get it for free?" Simply put, there are many reasons why enterprises should select proprietary software over open-source.

Most proprietary vendors offer comprehensive enterprise-class BPM solutions out-of-the-box, delivering the functionality and scalability required to fulfill both current and future needs of enterprise users. With most proprietary software, organizations can change and fine-tune business processes dynamically, avoiding long lead times and disruption of operations. Open-source BPM tools, on the other hand, place organizations in the BPM development business for the long term. As application requirements change, organizations must continually develop and enhance the BPM platform, as well as any associated QA and underlying applications. If an organization chooses to implement open-source BPM, it should be prepared to staff significant BPM expertise for continuous configuration, development and maintenance of the open-source BPM infrastructure.

Further comparisons reveal that most proprietary software is fully developed and supported. Robust and scalable out-of-the-box, proprietary solutions allow companies to focus on core business, and not on building and maintaining BPM systems. However, open-source BPM tools almost always represent a patchwork of contributions from multiple developers, each with a different level of BPM expertise and disparate object agendas; making a cohesive, unified product approach very difficult or nearly impossible to achieve.

Open-source vendors stay in business by charging for support and license upgrades if/when an organization needs a more reliable and flexible platform to operate its mission-critical processes. Therefore, free ends when users need to enhance and customize each BPM implementation. If one truly understands the future importance and pervasiveness of BPM within the evolving virtual enterprise, the decision to select products from focused development companies over community-contributed software becomes a clearly superior decision.

With Workpoint, organizations can rely on comprehensive BPM backed by more than 17 years of development and support. As opposed to most open-source solutions, Workpoint allows new components to be integrated into an organization's existing applications. Moreover, this can be done without expensive recoding, retesting or redistributing. In addition to its high volume, high throughput capabilities, Workpoint offers flexible, world-class BPM to organizations across the globe spanning various industries, such as healthcare, insurance, manufacturing, banking and retail. Whether used as an embeddable component or as a standalone solution, Workpoint provides the technology to seamlessly automate, manage and optimize dynamic, high-volume business processes across the enterprise.

Workpoint vs Microsoft Windows Workflow Foundation

Windows Workflow Foundation (WF) is a general workflow framework platform for .NET developers—it is not a true BPM product. As a framework indicates, WF can not operate on its own; rather, organizations must host the WF engine to execute a workflow. In addition, the WF framework does not have built-in scalability, so organizations must develop the technology around runtime objects in order to execute multiple instances at the same time. Furthermore, WF only supports two types of workflows: sequential and state machine. WF is essentially a single component that requires several additional components to meet the criteria of a BPM solution. A subset of components organizations must add might include BizTalk for orchestration and BAM, and SharePoint and InfoPath for form generation. This approach ultimately forces organizations to support continuous in-house BPM development, and puts the user at a significant disadvantage when aiming to achieve established enterprise BPM, quick time-to-market and ROI.

A product comparison will reveal that Workpoint provides an enterprise workflow object model, while WF provides a workflow application generation model. Workpoint's object model offers concept of work items and resource assignment, allowing for easy integration with existing applications and systems. However, users will most likely find that the application generation model requires significant development to achieve sophisticated workflow capabilities. Users have ultimately found that the code generation paradigm falls short of the well-defined object model when comparing both ease-of-use and ease-of-deployment. Furthermore, the code generation paradigm simply does not lend itself for use in dynamic, large-scale enterprise workflow applications.

In addition, Workpoint differentiates itself from WF by its ability to model multiple transitions coming out of a node. This makes process design much simpler than the flowchart-like design deployed by WF. Moreover, with WF, there are several different types of models (i.e., sequential and state machine) while Workpoint only requires one type to model everything. For example, custom activities in WF must be developed in Visual Studio and don’t offer any functionality over a standard out-of-the-box Workpoint activity.

The table below details additional differences between Workpoint and WF.

	Workpoint	Windows Workflow Foundation (WF)
Product maturity	17 years	.5 years
Process manager	YES	NO
Graphical process designer	YES Applet & thin client Drag/drop Separate IT/business analyst views & priveleges	YES Visual Studio with WF Extension
User interface	YES Portal Generator (SPRING-based with .NET controls)	NO Requires development
Reporting	YES	NO
Orchestration events	YES	NO
Cross-instance milestones	YES	NO
Dashboard	YES	NO
Business activity monitoring	YES	NO
Appserver support	All J2EE + .NET 3.0	.NET 3.0
RDBMS support	All	SQL support always requires development
Transaction support	YES	YES Can't participate in client transactions
Data versioning	Accessed in place	NO
Model and instance persistence	YES Every state change is inherently transacted and persisted	YES Persistence must be more explicitly managed
Update executing instance	YES Can view and change instances graphically as one would a process model	YES Requires updated version of Sharepoint for non-graphical wizard-based changes to executing instances
Graphical application integration environment	YES	NO
Product support	YES	Available
Business analyst tool	YES	NO
Transition rule execution	YES	NO
Transition upstream (looping)	YES	YES
Remote client APIs	YES	NO
Out-of-box notification	YES	NO
Process-centric	YES	NO
Security infrastructure	YES	NO
Graphical form builder	YES	NO Requires WPF development
New Process deployment	YES Create new Process in Designer and all servers can instantly utilize it	YES Create new Visual Studio project, create new Process, generate assemblies and deploy to all servers
Call out to any existing assembly	YES Optimized reflection can call existing code without major performance penalties	No
Instance History	YES History is maintained for all instance state changes, unless explicitly configured not to	NO

Workpoint vs Microsoft BizTalk Server

BizTalk Server is an EAI solution from Microsoft, a product that combines rich enterprise application integration and message brokering with basic automated process management features that must be combined with other Microsoft products to deliver the enterprise orchestration offered by today's BPM vendors. These services, found within the domains of separate product offerings, include the following:

• Windows SharePoint Services and Office SharePoint Server: primarily a provider of human workflow.

• Windows Workflow Foundation (WF): Microsoft's workflow framework and low-level execution engine.

• Microsoft Excel and Office PerformancePoint Server: business activity information.

• Multiple Designers, including Microsoft Visio and two separate Sharepoint designers: process definition tools.

• Infopath: forms manager used in some environments to gather information from human process interactions.

State-of-the-art BPM orchestrates human and automated activities within one unified paradigm. This paradigm is supported by a single graphical user interface providing views tailored to either the IT or business user, with privileges granted for each type of user. Product flexibility and scalability ultimately depend on whether the BPM engine is architected to leverage a data-driven model (Workpoint) or a code-generated model (Microsoft). Generated code, which ultimately becomes a binary executable, can provide neither the flexibility nor the agility required by today’s fast moving, constantly changing corporate operations and IT environments. Code generated models also lack the key capability of adapting instantiated orchestrations, which is extremely important when creating enterprise-aware processes.

Data-driven models such as those employed by Workpoint, can provide real-time graphical representations of executing orchestration instances with the ability to modify any instance independent of the original orchestration template while retaining all state change history. This is not possible without code regeneration and deployment in Microsoft’s model. Data-driven models also provide the ability to participate in client transactions (not possible with WF) and offer enhanced reporting capabilities that require no extra data capture. Data-driven models also provide an architecture that inherently provides better scalability.

Taking a closer look at Microsoft’s multi-product integration approach, one will quickly observe important deficiencies, such as the complexity involved to invoke WF workflows from Windows Communication Foundation (WCF) services, the difficulty of integrating disparate directory services to perform just-in-time resource assignment and the inability to graphically change all aspects of an orchestration (template or instance) without requiring a binary deployment. These are all functions that mature BPM products perform effortlessly. These operations are either not possible or very difficult to achieve within Microsoft’s multi-suite BPM approach.