14. Models of Business Architecture; Requirements and Context
DE + IA (INFO 243) - 5 March 2007
Bob Glushko
Plan for Today's Class
- Assignments and Project Schedules
- How Models and Patterns Evolve
- Requirements and Context
Remaining Graded Assignments
- Assignment 3, Business patterns (due 3/2)
- Assignment 4, Requirements and Source Inventory (assigned 3/7, due 3/16)
- Assignment 5, Business Process Analysis (assigned 3/14, due 3/23)
- Assignment 6, Document Analysis (assigned 4/9, due 4/21)
Course Project
- The Individual assignments teach separate skills that you'll bring together in a 2-3 person team project
- You can work alone if you have a very compelling justification but I don't recommend this
- Find something that turns you on... it might be a DE+IA slant on something you're already working on or about some news article
- 40% of final grade
- For I-School 2008ers, could be incubator for MIMS project (or summer internship, or 2007-8 GSR appt.)
Course Project Key Dates
- (ungraded) Project Proposal, due 3/19
- (ungraded) 1-page Project Status Report (and short presentation), week of 4/9
- (ungraded) 1-page Project Status Report (and short presentation), week of 4/23
- (graded) Final deliverables/report due 5/4
- (graded) Final presentation 5/7
The Big Ideas of Chapter 5 (and of the Information-Powered Economy)
- Business architectures co-evolve with technology
- Information technology has radically changed the structure of firms
- Information about goods becomes a good (or a service?)
- Business models are shifting from forecast/schedule-driven to demand/event-driven
- Business relationships/architectures shifting from tightly to loosely coupled
- Business models are shifting from proprietary to standard models with reusable components
Co-evolution of Business Models and Enabling Technologies
- Business patterns are continuously evolving, mostly as a result of changes in information and communications technology
- Businesses don't just select a pattern and follow it; they may have to adapt a pattern or change to a different pattern to succeed
- "... achieving the Digital Business Transformation is a journey, not a consulting project or a one-time improvement initiative"
- New technologies
pose predictable problems for the business models of incumbents (as opposed to new firms) in an industry
- What are the internal or external signs that an enterprise should consider new technology?
From Hierarchical to Network Forms
- The traditional industrial corporation of the mid-to-late 20th century was large, vertically integrated, and hierarchically organized
- Today IBM, Cisco and other large firms are repositioning themselves as comprehensive "service networks"
- Competition is increasingly between entire supply chains or ecosystems, not just between firms
- The command-and-control model is being replaced with open, shared communications
"The Nature of the Firm" – Ronald Coase (1937)
- Why do firms exist at all? Why does an entrepreneur hire people instead of "renting" them in the marketplace?
- A transaction costs analysis says that firms are created when hierarchical coordination of internal processes is more efficient than carrying out the same processes externally "in the market"
- So a firm grows until internal and external costs are the same
"Transaction Costs"
- Search – Discovery of potential business partners
- Information Analysis – Determining what products and services are offered and whether the partner is appropriate on other dimensions
- Bargaining – Proposing the terms of a business relationship
- Decision-making – Agreeing on the terms and ensuring their fit with other business processes
- Monitoring – Ensuring that the terms and conditions are being met
- Enforcement – Taking corrective action if they are not
- Note that what one firm views as its transaction costs another firm may view as "how we make money"
Transaction Costs and New Technologies
- New technologies (e.g. telephone, mainframe computer) reduce coordination costs
so firms can get bigger...
- Vertical integration also reduces all of these costs and firms grow bigger...
- But if new technologies reduce the external costs proportionally more than internal costs then Coase gets turned on his head and firms get smaller
- As communication, coordination, and monitoring costs decline because of new technology and more organizational autonomy it becomes possible to outsource non-essential functions
- And makes it cheaper to work with new business partners on shorter term, more ad hoc
relationships
- New possibilities for disintermediation and reintermediation are created as value chains get more decomposable and granular
- Technical standards for product description and document exchange can also be seen as enabling technology that reduces transaction costs
Information About Goods Becomes a Good
- Information about the supply chain is taking on independent value
- Information about where products are, who uses them, and when and how they are used can be worth more than the products themselves
- Information supply chains can be created in any industry
Toward On Demand/Event-Driven Business Models
- No forecast can ever be as accurate as actual sales and demand information
- The key to supply chain optimization isn't moving things faster according to plans, it is moving things smarter according to actual demand
Tight Coupling
- Pre-Internet era application architectures used "tight coupling" to support the exchange of information in completely automated and processable ways
- Tightly-coupled applications used detailed knowledge about the implementation (the record, file, or table structure) or use fine-grained APIs to send information to the "other side"
- This makes sense within an enterprise or when you can control both ends of the exchange because then you can take advantage of the performance benefits of tight coupling
- EDI's "coarse-grained" document architecture was supposed to remedy this, but the difficult EDI syntaxes encouraged "optimized" document models that were tightly-coupled in practice
Document- or Service-Oriented Integration
- Internet protocols and XML are enabling "loosely coupled" architectures and "coarse-grained" information exchanges that make far fewer (or no) assumptions about the implementation on the "other side"
- When integration is done with loose coupling, the two sides can make (some) changes to their implementations without affecting the other
- This is even more true when they communicate through an "integration hub" which can further abstract their implementation by doing transport protocol/envelope/syntax translation for them
- The particular integration technology for loose coupling is less important than the philosophy or business model that
requires it – treating different organizations, applications, and devices as loosely-coupled cooperating entities
regardless of where they fit within or across enterprise boundaries
Web Services {and,vs} Service Oriented Architecture
- Web services are an important physical architectural idea and a set of standards and techniques for loose coupling
- Service Oriented Architecture is a conceptual architectural perspective and design philosophy for loose coupling
- MBAs and CIOs talk about SOAs, software architects and developers talk about web services
E-Government Architecture in Ireland
Principles of E-Government Architecture
- What are some of the ways in which public sector concerns and priorities differ from those of commerical enterprises?
- How do these differences influence architectural decisions in e-government?
- It has been said that "most software business models are based on lock-in" -- why is this a concern for governments?
- Why are many governments endorsing XML?
Setting the Context
- Any Document Engineering project worth doing will involve some set of document types and information components that take part in some set of business processes
- Because "no document (or process) is an island" there will always be some point at which the documents and processes you care about will intersect or overlap with some that that you don't care about
- We'll call the Context whatever characteristics of the situation that define what is in or out of scope, inside or outside of the boundary in which our solution has to work
Patterns as Requirement Clusters
Context and Selecting Patterns
- Much of what businesses do for themselves and with other businesses can be described using a small repertoire of supply chain or other business process / transaction patterns
- Each of these patterns implies a set of documents and some choreographies of document exchanges
- Selecting an appropriate pattern will help expose the information requirements, rules and constraints for our subsequent document analysis and design
- Choosing a pattern suggests which document payloads we'll need to find or design and in which business processes we are likely to deploy them
- How we describe context influences what patterns we identify and how we apply them
Business Process is the Most Important Context Dimension
- Business processes are the most important context dimensions because they most strongly shape the information requirements
- For example, contextualizing a simple procurement pattern to have the seller and buyer in different countries adds new processes and documents
Other Context Dimensions
- Product Classification
- Industry Classification
- Geopolitical Classification
- Legal or Regulatory Jurisdiction
- Business Process Role or Supporting Role
Representing Context in Document Architecture
What Are Requirements?
- Once a problem or opportunity is defined, any constraints on possible solutions
or goals that must be satisfied can be viewed as requirements:
conditions that must be met for
the solution to be acceptable
- Requirements are most often functional: descriptions of what the
solution must do or must enable someone to do with it
- Requirements can be quantitative or qualitative, but in all cases should be
verifiable
- Requirements do not dictate how the solution is to be achieved – that is the
responsibility of design
Rigorous Requirements Processes are Document-Intensive
- Occasionally requirements are developed in an extremely rigorous way
- Large companies or organizations (example: government, military, General Motors) may
conduct a "contract definition phase" or issue a "Request for Information" (RFI) document in which they engage multiple companies or consultants
to define a problem and come up with some preliminary solution or design concepts
- These requirements may be heavily constrained by legacy technology or processes unique to the customer, which implies that an "engineered to order" solution is required rather than a standard "off the shelf" one
- The best ideas then get turned into a "contract specification"
or a "Request for Quote" (RFQ) document and companies (usually including those that contributed to it)
compete for the right to build the system or supply the goods according to the specification.
A More Typical Requirements Process
- Most companies carry out IT planning activities (in software companies
these are called "product management" or "product marketing" activities)
to define requirements for systems
or applications
- The results of this activity are recorded in a "Product Requirements Document" or PRD
- These requirements are then negotiated with the organization that will design and develop them
(engineering or other R&D organization)
- Even if what ultimately gets built is less ambitious than what marketing wanted,
the requirements specifications can provide a
roadmap for future versions or products
When There Isn't A Requirements Process There Are No Documents
- Some companies – especially new or undisciplined ones
– don't bother with requirements
- Many people want to "get on with it" and are biased toward working
on the "end product" (doing the programming or implementation
activity) rather than working on less tangible
intermediate artifacts (like those produced by requirements, analysis, and design
activities)
- So they don't specify requirements in any rigorous way and no models of information or process are created
- However, products or systems built in such an ad hoc manner tend to be difficult
to modify when the true requirements become known. And despite what people say they will do, such prototypes are almost never "thrown away" but instead are hacked until they evolve into the "real" product.
- Not saying that "prototyping is bad" but "model-guided prototyping" is a lot better
Document Engineering Requirements and System Requirements
- Document Engineering focuses on the requirements for information and process models and by their computer-processable implementations
- Requirements for the associated software applications are obviously important, but Document Engineering has nothing special to say about them
- But a successful project must also satisfy the latter!
Sources of (Information) Requirements in Document-Intensive Contexts
- Many of the information requirements in document-intensive contexts are contained in existing documents
- There is no sharp line dividing "requirements analysis," in which we get requirements from people, and "document analysis," in which we obtain them from documents.
- But it is easier to explain the latter if we begin by discussing the former, treating them as separate activities
Generic Requirements in Document-Intensive Environments [1]
- Automated information capture -- Eliminate manual entry (or reentry) of information when documents are created, reusing as much as possible from other documents or sources.
- Straight-through processing -- Minimize the need for any human intervention as a document flows through some specified processes.
- Timeliness -- Make information available to those who need it when it is needed and when promised, and update it promptly when it changes.
- Accuracy -- Ensure that every piece of information in a document is correct.
- Completeness -- Ensure that a document contains all the information it should or that its recipient (person or application) expects.
- Automated validation -- Provide a schema or specification that enables information to be validated.
Generic Requirements in Document-Intensive Environments [2]
- Interoperability -- Enable information to be used "as is" or via automated transformation by systems or applications other than the one that created it.
- Standards compliance -- Conform to regulations or standards for information structure, accessibility, availability, security, and privacy.
- Customizability -- Facilitate the internationalization, localization, and subsetting of information.
- Usability-- Present information in a format or medium that is easy to use and understand by its intended users.
- Identifiability -- Ensure that the design or appearance of a document signals that it comes from our organization or company; also called branding of the information.
People Who Can Help Identify Requirements
- Users (there may be multiple classes of users)
- Customer
- Subject matter experts
- Consultants
- Technical gatekeeper
- Executive project sponsor (funding sponsor)
- "Product visionary"
- Marketing and sales people who talk with customers
The Primary Role of the Requirements Analyst is to Listen
- "Seek first to understand, then to be understood"
- In "Design for Success" (Bill Rouse [Wiley, 1991]) this is called the "naturalist" phase
- A "naturalist" or "anthropologist" studies people or phenomena in their
natural surroundings
- observes and listens but does not try to influence
- ...
- We also need to take an archaeologist's perspective to discover requirements, but we'll defer that to "Document Analysis"
Sometimes You Go Back to Square One
- Most people concede that the "naturalist" perspective is needed if you're designing a
new system or a new product (or a new document)
- But others will argue that once something exists, upgrades or new versions
of it can be designed without a new requirements activity
- In "document-intensive" processes (especially those where the documents are paper ones) it is seductively easy to define a requirement of "replacing paper forms with online ones" while otherwise leaving the basic processes the same
- Going back to "square one" is desirable, if only to validate existing requirements
The Secondary Role of the Requirements Analyst is to Clarify
- If you did your job well in the naturalist phase,
you can test your understanding of the requirements by conceptualizing alternative
ways to satisfy them and trying to "sell" these to the people giving you the requirements
- Rouse calls this the "marketing" phase
- Testing your understanding means you won't end up "blaming the victim" for not
expressing requirements correctly
- Get people's impression of whether your approach would meet the need in an
acceptable and usable way
The Final Role of the Requirements Analyst is to Communicate
- The analyst is the "communication middleman"
between the customer and the developer (Wiegers) [and often between
different types of customer stakeholders]
- The analyst translates technical language into business language
and vice versa
- An intermediary is necessary because the customer
and developer speak different languages
- So the analyst needs to be able to speak the language of both the customer and the developer
Requirements Categories in Document-Intensive Contexts
- Solution requirements – the functional, performance, quality attributes
- Information or data requirements – what information is needed, what are its
datatypes, possible values – the document component model
- Document or structure requirements – how is the information organized / assembled / packaged into
sets of related information – the document assembly model
- Processing and usage requirements – what relationships between documents have
a business purpose, what constraints on access or presentation (or on the relationship
between logical and presentation models) are mandated by business relationships – process / choreography / orchestration model or adjuncts to document models
- Presentation or syntactic requirements – how is the information
presented or formatted or rendered – the
physical or output model
YART from Chapter 8 of Document Engineering
- Rules that Apply to Conceptual Models
- Rules that (Can Also) Apply to Physical Models
- Syntactic
- Processing
- Presentational
- Rules that Apply to Instances or Implementations
Requirements in the Model Matrix
Context Dimensions x Rule Types
Readings for 7 March - Document / Information Source Inventory
- Chapter 11 of Document Engineering
- Chapter 16 of Document Engineering,
540-554 (Capability Assessment)
- The Myth of the Paperless Office (2002). "Two Case Studies (pages 33-49)"
