XML

The Extensible Markup Language (XML) has emerged as the middleware approach of choice for companies that want to create distributed applications (Web services) on the Internet. By itself, XML provides a message format. In the past year, XML has been supplemented by a variety of protocols that extend its power. XML's tag description facility has been extended with XML script to make it easier to describe complex data formats. Simple Object Access Protocol (SOAP) has been widely adopted to provide a transport mechanism. Universal Description, Discovery and Integration (UDDI) and the Web Services Description Language (WSDL) have been adopted as a mechanism for locating potential partners and determining what data formats to use to exchange data with the partners. UDDI defines a repository mechanism, and WSDL provides a script that is used to describe endpoints and possible messages that partners support. E-business XML (ebXML) -- which includes SOAP, UDDI, and WSDL -- is a growing collection of services that will make XML even more useful. For example, ebXML will eventually define security and transaction services.

In addition to the growing middleware capabilities of XML, various consortia are working on XML languages, defined as document type definition (DTD) tag sets or XML schema languages, that can be used to standardize specific types of information that companies might want to communicate. Early DTD standardization efforts, for example, provided uniform ways of passing data about banking and insurance information. In this Executive Update, I'm going to focus on emerging XML schema for defining business processes.

BUSINESS PROCESSES

The emphasis on the Internet and e-business during the past two years has paralleled a sharp rise in corporate interest in business process redesign. Most companies realize that they will need to make major changes in the way they do business to take advantage of the Internet. An extreme example would be a company that replaced some or all of its sales force and accepted new orders via the Web. Some sales jobs will disappear, and other jobs in Web maintenance will be created. Web orders are digitized orders that have already been checked for completeness by the computer system that took the online order. This implies other changes in how the order is processed. Similarly, companies that seek to build Internet-based external supply chain systems are forced to redesign the processes they use to monitor the flow of parts and inventory, order new parts, check orders, and pay for orders.

If one department within a company seeks to integrate its business processes with those of another department, or if two companies seek to integrate processes to automate supply chain functions, each department or company needs information about the exact nature of the business processes to be integrated. One way a department or company could convey this information is via a flow diagram that illustrates the nature of a business process. In the near future, an alternative will be to pass an XML file that will provide the same information.

BUSINESS PROCESS XML SCHEMA

In this Update, I will briefly consider four XML business process initiatives. They include: IBM's Web Services Flow Language (WSFL), Microsoft's BizTalk with its Orchestration Designer and XLANG, the Business Process Management Initiative's Business Process Management Language (BPML) schema, and the business process initiative sponsored by ebXML. All four of these initiatives are built on top of WSDL and extend WSDL so that more precise information about business processes can be exchanged between partners.

IBM'S WSFL

IBM originally developed WSDL as a way to pass very technical information about ports, endpoints, and messages between two companies that were using UDDI to establish online communications. In effect, WSFL extends WSDL by providing specific information about business processes, business rules, and the flow of information between specific activities within processes. WSDL was tailored to provide an Internet interface for IBM's popular workflow product, MQSeries Workflow. In effect, each element that can be represented in MQSeries Workflow is represented by a tag in the WSFL XML schema.

For more information, check http://www-106.ibm.com/developerworks/library/ws-ref4/index.html.

MICROSOFT'S BIZTALK ORCHESTRATION AND XLANG

Microsoft has sponsored BizTalk, an initiative to encourage companies to specify business components that can be used in Web services applications. Microsoft's .NET is, in effect, an implementation environment for BizTalk components. Microsoft's Visual Studio .NET includes a business process design tool called Orchestration Designer. In effect, a user creates a business process workflow diagram on one side of a Visio-like environment and then specifies the ports that link specific activities to COM components on the right side of the diagram (see Figure 1). When the user is done, he or she compiles the Orchestration diagram into XLANG -- an XML schema language that captures the information from Orchestration Designer.

Figure 1 -- Microsoft's BizTalk Orchestration Designer.

To date, Microsoft hasn't done much to define the actual workflow notation. This isn't a tool designed for large-scale tasks or anything a business manager could use to analyze a process. It's a tool for software developers trying to use XML to generate information about how components in a process can be linked and managed. Like IBM's WSFL, XLANG is closely linked to WSDL, and there is talk that IBM and Microsoft might try to develop a common solution.

For more information, check www.microsoft.com/biztalk and search for Orchestration Designer.

BPMI.ORG'S BPML AND BPMN

The most interesting work in business process modeling is being done by the Business Process Management Initiative Organization, (also known as bpmi.org). This open consortium was established in 2000 and has recently become more organized. Membership now exceeds 100 and includes most of the small business process modeling vendors and all of the major vendors (IBM, BEA, etc.), except Microsoft.

The first product development undertaking by bpmi.org was an XML schema language, BPML, that can describe business processes. (Like WSFL and XLANG, BPML is based on WSDL.) If you use a tool that supports BPML and defines your business process models, then you can automatically transmit XML descriptions of those processes to someone else.

During the latest meeting of bpmi.org in October, the organization considered a graphical notation that could be used in conjunction with BPML (a Business Process Modeling Notation, or BPMN). Obviously, an individual could simply write XML BPML schema code to describe a process workflow, but few expect this would be very useful to most business process groups. In fact, in most cases, it will work the opposite way: a group will develop a graphical model of a process, and then seek to generate the XML schema code from the model.

The bpmi.org task force has taken a major step forward in thinking about business process modeling by making a distinction between two levels of business process notation. Too many companies have assumed that business managers will use software tools to model business processes. In most cases, business managers have a different focus than software designers. They are more vague about some things, and they are more interested in the human jobs involved in the tasks and how managers are going to measure quality, outputs, and so forth. Managers usually prefer a simple form of workflow modeling, supplemented by text documents. They are happy with boxes describing activities and usually assume that the activity is being performed by an individual who knows how to do the activity. The business process models created by management business process teams are very valuable to companies that are trying to redesign business processes. They are not a prescription for software development. They are not detailed enough to serve as software requirements.

The bpmi.org task force working on the notation for BPML decided that, in fact, two notations were needed: a Business Level BPMN and an Execution Level BPMN. In effect, the Business Level version of BPMN will be a lightweight notation that will be tailored for the kinds of business process descriptions that management-level business process redesign teams often use. BPMN, plus additional information and constraints, will result in Execution Level BPMN -- a notation that precisely describes a process in a manner that is adequate to generate BPML code. (Similarly, one should be able to generate BPMN from BPML.)

The bpmi.org notation committee was open minded about how closely the Business Level BPMN can be tied to the Execution Level BPMN. It is assumed that, at a minimum, the same graphical symbols can be used for common concepts, like activity, workflow, decision, etc.

Figure 2 provides an overview of the process that the bpmi.org notation task force is embarking upon. They are starting by creating a metamodel of BPML. (The BPML metamodel will be a Unified Modeling Language [UML] class diagram defining all the objects and relationships involved in BPML.)

Figure 2 -- The bpmi.org notation development process.

One way to consider the distinction between the two levels of notation is to think of a Zachman Framework.¹ The Business Level notation is concerned with issues that appear on the top two levels of the framework. The Execution Level notation is concerned with capturing information that normally occurs on the third and fourth levels of the framework, and BPML would capture the information on the fifth and sixth levels of the framework. (For those who want a current version of the Zachman Framework, visit www.zifa.com.)

The distinction between the Business Level and the Execution Level may describe two different classes of business process modeling tools, although some tools will support both levels. The key is that Business Level products are designed to support business managers, while Execution Level tools are designed to help software analysts and developers.

It's still unclear how tightly Business Level and Execution Level models can be tied. In most cases, business managers focus on different issues and aren't as precise as software developers need to be. Business Level flowcharts often have dozens or hundreds of activities that are performed by employees and are not automated. While all of these activities could be modeled in BPML, it is not clear that it's useful. As a rule, a Business Level model must be supplemented with a detailed requirements phase before an execution model can be developed. Moreover, in some cases, activities will be defined one way for business purposes, but may need to be regrouped for efficient software development. These issues will undoubtedly be explored by the bpmi.org notation task force as they seek to develop their two notation levels.

Figure 3 provides an example of a Business Level metamodel. In this case, the metamodel is the one used by Proforma Corporation for the workflow diagrams supported by its Pro Vision tool.

Figure 3 -- Pro Vision metamodel and a process workflow screen.

I have modified the UML class diagram created by Proforma by placing the modeling symbols inside the class boxes. I've added a screen shot from Proforma's Pro Vision modeling tool and linked some instances on the screen to the class in the metamodel. Obviously, the metamodel and the Execution Level BPMN would be much more detailed. Business analysts usually don't model transactions, for example, while software developers need to be aware precisely which activities are involved in transaction processing.

Proforma's Pro Vision is one of the best-selling business process modeling tools. It is widely used in business process improvement efforts. It is usually used by a Scribe in conjunction with a Facilitator. The Facilitator works with a group of business people as they analyze an existing business process and then decide how to improve it. The team typically creates and modifies diagrams on a whiteboard using the Pro Vision notation (which is derived from Rummler-Brache -- a notation specifically designed for business managers, not software analysts). The Scribe recreates the diagrams in Pro Vision and then prints them so everyone has copies. (For more information on Pro Vision, check www.proforma.com.)

A number of vendors -- from Proforma, CaseWise, Popkin, and Rational -- will be submitting proposals for Execution and Business Level notations to the bpmi.org task force. The execution notation will obviously need to reflect the BPML. In addition, there should be a clear relationship between the Execution notation and the Business level BPMN. The task force may decide to adopt a unique workflow notation, but it is likely that the notation adopted will be very similar to the Object Management Group's UML activity diagram notation. This would have been less likely if bpmi.org was considering UML 1.4 notation, where activity diagrams were considered as a subset of state diagrams. However, UML 2.0, which is now being finalized, has made activity diagrams independent of state diagrams and added many features that those developing flow charts will find useful. It's possible that bpmi.org will define its BPMN as a profile or special extension of UML activity diagrams. Whatever happens, bpmi.org seems set to generate a business process notational system that will make it much easier for business analysts to talk with software designers. For more information, see www.bpmi.org.

EBXML'S BP INITIATIVE

The ebXML initiative, which operates under the sponsorship of the Organization for the Advancement of Structured Information Standards (OASIS) and the standards organization United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT), is also working on a Business Process Specification Schema (BPSS). BPSS, at the moment, is the most narrowly focused of the various efforts. It concentrates on defining an e-commerce relationship between two partners. The BPSS team has defined business processes in terms of UML models and a high-level model of an e-commerce exchange. They describe business processes with worksheets.

For more information, see www.ebxml.org and search for BPSS.

SUMMARY

The initiatives described in this Update provide an idea of trends and directions, although none is ready for serious development work. They will probably begin to be used in 2002. Of the four initiatives, I think the bpmi.org initiative is the most interesting. The other three provide ways for software developers to document business processes and communicate that information. Only the bpmi.org team, however, has been bold enough to consider developing two levels of notation and actually reaching across the divide between business processes, as the business analyst or manager perceives them, and business processes, as a software developer might document them. There will probably be other business process XML schema initiatives in the year ahead and some of the existing efforts may be combined. Let's hope the idea of unifying Business and Execution Level notations isn't lost in the process. It would provide a powerful tool for all those working to align business processes and IT systems.

NOTES

¹Implementing Enterprise Architecture with the Zachman Framework provides a practical video presentation demonstrating how the city of Oakland, California, USA, used the Zachman Framework to integrate its complex emergency response system. For information visit www.cutter.com/itgroup/reports/zachman.html.

Back to Top

Cutter Consortium has been a leading information provider since 1986. Cutter has more than 5,800 clients located throughout the world. These professionals rely on Cutter advisories, journals, reports, research studies, and consulting & training services to obtain the advice and analysis their jobs demand. As a smaller information provider, the Consortium customizes its services to meet each client's needs.

Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474, USA. Phone: +1 781 648 8700, Fax: 781 648 1950; E-mail: service@cutter.com.

Contact the Webmaster