17. Business Process Analysis (2)
DE + IA (INFO 243) - 14 March 2007
Bob Glushko
Plan for Today's Class
- Process Patterns at Different Levels in the "Abstraction Hierarchy"
- Control and Logic Patterns
- Transaction Patterns
- Business Signals
The Abstraction Hierarchy in Process Models
- We can model processes at an organizational level from the perspective of the nature and pattern of "value exchanges" between an enterprise and its suppliers, customers, and other entities in its "value chain"
- A group of interconnected or choreographed transactions as a construct in a process model is what we most often mean by "business process"
- Documents and processes are at the same abstraction level when we focus on business transactions -- this is the level of the RosettaNet PIPs and UBL
- Process models have little abstraction when we want to specify every detail of control and decision logic needed in an implementation
The Abstraction Gap in Process Models
- An abstract / coarse / strategic / goal-oriented view of processes is the top-down perspective from senior management
- The granular / transactional / implementation view is bottom-up, less likely to be technology-independent, and naturally emerges from operational personnel as they describe the processes and documents they work with
- We need to close this gap to get a complete, balanced, and actionable view of the processes
- So there seems to be consensus that we need an intermediate level of process description that is more abstract than "transaction" and less abstract than "value chain"
Control and Logic Patterns
Inefficiency in Sequence Pattern
Removing Inefficiency with Parallelism
Allowing for an Unconditional Activity
Merging Conditional Process Branches
Conditional Parallelism with Synchronized Merge
Poor Process Design Allows "Upstream" Cycles
Business "Transaction"
- A more abstract and a far more important perspective in process modeling is to describe processes at the level of the transaction
- A business transaction is an atomic unit of work in a trading or commercial relationship between two parties or services
- A business transaction is conducted between two parties or services playing the requesting
and responding roles
- There is always a requesting business document and optionally a responding
business document depending on whether the transaction semantics are one-way
or two-way
Sequence Diagram for "Submit Event" Transactions
Activity Diagram for "Submit Event"
Business "Transaction" (2)
- At the "business" level, a transaction either succeeds or fails.
- If it succeeds it may imply a legally binding contract or obligation
between the parties participating in the transaction or otherwise govern their collaborating activities
- If the business transaction fails each partner must relinquish any mutual claim that would have been established by a
successful transaction
- Business transactions cannot be "rolled back" but the obligations established by a successful transaction can
sometimes be undone by a compensating transaction
- The time scale for a business transaction can range from seconds to days, weeks, or longer
(One Parenthetical Slide : Database "Transaction" )
- A transaction is a group of statements or instructions to a database whose changes can be made permanent or undone only as a unit
- Transactions provide a simple model of success or failure – a transaction either commits (all its actions happen) or
it aborts (all its pending actions are undone). This all-or-nothing quality makes for a simple programming model
- A transaction can be "rolled back" in the same unit with which it was committed to undo all of its effects and
return the database to a prior state
- The time scale for a database transaction is measured in fractions of a second
Document or "Business level" Errors
- The document is invalid with respect to its schema
- The document is valid according to its schema but some content doesn't conform to rules that aren't expressable in the schema
- The document conforms to its schema, but additional information is needed to initiate the receiving process or service
- The document was OK but additional information was sent that wasn't expected
- The document contains inconsistent information; eg. sum of line item amounts doesn't agree with order total
- Everything in the document is valid and conforms to business rules... but its information is inconsistent with information the recipient already has
What ELSE Can Go Wrong in a Document Exchange?
- When we analyze processes at a transactional level we identify the success and failure in terms of business events, but there's way more nuance to it than that
- Before we go on with our discussion of the "conceptual" or "abstract" idea of what a transaction is, we will briefly mention other things that can go wrong:
- Transport errors
- Envelope/messaging errors
- Security errors
Modeling Transactions with Worksheets
- A model of a transaction can be recorded as an artifact as a diagram, an XML instance, or as a "worksheet" that simply lists the information components in the metamodel of the transaction
- You can tailor the modeling approach
by customizing the worksheet to fit your or your client's methodology
- Using worksheets to capture information lets the analyst capture "fragments" of the metamodel whenever they arise or are discovered
- This is a less prescriptive and more user-friendly approach than the other notations, which require more information to be "well-formed"
BTV Worksheet for "Submit Event"
Business Transaction Patterns – Exercise
- A) Where can I buy a notebook computer?
- B) Here's my catalog of notebook computers.
- A) I'd like to order this one.
- B) OK.
- B) And here's your invoice.
- A) OK.
- A) When will the computer arrive?
- B) By next Tuesday.
- B) Here's my complete catalog, in case you're interested in other products besides notebook computers.
Business Transaction Patterns
- Business Transaction Patterns describe typical ways that
business documents are exchanged:
- Offer-Acceptance (Commercial Transaction)
- Request-Response
- Request-Confirm
- Query-Response
- Notification
- Information Distribution
Offer-Acceptance (Commercial Transaction) Pattern (1)
Offer-Acceptance (Commercial Transaction) Pattern (2)
- This is the common "offer and acceptance" or "contract formation" pattern
- The standard and simplest example is "Place Order"
- The party making the offer "exposes itself to the imposition of legal liability by another" if the offer is accepted
- The accepting party must send an acknowledgment when it determines that the offer document passes the "business acceptance" test (this is often an "Order Response")
- Because of this legal exposure and the time it may take for the recipient to decide on the offer, the recipient might send receipt and confirmation signals
- The offer and the acceptance are "non-repudiable" – the party making the offer guarantees that the offer came from it (typically done with signatures) and the party accepting it guarantees that the acceptance came from it
Request-Response Pattern (1)
Request-Response Pattern (2)
- This pattern is used to model the situation where one party makes a request for information when the responding party has to apply some business logic to answer, because it may be dependent on the identity of the party making the query or because it needs to be dynamically generated
- Typical examples are "Request Quote" or "Check Inventory"
- This transaction might require non-repudiation on the responder's part
- The response doesn't create any obligations for the responding party
Request-Confirm Pattern (1)
Request-Confirm Pattern (2)
- This pattern is used to model the situation where one party requests confirmation about a previously established contract or obligation
- It might be used to get status information or obtain authorization
- A typical example is "Request Order Status"
- This transaction will typically need non-repudiation on the responder's part
Query-Response Pattern (1)
Query-Response Pattern (2)
- This pattern is used to model the situation where one party makes a request for information that the responding party already has, that is static (or slow-changing) and that isn't dependent on the identity of the party making the query
- A typical example is "Request Catalog"
- The response consists of a collection of results, each of which meets the constraints specified in the query
- Usually no receipt or confirmation signals
- And usually no non-repudiation requirement
Notification Pattern (2)
- This pattern is used to model a formal information exchange
- The standard example is "Notify of Invoice"
- It has non-repudiation requirements for the sender
- The recipient should respond with a receipt business signal
- It is like the Commercial Transaction pattern but there is no business response document
Information Distribution Pattern (1)
Information Distribution Pattern (2)
- This pattern is used to model an informal information exchange
- A typical example is "Publish Catalog"
- This transaction will typically not use non-repudiation
- It is similar to Query-Response but without a responding business document.
Readings for 19 March
- Chapter 15, pages 501-504 of Document Engineering
- "Staple yourself to an order"
- "Innovation at the Speed of Information"
