Robust middleware technology has provided a rich, fertile, and mature layer of technology that has enabled the concept of workflow to play a much more powerful role in an organization, moving it out of the structure of an application onto the middleware layer to do more than just route documents within an application.
Today, workflow automation software is a subset of a much larger environment, BPM, which defines, enables, and manages the exchange of enterprise information and the adaptive structures for action through the semantics of a business process view that involves employees, customers, partners, applications, and databases. While the goal of workflow is to accomplish a task according to a set of procedural rules, the goal of BPM, according to the BPMi Business Process Modeling Language Working Draft version 0.4, is to "accomplish business goals that include end-to-end efficiencies, transformation empowerment and value management." BPM has to be capable of modeling a process, brokering that process, delivering it with straight through processing (STP), and then managing it.
The path to BPM is evolving from three "forks in the road" -- traditional workflow suppliers, EAI suppliers, and pure-play BPM suppliers. Knowing which front a supplier has emerged from can be instrumental in understanding the core competencies of suppliers and their BPM offerings.
Workflow suppliers are traditionally well versed in collaborative applications and understand the definition and flow of operations among people and document and image formats within these environments. Traditional workflow applications were built in C or C++ rather than Java, making them platform-dependent. They are subsequently less savvy with integration issues between software and hardware systems and often may not have thin-client architectures. Even those companies adopting thin-client architectures -- unless they create a code base from scratch -- required grafting new technologies on old architectures, which can be problematic. In addition, starting from scratch creates a serious time-to-market impediment.
Workflow suppliers have also been traditionally internally focused, limiting business-to-business integration (B-to-Bi) capabilities. BPM suppliers that have evolved from the traditional workflow market include FileNET, Kabira Technologies, Metastorm, and Staffware.
EAI suppliers or B-to-Bi suppliers, while being the ultimate enablers of BPM, tend to be focused on point-to-point integration and approach process integration as an extension of an application. These suppliers have more of a data- and transaction-oriented domain expertise.
EAI suppliers moving to BPM have traditionally built workflow capabilities on top of their EAI frameworks. These solutions address static resources within an organization such as documents or information and provide data or document-modeling environments to describe processes and tasks that will facilitate disseminating these resources, but do little to address the dynamic and flexible aspects of a business. Dynamic conditions can include constraints and heuristics and exceptions to procedures.
|Recent Aberdeen InSights|
|Where Financial Processes and Technologies Stand: A look at the opportunities and challenges offered by financial process automation. The Road to .NET for Business Applications : Great Plains' annual Convergence conference showed it is truly Microsoft's business apps arm. Human Capital Management Lessons from 9/11 : Sept. 11 has taught companies the importance of proactively managing their employee assets in addition to their IT assets A New Era for Best-of-Breed CRM? : CRM vendors have been redeveloping application suites over the last two years, attempting to make them more modular and Web friendly. With New PDAs, It's High Time for Wireless : When it comes to mobile solutions, CIOs want wireless e-mail, synchronization, access to enterprise databases - and good ROI. Click here to reach CIN's Research section.|
The dynamic conditions of a process cannot be predetermined when processes are being modeled. These conditions are spontaneously invoked to respond to changes in an environment. Support for this kind of flexibility is what differentiates best-of-breed BPM solutions from traditional business modeling techniques as well as application and data integration platforms. For EAI suppliers to excel in this arena, they need much more flexible functionality and domain expertise and a much greater understanding of business issues -- particularly dynamic ones. BPM suppliers that have evolved from the EAI market include CrossWorlds, Level8, SeeBeyond, TIBCO, Vitria, and WebMethods.
Pure-play BPM suppliers start at the top of an organization to understand organizational processes and drill down from there. This approach typically has a better defined modeling environment that is process-oriented rather than data- or information-oriented. That approach may also be more people-oriented and consequently better suited for change management. Pure-play BPM suppliers that have built their applications from scratch include Business Threads, Intalio, Lombardi Software, Metaserver, Nobilis, and Savvion.
Many of these suppliers still have a long way to go to architect their methods and tools to be able to deploy objects, components, and applications within a services-oriented framework. This approach will ensure the fundamental flexibility required to move from a static, workflow-enabled environment to a dynamic, real-time BPM infrastructure. The ideal architecture will embed routines and handle exceptions flexibly and with adaptability.
However, for BPM to rise to the top of the enterprise and be truly suitable as the conductor of an organization's multi-faceted business, it must effectively culminate the functionality of all of the backgrounds from which BPM suppliers are emerging. It is no longer tolerable for BPM, workflow, and integration to be separate capabilities. Just as a composer is interested in the combined sounds of the entire orchestra and would only rewrite the strings section of a composition if it were "out of synch" with the rest of the instruments, a business process conductor is interested in the integrated landscape of the business. The overarching concern is how each of the parts interacts with all of the architectural layers of the business -- from application-specific components to business domain components to extended platform components to platform/network components.
Industry proponents claim that BPM will become as valuable to managing business processes as RDBMS (relational database management system) was to managing databases beginning in the mid- to late-1980s. Business processes, like data, have to reside in their own management systems where they can be analyzed to determine the best way to conduct business. They can then be disseminated to various constituencies -- systems, applications, and people -- in a common language, describing how a particular process should be performed.
There is a good probability that BPM will follow in the RDBMS market's footsteps, which took about a decade to mature and is now growing between 8% and 10% annually. In 2001, the BPM market represented a $1 million opportunity and has a projected 70% CAGR (compound annual growth rate) by mid-2003. Even for the small percentage of early adopters, to date, less than half are in their final stages of deployment. These are early indicators of a market poised for growth. That also indicates that 2002 will be a year of transitioning from early adopters to early majority, a pivotal year for BPM.
Standards are still elusive in the BPM arena, with multiple efforts being focused on the issue of coordination between and collaboration of standards. Creating a common business process language is critical for enabling interoperability. It is this language that will enable process to be managed across an enterprise and beyond it, bridging the gap between legacy IT infrastructures and emerging B-to-B collaboration protocols such as RosettaNet, BizTalk, and ebXML (electronic business eXtensible Markup Language).
The Business Process Modeling Language (BPML) is one language specification that outlines a simple language/process structure that extends the semantics of other models -- including the WfMC Workflow model, RosettaNet PIPs, and Universal Modeling Language diagrams -- to represent a BPM architecture that covers a wider set of requirements (Figure 1).
BPML uses simple activities to model the consumption and production of messages, tasks, data, or goods. The language also models operations of actions and communicates failure. The modeling environment models the flow of control, including serial, parallel, or conditional. It must also model compound states, consisting of multiple subactivities representing substates. (For more information on this language/process structure, download the BPML Specification Working Draft 0.4 at www.BPMi.org).Aberdeen Conclusions
The current economic environment demands that organizations reduce operational costs in an effort to stop the fiscal bleeding from drastic revenue declines. But reducing operational costs must, in turn, bolster operational efficiencies: Organizations can cut fat but not muscle. BPM offers a compelling path to obtain healthy operations -- and burns fat in the process. BPM leverages an organization's existing IT infrastructure, bridges the gap between this environment and emerging B-to-B collaboration protocols, and provides ongoing incremental value and savings.
Darcy Fowkes is research director of the Internet infrastructure group at Aberdeen Group in Boston. Aberdeen Group is an IT market analysis and positioning services firm that helps Information Technology vendors establish leadership in emerging markets. For more information, go to www.Aberdeen.com.