Describing Business Processes with the Unified Modeling Language (UML) | ebXML: The New Global Standard for Doing Business on the Internet

Electronic business needs an architecture that can work independently of hardware platforms, operating systems, software packages, network services, and even markup languages. To get complex systems in different companies and even different industries to talk to each other, as well as building a capability to handle future business coming from platforms as yet undetermined, means defining this overall structure in a whole new way. Also, e-business needs a way to connect business practices and processes directly to their representative technology.

Objects are the software building blocks of object technology, designed to run on any system, without regard to the software or equipment platform used to create the object.

The tool used by many participants in the ebXML initiative and many other e-business efforts to achieve these objectives is the Unified Modeling Language ( UML ). This language ”actually more of a way to graphically define business processes for software system design and development ”defines the components in the business processes as objects. This object orientation makes the business processes the rationale and reference point for the design of e-business data exchanges.

UML was created as a software designer's shorthand notation tool, thus providing a level of abstraction useful for classifying software objects and processes. UML is weaker as an overall business process definition because it lacks the enforced ability to capture and track roles, responsibilities, and relationships critical to documenting human business interactions. Theoretical work in the field of business-process representation continues, such as Zachman Frameworks (www.zifa.com) and Dynamic Systems Definition Methodology or DSDM (www.dsdm.org).

In some instances, UML can have too much functionality or too little. For simple systems, it may complicate and obscure otherwise trivial needs. For large-scale, complex systems, other tools may be needed to capture the full breadth of the process sequences involved. This inability to build models for large, complex systems particularly applies to self-referencing or self-modifying systems.

UML takes a top-down approach to modeling, which has value in many circumstances. However, where the focus is more on the activity of the individual components, UML can bring the wrong set of tools to the job. Consider for instance applying UML to the game of chess, where the model would begin with defining all use cases ”that is, all possible sequences of piece moves ”rather than analyzing the set of moves undertaken by the 16 different pieces. Clearly, applying UML itself to a problem has to be evaluated on scope and needs. Often, the simple information-modeling capabilities of XML syntax alone can be sufficient.

Object Technology and Business Processes

We need to provide a little background on object technology here.Tech Encyclopedia defines an object as "a self-contained module of data and its associated processing." Objects are the software building blocks of object technology, designed to run on any system, without regard to the software or equipment platform used to create the object.[17]

The idea of modular system design is hardly new. However, as Harry Featherstone notes, object technology brings something new to the table, namely the ability to create models of business processes, and to decompose those processes down to the technology level, while staying true to the business process. The idea is to have the technology better represent the business process, rather than bending the processes to fit the needs of the technology.

By defining business processes with these modeling techniques, designers can separate technology requirements from business semantics or content, which increases the likelihood of communicating successfully among various physical implementations .

Business process models represent the internal business processes and data in a standard format, by providing the following features:[18]

A consistent way of capturing user requirements and clarifying business semantics
Better communications among parties, by introducing more objectivity in the communications process
More traceability and documentation of customer requirements
A way to apply improvements to existing processes

UML uses a visual graphical metaphor to achieve these objectives.While written initially for software development, its use has expanded to the design of inter-enterprise applications that reflect the objectoriented approach. UML doesn't require any particular solution, but it does encourage an approach based on use cases, centering around a neutral technical architecture, with an iterative and incremental process.[19]

Architectural Views

UML enables business analysts and systems designers to organize the knowledge and relationships generated in the development of models in various ways, to meet a set of problems and solutions, called an architectural focus. The set of elements from a model that address the architectural focus is call an architectural view, including the following types:

The user model view encompasses a problem and solution as understood by those individuals whose problem the solution addresses.This view is also known as the use case or scenario view.
The structural model view covers the structural dimension of a problem and solution. This view is also known as the static or logical view.
The behavioral model view includes the behavioral dimension of a problem and solution. This view is also known as the dynamic, process, concurrent, orcollaborative view.
The implementation model view encompasses the structural and behavioral dimensions of the solution's realization. This view is also known as the component or development view.
The environment model view covers the structural and behavioral dimensions of the domain in which the solution is realized.This view is also known as the deployment or physical view. [20]

For example, financial settlements covering the process of invoicing through funds transfers may define an architectural focus.The different collection of elements defined in a model of the financial settlements process would comprise one or more architectural views.

UML offers nine types of diagrams for modeling systems (see the following for an example of use cases and Chapter 8 for examples of most of the other diagrams):[21]

Use case diagrams model business processes.
Sequence diagrams model time dependencies and events.
Collaboration diagrams model interactions within a system.
State diagrams model the behavior of system objects.
Activity diagrams model the behavior of use cases, objects, and operations.
Class diagrams model the static structure of a system, particularly the entities that exist within the problem context, their internal structure, and their relationships to other entities. Class diagrams aid in recognizing business information objects, the basic elements of electronic business documents.
Object diagrams model the static structure of an instance or detailed state of a system at a given point in time.
Component diagrams model the structural or behavioral dimensions for developing a solution.
Deployment diagrams model productive implementation of a system in its domain.

Use Cases

The proponents of UML claim that the technical diagrams it uses are accessible by businesspeople who can therefore take part in use case analysis and understand the resulting diagrams. Use cases describe the performance of systems, showing the actors, actions, and sequences (including variations), that result in value to the actors. Because they're relatively easy to build and understand, and require only limited special technical expertise, use cases often are the first step in the analytical exercise. They also help provide a sound base for communications between business and technical staff.[22]

Edward Kenworthy describes these steps for conducting a use case analysis:[23]

Identify who will use the system directly, called the actors.
Pick one of those actors.
Define what that actor wants to do with the system. You will need to develop a use case for each of these things that the actor wants to do with the system.
For each of the use cases, select the course that best describes what normally happens when that actor uses the system. This is called the basic course.
Describe that basic course in the description for the use case. Use the dialogue of "actor does X and system does Y." Keep the dialogue at a high level. Describe as well the things that an actor would need to know, and what the actor does that the system needs to know.
Once the basic course is described, then go on to alternative courses to the basic course. Each of the alternatives becomes an extension to the basic course.
Review each of the use case descriptions. Those descriptions with a high degree of overlap are called the common use cases. The common use cases essentially describe a single process.
Repeat steps 2 “7 for each actor.

Use case diagrams illustrate the processes described in the use case scenarios. They often identify the actors with stick figures and have ovals with text enclosed , describing the processes. The order of the ovals indicates the sequence. Figure 5.1 shows a sample use case diagram from the running store example in Chapter 3,"ebXML at Work."

Figure 5.1. Use case scenario diagram.

graphics/05fig01.gif

Further analysis with sequence, class, or activity diagrams normally requires technical specialists. However, starting with use case scenarios locks in the basic business requirements of a system or interactions among systems; thus, the use case stage is one in which business rather than technical expertise is required.

The major problem with this approach occurs when the actors cannot be neatly categorized and therefore have to be artificially prescribed in order to make the method work. Furthermore, business problems can often be more accurately described in terms of what is not allowed, as well as what the designers envision as permitted.

In systems analysis, tools and terminology may change, but the fundamental principles often stay the same. Thus, many of the good ideas in UML had been identified and formalized earlier and in other ways. While the object-oriented software community gave us the term use case and gave it a formal role in UML, the process follows the same basic approach to needs and workflow analysis practiced by systems professionals for 20 years .

Other analytical methods , such as the Dynamic Systems Definition Methodology ( DSDM ), also prescribe a sequence of steps to capture and document abstract concepts of systems design. Like ebXML, DSDM does not impose a specific modeling technology, but lets practitioners select their own tools to identify and document components of business systems.

The ebXML approach is similar to the DSDM approach in that, rather than attempting to prescribe a particular modeling technology, an XML business process layer allows implementers to select their own preferred tools, and then ultimately derive and populate the business process XML content that ebXML requires as the end product.

Use Case Scenario

We can give an example of a use case with one of the scenarios from Chapter 3, namely the running store's vendor-managed inventory. For simplicity, we'll stick with the basic course in this example. The actors are Marathoner (the store) and the shoe manufacturer.

The following table shows the setup for Marathoner:

Actions	Actor Needs to Know
Creates annual sales forecast	Previous year sales, scheduled events, promotion plans, special conditions
Sends forecast to manufacturer	Manufacturer capabilities and limits
Agrees to prices and terms with manufacturer	Manufacturer capabilities and limits
Updates forecast monthly, shared with manufacturer
Sends inventory status report to manufacturer
Receives shipment and ship notice from manufacturer
Replenishes inventory from shipment
Sends receiving report to manufacturer
Authorizes payment

The following table shows the setup for the shoe manufacturer:

Actions	Actor Needs to Know
Receives annual forecast from Marathoner	Store's capabilities and limits
Agrees to prices and terms with Marathoner	Store's capabilities and limits
Receives monthly forecast update	Store's annual forecast
Receives periodic inventory report
Calculates replenishment quantity	Store's annual forecast and updates
Ships replenishment stock, sends ship notice
Gets receiving report from Marathoner

Refer to Figure 5.1 for the diagram for this scenario, showing the interactions with both actors and the sequence of actions.

UML and UN/EDIFACT

The e-business standards community sees significant relevance to the object-oriented approach. The X12 and UN/EDIFACT committees joined forces in 1998 to explore the use of UML to build the next generation of EDI standards. In 1999, X12 combined with American Express and Visa in a demonstration project of UML techniques applied to procurement transactions involving a corporate purchasing card. The UN/CEFACT organization has a Techniques and Methodologies Work Group (TMWG) that has spearheaded the work on object-oriented technologies for the UN/EDIFACT side of this partnership.[24] (See the later discussion of UN/CEFACT in the section "ebXML Founding Organizations and Process.")

UML provides useful tools for understanding and documenting business processes in ebXML, but UML is not required to use ebXML technology.

In October 2000, X12 voted to begin creating accredited cross-industry XML standards based on ebXML. This work, coordinated with UN/ EDIFACT's counterpart workgroup, includes defining business processes and core business objects.[25]

An entire discussion of UML is well beyond the scope of this book. Further information on UML can be found at the web site of the Object Management Group (www.omg.org), the organization that standardized UML and promotes its development. The site has introductory papers and tutorials. The site of software developer Rational (www.rational.com) also has good introductory materials on UML.

As we have noted, UML provides useful tools for understanding and documenting business processes in ebXML, but UML is not required to use ebXML technology. The ebXML architecture uses production rules to translate models written in UML (or other modeling languages) at their finest degree of granularity to XML. Work is underway through initiatives such as the XML Metadata Interchange ( XMI ) to translate directly from UML models to XML syntax.[26]

RosettaNet: XML for the Supply Chain, with an Emphasis on Business Process

So far, this chapter has discussed the work done in EDI and UML that contributed significantly to the development of ebXML, as well as the contributions of the XML/edi Group. The Rosetta Net Consortium is an initiative that put many of these ideas into practice well before ebXML and shared that useful experience during the development of ebXML.

RosettaNet combined an early industry XML vocabulary with business process analysis and supply-chain integration. This consortium, nurtured initially by IBM and Ingram Micros, works in the computer technology industry and has become a metric for other industries. As a result, its influence is felt well beyond its original industry boundaries.

RosettaNet, begun in 1998, has some 350 members in the information technology industry, broadly defined to include computer manufacturers, chip and circuit manufacturers, software developers, and distributors of products in the industry. The consortium seeks to develop a common language, thus taking its name from the "Rosetta Stone" written in 196 BC and discovered in Egypt in 1799 that helped comprehend for the first time the hieroglyphics of ancient Egypt.

RosettaNet's use of business process analysis separates it from most other vertical industry vocabularies. Rather than jumping immediately into defining XML messages, the early sponsors, utilizing resources provided by IBM, chose to first define business processes in considerable detail. This provision for a top-down business process methodology can also be implemented using the ebXML specifications.The inventories of processes undertaken by RosettaNet can serve as a reference point for other industries using ebXML.

In April 1999, less than a year after its founding, RosettaNet released its first Partner Interface Processes ( PIPs ), which are specifications for business process alignment. RosettaNet carried out extensive process modeling to find out how companies in the supply chain interacted with each other to perform their normal business activities.[27]

RosettaNet breaks down the PIPs into eight categories, with one reserved for RosettaNet administrative functions. The seven categories covering industry business processes are described in the following sections. We present the descriptions of clusters here in some detail to illustrate the need for industries to define processes both comprehensively and in detail, to reflect the realities of doing business in that industry.

Cluster 1: Partner, Product, and Service Review

The first cluster provides for the collection and distribution of information for creation of trading partner profiles and subscriptions for information about products. One segment in this cluster contains PIPs for automated support for setting up a trading partner account, and for maintaining important trading partner information, such as shipping and billing locations. Another PIP in this cluster defines the process for establishing subscriptions for the exchange of product information among trading partners , as well as changes, cancellations , and confirmations of these subscriptions.[28]

Cluster 2: Product Information

The second cluster of PIPs covers the distribution of sales catalogs and related technical data, and the obtaining of extended specifications beyond the basic data. A separate segment handles updates, such as change notices, for these pieces. The first group of these PIPs includes the original distribution of product information, and a series of queries ”products, marketing information, sales promotions/rebates, technical specifications, and product lifecycle and discontinuance. Other PIPs handle electronic commerce queries, distribution of product numbers (known as stock-keeping units or SKUs ), and change notices for various marketing and product announcements.[29]

Cluster 3: Order Management

This cluster covers many of the basic supply-chain functions, with separate segments for quote and order entry, transportation and distribution, financial interactions, and custom configurations. The quote and order-entry series covers processes including requests for quotes, prices, and availability; quick transfers of shopping cart contents; purchase order management; and queries on order status and work in progress. The transportation segment includes PIPs projections, ship notices, delivery management, claims, and changes. The financial segment covers invoicing, remittances, product returns, and reconciliations. The product configuration segment has a series of PIPs covering the complex processes for developing and managing custom-engineered products for customers.[30]

Cluster 4: Inventory Management

The fourth PIP cluster covers processes for forecasting, inventory allocation and reports, sales reports , replenishment, and price protection. The forecasting segment includes processes for collaborative sales and order forecasts, forecast submissions, notifications, and confirmations. The allocation segment concerns allocation of scarce inventory to buyers . The inventory-reporting segment covers inventory reports, reconciliations, errors, and reconciliation discrepancies. The sales-reporting segment includes PIPs for several types of sales reports and error notifications. The price-protection segment covers processes for price-protection announcements, requests, claims, and provisions, as well as new order price changes.[31]

Cluster 5: Marketing Information Management

This cluster offers PIPs for exchange of marketing leads, campaign plans, design registrations, and ship-from-stock and debit transactions. The first segment in this cluster covers processes for exchanging data on sales opportunities, including management, queries, and notifications of leads. The second segment includes PIPs for distribution of marketing activity information such as incentive programs, claims, and rebates. The third segment covers processes for electronic component design registrations. The fourth segment also applies to electronic components and covers ship-from-stock and debit authorization processes.[32]

Cluster 6: Service and Support

The sixth cluster provides PIPs for technical support after the sale, service warrantees, and asset management. The first segment covers warranties and has one PIP for service registration. Another segment has PIPs for technical support and service management, including requests for service events, transfers of service-event ownership, notification of solutions, and service status queries. A third segment scheduled for asset management is covered under the warranty segment.[33]

Cluster 7: Manufacturing

As of December 2000, this cluster had not yet defined its processes, but will include PIPs for the exchange of messages for supporting a virtual manufacturing enterprise, covering design, configuration, process, quality, and other data needed on the shop floor.[34]

RosettaNet Implementation Framework

RosettaNet has defined guidelines for exchanging messages based on PIPs, called its implementation framework. It begins with an overall business model that spells out how companies interact within the PIPs and with each other. The business model has five parts :

Creation of PIP guidelines that provide detailed specifications to supply-chain partners
Distribution of those specifications to supplychain partners
Validation of the message content exchanged among trading partners
Extensions of guidelines for special trading-partner implementations (but they cannot override original RosettaNet specifications)
Exchange of extended guidelines to allow for validation of these special messages[35]

The RosettaNet technical architecture matches up to the seven-layer ISO open systems interconnect reference model, with most of its interactions contained in the highest or application layer of the ISO reference model. The one exception is RosettaNet's security layer that corresponds to the session layer in the ISO model.

The RosettaNet architecture focuses on four application layers , each with a set of protocols and messages:[36]

Action layer ” the main business actions that contain or accompany the primary message content
Transaction layer ” monitors the sequence of action messages that perform the work
Process layer ” contains the choreography of transactions for executing the PIPs
Service layer ” provides resources to perform network and related business functions

RosettaNet business messages consist of a header and message body with the content. Each message is contained in a Multipurpose Internet Mail Extensions (MIME) package used in email and many other file transfers. The message header and body themselves are encoded in XML.[37] The ebXML messaging specifications also use a combination of MIME and XML headers.

The headers include a preamble that includes the version, date and time, authority code, and usage code that indicates a test or production message. These elements appear in all messages. The service header identifies the parties in the exchange, the processes covered by the exchange, and the transactions and business actions in the message. Each of these parts has a separate sub-header. The service content is the business section of the message.

RosettaNet defines separate protocols for the exchange of request and response messages overall, as well as special protocols for web browsers using HTML and common gateway interface codings. The specifications also define protocols for HTTP and Secure Socket Layer (SSL) exchanges.[38]

Unlike some other early XML business vocabularies, RosettaNet defines its security specifications in some detail, rather than leaving the function to implementers. These specifications include a digital signature and an authentication model using both SSL and digital signatures.[39] The specifications define what it means to be in technical compliance with RosettaNet specifications (PIPs, protocol messages, server-to-server transfers, and security). The document also gives detailed definitions of RosettaNetcompliant organizations, including users, initiating organizations, servicing organizations, third-party agents , and technology solution providers.[40]

RosettaNet Dictionaries

Definitions for the semantics of RosettaNet messages are found in their dictionaries. The group offers three main types of dictionaries, each consisting of lists of individual data items:

Business dictionary, including business properties and business data entities, as well as a separate list of fundamental business data entities
Electronic component technical dictionary
Information technology technical dictionary

The business dictionaries provide the elements for the business action messages defined throughout the specifications. Both the electronic component and information technology dictionaries are used to define products. As of December 2000, the electronic component dictionary was in beta testing.[41]

The momentum that RosettaNet generated in the use of XML in a traditional supply-chain arena acted as a catalyst for the existing EDI establishment to step across the bridge and embrace XML as a central plank for the future of business transaction standards. Klaus-Dieter Naujok in the summer of 1999 put in motion events that led to the formation of the ebXML initiative itself, broadly based on the vision of openEDI and XML/edi that had been discussed in a white paper published earlier that year.[42]