18. Business Process Analysis (3)
DE + IA (INFO 243) - 19 March 2007
Bob Glushko
Plan for Today's Class
- Business Signals and Transaction Properties
- Staple Yourself to an Order
- Innovation at the Speed of Information and the DSM
The ebXML Process Metamodel
Order Offer and Acceptance -- Sequence Diagram
Business Signals in the Process Stack / Pipeline
- These transactional depictions omit other events or information sent by the message recipient in support of the "business document level" activity
- These events provide useful feedback or reassurance to the sender when the responding business can't reply to the request immediately
- While they are not documents, these business "signals" or "confirmations" have business value and are in addition to any acknowledgement
signals associated with the lower level message transport layers (e.g., HTTP, TCP/IP)
Sequence Diagram with Signals
Three Types of Business Acknowledgments
Business Signals: Types
- Business Signals are not business
documents but they are used at the process level to notify the sending party of certain types
of events
- A Receipt is used to inform a sender of a
business message that the message has been received
- A Confirmation is used to inform a sender of
a business message that the business document content is valid or invalid
according to the recipient's business rules (e.g. valid part numbers)
- Business signals help to interrelate the parts of a transaction and are an essential part of what the transaction means; their presence or absence says a lot about the relationship between the sender and the recipient
Business Acknowledgments as Transaction Properties
- With the six transaction patterns we can make broad contrasts, but we often need to make finer distinctions
- Even the same transaction type can "behave" differently within a particular trading community, supply chain, or marketplace because of different business rules, "quality of service" contracts or similar guarantees
- So we need some additional properties that further define the semantics of transactions to explicitly tell the participating businesses in a transaction what to expect from each other.
-
Each of the six transaction patterns has a characteristic property profile
Time-Based Transaction Properties
- Time To Acknowledge Receipt -- The time in which a recipient of a document must respond with an Acknowledge Receipt business signal
- Time To Acknowledge Acceptance -- The time in which a recipient of a business document must respond with an Acknowledgement Acceptance business signal
- Time To Perform -- The time in which the responding party must respond with the expected business document
Other Transaction Properties
- Authorization Required -- The sender must sign the document and the recipient must validate the signature and the role associated with the signature
- Non-Repudiation of Origin and Content -- The sender must store the business document in its original form for a duration mutually agreed upon in a trading partner agreement; the non-repudiation process includes validating the identity of the sender and the integrity of the content
- Non-Repudiation of Receipt -- The sender of the receipt is required to store the Acknowledgement Receipt for the mutually agreed upon time period; the non-repudiation process includes validating the identity of the sender and the integrity of the content
Typical Transaction Properties
Business Process Concept of "Collaboration"
- Two or more business transactions can be sequenced to carry out a business collaboration
- A business collaboration is a series of activities carried out by two or more partners
for the purpose of achieving a business goal; these activities are business transactions
- These transactions have more context in common with each other than with transactions that perform other parts of the business process
Meaningful and Necessary Semantic Overlap
-
The set of transactions in a collaboration have meaningful and necessary semantic overlap with each other
- They have parties/actors in common
- The overlap must be necessary -- two parties must need to know about each of their transactions with a third party for the set of transactions to be collaborative
Example: Collaborations in Drop Shipment
Choreography
- The choreography describes the sequence and transition between business transactions that make up a
business collaboration.
- From a "top-down" modeling perspective, the business transactions are
re-usable (or "pluggable") components into collaborations – you could have a collaboration that mixes
RosettaNet business transactions with xCBL transactions
Choreography, Orchestration, and Workflow
- Choreography is also used in a more precise sense to distinguish different patterns of process control
- We use choreography where there is distributed coordination with equivalent responsibility or where we don't need to take a position on how the process is controlled
- In an orchestrated process, one of the two parties serves as the conductor or it is controlled by an intermediary (the "traffic cop" analogy)
- Workflow is a choreographed process that includes people as participants
"Staple Yourself to an Order"
"Staple Yourself to an Order" -- Organizational Responsibilities
"Staple Yourself to an Order" -- Cracks in the OMC
- What are the (horizontal) cracks described in the article and why do orders fall through them?
- What are the (vertical) knowledge gaps and why do they exist?
- What does it mean that "not all orders are created equal" and why does it matter?
- Why is it important to chart the OMC?
- How does the OMC pattern compare and contrast with the SCOR model?
- Why is it important to look at OMC priorities from customer's perspective?
"Innovation at the Speed of Information"
- Experimentation and innovation in product development is facilitated by information exchange between designers of different subsystems or components
- But if this "concurrent engineering" or "iterative design" isn't carefully managed, it can be inefficient and cause excessive rework and delays
- The "Design Structure Matrix" is a notation for analyzing and optimizing these iterative information flows
- We can add DSM to our Document Engineering "method toolkit" to help in modeling business processes
DSM Notation
- Processes/activities/tasks are the rows and columns of a square matrix
- The dependency or information flow relationships between any two processes i and j is indicated by the presence or absence of a mark in cells (i,j) and (j,i)
DSM Example - Planned and Unplanned Iterations
DSM Techniques for Improving Process Models [1]
- The overall goal is to reorder the rows or redefine the tasks to eliminate the Xs that were in the upper half matrix or at least to move them closer to the diagonal (this minimizes the number of tasks that are coupled in a cluster)
- Start by identifying the first and last tasks (these have no inputs and no outputs, respectively)
- Identify tasks that use information from the first task and determine if they are parallel, sequential, or coupled to each other
- Reorder the rows to create the smallest set of coupled tasks (the box in which planned iteration takes place)
DSM Techniques for Improving Process Models [2]
- Likewise, identify tasks that contribute information to the last task and determine if they are parallel, sequential, or coupled to each other
- IN ADDITION OR INSTEAD OF REARRANGING THE TASK ORDER, YOU CAN REARRANGE THE PEOPLE WHO DO THEM
- OR YOU CAN USE MODELING TOOLS THAT CAN PREDICT/SIMULATE DESIGN IMPACTS
Using DSM in the Document Engineering Methodology
A Revised Document Engineering Methodology
Assignment 5 - Modeling Processes
- Modeling the process of course registration
- Starting with narrative description:
- DSM analysis
- Sequence Diagram
- Transaction Worksheet(s)
- Due on Friday 30 March
Readings for 21 March
- Chapter 10 of Document Engineering
