1. plan for today's class

4. Business Patterns and Reuse

Bob Glushko ([email protected])

Document Engineering (IS 243) - 31 January 2005

1. Plan for Today's Class

l What is a pattern?

l Why businesses follow patterns

l The Model Matrix

l Integrating America / Why Care About Processes? / What's in a Name?

l A Tour of Pattern Resources

2. Patterns

l A Pattern is a model that is sufficiently general, adaptable, and worthy of imitation that it can be reused

¡ It must be general so that it can apply to a meaningfully large set of possible instances or contexts

¡ It must be adaptable because the instances or contexts to which it might apply will differ in details

¡ It must be worthy because the instances or contexts to which it might apply are supposed to benefit by following the pattern rather than being impaired

l Pattern is an overused and overloaded term. Many of you have some familiarity with Design Patterns in software engineering

l A pattern that is formalized and widely adopted can become an official or de facto standard

3. Modeling to Identify Patterns

l Models are also valuable design tools for identifying recurring patterns in both structures and processes

of 134. Business Patterns and Reuse

1/29/2005file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...

l Often these patterns are visible in the model but invisible in the concrete, real-world objects and functions that the model describes

l Once patterns are identified they assist in analysis by simplifying structures and processes as they replace low-level specific descriptions with more abstract ones

4. Patterns and Reuse

l In addition to improving designs (by replacing an ad hoc approach with a successful one) - patterns promote reuse

l Reuse has the immediate benefit of reduced implementation and maintenance costs

l Reuse has the longer term benefit of encouraging and reinforcing consistency and standardization

l Reuse at more abstract levels enables interoperability between systems that follow patterns that differ at more concrete levels

5. Why Businesses Follow Patterns

l At the most abstract level all businesses (or "enterprises," so that we can include governmental, educational, military, and non-profit "businesses") follow the same pattern

¡ They all demonstrate some purposeful and organized activity to sell or provide products and services, usually with a profit motive

l Businesses share common external influences, especially those in the same industry

l They also share common internal influences and goals

l Simply put, "Good business practice"' is a pattern – businesses are always striving to follow "reference models" and "best practices" for their industries

l Some resistance to using patterns arises from the need for a business to differentiate itself from competitors, but few companies have the market dominance or true innovations to divert from patterns in significant ways

6. Document Exchange is the Mother of All Patterns

l Document exchange is the "mother of all patterns" for business models, business processes, and business information



¡ Business model or organizational patterns: marketplace, auction, supply chain, build to order, drop shipment, vendor managed inventory, etc.

¡ Business process patterns: procurement, payment, shipment, reconciliation, etc.

¡ Business information patterns: catalog, purchase order, invoice, etc. and the components they contain for party, time, location, measurement, etc.

7. The Model Matrix

8. The Model Matrix: Examples



9. The Model Matrix: Navigation



10. The Model Matrix: 4 Modeling Approaches



11. A Unified View of Analysis and Modeling

l Document Engineering unifies four different disciplines or methods of analysis that until now have had little intersection

¡ Document-centric analysis – from text processing, publishing, hypertext systems

¡ Data-centric analysis – from database systems design, computer science

¡ Business process analysis – from business strategy, process design and re-engineering

¡ User task analysis – from application and user interface design; generalization of use cases from observation

12. Data/Document Driven {and,or,vs} Business Process Analysis

l Business process analysis begins with an abstract or broadly scoped perspective on business activities



l Emphasizes "Does this work from a business perspective?"

l Inherently a "top down" approach that starts with business models and processes and gets to the "document payloads" only at the end

l In contrast, the document analysis and data modeling approaches focus from the beginning on the structure and content of the "document payload" that will be exchanged – a "bottom up" approach that emphasizes "Does this work from a technical perspective?"

13. Meeting in the Middle

l We need to achieve both business and technical interoperability – the former is necessary but insufficient for the latter

l We need models of the desired business processes and the documents that they will produce and consume at the same level of detail and implementability

l This is represented in the Model Matrix as "meeting in the middle"

14. The Model Matrix: Yin & Yang of Documents & Processes



15. Modeling Documents {and,vs,or} Modeling Processes

l A document exchange consists of both the documents and the processes that produce and consume them

l By understanding the information in the documents, we learn what kinds of processes are possible

l By understanding the processes, we learn what kinds of information are needed

16. Two Perspectives on the Same Thing

l In the "generic application" information flows through a set of business processes and their associated document types

l A document-centric depiction focuses on the documents and de-emphasizes the processes as the transitions between document types

l A process-centric depiction de-emphasizes the documents and treats them as process inputs and outputs



l The fundamental difference is that the documents are visible to both parties as the inputs and outputs of the processes, but the processes are not themselves visible to the other side

17. The Model Matrix: The Document Engineering Approach

18. Integrating America

l A CIO's perspective on document engineering in the new Homeland Security Department.

l What are the four technical and organizational challenges in combining 22 agencies, hundreds of systems, and 170,000 employees?

19. What is Business Process Design and Why Should I Care?



l A process is an goal-oriented activity that takes specified inputs and adds value to the inputs

l The goals, inputs, and added value can be just about anything

l The output of one process can serve as the input to another process.

20. What's in a Name?

l "The expense of resolving ambiguous business terms over and over on a daily basis pales in comparison with the expense of NOT realizing that there is an ambiguity in the term"

l Farish's example: "Shipping Container"

¡ If one person thinks of a "shipping container" as being a cardboard box and another thinks of it as a semi-trailer, some interesting conversations about capacity can occur

¡ The latter concept can easily handle the idea that a "shipping container" can



contain many other kinds of "shipping containers" but the former obviously can't

21. Three Kinds of Names

l Farish recommends three "levels" of models (or names) that line up nicely with our three stages of analysis, design, and encoding

¡ Business names – a format that lets the requirement or semantics be easily readable and verifiable by a business person (not a modeling or XML expert)

¡ Logical names – a format optimized for the expression of the design or model; essential that they are expressive enough to reflect the relationships between model components

¡ Physical names – the format required by the implementation technology for the model; there may be length or character set constraints, sorting considerations, naming rules like the use of CamelCase for elements and lowerCamelCase for attributes

22. Some Pattern Resources

l Federal Enterprise Architecture Business Reference Model http://www.feapmo.gov/

l MIT Process Handbook http://process.mit.edu/

l RosettaNet http://www.rosettanet.org

¡ Intel a driving force

l Cover Pages http://xml.coverpages.org/

l United Nations Centre for Trade Facilitation and Electronic Business http://www.unece.org/trade/untdid/d04b/trmd/trmdi1.htm

¡ EDI Message Fragment

l XML Common Business Library http://www.xcbl.org

l Universal Business Language http://docs.oasis-open.org/ubl/cd-UBL-1.0

23. The Federal Enterprise Architecture Business Reference Model



l The US Government consists of a bewildering number of departments, agencies, programs, and other organizational entities that do not "interoperate" well because of legacy technology, processes, policies, and politics

l The FEA BRM is an ambitious attempt to improve how the US Government "does business" by taking a cross-agency perspective on products, services, and processes

l By identifying and reducing redundant capabilities, activities, and infrastructure, the government hopes to improve its delivery of products and services to its "customers" and more tightly link decisions about budgets and initiatives to measurable benefits

l While the content of the BRM is specific to the government, the ideas here are broadly applicable

24. FEA BRM "Architecture"

l The heart of the BRM is a set of 39 "lines of business"

l These are hierarchically organized in broad "business areas" that contain numerous "sub-functions"

l "Sub-functions" in "Public Asset Management"

¡ Cultural Archives and Artifacts

¡ Public Funds

¡ Public Facilities

¡ Public Records/Data Management

l "Subfunctions" in "Disaster Management"

¡ Disaster Monitoring and Prediction

¡ Disaster Preparedness/Planning

¡ Disaster Repair and Restore

¡ Emergency Response

25. The FEA BRM as the "Foundation Model"



l The BRM is being complemented by other reference models

l These models will be interlinked to help tie resource allocations to activities in ways that are measurable and to provide discipline to organization and process design

26. Readings for 2 February

l Document Engineering, Chapter 4 (through 4.1)

l Line 56 Business Ecosystem (http://www.line56.com/articles/ebiz_ecosys_index.asp)

l Principles of e-government architecture

l Supply Chain Operations Reference Model

l Evolution of B2B: Lessons from Auto Industry

