Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Communicating Business Operations Requirements to IT: Using Business Operations Modeling in the Northern Electronics Scenario

 

Jim Clark, Max Morris, and Dave Welsh
with Frederick Chong

September 2005

Applies to:
   Enterprise Architecture
   Solution Architecture
   Service Oriented Architecture (SOA)
   Service Oriented Management (SOM)
   Application Integration
   Business Process
   Business Operations Modeling

Summary: The Architecture Chronicles on Dynamic Modeling: Aligning Business and IT seek to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. This document focuses on communicating business operations requirements to the IT organization by applying business operations modeling to the product shipping business collaboration in the Northern Electronics scenario. (38 printed pages)

Click here to download the Dynamic Modeling: Aligning Business and IT Demo.

Contents

This Document
Abstract
Acknowledgements
Introduction
Business Operations
Business Operations Modeling Methodology
Modeling Using Worksheets
Product Shipping at Northern Electronics
Modeling the Product Shipping Activities
Business Operations Requirements of Product Shipping
Conclusion

This Document

This document is part of the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT. This volume seeks to present to business, solution and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. The information map to the series provides an up-to-date description and cross-index of the information available and can be found at the Microsoft Architecture Resource Center.

Abstract

This document examines how to communicate business operations requirements to the IT organization by applying business operations modeling. It examines business operations concepts, business operations modeling methodologies, and the practical aspects of modeling using worksheets. It connects these concepts together through a set of proof-of-concept forms running within Microsoft Office InfoPath 2003 to first model the product shipping business collaboration from the Northern Electronics scenario, and then generating a set of specifications for the IT organization to use.

Acknowledgements

Many thanks to Nelly Delgado for her help with technical writing, Claudette Siroky for her graphics skills, and Tina Burden McGrayne for her copy editing.

The authors would also like to thank Klaus-Dieter Naujok and Allyson Winter (of Global e-Business Advisory Council) for their contributions to the development and documentation of the proof-of-concept business operations modeling worksheet tool used to illustrate this document.

Introduction

This document focuses on communicating business operations requirements to the IT organization by applying business operations modeling to the product shipping business collaboration in the Northern Electronics's scenario. Background information on the Northern Electronics scenario can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

  • The document examines how the business program manager and a business analyst can apply a business operations modeling methodology to derive a set of requirements for use by the IT department in building a solution. Specifically, this document discusses:
  • Business operations concepts.
  • Business operations modeling methodologies, including a background on such modeling approaches as well as a brief discussion of a modeling approach used to illustrate this document.
  • Modeling through worksheets, including a discussion of worksheets concepts and basic procedures such as the following:
    • Production of a solution set that contains business operations requirements information for use by the IT organization, with a specific focus on the inputs to the service management and health modeling functions.
    • Demonstration of the approach using the Northern Electronics scenario.

Business Operations

When two businesses collaborate with each other in a value chain, whether as supplier-customer or partner-partner, the dealings they have with one another generally follow procedures the two agree upon in advance. These procedures are usually defined with enough clarity through a contract that each company can clearly know its role, can perform the activities it has committed to, and when its commitments are fulfilled, can collect whatever benefit or payment is due from the other.

Note   The approach presented here readily applies as well to two organizations within a company. The difference is a matter of business trust. There is less business trust between two companies than between two organizations within a company. When there is more business trust, there is less potential for business relationship drift; when it does occur, it is easier to drive change to achieve business state alignment.

It is the job of the business operations organization to put into place the infrastructure necessary to support at an operational level a company's own side of the business collaborations it has with others. In performing its work, the business operations organization maps contractual requirements onto business capabilities as it defines, implements, and operates a collection of business processes.

The business operations organization does not work in isolation. It works carefully with corresponding business operations organizations at other companies with whom its company collaborates throughout all phases of the business collaboration in question. Considerable attention is paid to these interactions, or shared activities, to make sure the right information is exchanged in a timely and secure way without any loss of information integrity. These exchanges are done using a variety of technologies, including face-to-face meetings, faxes, phone calls, postal mail, express mail, e-mail, and other forms of specialized, structure information exchange using computers. Which technology is used and how it is used depends on many different circumstances such as historical precedent, industry standards, regulation, and business capability. Therefore, the business operations organization also works closely with the IT organization to support the IT organization's work in defining, developing, and operating technology solutions that realize the collection of business processes.

There are two ongoing challenges business operations organizations have as they oversee the running of the business, as illustrated in Figure 1:

  • Business relationship drift. This situation occurs as the two businesses in a business collaboration experience different levels of information about the ongoing business activities they share.
  • Business operations drift. This situation occurs as the business operations organization and the IT organization within a company experience different levels of information about requirements and ongoing operational performance of business processes and the technology solutions that support them.

ms954615.chapter03_f01(en-us,MSDN.10).gif

Figure 1. Illustration of business relationship drift and business operations drift

Business relationship drift in a business collaboration is inevitable. It's not possible for one business to have all the same information at the same time as the other. But business relationship drift does not become a problem, and remains hidden away, when a business collaboration proceeds as expected. The different, shared activities unfold in a timely way, continuously bringing the business relationship back into alignment, and each business continues to experience the outcomes it expects.

It's when business exceptions occur—when an expected event is delayed, or an expected event occurs out of sequence—that business relationship drift manifests itself as a problem. Typically the manifestation is a cascade: one important activity completes late, or not at all, leading to other activities not starting, and so on. It's very hard for the businesses to get back on the same page, or to get back into business relationship alignment. Figuring out what has gone wrong and where, and getting things back on track (if that is even possible) can take a lot of time, energy, and expense.

With good up-front planning and experience to draw on, the difficulty in handling business exceptions isn't in knowing what to do about them. Most issues can be anticipated, and a good plan will include some way of dealing with the completely unexpected. Instead, the difficulty in handling business exceptions is mostly about getting useful information about an exception that has occurred to the right person in time, or even ahead of time, so that he or she can do something about the problem as it happens—or before it happens. When the right information arrives to the right person in time, there's a better chance that whatever intervention the person can implement can have a more significant mitigating effect.

Getting useful information about what exceptions are occurring to the right person in time is no easy task, and it is the hallmark symptom of business operations drift. Expected performance is not achieved, but the current performance level actually remains unknown. The information to achieve alignment of business operations usually exists, but it is almost always distributed in a piecemeal fashion throughout the technology solution that implements the business processes that work together to enable the business collaboration. In such situations, non-performance of a contractual commitment isn't something that is known at the business operations level until some time later, when an after-the-fact audit is performed. Such an audit, usually directed manually, uncovers that certain requirements from the contracted service level agreement were or were not met. In failure cases, penalties are often assessed. Meanwhile, in real-time, the non-performance of the commitment often leads to cascading business exceptions in the business operations.

The key to ensuring business relationship alignment between two businesses would seem to be business operations alignment between the internal business operations and IT operations organizations of each business. If there were some way for the IT organization to know in advance what business operations requirements needed to be met so that IT operations could then let business operations know as those requirements were not met, the business operations team would be better able to detect business exceptions that will likely worsen business relationship drift as they occur—or even before they do.

ms954615.chapter03_f02(en-us,MSDN.10).gif

Figure 2. Illustration of business state alignment

This document argues that a modeling approach to formalizing business collaborations can facilitate the identification of conditions that will worsen business relationship drift. When these conditions are identified and transformed into a model that the IT organization can use, the IT solution can be designed, implemented, and operated in way that combats business operations drift. With tighter coupling between business operations and IT operations at both businesses in a business collaboration, following this approach, much more timely knowledge about the state of shared business activities can be known to both parties. This condition is referred to as business state alignment, and it is illustrated in Figure 2. With business state alignment achieved, business operations can run more smoothly and unnecessary expense and downtime can be avoided.

Business Operations Modeling Methodology

The process of modeling business operations is a team effort and provides several benefits to the organization:

  • Means of communication. Modeling is a means of communication across and between organizations and within an organization.
  • Logical framework. Modeling provides a logical framework within which to relate an agreed collaborative view and partner responsibilities.
  • Clarify business objectives. Modeling helps clarify business objectives by understanding and relating dependencies between business management, business operations, application systems, and IT operations.

Background

Several approaches to formally modeling the business collaborations that occur when running a business have been developed over the last decade. The Open-EDI Reference Model is commonly understood to be the basis for most of these approaches (ISO/IEC 14662, (http://www.iso.ch/) or (www.disa.org/international/is14662.pdf)). More recently and of particular interest to the discussion in this document, UN/CEFACT developed a well-known derivative named the UMM. The UMM was developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). UN/CEFACT "supports activities dedicated to improving the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively." UMM stands for UN/CEFACT Modeling Methodology. More information about UN/CEFACT and the UMM can be found at http://www.unece.org/cefact/.

The UMM was developed as a technology-neutral methodology to formally describe a business collaboration from multiple perspectives. At the heart of the UMM is a metamodel derived from economic and accounting theories, as well as from commercial best practices and laws from around the world. The use of the UMM and its metamodel is not restricted to only business collaborations in bilateral value chains. Both have been used widely (in part or in full) by industry standards organizations to describe the standard business collaborations that occur within their industry-specific value chains. Such industry standards organizations include AIAG (http://www.aiag.org), SWIFT (http://www.swift.com/), GS1 (http://www.ean-int.org/), and ISO TC 204 (http://www.iso.ch/).

Several incremental changes to the UMM and its metamodel have been made by two of the co-authors. (Jim Clark and Dave Welsh were both collaborators on the development of the UMM and also collaborators on the development of the variant used here. Notable changes include structural corrections to the UMM Business Relationship View (and a renaming of the variant view to Business Collaboration View) as well as the introduction of a sub-model of the BCV specifically for SLA modeling.) Though similar in many ways, because the variant is distinct from the UMM, it has a different name, the Business Operations Modeling Methodology (BMM). The BMM is used to illustrate the discussion about business operations modeling in this document. Salient points about the BMM are provided in this document. However, full elaboration of the BMM is not provided and the interested reader is referred to the UMM for further detail.

Supporting Multiple Perspectives: Key to Problem Solving

Considering the complexity of business and process automation problems, fully describing a business solution requires input from many people with different backgrounds and disciplines. Unfortunately, without using care, the varying consistency and precision of their input can directly impact how well-formed the solution is. An architecture designed up-front to support this variety and coalesce it all into a harmonized view helps ensure the solution that emerges is well-formed.

By separating business and technical perspectives, it is possible to provide a means for business people to model what they know without requiring specialized knowledge or skills. These models can then be mapped into targeted technologies and architectures.

BMM Structure

The BMM comprises of a set of architectures, patterns, and business semantics defined in accordance with certain business reference models and ontologies (domain-specific schemas). The BMM provides for the transformation of process and information as defined in one view (or perspective) to the next view without the loss of semantic or computational integrity.

The BMM includes five different perspectives, each with its own concepts and defining its own set of canonical semantics. As the BMM is put to use, each perspective adds more detail to the solution definition. Concepts defined in one perspective are transformable into the other perspectives. The five perspectives are:

  • Business Domain. This perspective describes the context for the business operations modeling.
  • Business Collaboration View. This perspective describes the business goals and the business collaborations involved in achieving them. It enumerates the scenarios, inputs, outputs, constraints, and system boundaries.
  • Business Transaction View. This perspective describes the logical transactions of information between business entities that are involved in accomplishing the business collaborations.
  • Business Service View. This perspective describes the exact information exchanges in accomplishing the business collaborations.
  • Implementation Framework View. This perspective describes the technology-specific bindings for the information exchanges.

Certain patterns that are useful for reuse are also defined in the BMM, including business collaboration patterns, business transaction patterns, and service interaction patterns.

Finally, a well-formed metamodel defines the syntax and semantics for each view. Uniformity of notation and precision of semantics provide concise and unambiguous business process definitions.

Business Domains: Giving Context to the Problem

The business domain view (BDV) is the framework for understanding business area process interrelationships. A particular BDV is typically a domain-specific business reference model that is used to categorize business processes to aid in business process definition, business process integration, and auto discovery.

Business areas comprise process areas. A process area is a set of business processes that implements a particular business operations model.

Business operations areas such as "Deliver stocked product" and "Deliver make-to-order products" are two different business operations models that use many of the same business processes.

The business domain model (BDM) provides a facility for categorizing and classifying processes and information according to a domain taxonomy. A taxonomy that is defined according to a particular domain ontology will closely represent the structure or organization of the problem space of the domain. This same taxonomy can be used to classify business processes to determine where within the organization of the problem domain these processes or solutions fit. Table 1 presents many of the BDM elements.

Table 1. Business Domain Modeling Elements

ElementDescription
Business ProcessA business process is a set of activities that are conducted to achieve a certain goal or objective. Inputs to the business process are specified in the preconditions and outputs from the business process must be specified in the post-conditions. In the BDV, business processes are used to identify and categorize business processed at a top/root level.
Business Domain MapA business domain map is a framework for understanding business area sub-process interrelationships. Typically a business domain map is a domain-specific business reference model that is used to categorize business process to aid in business process definition, business process integration and auto discovery. Registries and repositories would support the ontology and taxonomy specified by a business domain map.
Business Area A business area is a category of decomposable business process areas. A business area collates process areas.
Process Area A process area is a category of business processes and business transactions. A process area collates business processes and business transactions.
Business Entity A business entity is a real-world, first-class definitive phenomenon that exists; it has structure and a life cycle (state). In the context that the world understands what an object is, an object is usually system-oriented and a life cycle is optional, structural only. A business entity has structure and a life cycle (state). The concept of entity defines the real world instance of an object, not just a representation.
LocationA location identifies or defines the spatial aspect with respect to time that a business entity or business process can be realized.
StakeholderA stakeholder represents a role played by a business entity in relation to the business domain view, business areas or process areas.
Business EventA business event is an observance of and identification of the time, location, and type of an occurrence or activity
RequirementsA requirement, identified by a requirement category, that is either partially or completely satisfied by this use case. Requirements categories include 1) static and structural; 2) dynamics; 3) exception conditions; 4) non-functional; and 5) system administration.
JustificationA justification defines the set of rules and constraints that rationalizes the adoption of the solution identified in the associated business area or process area.

Business Collaborations: Process Elaboration

The business collaboration view (BCV) is the view of a business process model that captures and defines the business scenarios, inputs, outputs, constraints, and boundaries for business transactions and their interrelationships.

The goal of the BCV is to fully specify units-of-work that achieve defined business objectives. Objectives are elaborated in the form of business requirements and constraints.

To arrive at the BCV, business processes from the BDV are mapped into high-level business processes. These are then further specialized into sub-level business processes. This approach continues until the specialization reaches a level of specificity that defines a scope particular to a business collaboration. A business collaboration is a set of activities that are conducted by two or more parties to achieve a certain goal or objective. The BCV defines a business collaboration according to economic and jurisdictional ontologies.

The business collaboration is the primary concept within the BMM, providing modularity to sets of business transactions. The key difference between a business process and a business collaboration is the requirement of two or more parties having a shared perspective. This multiparty nature of the business collaboration brings many required aspects into the problem and solution spaces. Such aspects include who does what (role played), relationships between the parties (trust), commitments, expectations, ownership, and the consumption and production of resources. With a business process, these aspects are reflected as part of the definition, but they are optional. With a business collaboration, such aspects are integral to its definition. They must be specified to ensure the completeness of the solution. (This difference also plays an important role in defining a set of immutable properties that make up a business collaboration pattern.)

Business collaborations specify the relationships between business parties. They provide the business events that move to and from business parties. They define business entities or objects and their life cycles and states within the context of the business collaboration. Finally, they define business constraints and rules according to the context of the business collaboration.

The business collaboration model (BCM) provides for the structure and semantics necessary to elaborate operational, functional, and informational aspects of a business collaboration. A set of extensions elaborate the logical relationships, business relationships, commitments, expectations, resource consumption, and resources production of a business collaboration. Table 2 presents many of the BCM elements.

Table 2. Business Collaboration Modeling Elements

ElementDescription
Business EntityA business entity is a real-world, first-class definitive phenomenon that exists; it has structure and a life cycle (state).
Business Entity Life Cycle A business entity life cycle defines the observable conditions that may occur to a business entity within a given context.
Business EventA business event is an observance of and identification of the time, location, and type of an occurrence or activity.
Business ProcessA business process at the BCV level is a fully detailed definition of a business process, opposed to the business processes defined at the BDV level.
Business RulesA business rule is a set of computational constraints that are evaluated against the validity of the structure or state of business entities and business processes within the defined context.
PartnerA partner is a participant in a business collaboration.
Partner TypeA partner type is a category of participant in a business collaboration. Partner types include manufacturer, distributor, retailer, end user, carrier, and financier.
Process Life CycleA process life cycle defines the observable conditions that may occur to a business process within a given context.
Business Collaboration A business collaboration is a set of activities that are conducted by two or more business parties to achieve a certain business goal or objective.
Economic Elements An economic element is used to express the structure, interrelationships, and behavior of economic entities in the BCV of an economic model depicting resources, events, and agents.
AgreementAn agreement is an arrangement between two partner types that specifies in advance the conditions under which they will trade (for example terms of shipment, terms of payment, and collaboration protocols). An agreement does not imply specific economic commitments.
CommitmentA commitment is an obligation to perform an economic event (such as a transfer ownership of a specified quantity of a specified economic resource type) at some future point in time. Order line items are examples of commitments.
ClaimA claim is a request for fulfilment of a reciprocating economic commitment based on an economic event. A claim automatically arises when there is an unrequited economic event, for example a partner needs to be compensated for an economic event that is fulfilling an economic commitment.
LocationA location identifies or defines the spatial aspect with respect to time that a business entity or business process can be realized.
Contract A contract is the specification of a set of reciprocal business commitments between two or more parties. Each commitment is fulfilled by one or more business events. The contract also defines terms and conditions for the execution of a business collaboration.

The BMM has identified five business collaboration patterns that are commonly used in business:

  • Negotiation
  • Auction
  • Escalating commitments
  • Order fulfilment
  • Settlement

Business Transactions: Adding Legal Enforceability

The business transaction view (BTV) is the view of a business collaboration that captures the semantics of business entities and the exchange of business information between business partners as they perform business activities. The BTV facilitates the definition and specification of a legally binding business transaction.

A business transaction is a set of business information and an exchange of messages (of the business information) between two business partners that must occur in an agreed upon message format, in an agreed upon sequence, and under certain, previously agreed upon time period conditions. There are two types of messages that get exchanged in a business transaction: business action messages that contain business information mapped to business events, and business signal messages that are used by the business services during processing and are mapped to a business action message technical processing event instead of a business event.

There is a clear intent by a business transaction, agreed to ahead of time by both business partners. A business transaction pattern provides a basic mechanism for each business partner to do business transaction state management and business-to-business process alignment. When one business partner knows a business event has or should occur, the other business partner can also align or share in the knowledge of that business event.

Every business transaction follows one of the six business transaction patterns listed in Table 3. These business transaction patterns comprehensively cover all the known legally binding business collaborations at the lowest level of request/response interaction between two business applications. The specific business transaction pattern to be used in a business collaboration is determined by application of the modelling methodology in the BCV. A short description of each business transaction pattern is provided in Table 3.

Table 3. Business Transaction Patterns

Business Transaction PatternDescription
Offer & AcceptanceUsed to model an "offer and acceptance" business transaction that results in a residual obligation between both parties to fulfill the terms of the contract. In other words, a commitment between the two parties is left over after the transaction is completed. The pattern specifies that an originating business activity sending a business action message to a responding business activity, may return a business signal or business action message as a last responding message. The pattern mandates the acknowledgement of the requesting business action message when it passes a "business acceptance" test, which is the content validation step. This acknowledgement can be substantive or non-substantive, it may contain the terms of acceptance of a contract or a general auditable business signal.
Request & ConfirmSpecifies the exchange of a requesting and responding business action message and usually has no residual obligation between both parties to fulfill the terms of a contract. Different from request & response because it requires confirmation. For example, a request for authorization to sell certain products expects a confirmation response to the request that confirms if the requestor is authorized or not authorized to sell the products. An example is obtaining order status.
Request & ResponseSpecifies the exchange of a requesting and responding business action message and usually has no residual obligation between both parties to fulfill the terms of a contract. For example, a request for price and availability does not result in the responding party allocating product for future purchase and it does not result in the requesting party being obligated to purchase the products. This information may be dynamic, for example, obtaining a price for an airline ticket given certain inputs (location, dates of travel) and availability.
Query & ResponseSpecifies one business action message as output and one business action message as input. The query & response pattern does not permit the return of auditable business signals, or receipt acknowledgement, or business acceptance acknowledgement. The responding activity is most likely to be serviced by an organizational role, typically not by an employee role, and there is no non-repudiation requirement for these activities. An example may be the sending of static information, such as a store catalog, to a customer.
NotificationSpecifies the exchange of a notifying business action message and the return of an acknowledgement of receipt business signal. This pattern is used to model a formal information exchange business transaction that therefore has non-repudiation requirements.
Information DistributionSpecifies the exchange of a requesting business action message and the return of an acknowledgement of receipt business signal. This pattern is used to model an informal information exchange business transaction that therefore has no non-repudiation requirements.

Each business transaction pattern stipulates parameters that need to be specified by the service provider and service consumer.

Depending on the pattern, the service consumer may specify these parameters (valid values are shown in Table 4):

  • Time to acknowledge receipt (time interval). Both parties agree to verify receipt of a requesting business document within a specific duration.
  • Time to acknowledge acceptance (time interval). Both parties agree for a business acceptance document to be returned by the responding party after the requesting business document passes a set of business rules.
  • Time to perform (time interval). Overall time both parties agree to perform a total business transaction.
  • Authorization required (Boolean). True if the identity of the sending role is verified, false otherwise.
  • Non-repudiation of Origin and Content (Boolean). True if the business activity stores the business document in its original form, false otherwise.
  • Non-repudiation of receipt (Boolean). Both parties agree to mutually verify receipt of a requesting business document.
  • Recurrence of transmission (Int). Agreement to the number of times to retry a transaction when a time-out exception condition is signaled.

Table 4. Service Provider Parameters

Business Transaction PatternTime to Ack ReceiptTime to Ack AcceptTime to PerformAuth
Req
Non-repudiation of Origin and ContentNon-repudiation of ReceiptRecurrence of Transmission
Offer & AcceptanceTime IntervalTime IntervalTime IntervalTrueTrueTrueInteger
Request & ConfirmNULLNULLTime IntervalFalseFalseTrueInteger
Request & ResponseNULLNULLTime IntervalFalseFalseNULLInteger
Query & ResponseNULLNULLTime IntervalFalseFalseNULLInteger
NotificationTime IntervalNULLTime IntervalFalseTrueTrueInteger
Information DistributionTime IntervalNULLTime IntervalFalseFalseFalseInteger
  • Depending on the pattern, the service consumer may specify these parameters (valid values are shown in Table 5):
  • Time to acknowledge receipt (time interval). Both parties agree to verify receipt of a requesting business document within a specific duration.
  • Time to acknowledge acceptance (time interval). Both parties agree for a business acceptance document to be returned by the responding party after the requesting business document passes a set of business rules.
  • Time to perform (time interval). Overall time both parties agree to perform a total business transaction.
  • Authorization required (Boolean). True if the identity of the sending role is verified, false otherwise.
  • Non-repudiation of Origin and Content (Boolean). True if the business activity stores the business document in its original form, false otherwise.

Table 5. Service Consumer Parameters

Business Transaction PatternTime to Acknowledge ReceiptTime to Acknowledge AcceptanceTime to PerformAuthorization RequiredNon-repudiation of Origin and Content
Offer & AcceptanceTime IntervalTime IntervalTime IntervalTrueTrue
Request & ConfirmTime IntervalNULLTime IntervalTrueFalse
Request & ResponseNULLNULLTime IntervalFalseFalse
Query & ResponseNULLNULLTime IntervalFalseFalse
NotificationTime IntervalNULLTime IntervalFalseFalse
Information DistributionTime IntervalNULLTime IntervalFalseFalse

Legal Enforceability

A business transaction specifies a contract formation process between two business partners. Typically a business contract is used to legally bind parties to a clearly stated intention (promise, obligation) and responsibilities of each party.

A business contract usually outlines what each party can do if the intended actions are not carried out (for example, promised services not rendered or services rendered but payment not issued). Prudent business parties contract with one another prior to carrying out their intended business actions to limit their liability and to protect their business interests. In the BMM, all business transactions are treated as contract formation processes in that there is always an obligation (perhaps not residual; that is, left over after the event) between each of the parties participating in the transaction.

The power of business transaction patterns is that business partners can know whether they are in business state alignment with each other. Business state alignment means that both parties, the sender and receiver, are in sync with each other at a business operations-level perspective. When there is a transfer of information at the technical level, there must also be an acknowledgement and indication whether the information was accepted or not accepted at the business operations level. Thus, the transaction patterns help drive business partners to the same level of understanding to establish business trust.

As it is commonly understood, digital identity management works because it binds a person's identity to cryptographic keys using procedures that require a qualified (trusted) entity to the person to be authenticated to a computing network to which the person should be authenticated. The qualified entity is the basis of the legal chain of trust.

In building business transaction patterns, it was necessary to find a way to connect the intent (or meaning) of a legally binding business transaction to generic software transaction principles. Software transactions can enable business transactions, but business and software transaction types have a very different intent. Software transactions support actions such as rollback that are not allowed in business transactions. Sometimes this restriction is because of the nature of business. Sometimes this restriction is because of regulatory rules.

The goal with defining business transactions in the BMM was to build a general-purpose business transaction model structure. The structure was intended to clearly show how only certain business people, and the business entities who gave those people permission to act, could make promises and legally binding statements for the business entity to their business partners. Furthermore, the structure was specifically designed for all types of business transaction pattern use cases.

The "legally binding" mechanism used to accomplish a binding of a business transaction to a software transaction is referred to as "construed intent." That is, how easy it is to identify an intentional arrangement of business actions that rationally fit with an intent to do legally binding business.

The business transaction patterns (along with their associated service interaction patterns described later in this paper) help legally document whether business intent existed at the exact time a business transaction was concluded. The proper, well-formed existence of a business transaction, together with the service interaction pattern, models in software two important pieces of information to be assessed by a decision maker in trying to determine the intent of a promisor in the possible context of any legal dispute.

At the application level, other information about how the parameters in the business transaction pattern were triggered for inclusion will probably be needed, including the user interface the user experienced. The goal is to enable drawing a conclusion that what the user activated was what the user intended, and what was intended was correctly recorded and transmitted by the application.

For this reason, the business transaction patterns have been designed to provide the basic evidentiary needs in case of a legal dispute. Only a binding to a well-composed technology infrastructure can effectively and efficiently provide the full audit trail necessary.

Business Action Messages

Business action messages, sometimes referred to as business documents, are what is used to convey the actual business information content between the business parties.

A business action message is a legal instrument that represents a cognitive definition of a real-world entity. The business action message has identity and it exists. It also has a beginning, an ending, and behavior in a life cycle. The business action message can come into existence in the business transaction or be supplied to the business transaction already composed.

As a business action message moves through the business transaction processing, the state of the message changes as defined by the business action message's life cycle.

A business action message (also referred to as business information in the metamodel), can be a structured document containing defined information entities or an unstructured document of information entities of an undefined structure (for example, pictures and binary information).

Information Entity

Within the business transaction pattern model, the information entity is the container structure used for holding the structured and unstructured (digital image) business action messages.

In a proper business transaction, it is necessary to structure and have security on the business information so that only qualified business roles may operate on it. Because of this, an information entity structure is used to contain the business message with business role-based security instructions. Because some business information is built from other business information, in a compound fashion, information entities may also include or reference other information entities through associations.

Security controls on an information entity need to be specified when information must be secured within an enterprise organization until it is accessed by an authorized partner business role. These parameters on the information entity element must be specified in a manner that ensures document integrity by maintaining a "chain-of-custody" from the sender to the intended recipient of the business information.

An information entity has three security controls:

Confidentiality. The information entity is encrypted so that unauthorized parties cannot view the information.

Tamper Proof. The information entity has an encrypted message digest that can be used to check whether the message has been tampered with. This requires a digital signature (sender's digital certificate and encrypted message digest) associated with the document entity.

Authentication. There is a digital certificate associated with the document entity. This provides proof of the signer's identity.

These security controls are also applied to the business action message.

Business Partner Roles

A business partner participates in the context of one or more authorized business roles that in turn define a façade for their business service capabilities.

The business partner participates as an AuthorizedRole of type EmployeeRole, OrganizaionalRole, or both (FunctionalRole). The distinction is in the need to identify who is authorized to the individual in a company to perform some business action, such as only a certain manager being allowed to approve vendor payments, while other times anyone in the organizational group may be allowed to perform the action.

An OrganizationalRole is a role that only an organization performs in a business collaboration. An EmployeeRole is a role that, for business and legal reasons, only an employee can perform. Usually the details of the employee must be captured, stored, and transmitted to another partner for auditing and liability purposes when the two partner roles are not in the same organization. Both partners must agree to exchange business information using a secure transport channel.

The following security controls ensure that business action message content is protected against unauthorized disclosure or modification and that business services are protected against unauthorized access. This is a point-to-point security requirement. Note that this requirement does not protect business information after it is off the network and inside an enterprise (document security provides for outside transport security).

The following are requirements for secure transport channels:

Authenticate sending role identity. Verify the identity of the sending role (employee or organization) that is initiating the role interaction (authenticate). For example, a driver's license or passport document with a picture is used to verify an individual's identity by comparing the individual against the picture.

Authenticate receiving role identity. Verify the identity of the receiving role (employee or organization) that is receiving the role interaction.

Verify content integrity. Verify the integrity of the content exchanged during the role interaction; that is, check that the content has not been altered by a third party.

Maintain content confidentiality. Confidentiality ensures that only the intended, receiving role can read the content of the role interaction. Information exchanged during role interaction must be encrypted when it is sent and it must be decrypted when it is received. For example, seal envelopes so that only the recipient can read the content.

Business Services: Constructing a Business Dialogue

The business service view (BSV) captures the structure and semantics of business action messages and their exchange between enterprise components that provide business services. The BSV specifies the elements of an execution process that comprises the business transaction exchange between enterprise business services as a result of the execution of business actions. The BSV is a transformation of the BTV in context of the types of business transactions being performed and the class of partner role performing the transactions.

Predefined design patterns are described for the service interactions appropriate for each business transaction pattern. These service interaction patterns specify interaction sequences (protocols) between two services, including the message and information exchanges. The specific service interaction pattern used depends on the type of business transaction, type of role, security parameters, and timing parameters. Unless parameter default values are required to be overridden, the appropriate service interaction pattern is derived according to the metamodel and is instantiated in the solution specification.

A business service is a façade that exposes a business transaction. (The façade may also be presented by a business service agent, which is an entity that acts on behalf of the business controlling the business service.) Business services, and their possible agents acting as their business surrogates, need to always be in alignment with any specific business transaction needs when sending and receiving business messages. For example, if the business transaction needs a quality of service to be performed within certain time constraints and with a degree of security, the service interaction pattern must in turn be faithful to meeting those requirements.

There is a standard set of service interaction patterns that support the six business transaction patterns:

  • Service-Service. Messages flow between two business services.
  • Agent-Service-Service. Messages flow between a business service agent and its business service, and then between two business services.
  • Service-Service-Agent. Messages flow between two business services, and then a business service and its agent.
  • Service-Agent-Service. Messages flow between two business services through an agent.
  • Agent-Service-Agent. Messages flow between two business service agents through their business service.

Each of the service interaction patterns may have as many as five variants, as follows:

  • Interaction Variant Pattern A. Applies to the business transaction pattern where time to perform equals time to acknowledge acceptance and there is no responding business document.
  • Interaction Variant Pattern B. Applies to the business transaction pattern where time to perform equals time to acknowledge acceptance and a responding business document.
  • Interaction Variant Pattern C. Applies to the business transaction pattern where time to perform is greater than time to acknowledge acceptance.
  • Interaction Variant Pattern D. Applies to the Query/Response, Request/Response, and Request/Confirm business transaction patterns.
  • Interaction Variant Pattern E. Applies to the Information Distribution and Notification business transaction patterns.

Processing Business Action Messages

Service interaction patterns are stateless message exchange patterns, as messages are interchanged between two business services. There are two types of messages:

  • Business action messages. These have business information.
  • Service messages. These report on the processing of the business action message.

As they are processed by a business service, all business action messages must undergo a technical evaluation process to determine whether the message is well-formed. The business action message processing rationale behind the service interaction patterns is based on a document-processing framework of the following steps:

  1. Grammar validation. The task of verifying the syntax grammar of a business action message is valid (usually only the header of the message is checked at this step).
  2. Sequence validation. The task of verifying that the collaboration control information is valid with respect to the business transaction specification.
  3. Schema validation. The task of verifying that the message schema is valid with respect to a message guideline agreed to in advance by both partners. It is recommended that message receipt be acknowledged after this validation step to ensure that documents are "readable" as well as "accessible."
  4. Content validation. The task of verifying that the content of a message is valid with respect to any business rules that govern the formation of a contract. It is recommended that business acceptance be acknowledged after this validation step.
  5. Activity processing. The task of processing the business transaction request in the initiating business action message.

Figure 3 illustrates the processing of a message when the contract-closing (contract acceptance document) message is an acknowledgement of receipt. The acknowledgement of receipt is a business signal.

ms954615.chapter03_f03(en-us,MSDN.10).gif

Figure 3. Acknowledgement of receipt closing message

In processing the business action messages, the rationale around timeouts is a particularly important concept to understand. This is because performance of business responsibilities within agreed time boundaries is an obligation placed on all trading partners.

The service interaction patterns need to deal with timeout exceptions whenever a requesting partner expects one or more responses to a business action message request. The idea is that a requesting partner shall not remain in an infinite wait state for the responding party.

There are four possible responses and hence four potential time-out specifications to service interaction patterns:

  • Acknowledge Receipt. The time a responding role has to acknowledge receipt of a business action message.
  • Non-Substantive Acknowledge Business Acceptance. The time a responding role has to non-substantively acknowledge business acceptance of a business action message.
  • Substantive Acknowledge Business Acceptance. The time a responding role has to substantively acknowledge business acceptance of a business action message.
  • Perform Transaction. The time a business transaction has to complete.

By convention, the value for each time-out parameter is absolute and not relative to each other. Also by convention, all message processing timers start when a requesting business action message is sent. The rules around whether service interaction patterns are well formed include:

  • If the retry count is not zero and a time-out condition is signaled for any of the expected responses, the original business action message shall be resent from the initiating partner role.
  • The original business action message shall be sent even if responding acknowledgements have already been received.
  • If an initiating partner receives a response after a time-out condition is signaled and the original business action message has been resent, ignore this response.
  • A responding partner that receives a business action message from a retry shall terminate its responding transaction for the previous business action message and the retry request shall be serviced.
  • Upon sending a business action message retry, it shall be guaranteed that the sending party resends an identical business action message, except for a timestamp. Otherwise, a receiving partner shall be capable of rolling back an incoming business action message at any point in time through the acknowledgment interval, acceptance interval, and back-end processing interval.
  • When the time to perform an activity equals the time to acknowledge receipt or the time to acknowledge business acceptance, the highest priority time-out exception shall be used when the originator provides a reason for revoking the original business action message offer.
  • The time to perform exception is of a lower priority than both the time to acknowledge receipt and the time to acknowledge business acceptance.

Often, for technical reasons, it is not possible for one of the business partners to complete processing a business action message. With service interaction patterns, a business protocol exception also terminates the business transaction. The following are standard business protocol exceptions:

  • Negative acknowledgement of receipt where the structure or schema of a message is invalid.
  • Negative acknowledgement of acceptance where the business rules are violated.
  • Performance exceptions where the requested business action cannot be performed.
  • Sequence exceptions where the order or type of a business action message or signal message is incorrect.
  • Syntax exceptions where there is invalid punctuation, vocabulary, or grammar in the business action message or signal message.
  • Authorization exceptions where roles are not authorized to participate in the business transaction.
  • Business process control exceptions where business action messages are not signed for non-repudiation.

A responding role that throws a business protocol exception signals the exception back to the requesting role and then terminates the business transaction. A requesting role that throws a business protocol exception terminates the transaction and then sends a notification revoking the offending business action message request. The requesting role cannot send a business signal to the responding role.

Implementation Framework: Connecting to IT

The implementation framework view (IFV) defines the nominal set of properties a targeted technology must be capable of in order to enable the upper views and specifications of the BMM. The BMM helps define business collaboration and information models in non-technology-specific terms. However, actually using the resulting business collaborations may be facilitated by, and may even require, automation of certain aspects. The more standardized the automation to apply can be, the more cost effective the implementation can be. The IFV does not define or specify any particular technology to bind to; instead, it simply provides for a logical loose-coupling between the technology-neutral domain of the BMM and an underlying technology infrastructure.

Modeling Using Worksheets

A business environment may be large and complex. Any basic understanding of this environment begins with information and documentation.

Worksheets use a question and answer process to facilitate the application of the BMM. The worksheets process takes a business analyst (working with business experts from the enterprise) through an incremental business process and information model construction process that provides a conceptual framework for common concepts across the enterprise.

Worksheets can be used top-down, bottom-up, or both for business analysis. The end result of completing all forms is a complete business operations model of the business requirements, defining a legally binding set of business service relationships.

As illustrated in Figure 4, when bound through the IFV to a technology stack, the worksheet process can produce a solutions set. A solution set is a set of specifications that can be used to configure a messaging, choreography, and health model IT system. Where the technology stack is Web services, the solution set can be in the form of XML files including Web Services Definition Language (WSDL), Business Process Execution Language (BPEL), and a health model.

ms954615.chapter03_f04(en-us,MSDN.10).gif

Figure 4. Modeling through worksheets to produce a solutions set

Basic Worksheet Concepts

Worksheets are a question and answer process using forms. Worksheets:

  • Are a comprehensive business process and information process analysis methodology.
  • Retain business acumen that is reusable over generations of new technology.
  • Provide a methodology to capture business process knowledge, independent of the underlying technology
  • Help discover and define a set of reusable process and information descriptions. Patterns are used to help enforce consistent, reproducible results.
  • Implement processes that help insure predictable results from a software project.
  • Build a model of the business requirements into a technology implementation solutions set.

The following are basic worksheet concepts. They include descriptions of the people who participate in completing worksheets as well as key modeling concepts behind worksheets. They are:

  • Industry Expert. Able to categorize and decompose a business environment into business areas, process areas, and business processes.
  • Business Expert. Knowledgeable of the business area being modelled.
  • Business Domain. A set of business concepts, a taxonomy, for understanding business area and process interrelationships.
  • Business Collaboration. A set of activities conducted by two or more parties to achieve a commonly defined goal or outcome.
  • Business Stakeholder. Someone, or an organization, who has some stake in the success of the business.
  • Business Process Activity. A set of activities conducted by one or more parties for the purpose of achieving a business objective and can be conducted with time as a constraint or business rule.
  • Business Collaboration Activities. Multi-partner business process activities that scope business requirements gathering and specification. A business collaboration activity is a predefined set of activities or processes initiated by one partner to accomplish an explicitly shared business goal and a business collaboration activity is finished on recognition of one of the agreed conclusions by all the involved partners.
  • Business Interaction Activities. Define requirements in the business environment placed by one partner's activities on multi-partner activities
  • Business Information. The business rules on business collaboration activities (goals, requirements, and constraints). Business information is gathered from commercial trading agreements, business process agreements, and system interface agreements.
  • Business Collaboration Model is made up of:
    • Business Process Models. Defined by business analysts which specify the choreography of business objects through business collaboration activities.
    • Information Models. Formal representations of business information that can be understood and confirmed by the business environment experts.
    • Business Collaboration Patterns. Selected to fit the requirements of a business collaboration activity and to facilitate business process model and information model reusability. However, in the absence of a suitable business collaboration pattern, the selection of pre-specified business transaction patterns simplifies the reuse components in a business collaboration activity.
    • Business Object. A reusable class of attributes from which business information structures can be assembled for information exchange.
    • Business Transactions. Atomic business processes involving two trading partners. There are six canonical business transaction patterns.
    • Business Entity. A real-world thing, concept, process or event having business significance that is shared among two or more trading partners, and which exists in two or more states of at least one life cycle.
    • State. Describes the status of a business entity and a business collaboration before or after a transition (for example, delivery of goods triggers the transition of order line status from "pending" to "fulfilled").
    • State Transition. Describes the progress of a business entity from one state to another as expressed by pre-conditions (for example, order-line pending) and post-conditions (for example, order-line fulfilled) of a business entity triggered by an event.
    • Event. Represents a business collaboration activity (for example, order and goods transfer) directed towards meeting a requirement of a business entity.
    • Life Cycle. Describes all of the permitted states and transitions of the business entity during its lifetime.

Participants in the Worksheets Process

The overall worksheets process can be logically broken down by audience and their contribution towards filling in the worksheets. Table 6 presents a summary view of this breakdown.

Table 6. Participants in the worksheet modeling process

ms954615.chapter03_table06(en-us,MSDN.10).gif

There are participants for each of the three worksheet views. Each view contains a collection of worksheet forms. Depending on the view, the roles could be played by different participants. The following list provides further detail:

  1. BCV modeling captures the business scenarios, inputs, outputs, constraints and boundaries for business processes and their interrelationships within business process collaborations. This view is how the business domain expert sees and describes the process to be modeled. The BCV is expressed in the language and concepts of the business domain expert. A special set of forms in BCV modeling are the Service Level Agreement (SLA) worksheets, which describe the metrics and activities in the SLA. The BCV participants are:
    1. Business stakeholders: Executive management, business owners, information modelers, process modelers.
    2. Worksheet modelers: Business analysts, business modelers.
  2. BTV modeling captures the semantics of business information entities and their flow of exchange between roles as they perform business activities. This view is an elaboration on the BCV by the business analyst and is how the business analyst sees the process to be modeled. This view uses the language and concepts of the business analyst to convey requirements to the software designer and to the business domain expert. The BTV participants are:
    1. Business stakeholders: Business analysts, systems architects, implementers.
    2. Worksheet modelers: Information modelers, process modelers.
  3. BSV modeling specifies the component services and agents, and their message (information) exchange as interactions necessary to execute and validate a business process. The BSV is expressed in the language and technical concepts of the software developer. The BSV participants are:
    • Worksheet modelers: Derived from BTV worksheets

Practical Approaches for Modeling Using Worksheets

Several practical considerations apply to modeling using worksheets.

Top-Down, Bottom-Up

Building a worksheets-compliant business operations model can start top-down or bottom-up. In the end analysis, when all the forms are complete, the final controlled check is a top-down modeling control.

Any use of worksheets first starts off with a clear understanding of the specific domain of business activities. Working with worksheets de-emphasizes the use of business documents and transactions to model business service interactions because that approach may have captured only one part of the required legally-binding business process model. An emphasis with worksheets is placed on the definition of business entities, the identification of their state management, and the identification of their state life cycle to produce a model that encompasses all instances and can evolve as new business requirements emerge.

Bottom-up modeling can be used as a starting point to fill in parts of the worksheets through use of existing business documents and transactions. It can help identify some model elements. However, the top-down approach must ultimately be applied to produce evolvable and maintainable models that support reuse and manage loosely coupled business processes between trading partners on the Internet.

Business Information Dependencies, not Document Exchange

The goal of worksheets is to understand and formalize the dependencies between partner processes for a problem domain. Historically business partner communication methodologies (such as Electronic Data Interchange, or EDI) have focused on modeling the business documents being exchanged, while worksheets focus on modeling the business actions and objects that create and consume business information. Of course documents are an important part of business operations; worksheets allow for declaring business documents.

Measurability and Traceability

Worksheets top-down approach drives out the identification of measurable business objectives and requirements, which can be verified by stakeholders. Worksheets and their production rules ensure the true representation of these objectives down to their technical implementation. Traceability of these objectives is the basis for ultimate "success" or "failure" of the business operations model when in operation.

The other benefit from the top-down modeling activity is that it expresses the common semantics that will be used to describe a public business collaborative process.

Model Production Approach

Worksheets are a simple tool to collect and organize the information needed to produce a complete business requirements model. The process of gathering information for the various worksheet forms is very iterative in real world practice. As one works through the various worksheets, new information will be discovered and previous worksheet forms may need to be updated to reflect any changes.

In gathering information from business stakeholders for the forms, the modeling facilitator may learn information that is required for worksheets that would be covered at a later time. Vital information should be captured at the time it is discovered to avoid losing track of it. Worksheet facilitators should be prepared to keep track of such information on a notepad, for later transfer to the appropriate worksheets.

Simplified Procedure for Modeling Using Worksheets

This section illustrates a very simplified, step-by-step procedural overview to using the worksheets. The approach described sequentially in Tables 7, 8, and 9 proceeds in a top-down fashion with each of the three views (sets of forms) in the worksheets. Procedures within each of these groups of forms describe how to populate the worksheets. The procedures here are meant to be a typical, not authoritative or normative work procedure. Sometimes in the real business world it is best to start with what little information you have available and continue through a progressive refinement process of verifying facts, refining business needs, and coming to agreement with all parties involved in the modeling exercise.

Table 7. Business Collaboration View Forms

StepsWorksheet Name
1. Describe each business process. Business Process

Requirements

2. Identify and describe business collaborations starting with a large collaboration and breaking it down to smaller business collaborations use cases. Each needs to be further described until business transactions are identified and described.Business Collaboration

Business Process/Collaboration Life Cycle

Business Process Metric

3. Identify and describe any partners and their roles, specifically in relation to business collaborations, agreements, and commitments.Business Partners and Roles
4. Identify and describe business entities.Business Entities
5. Identify and describe any business events that are used to signal the change in state of business entities and thus a business collaboration.Business Events
6. Identify and describe the contracts as well as the agreements and commitments that are part of it.Contracts

Commitments

Table 8. Creation of the Service Level Agreement

StepsWorksheet Name
1. Define the Service Level Agreement (SLA) that is agreed to, the terms and conditions of the agreement, the parties involved, and the measurements to be used.Service Level Agreements
2. Provide a description of the activities (services) that comprise this SLA.Service Definitions
3. Identify and describe the measurements that result from this agreement.Key Performance Indicators

Table 9. Business Transaction View Forms

StepsSection / Worksheet Name
1. Define a business collaboration life cycle for each business collaboration to capture the dynamic requirements; that is, business transaction activities.Business Collaboration Life Cycle
2. Provide a description of the business partners and their authorized roles in this business domain.Business Partners and Roles
3. For each business transaction activity define a business transaction worksheet. Identify requesting information and optional responding informationBusiness Transaction
4. Document the key informational elements that are important to a transaction especially in achieving document element level interoperability.Business Information
5. Define the structural aspects, constraints, relationships of the business entities as well as the various states of its life cycle. Business Entities

Business Entity Life Cycle

6. Define the structural aspects, constraints, relationships of the information entity.Information Entity

Product Shipping at Northern Electronics

The order fulfillment department at Northern Electronics coordinates the pickup and delivery activities around getting an ordered product to a customer. These activities include verifying and validating purchase orders (POs) with the sales department, verifying credit with the accounting department, coordinating inventory management with the production department across the various warehouses, managing the transport of products to customers, and updating delivery status for the accounts receivable department.

Within the transport function, product shipping is an area that the company has had problems with. Product shipping involves significant coordination, including ordering transport from the right consolidator, moving the right product in the right amount from the right warehouse to the right loading dock, and getting the waiting product onto the right truck. That truck must be driven by the right trucker and arrive at the right time as an agent from the right consolidator.

Product shipping is a core business process for Northern Electronics. Businesses expect problems to arise and have procedures in place to handle them. In some cases, the consequences can amount to just a marginal impact, because the exception can be managed easily or simply accommodated. In other cases, the consequences can be severe and can lead to financial penalties or even loss of business. From the perspective of the warehouse, problems such as the truck not arriving on time, a truck arriving but being the wrong truck, or the truck being too full to accommodate the order can occur. From the perspective of the customer, problems such as non-delivery of product, incorrect delivery of product (the wrong product or the wrong amount of product), or delayed delivery of product can occur.

The company has had ongoing problems with the product shipping process. Trucks don't always arrive on time. And even when they do, the requirements for the truck aren't always met. Also, the wrong cargo shows up at the loading dock more often than it should. All of these logistical problems result in much higher overhead costs, and especially, in delay for the customers expecting on-time arrival.

Product shipping is an area that Northern Electronics has decided to improve. The company has decided to tackle two aspects of the product shipping process:

  • Achieve more efficient coordination in product shipping with business partners.
  • Achieve more efficient handling of business exceptions in product shipping when they occur.

An important step in the effort to improve product shipping is to model how the process works.

Who's Who in Northern Electronics

The following individuals from Northern Electronics are involved with the modeling of the product shipping business collaboration:

  • Pam: She is the business program manager whose responsibility in this context is to understand and model the product shipping process.
  • Zack: He is the head of IT architecture whose responsibility in this context is to work with Pam to help her understand the IT organization and its requirements.
  • Mark: He is the business analyst whose responsibility in this context is to collaborate with Pam and Zack to facilitate the worksheets process.

    One of the goals of the modeling exercise for Pam will be to translate the formalized information in the model into something that the IT organization can use to design, implement, and operate a solution. Particularly, Pam wants to make sure that the IT solution is set up and operated in such a way that it can help detect and correct any business exceptions that will occur when the product shipping business collaboration operates.

Modeling the Product Shipping Activities

As Pam gets to work, her first decision is that she must get a handle on understanding the product shipping process. She decides the best way to do this is to pull together a formal description of the existing processes in product pickup and delivery, so she can better determine what the problems with product shipping are and where changes should be made. In a sense, she begins an effort to formally model how product shipping is done.

Understanding Product Shipping

To understand the domain, Pam interviews a number of experts within Northern Electronics and related third parties including the individuals in the following roles:

  • The business analyst provides business knowledge about product shipping, including what data needs to be collected and how it should be manipulated to reflect the physical reality. This includes requirements for handling and packaging the goods, requirements for third-party transport services, and shipping schedules.
  • The financial analyst provides the financial plan regarding the shipping budget, customs charges, any other taxes, freight rates (tariffs), and insurance rates.
  • The shipping manager supervises logistics and enforces any regulatory requirements.
  • The consolidator is a third party who provides input regarding requirements for packaging, delivery options, scheduling, and relevant forms.
  • The attorney provides guidance on industry standards and regulations that are best practices and legal requirements for product shipping.

It's especially important to note that not all of these individuals work at Northern Electronics. For example, the consolidator is a third-party company that Northern Electronics does a lot of business with. Getting improvements in the product shipping process is not something Northern Electronics can do alone—it involves the entire value chain.

Through Pam's interactions with these individuals and from market and regulatory information, Pam begins to develop a good model for how the product shipping process works.

An example of the broader product pickup and delivery process, namely how a product moves from the manufacturing floor to a customer's facility, that the product shipping process is a part of helps illustrate Pam's findings. Figure 5 describes the high-level business entities involved in the larger product pickup and delivery process.

Some of Northern Electronics's products are manufactured at their plant in China and then shipped to their warehouse in Everett. One such product line is the electronic controller for remote-controlled airplanes. One of Northern Electronics's customers is a wholesaler named Wingtip Toys that assembles remote-controlled airplanes in Dallas, Texas, and then sells the airplanes to retail companies. Northern Electronics hires Acme Consolidation Company, a freight consolidator based in Portland, Oregon, to arrange the transport of the electronic controllers from the warehouse in Everett to the wholesaler's warehouse in Dallas.

Acme Consolidation Company performs many tasks, including:

  • Collecting the appropriate paperwork from Northern Electronics.
  • Providing the freight cost.
  • Reserving space for freight with freight companies and coordinating with the freight companies to deliver the cargo to the destination warehouse.
  • Offering Northern Electronics insurance for the cargo while in transit.

In this example, Acme Consolidation Company hires Blue Yonder Truckers, a local trucking company to pick up and transport the goods.

ms954615.chapter03_f05(en-us,MSDN.10).gif

Figure 5. Entities involved in the product pickup and delivery example

Pam learns that whenever Wingtip Toys wants to place an order with Northern Electronics, the purchasing agent at Wingtip Toys calls Northern Electronics's sales agent. Pam determines that the product shipping business collaboration begins when a PO is created.

In the case of the example, Pam determines that the product shipping business collaboration works like this today:

  1. Richard, the shipping clerk at Northern Electronics gets new POs on his desk every morning. One of his daily tasks is to verify that the warehouse has the items in stock. If the items are not in stock, Richard notifies the customer that the PO is backordered. The PO is placed in a "Waiting for Goods to Arrive" backorder pile.
  2. When Richard knows that he has the goods in stock, he performs a stock allocation to cover the order. He calls Julie, the transport consolidator clerk at Acme Consolidation Company, to arrange the delivery of the goods to Wingtip Toys. Julie was on her lunch break when he called, so he left her a voice mail and put the PO into the "Pending" pile. When she gets back from lunch, she calls him back to get the details. Because Richard has a lot of piles on his desk, it takes him a few minutes to locate the PO he needs. He finally finds the PO and lets her know what the requirements are. Julie considers these, and then she agrees to transport the goods. Richard then writes up a new transport order request and puts the PO into the "In Progress" pile. He updates and gives the pickup list to David, the loading dock clerk, to get the required number of items of the product from the warehouse and arrange for the packaging of the goods, including putting the items on pallets, shrink-wrapping them, and labeling the package.
  3. Julie has a pool of trucking companies that she calls. She goes down the list to order a truck that can drive the shipment from Everett, Washington, to Dallas, Texas. She finally finds one that can do the job. Blue Yonder Truckers can arrive on the following Tuesday at 10:00 A.M. to load the truck. The clerk at Blue Yonder Truckers gives Julie the license number of the truck and she sends the transport order details to the trucker. Julie also faxes Richard a transport notification form with the specific details of the truck.
  4. Richard keeps track of the scheduling of when packages are supposed to be picked up and makes sure the goods are ready to be loaded onto the dock when the truck arrives. He has a schedule of the pickups on the white board in his office and writes down the new request.
  5. On the morning of the scheduled pickup, Bob, the trucker, checks in with Richard at 10:05 A.M. Richard pulls up the order and checks Bob's paperwork. He notes the time of arrival and tells Bob which loading dock he should pull his truck to.
  6. Bob pulls his truck up to the correct loading dock. David asks Bob for the paperwork and loads the packaged and labeled order on the truck. Bob counts the items to verify it's the same number as the number on the paperwork. David enters the final load weight into the transportation documentation and Bob signs the paperwork, assuming liability during transportation of the goods. When Bob drives away, David notes and enters the time and gives a copy of the paperwork to Richard.
  7. Richard gets the documents and faxes the information to both Wingtip Toys and Acme Consolidation Company to let them know that the trucker has picked up the shipment. He then updates the PO and places both the PO and transport order documents into the "In Progress" pile.
  8. When the truck arrives at the customer's warehouse, the customer faxes a confirmation of the arrival to Richard. He then places the PO and transport order into the "Completed" pile.

While all of the shipping is happening, Northern Electronics invoices Wingtips Toys, and Acme Consolidation Company invoices Northern Electronics.

Pam models the information flow around the product shipping business collaboration by using a flow chart, as shown in Figure 6.

ms954615.chapter03_f06(en-us,MSDN.10).gif

Figure 6. Product shipping business collaboration information flow

Pam can see now more specifically that many of the processes surrounding the product shipping business collaboration are dependent on human interaction and manual processes. There is information that is transmitted over the phone, paperwork that is manually filled out, faxes that are sent and received, and paperwork that is manually handed from one person to another. Pam wonders how often a message is not received or a piece of paperwork gets lost. This must certainly waste the employees' time, waste the company's money, and cause a lot of frustration for everyone involved. Moreover, how well can this process scale when the company starts to grow, or as it tries to be more competitive? How many more employees are going to need to be hired and trained to process paperwork and answer phone calls? Ultimately, the concern is: What is the impact to the customer and customer service?

Pam recognizes that some aspects of product shipping will still need to be manual but other parts of the process can certainly be automated. Pam works with Zack to identify the areas that can be automated.

Pam and Zack decide that they need to identify discrete business services that make up the product shipping business collaboration.

Automating business services in the product shipping business collaboration, where possible, should provide the means for better communication, coordination, and collaboration between Northern Electronics and its business partners. Automating business services should help Northern Electronics to:

  • Manage for business performance.
  • Stipulate authorized business rules.
  • Obtain real-time business intelligence through key performance indicators.
  • Ensure the services are designed for reusability and scalability.

One significant source of improvement from automated business services should be the ability of Northern Electronics to be in better synchronization with its business partners involved in the product shipping business collaboration. As noted earlier, one major problem area in product shipping is dealing with exceptions in a timely and effective way. The challenge in exception handling is mostly about getting useful information about an exception that has occurred to the right person in time, or even ahead of time, so that he or she can do something about the problem as it happens—or before it happens. When the right information arrives to the right person in time, there's a better chance that whatever intervention the person can implement can have a more significant mitigating effect.

Pam interviews Richard and asks him, "What are the key things in product shipping that you worry about?" He lets her know there are key events that must happen for the product shipping process to flow smoothly. The most important are:

  • The truck must arrive on the correct day within the specified period of time. The pickup time is Monday through Friday from 10:00 A.M. to 10:30 A.M. If the trucker does not arrive within the designated time, the trucker will need to pick up the goods on the next business day.
  • The truck must be the right truck. This means that the truck must have the correct license plate number as agreed in the paperwork, must be the right size, must be insured, must have the right trucking permits, and must be in good working condition.
  • The truck driver must be the right trucker. The truck driver must have the correct paperwork containing the shipping reference number allocated by Northern Electronics.
  • The loading dock must be ready with the goods when the truck arrives.
  • The truck must depart with the shipment loaded within the specified period of time.

    In the event that one (or more) of these conditions is not met, the process will be delayed. In the worst case, one delay can have a snowball effect and delay other shipments as well. This will severely and negatively affect the business.

    Pam talks to Zack to find out whether some of these key events can be managed with IT infrastructure. Pam reasons that if Richard can get an advanced warning before one or more of these conditions are not met, it can help them plan for the situation before it becomes a problem.

Formalizing the Product Shipping Business Collaboration

Pam's investigations into how product shipping works at Northern Electronics have made her the expert. She has put a lot of organization into arranging the information she has collected, much of which came from many different sources. But still, only she really has the full picture of what is happening. The challenge is that many other people within Northern Electronics (and Acme Consolidation Company) need to know some or all of the details about how the process works and where she wants to improve it. It is important for Pam to formally capture the information in such a way that she can put context onto how the information is interrelated. To do this, Pam uses a business process modeling approach.

After Pam has looked at the entities as a whole, Pam wants to better understand the business collaboration by identifying the following actors in the scenario and their responsibilities:

  • The supplier shipping clerk receives new POs and verifies that the warehouse has the items in stock. The clerk is responsible for ordering the necessary transportation for delivering goods to the wholesaler. The clerk is responsible for verifying that the details in the transport notification satisfy the conditions in the requests or take corrective actions if necessary. The clerk arranges for the packaging of the product and is responsible for preparing the loading dock with the goods to be shipped. The clerk uses a pickup scheduling application to determine the PO that has an associated transport notification. The goods are then queued in first-in, first-out order at the loading dock.
  • The transport consolidator clerk is responsible for processing the transport requests coming from the supplier. The clerk will research with the contracted trucking companies to find available transport for their supplier client. After the transport provider is identified, the clerk fills up a transport notification form and sends it to the supplier.
  • The trucker is responsible for picking up the goods from the supplier. On the day of pickup, the trucker arrives at the designated time and checks in. When the loading is completed, the trucker signs a pickup completion form to transfer and assume liability of the goods in transit.
  • The supplier loading dock clerk prepares the final transportation document that contains the pickup details. Upon completion of loading, the clerk sends the document to the transport consolidator to confirm the goods pickup.

Pam uses an activity diagram to document the business activities in the product shipping business collaboration, as shown in Figure 7.

ms954615.chapter03_f07(en-us,MSDN.10).gif

Figure 7. Product shipping business collaboration activity diagram

Some of the business activities are internal activities only relevant to Northern Electronics. However, other business activities rely on a successful collaboration between Northern Electronics and Acme Consolidation Company.

Business Operations Requirements of Product Shipping

Now that Pam has a firm understanding of how product shipping works in the business environment, Pam needs to translate the information into something that the IT organization can use to design, implement, and operate a solution. Particularly, Pam wants to make sure that the IT solution is set up and operated in such a way that it can help detect and correct any business exceptions that will occur when the product shipping business collaboration operates.

Pam uses the information she has collected and works with Mark, the business analyst, to go through the worksheets process.

Mark uses Microsoft Office InfoPath 2003 to conduct the worksheets process. He has a set the worksheets from the BMM implemented as a collection of forms. Figure 8 shows what the worksheets tool looks like.

Click here for larger image.

Figure 8. Worksheets process based on the BMM implemented in Microsoft Office InfoPath 2003

Modeling Product Shipping Using Worksheets

With Mark's help, Pam starts using the worksheets to describe the product shipping business collaboration. Table 10 describes what is going on at the virtual and physical levels in the flow identified in Figure 5. It also states the event that identifies when the legal responsibility is transferred from one entity to another.

Table 10. Product Shipping Service Events

OrderVirtual (Technology) LevelPhysical LevelEvent
1Supplier calls the service with the transport order details. Consolidator calls the service to verify details and enters additional information.Consolidator dispatches the trucker to the supplier.Transport arrangement between the consolidator and the supplier.
2Consolidator and supplier agree on protocol. Service transaction is executed.The trucker arrives at the supplier's warehouse at the designated time. A licensed driver picks up the cargo.Supplier accepts the truck (verifies the correct truck, condition, and size). Supplier accepts the trucker (verifies the correct trucker).
3 Supplier loads the container with the packaged goods, does a final check of the cargo, and produces the final paperwork.The truck is loaded. At this point, the supplier is still responsible for the goods.
4Responding business transaction service details.Trucker signs paperwork and consolidator accepts responsibility. The truck leaves the supplier's premises.

The worksheets help Pam determine which business transaction pattern applies to the business activities. In the product shipping scenario, there is a response required, the responder does not already have the information, pre-editor contact validation is required before processing, and there is a residual obligation between roles to fulfill the terms of the contract. This means that the product shipping business collaboration uses the offer & acceptance pattern. The documents that formalize the contract are a pickup instruction document and a pickup confirmation document response.

There are other important details about the product shipping business collaboration. Northern Electronics and Acme Consolidation Company agree to the terms of a service contract. The service contract encompasses the service level agreement (SLA). It includes both business and technical conditions and defines parameters including:

  • Response time, time-out, and availability
  • Development, test, and production environments
  • Priorities and keywords
  • Legal enforceability requirements

The worksheets asks Pam to specify the parameters in Tables 11 and 12. Table 11 refers to the parameters that Acme Consolidation Company needs to provide to Northern Electronics, while Table 12 refers to the parameters that Northern Electronics needs to provide to Acme Consolidation Company. To determine these parameters, Pam relies on the SLAs and her understanding of the business collaboration.

Table 11. Service Consumer Parameters

Business Transaction PatternTime to Ack ReceiptTime to Ack AcceptTime to PerformAuth ReqNon-repudiation of Origin and ContentNon-repudiation of ReceiptRecurrence of Transmission
Offer & Acceptance30 minutes2 hours48 hoursTrueTrueTrue3

The transport agreement is that Acme Consolidation Company will call the product shipping service no less than 24 hours in advance of the truck arriving. They collectively agree that the loading of the truck should take no more than 24 hours. Acme Consolidation Company will receive an event notifying that the truck departed (with the goods) no later than 48 hours after the original call to the product shipping service.

Table 12. Service Provider Parameters

Business Transaction PatternTime to Acknowledge ReceiptTime to Acknowledge AcceptanceTime to PerformAuthorization RequiredNon-repudiation of Origin and Content
Offer & Acceptance30 minutes2 hours48 hoursTrueTrue

After Pam enters all the information about the product shipping business collaboration into the worksheets, the tool is able to provide output of a set of specifications that formally specify a solution set for the product shipping solution.

Pam is able to use the specifications to communicate her requirements to Zack and the rest of his team in the IT organization in a way that relates to the kind of work they do.

Particularly, the business operations specification that specifies management requirements helps Zack know which management functions need to be set up to support the business operations requirements as he and his team design the system. The system infrastructure will need to be set up and configured so that appropriate business activities can be managed or logged. The business operations specifications present requirements to IT in a way that can be used to create a business operations health model. A business operations health model is a specification of the detection, verification, diagnostic, resolution, and re-verification actions for any manageable condition in a business collaboration. Of course, not all business exceptions are predictable, and not all manageable conditions are business exceptions. But business exceptions already known to impact the business collaboration negatively are contained in the information Pam has collected. The information also contains requirements for other manageable conditions, such as logging certain activities that occur to produce an evidentiary record. The business operations specifications pull these manageable conditions out of the formal business collaboration model and present them in a way that Zack and the rest of the IT organization can work with.

An example of such a manageable condition from the product shipping business collaboration that Northern Electronics wants to pay close attention to has to do with the on-time arrival of the trucks. The business operations specifications call out this requirement formally:

  • Business Operations Requirement (BOR): The truck shall arrive to pick up the goods at the supplier's warehouse on or before the specified SuggestedPickupTime.

Tables 13 and 14 describe the details around this business operations requirement.

Table 13. Business Operations Health Model (Detection Information)

ProblemHealth State and Operational ConditionIndicatorsOperational AlertsCriticality
Violation of BORDegraded; Integrity ProblemEvent (ID = EVENT_TRUCK_ARRIVAL_DELAYED)

This event is logged to the event log.

An e-mail notification will be sent to the Business Operations Managers notification group.An event processing rule generates an alert with the severity set to Severe.

Table 14. Business Operations Health Model (Verification, Diagnostic, Resolution, and Re-verification Information)

ProblemVerification ProcedureDiagnostic InformationResolution and Final Desired StateRe-verification
Violation of BORManual check that truck has not arrived (should return TRUE). Operational condition confirmed as integrity problem.Manual check. Call to transport consolidator to find out where truck is.Manual resolution. Supplier renegotiates truck arrival time with consolidation company and updates the time in the system. Supplier updates SuggestedPickupTime. The logs and databases are both updated with new information.Manual check that truck has not arrived (should return FALSE).

Table 13 shows how to detect the condition (in this case, a business exception) and Table 14 shows how to proceed after the detection has been made. The final resolution in this case from the IT domain is just to provide feedback to the business operations managers. No control action by the IT management system is needed to change the state of the system.

Conclusion

This document examined how business operations requirements can be communicated to the IT organization by applying business operations modeling.

  • The document described how the business program manager and a business analyst can apply a business operations modeling methodology to derive a set of requirements the IT department can use to build a solution. Specifically, this document discussed:
  • Business operations concepts.
  • Business operations modeling methodologies, including a background on such modeling approaches as well as a brief discussion of a modeling approach used to illustrate this document.
  • Modeling through worksheets, including a discussion of worksheets concepts and basic procedures such as the following:
    • Production of a solution set that contains business operations requirements information for use by the IT organization, with a specific focus on the inputs to the service management and health modeling functions.
  • Demonstration of the approach using the Northern Electronics scenario.
Show:
© 2015 Microsoft