SE735 - Data and Document Representation & Processing

Lecture 5 - Describing What Businesses Do and How They Do It


Businesses and Patterns

·         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

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

·         They also share common internal influences and goals

·         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


Model and Pattern Abstraction and Granularity

·         Recurring patterns in structures or processes are visible in abstract models but invisible in the concrete, real-world objects and functions that the model describes

·         Models can also be expressed at different levels of granularity

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

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

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



Business Organization Patterns

·        Organization charts, facilities maps

·        "Organization of business unit" patterns

·         Business Models


Business Models

A business model

·         is the story of what a business does and how it makes money doing it

·         Who are the customers?

·         What do the customer’s value?

·         How does the business deliver this value to customers at a price they will pay and at a sustainable cost?

So the generic business model pattern has two parts:

·         Making something or preparing to deliver something that customers value

·         Finding the customer, transacting to create the sale or relationship, delivering the value



Types of Business Model Patterns

·        Classifications for measuring economic activity (e.g., NAICS)

·        Frameworks for understanding the adoption and impact of IT, migration to "self-service" or "web-based services"

·         Frameworks for understanding the financial performance of different kinds of economic activity



MIT "Business Model Archetypes"

·         Extensive research on business model and business processes has been conducted by Tom Malone and others at MIT Sloan School

·         An innovative part of this research program is empirical study of what businesses actually do and the relative performance or effectiveness of different business models

·         A fundamental challenge was how to classify business activity to support this kind of analysis

o   What is the business model -- what types of rights are being sold?

o   What kind of asset is involved?


Four Types of Business Models

·        Creators -- design what they sell

·        Distributors -- buys something from a creator and then sells it

·        "Landlords" -- sells the right to use, but not own some asset

·         Brokers -- match potential sellers and buyers


Four Types of Assets

·        Physical -- durable and nondurable goods

·        Financial -- cash, stocks, bonds, insurance

·        Intangible -- intellectual property, knowledge, goodwill, brand image

·         Human -- time and labor


Business Models X Assets: The Archtypes

This is interactive at

·         The table below shows a matrix of what rights are being sold by what asset is being sold.

o   This typology shows 16 possible models that we call Business Model Archetypes (BMA).

o   While all of the models are logically possible, some are not as common as others and at least two (Human Trader and Human Creator) are currently illegal or there are serious ethical issues.

·         Clicking on the type of right will bring you to the entry in the process handbook.

o   The bolded models have some examples in the handbook.

What is being sold?

Asset Type





Asset Right

Ownership–Significant Transformation (Creator)




Human Creator

Ownership–Limited Transformation


Financial Trader

Wholesaler/ Retailer

IP Trader

Human Distributor



Financial Landlord

Physical Landlord

Intellectual Landlord




Financial Broker

Physical Broker

IP Broker

HR Broker



What Businesses Do

Distribution of Business Model Archetypes

·         Percent = Percent of total sample revenue in Business Model Archetype

·         Number = Number of firms with any revenue in Business Model Archetype


What Business Models Are Most Profitable


"Component" Business Models

·        An emerging conceptual pattern of business organization "factors" what businesses do into modularized or specialized functions

·        "What components do" is defined in abstract, technology-independent terms so we don't have to care about the computer, operating system, or software application that performs the function

·        This level of abstraction reduces integration and communication costs between components and is the essence of service orientation

·         An emphasis on business model / business process / information exchange patterns facilities component reuse / reassembly into new combinations: virtual enterprises, composite services, etc.


The Federal Enterprise Architecture

·        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

·        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

·         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


The Federal Government -- "As-Is"



The Federal Government -- "To-Be"



"Reference Model"

·        A reference model is a special kind of model -- based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist

·        Typically a hierarchical and abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment.

·        A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations

·         It is generally NOT specific enough to build anything with


FEA Reference Models



FEA Business Reference Model



The Supply Chain

·         A supply chain is an aggregated and end-to-end view of the buy-side and sell-side relationships of an enterprise

·         A supply chain is the network of facilities and distribution capabilities an enterprise uses to:

o   "Source" (or "procure") raw materials (chemicals, ores, grains, ...) or components

o   Transform the materials or assemble the components into products

o   Deliver the products to customers (indirectly through distributors or stores or directly to the purchaser)


Supply Chain - Conceptual Model


Design Goals for Supply Chains

·         Especially for direct goods that are inputs to manufacturing processes, the things that businesses buy need to get to specified places at specified times in specified quantities according to manufacturing plans and sales forecasts.

o   The right stuff in the right amount at the right time in the right place

·         Get as close to zero inventory THAT YOU OWN without ever losing a sale or having to shut down the assembly line


Supply Chain Operations Reference Model (SCOR)

The Supply Chain Council

·         was established in 1996 to develop a standard process reference model for communicating supply-chain management practices across companies called SCOR that:

o   provides a common supply-chain framework with standard terminology

o   defines common metrics with associated benchmarks and best practices

o   serves as a common model for evaluating, positioning, and implementing

o   supply-chain application software

·         Put another way, SCOR is designed to provide discipline and advice to a firm trying to answer questions about its supply chain design


Process Reference Model in SCOR


The SCOR Model

·        Five essential supply chain processes (Plan, Source, Make, Deliver, Return)

·        Different supply chain models for different industries and partner configurations can be created from the same standard process vocabulary


SCOR Model Decomposition


The Build to Order Pattern

·        BTO is simple in concept, but complex in execution, requiring competencies in product design, process engineering, and supply chain management

·        Requires more modular design to enable configurability and concurrent assembly of sub-components

·        Often used in conjunction with "just-in-time" pattern whose goal is minimizing inventory by having suppliers deliver their raw materials or components to a manufacturing location "just in time" for them to be used

·         Building to order instead of forecast means a lot less inventory so the rapid obsolescence of components is less harmful


SCOR "Sourced Stocked Product"



What We Learn From SCOR

·         Every firm in a supply chain has the same problems to solve

·         Every process is a customer of the previous one and a supplier to the next

·         The model also distinguishes three patterns for "making" things: make-to-stock, make-to-order, engineer-to-order


Summary: Technical Requirements for Successful Supply Chain Collaboration

·        Can our systems exchange information?

·        Can our systems understand the information they get from each other?


Summary: Non-Technical Requirements for Successful Supply Chain Collaboration

·         Can our firms and people talk to each other?

·         Do we have a common vocabulary or reference model (like SCOR or RosettaNet) so we can understand each other's roles in the patterns we are trying to follow?

·         Do we have executive sponsorship that encourages us to talk with each other about how to be more efficient and effective in our supply chain?

·         Do we trust each other?


The Information Supply Chain

·        The flow of materials and goods in a supply chain is accompanied by information about it

·        But information about supply chain activities and processes is increasingly separated from the physical flow of materials and goods, and for information-based services there is no physical stuff

·        Information also flows in the opposite direction from the customer, retailers, and distributors back into the supply chain – this is also called the DEMAND CHAIN

·        The information supply chain has become especially important because increased global competition and better informed customers are forcing forms to shift from forecast to demand (i.e. customer) driven business models


Information Supply chain vs. Physical Supply Chain

·         Information can flow qualitatively faster than materials and goods, which might spend weeks in trucks, trains, or shipping containers moving around the world.

·         Information may flow in the opposite direction of the materials and goods, moving from customers and retailers back toward distributors, manufacturers, and their suppliers.

·         Information can go many places at once so that supply chain participants can know about inventories, locations, sales, and so on without having to witness them.


Design Issues for the Information Supply Chain

·        What information is exchanged?

·        Which entities in the supply chain are able to exchange information?

·        What is the frequency of this information exchange


"Document Automation" or STP Pattern

·        Many business processes can be described as "moving information around"

·        At each step information might be added to the input document or a new document might be created that contains most of the input document's content

·        However, even though the end-to-end process might span multiple departments (or companies), the business applications (run by separate departments) may not have been designed to share information with each other

·        Clerical functions can usually be totally automated

·        Processes carried out by knowledge workers can often be partially automated


Typical Characteristics of Document Automation Efforts

·        Create documents with templates or via guided assembly (aka "wizards")

·        Minimize manual intervention via rule-based routing, access control, exception handling

·        Concurrent process re-engineering

·        Documents are regenerated when source information changes

·        End-to-end perspective to maximize content reuse

·        Standard content components and processes


Buzzwords in the "Middle"

·        The Internet has been a disruptive force on many traditional business model patterns, particularly in the value chain activities of supply and demand chain management

·        Disintermediation – cut out the middleman

·        {re} Intermediation – introduce new middleman


Patterns in the "Middle"

·         Marketplaces and Auctions

·         Bring together sellers (or their catalogs)

·         Bring together buyers

·         Match buyers and sellers

·         Provide critical mass and infrastructure for other service providers



Marketplace - Physical Model


Istanbul’s Grand Bazaar


Marketplace - Conceptual Model

Glushko & McGrath's definition:

·         A "market maker" or "market operator"

·         Participating businesses

·         The services these businesses provide to each other

·       The messages and documents that are exchanged to request and perform the services


E-Business Architectures (Albrecht et al)


Rosetta Net

·         RosettaNet is a non-profit consortium aimed at establishing standard processes for the sharing of business information (B2B).

·         RosettaNet is a consortium of major Computer and Consumer Electronics, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards

·         The RosettaNet standard is based on XML and defines message guidelines, interfaces for business processes, and implementation frameworks for interactions between companies.

o   Mostly addressed is the supply chain area, but also manufacturing, product and material data and service processes are in scope.


Rosetta Net -- Three Level Hierarchy

To classify PIPs, RosettaNet divides the entire supply chain domain into clusters, segments, PIPs, activities, and actions.



Partner Interface Processes (PIP)

The following elements make up a PIP:

The following example represents an order management PIP: Rosetta Net -- PIP 3A4

1. Clusters 3: Order Management

1.1.1 Segment A: Quote and Order Entry

1.1.1 PIP 3A4: Manage Purchase Order Activity Create Purchase Order Action: Purchase Order Request

The following figure shows PIP interaction:



Document Automation and Straight Through Processing (STP)

·         A great deal of what businesses do involves abstract activities that can be described in terms of the movement of information

·         Sometimes the activities are so abstract that the only tangible things involved are artifacts that record the information.

·        These kinds of business processes follow the related patterns of document automation and straight through processing (STP).


Key characteristics or subgoals that define the STP pattern

·         They emphasize more efficient creation of the initial document or documents through the use of templates for different document types or guided assembly of a custom document from components.

·         They seek to minimize manual intervention as the documents flow from process to process by transforming information for reuse in different contexts and by using business rules to automate routing, access control, and exception handling.

·         They seek not just to automate existing processes, which would be akin to creating roads by paving cow paths, but to refine or reengineer them, possibly by adopting industry best practices or reference models.

·         They view documents as dynamic rather than static, automatically propagating changed information into the processing pipeline so that it is current and available when needed.

·         They take an end-to-end perspective that maximizes reuse and minimizes redundancy by extracting any sharable models or rules and making them available from a single logical repository.

·         They emphasize XML standards for information and process models because those standards facilitate the other five subgoals.


Document Interchange

The Context of Document Exchange


Electronic Data Interchange (EDI) and XMLification

·         EDI was developed to automate the exchange of structured information in transactional documents such as orders, invoices, and payments between business applications. Initially these exchanges took place over dedicated leased telephone lines or over private networks in a batch store-and-forward fashion

·         EDI took hold in the 1980s and 1990s and is widely used to automate routine document exchange transactions between established trading partners, especially in direct procurement and in the demand chains for CPG sector ("Consumer Packaged Goods")

·         The ANSI ASC X12 U.S. standards and Guidelines for Trade Data Interchange (GTDI) European standards began to emerge at this time, followed shortly by the ISO 9735 (UN/EDIFACT) standard developed by the United Nations to consolidate numerous national EDI standards

·         After XML's emergence in the late 1990s, many standards efforts have arisen to evolve document and process standards encoded in EDI syntaxes to XML

·         EDI isn't dead, but XMLification is inevitable because EDI's implementation and recurring costs are vastly higher than those for XML-based information systems


X12 EDI Message Fragment

ISA*00* *00* *08*JCPenny111 *ZZ*test22222 *971107*1220*U*00302*112240001*1*P*@






PER*OD*Chris Smith*EM*

PER*RE*Tom Gerry*TE*617-861-7900x1567




N1*EY*Chris Smith*92*csmith1

N2*Room 208C*SupplyWorks Corporate

N3*57 Bedford Street*Building 2



N1*SE*EC Office Supplies*1*98629321

N2*Purchase Department

N3*123 Main Street











EDIFACT Message Fragment



XML Message Fragment



<cbc:Note>this is an illustrative order line</cbc:Note>





<cbc:Quantity unitCode="KG">100</cbc:Quantity>

<cbc:LineExtensionAmount currencyID="GBP">100.00</cbc:LineExtensionAmount>

<cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount>


<cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount>

<cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity>



<cbc:Description>Acme beeswax</cbc:Description>












Why Encode A New Vocabulary in XML and Not EDI


(XML) Vocabularies

·        The most accessible information pattern resources are XML vocabularies (or "schemas" or "tag sets")

·        A vocabulary is a set of elements and attributes and the rules by which they combine

·        Linguists shudder at this definition because it conflates the vocabulary and the grammar

·        XML purists call these "applications" of XML but this conflicts with the more common usage of that word to mean "software application"


The Need for Controlled Vocabularies

·        There is no one good access term or name for most objects or concepts. The idea of an "obvious, "self-evident," or "natural" term is a myth

·        The words people use to describe things or concepts are "embodied" in their context and experiences... so they are often different or even "bad" with respect to the words used by others

·        What would "good" words be like?

·        Where would they come from?

·       How do you get people to use them?


Why XML Vocabularies Exist

Vocabularies must exist because:

·         There is no predefined set of tags

·         And since there is no predefined tag set, there can't be any predefined semantics

·         Semantics are defined in the schema and its documentation about what the elements and attributes mean

·         So using XML without a (documented) schema makes little sense


Why Vocabularies Are Desirable

Vocabularies are desirable

·        because people want to have a set of tags that is customized to their problem or industry so that they can take full advantage of XML

·        A good vocabulary represents a significant investment in defining a domain, identifying its key semantic components, and specifying the constraints and rules governing the combination and reuse of those components

·       A good vocabulary is a reference model for the domain that facilitates communication between enterprises operating within it


Vertical and Horizontal Vocabularies


·         Particular industry or vertical market

·         Detailed product semantics

·         Specialized process semantics

·         Sometimes called "domain-specific" languages



·         Concepts that are common to all (or a large number of) vocabularies



Creating Vertical XML Vocabularies – Worst Practices

·        Turn proprietary APIs into XML vocabularies by wrapping "<" and ">" around the names of methods that set and return values

·        Turn proprietary database schemas into XML vocabularies by wrapping "<" and ">" around the names that define the structure of a record or object

·        Turn existing EDI messages into XML by automated conversion, using the delimiters for segments, composites, and elements as "handles" for content


Creating Vertical XML Vocabularies – Better Practices

Turn existing EDI messages into XML

·         Analyze EDI messages to identify the "syntax-neutral" conceptual models they contain

·         Encode these conceptual models in XML

If no vocabulary exists:

·         Identify current and potential uses of the vocabulary

·         Analyze existing documents and information sources (with EDI, identify "syntax-neutral" models of message content)

·         Design conceptual models that satisfy the requirements in a feasible way

·         Encode the models in XML schemas


XML and Metcalfe's Law

·         The value of a language depends on how many people (or computers) understand it

·         How do you encourage and enable others to understand your language?

o   Standardization Approach 1: "Understand my language or I won't do business with you"

o   Standardization Approach 2: "Excuse me, here's my language, would you like to do business with me?"


Information Aggregations

·         Information aggregations occur where documents or data from numerous sources are brought together to create a consolidated information resource that is more valuable than the sum of the sources. 

o   In enterprise contexts this composite resource is typically called a data warehouse or data mart. 

·         An alternative approach is to create a virtual repository or virtual catalog in which the metadata from each source is aggregated into the composite resource, not the content itself.

·         Another information composition pattern is syndication, the consolidation and distribution of information products


Conceptual Views of Business Information

·         Conceptual views are more challenging to develop than physical ones

·         The ebXML initiative, launched in 1999 as a joint venture of EDI and XML standards organizations, was the first serious attempt to create conceptual views of business information that could be used in document implementation models in any syntax.

o   The resulting document exchanges would be interoperable because of their common semantic foundations called the core components

·         The Universal Business Language (UBL) effort began in late 2001 with the extremely ambitious goals of building on the ebXML core components, synthesizing the leading XML and EDI vocabularies for business, and creating standard business documents that would be nonproprietary and royalty free.


Views of Business Architecture


Physical Views of Business Architecture

·         A description of a system and its components as a physical model is a systems architecture.

·         A system’s architecture describes a business in terms of its computing platforms, operating systems, databases, and software applications.


Technology Platforms and Infrastructure

·         Sometimes the business architecture of an enterprise is characterized in terms of its dominant software architectures or technology suppliers; this is often called its platform.

·         Physical system architectures are often depicted using deployment diagrams that show the key information repositories (e.g. databases), computing resources (server farms), and dedicated communications links and networks needed to move data and documents around.


Integration Architectures and Patterns

·         Integration is defined as the controlled sharing of data and business processes between any connected applications or data sources Web Services

·         Integration approaches that depend on implementation details or other characteristics at the physical level are said to be tightly coupled.

·         Tight coupling is used to exchange data at high transaction rates

·         Loose coupling is necessary for integration across enterprise boundaries because interfaces might change


Web Services

·         A web service is defined as a platform-independent implementation of functionality that conforms to published specifications for:

o   the XML documents it sends and receives as its public interfaces (for example, the Web Service Description Language or the ebXML CPPP)

o   the messaging protocol used to send and receive XML documents through those interfaces (for example, SOAP or ebMS)

o   a searchable directory of services (for example, a UDDI or an ebXML Registry).

·         Because they can wrap a hodgepodge of legacy technologies and hide proprietary data models and protocols with XML document interfaces, web services provide a layer of abstraction and enable a more loosely-coupled integration approach than previous integration technologies.


Conceptual Views of Business Architecture

·         A logical architecture can portray the boundaries or interconnections among business systems and represent the extent to which systems are centralized or distributed within an enterprise.

·         Architectural patterns reflect different requirements for system communication or integration.

·         An architectural description can reveal the extent and direction of information exchanged between systems.

·         It can also identify systems that are isolated islands or silos of functionality because they can’t easily exchange information with other ones.

·         At the top of the conceptual model hierarchy are what IBM calls the Business Patterns, which describe at the most conceptual level the ways in which users and businesses interact with information.

·         There are four Business Patterns:

1.    Self-Service (also known as “user-to-business” or B2C)

2.    Collaboration (also known as “user-to-user” or C2C)

3.    Information Aggregation (also known as “user-to-data”)

4.    Extended Enterprise (also known as “business-to-business” or B2B).

·         These basic Business Patterns can be combined to create more complex patterns.


Conceptual Views of Integration Architecture

·         It is preferable for many of the participants in a business relationship to take a technology-independent and conceptual view of the integration architecture and focus on the more abstract goal of interoperability.

·         Interoperability means that the recipient can extract the required information from the sender’s document even if the sender’s implementation is not immediately compatible with the recipient’s business systems

·         Interoperability is a more abstract goal than integration


Service-Oriented Architectures

·         An abstract view of services in a business architecture that considers everything a business does as (potentially) realized by business service components that are combined and recombined as needed.

·         A SOA perspective drives a business to ask strategic questions like these as it systematically structures its business capabilities as self-contained resources or processes:

              What patterns of service combination are required to meet our business objectives?

              How can we design what each service does so that as a set they will be sufficient and flexible enough as business conditions change?

              Which of these services can we “carve out” of existing applications by changing their implementations or APIs?

              Which services should we build ourselves, and which should we obtain from others?

              Should we offer any of our services to other firms?