1. %XVLQHVV 3URFHVV 0DQDJHPHQW DQG ($,
%< 52%(57 0,&. $8*867 $5 ,16,*+76 (
.(:25'6
Business Process Management, Automation, Integration, BPA, BPM, BPI, Workflow
6800$5
Business Process Management (BPM), Business Process Automation (BPA), Business
Process Integration (BPI), and Workflow software overlap and have widely varying ar-
chitectures. To make matters worse, there may be more than 100 such products with no
commonality and few standard interfaces. Furthermore, business process automation
and management technology is finding its way into most Enter-
$Q LQWHUHVW LQ EXVLQHVV SURFHVVHV DV D
prise Application Integration (EAI) and many manufacturing
PHDQV WR LPSURYH SHUIRUPDQFH KDV
enterprise applications. However, standards efforts, such as the
FUHDWHG D SUROLIHUDWLRQ RI SURGXFWV
6WDQGDUGV DUH QHHGHG WR SURWHFW XVHU
Business Process Management Initiative (BPMI.org), Workflow
LQYHVWPHQW DQG HQDEOH WKH PDUNHW WR Management Coalition (WfMC) and the new XML Web Services
UHDFK LWV SRWHQWLDO Architecture will enable a new generation of BPM products spe-
cifically for process-centric EAI.
$1$/6,6
BPM is materializing in a wide variety of places, driven primarily by the common desire
to integrate supply chains, as well as internal functions, without the need for even more
custom software development. This means that the tools must be suitable for business
analysts, requiring less (or no) software development. They must reduce maintenance
requirements because internally and externally integrated environments routinely re-
quire additions and changes to business processes.
The variations in terminology have precipitated from three uses for business process
technologies. Workflow usually refers to the automation of such front-end processes as
document management that involves lots of people; workflow seldom includes back-end
processes. BPA and BPI typically refer to automating or coordinating processes that al-
ready exist in other applications or EAI software. This approach is necessary and
powerful for many situations, but it does not ease the overall maintenance problems as
much as BPM.
BPM emphasizes the management aspect of automating processes to achieve maximum
on-going flexibility with minimum development cost and time. To do this, BPM prod-
ucts must implement the entire business process as much as possible within the product,
@IU@SQSDT@Ã6I9ÃH6IVA68UVSDIBÃTUS6U@BD@TÃAPSÃDI9VTUS`Ã@Y@8VUDW@TÃ
2. 6S8ÃD†vtu‡†ÃQhtrÃ!Ã
using minimum custom code. This requires that BPM products have separate runtime
engines and tools for validation, testing, and monitoring in order to create new applica-
tions. Process-centric EAI that implements and manages business processes through
such new applications is an evolving, advanced form of enterprise integration.
6XSSOLHUV %XVLQHVV 3URFHVV $XWRPDWLRQ 7RROV
Look at some of the business process tools. Without distinguishing between workflow,
BPA, BPI, and BPM tools, it is informative to look at their breadth:
• There is a very long list of EAI (B2Bi) suppliers with some proc-
ess automation approach. For example, SeeBeyond and Vitria
already are very BPM-centric. Sterling Commerce and Intalio
are working on new standards-based Business Process Modeling
Language (BPML) products. And Fuegotech is clearly a BPM-
centric integration product.
• Platform suppliers such as Microsoft, IBM and Sun have some
sort of process automation tools. Microsoft BizTalk is a good ex-
ample of a BPM integration product, but its use is limited to
Microsoft Windows 2000 and .NET servers. IBM MQSeries Workflow, with ever in-
creasing J2EE content, supports IBM platforms (PC, midrange, and mainframe
eServers) as well as Solaris and Windows. Sun (iPlanet) has Forte Fusion and other
products. The combination of platform and EAI software gives these suppliers a
clear advantage with their installed base.
• Enterprise application suppliers, specifically ERP and Supply Chain providers, use
BPM technology for integrating their own product suites as well as integrating with
other applications. SAP, the best-known example, supplies WebFlow with all prod-
ucts. Undoubtedly, BPM tools will become part of an increasing number of
enterprise software supplier offerings.
7KH 3UREOHPV
Products already on the market differ considerably in user interface, scope, modeling
style, platform requirements, interface capability, scalability, extensibility, storage for-
mat, and execution behavior. Some of them still require considerable coding. For users,
the increase in BPM tools from multiple suppliers creates major problems in two areas.
Users must learn different programming paradigms, programming elements, editing
techniques, configuration options, external interfaces, etc. To combat the resulting com-
plexity and resulting inefficiency, users can only limit the variety of products used. Over
‹Ã! ÇÃ6S8Ã6q‰v†‚…’ÃB…‚ˆƒÃ‡ÃÃ6yyvrqÃ9…v‰rÇÃ9rquh€ÃH6Ã!!%ÃVT6ÇÃ' # ÇÃ6S8rip‚€Ã
VT6ÇÃVFÇÃBr…€h’ÇÃEhƒhÇÃDqvhÃ
3. 6S8ÃD†vtu‡†ÃQhtrÃÃ
the long term, the problem can get out of hand and be tougher to manage than well-
structured code.
The second problem is actually more serious. Once a process has been implemented, the
user knowledge and business logic is locked up in a proprietary application and format.
As processes and integration problems become more complex, this is essentially building
a large body of applications with an increasing cost of maintenance, and a high user risk.
5HOLHI
Market consolidation to some degree is a certainty, but there will always be multiple ap-
proaches and implementations. Even if Microsoft BizTalk managed to dominate all
Windows applications, this would still leave most enterprise applications and all J2EE
based applications with a different approach. The market is so large and fragmented at
this point that even within a segment (EAI, vertical, etc.) no single supplier is likely to
dominate. As with other enterprise applications, we must look to standards efforts to
relieve the end user pain. Consider four basic areas:
User Interface – The UI is an important part of product image and a focal point for compe-
tition. Standard Unified Modeling Language (UML) is used in some cases, but most
suppliers created their own graphical programming paradigm. Certainly, component
technologies are available for the creation of an Open Source or free workbench, which
would go a long way toward easing user pain, but this is unlikely.
Application Persistent Storage – Once an end user develops an application, it should be
written to a storage device in a standard format. Both BPMI.org and WfMC are defining
XML-based persistent storage formats for exchanging process definitions between sup-
pliers and platforms. Some basic elements, control flow, data flow, conditionals, rules
implementations, etc., are well known and are included in standards.
Application Execution - A standard storage format enables several runtime engines to im-
port, translate, compile, or execute the process directly. This will encourage consistent
behavior and, over time, a common, extensible engine may be feasible, much in the same
way that common Java programming services are now provided.
%XVLQHVV 3URFHVV 6WDQGDUGV
Founded in 1993, WfMC has been defining and standardizing a reference model, inter-
operability, connectivity, terminology, and process definition, releasing key
specifications in 2000. The process definition, XPDL, is intended as an interchange for-
mat between suppliers. WfMC has over 200 member organizations with some products
claiming compatibility (Vitria is one example).
‹Ã! ÇÃ6S8Ã6q‰v†‚…’ÃB…‚ˆƒÃ‡ÃÃ6yyvrqÃ9…v‰rÇÃ9rquh€ÃH6Ã!!%ÃVT6ÇÃ' # ÇÃ6S8rip‚€Ã
VT6ÇÃVFÇÃBr…€h’ÇÃEhƒhÇÃDqvhÃ
4. 6S8ÃD†vtu‡†ÃQhtrÃ#Ã
BPMI.org is wisely not trying to standardize everything about business process applica-
tions, but is focusing on the persistent storage representation of processes and leveraging
other standards. Draft 0.4 of BPML is available now, and the 1.0 version is scheduled for
December 2001. BPMI.org has over 100 members with more than 20 developer organiza-
tions working on implementations of BPML.
A close competitor for BPML is XLANG, which was developed by Microsoft for BizTalk.
Both have the same theoretical basis, and potentially might be made to converge, but the
BPMI goal is to provide a more general specification that is less coupled to BizTalk con-
cepts, thereby appealing to the large community of enterprise process automation
suppliers.
Neither organization is standardizing the graphical programming model (objects or con-
nections). But a side effect of the BPML and XPDL concepts is that tools will suggest a
general programming paradigm for visual tools.
One serious problem is standardizing the interfaces to existing processes and the inter-
faces between BPM applications from different suppliers. Fortunately, standards
associated with the Web Services Architecture, ebXML, and RosettaNet are being lever-
aged in BPML to provide solutions.
5(200(1'$7,216
• Users should pressure all BPM software suppliers to support the process definition
standards efforts and to adopt the resulting specifications for their products.
• Suppliers should support a common interchange format with existing products as
early as possible. This will result in a robust specification and early user acceptance.
• As with many XML processing tools, BPML and XPDL storage, retrieval, and parsing
software should be developed in a community fashion and made available under an
open source agreement. Multiple interfaces (API) would severely inhibit progress.
• A standard graphical programming model is needed and the standards organiza-
tions should give this immediate consideration. There would still be plenty of room
for competition.
For further information, contact your account manager or the author at bmick@arcweb.com.
Recommended circulation: All EAS.
‹Ã! ÇÃ6S8Ã6q‰v†‚…’ÃB…‚ˆƒÃ‡ÃÃ6yyvrqÃ9…v‰rÇÃ9rquh€ÃH6Ã!!%ÃVT6ÇÃ' # ÇÃ6S8rip‚€Ã
VT6ÇÃVFÇÃBr…€h’ÇÃEhƒhÇÃDqvhÃ
