Automated Residency -- University's Requirements
Copyright 2006 Robert J. Glushko
Review of Assignment 6
Transaction patterns
Collaborations
"Staple Yourself to an Order"
"Myth of the Paperless Office"
Course projects
Requirements from the University's perspective
Requirements from the Student's perspective
Documents and other information sources
The most important concept in business process modeling – and the most overloaded one – is transaction
A business transaction is an atomic unit of work in a trading or commercial relationship between two parties
A business transaction is conducted between two parties 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
Transport errors
Envelope/messaging errors
Security errors
Document/business errors
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)
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
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 describe typical ways that business documents are exchanged:
Offer-Acceptance (Commercial Transaction)
Request-Response
Request-Confirm
Query-Response
Notification
Information Distribution
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
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
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
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
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
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.
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
The set of transactions have meaningful (having business significance) and necessary (the "need to know" principle) semantic overlap with each other
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 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
If "OMCs differ from industry to industry and are different for products and services" then what's the point of this paper? What lessons transcend industries and span the product/service divide?
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?
What were DanTech's motives for going paperless?
What are the costs and benefits of co-locating people and the documents they create and use?
How might a paperless office change the cost/benefit tradeoffs?
What DanTech document types most easily became paperless? What document types resisted becoming paperless? What principles determine this?
What happens to legacy information in the transition to a paperless office?
How did DanTech hope to handle naming and classification of new documents? Why did the initial approach fail? Did the revised approach work any better?
What were the benefits to DanTech of going (almost) paperless?
What were UKCom's motives for going paperless?
What UKCom document types most easily became paperless? What document types resisted becoming paperless?
How did improved information access by Account Managers improve their processes? Why did they not reciprocate by sharing information with Bids and Sales?
What's the key lesson to learn from UKCom's experience?
Does everyone have a project?
Has every project heard from me? Have we negotiated?
Reminder - Project Status Report 1 on 5 April (Wednesday after returning from spring break). Each team will make a brief presentation (5 minutes) of its work to date, which might include some prioritized requirements, some review of articles, some initial process models, or interviews with at least one "animate" source
Chapter 10 of Document Engineering
pages 501-504 of Chapter 14