Variations on Concepts

strict warning: Only variables should be passed by reference in /home/enterpri/public_html/modules/book/book.module on line 560.

What we have organized here is a very generic architecture of concepts of relevance to the development of information systems for business.  As  the old saying goes, however, “the devil is in the details”.  In order for this architectural approach to be useful in practice, we need to be able to organize and depict the complete set of details relevant to the business or class of businesses being supported by the IT system.  This is the business equivalent of commonality and variability among IT systems, which itself is partly driven by “differences between the requirements and/or existing solutions across the customer set” for a solution to be created or deployed.[12]

A work product-based methodology is the way to introduce variability and details into the common structure that is represented by our generic business concepts.  We will briefly discuss a set of possible business modeling work products that can be used to articulate the needed levels of detail and variability.

The front-end into a set of business modeling work products is the terminology used by a particular business or class of businesses being studied.  The classified business terms work product consists of two things: a classification structure of generic business concepts, and a set of terms that are actually used by the business people in the particular business entity or organization under consideration.  The classification scheme is simply an expansion of the generic classifications we’ve already been discussing here.  The business terms of interest can be discovered by interviewing business people or analyzing key documents from the business domain of interest.  The terms are classified and grouped according to the more generic business concepts.  This provides the foundation and much of the material for many other business modeling and system development work products.[13]

Classified business terms help to focus our attention on the detailed instance of all of the concepts in our framework.  The most common terms to be found in business documentation apply to the concepts of resources, outcomes, behavior, functions, role-players, and locations.  It is also possible to find specific instances of situations and situational factors, purposes, and commitments.

To focus attention on these last three concepts, and to foster the work of articulating them, a work product such as a to-be business goals list can be used.  This kind of work product is a specific way of discussing purposes and commitments that are driven by the business situation.  This is exactly the set of factors that drives and justifies the investment in IT solution development and deployment.

A business context diagram is a graphic depiction of relationships among business role-players.  From the point of view of the business area being studied, it shows external relationships with businesses and individuals in the marketplace.  It can also show relationships among various internal business role-players.  The diagram consists of a simple notation with labeled circles standing for business role-players, and labeled arrows that indicate the type and direction of business interactions.  Business role-players are generally organizations, including corporations, divisions, departments, etc.  They can also be potential organizations (business functions, as we’ve discussed), when modeling a generic situation, or a possible future situation.

In addition to role-players, the context diagram helps us to understand more about business locations, functions, behavior and outcomes.

A business process model is a set of process flow diagrams.  Process models explore the ordering of tasks or activities that accomplish business goals, and that satisfy commitments between external actors and internal agents.  The common denominator for almost all process models is that a set of roles or organizations are defined, discrete units of activity, or tasks, are assigned to these roles, and the flow of activity from one task to another is indicated.  The most common way of depicting these elements of the process model is a linear flow of activity that moves generally from left to right.  This notation is often called “swim lane” notation, because of its resemblance to the racing lines painted on the bottom of a swimming pool.  Each of the horizontal areas that cut across the page corresponds to a role, played either by an organization or employee.

The business process model can be easily built based on verbs discovered during the classification of business terms.  Verbs denoting business behavior can be characterized in a number of ways, which all have an impact on the types of information system support that should be built into IT solutions.  The following are a few especially interesting dimensions of this characterization:

  • The duration of the behavior: sub-second, minutes, hours, days, years, etc.
  • Whether the behavior is boundary crossing (selling, advertising, emitting).
  • If there are things of interest to the business, then we can be sure that there are verbs that relate to how the business:  invents those things, creates those things, creates templates for those things, and classifies those things.
  • Pairings and groupings of behavior.  If we find one verb in any of these groups, we can anticipate that the others are lurking out there to be found as well.  Groups of verbs include: suggest / exhort  / persuade / coerce, reduce / increase, propose / approve, separate / combine, begin / accelerate // decelerate / halt, permit / forbid, ask / grant, store / retrieve, and borrow / loan // buy / sell.
  • Many actions can be decomposed into more granular, behavior.  For instance a transaction can be decomposed into: alert, identification, authentication, fact finding, determine availability, negotiation, agree, record agreement, record state changes (inventory ...), fulfill, settle, and conclude the transaction.
  • Another common business behavior is the decision process.  Decisions are the point where we can determine the value of information, and the cost and benefit tradeoffs in the work of capturing information to reduce uncertainty to the point where decisions can be made.  This is high leverage for the process of justifying information systems development.  In general the business wants the decision process to become more automatic (like the automaticity that takes place as human beings repeat learned tasks).  Some decisions will never be part of a standardized, repetitious process, but are part of a more open-ended “course of action”, or even initiate such a course of action.  The business also needs to be able to change the decision-making parameters as conditions change in the market.  If this is done well it can be a point of flexibility for information system support.  A typical decision protocol includes: recognize decision situation, gather data, analyze data, evaluate analysis, make decision, record decision, communicate decision.
  • Even the behavior of innovation (which is more like a course of action than a deterministic, formal process) has such recognizable parts as: explore, conceive, demonstrate, and implement.

Business commitments and many other facets of the business are subject to business rules.  Many policies of the business are explicitly stated in documents.  Others are already encoded in application software.  Still others are implicit, or are part of the tacit knowledge base of common practice.  The rules that a business lives by form the heart of the application software that is needed by that business, which is built largely to enforce those rules.  The purpose of an explicit business rules catalog is to create an external representation of these rules so that business people can validate them and developers can use them as well-defined input into the process of building software.

Finally, a useful modeling technique that helps to transition from a business system view to the IT system view is the business object model. The business object model is the work product that brings structure and behavior together, where structure and behavior may have been separated in other work products.  It is a bridging work product that articulates business concerns in a way that is similar to the way software developers think, while still retaining a purely business content.  It is a consolidation of what we know about the area of business concern expressed in terms of objects, attributes and responsibilities.
By the time we get to business object models we are generally working with the concepts of resources, role-players, outcomes, and to some extent locations behavior and functions.  We have left behind business purposes and the situations that are driving them.  For that reason, and to assure that we stay within the justification for the IT solution work, it is good practice to maintain traceability matrices for the various work products of business modeling, and the downstream work products that address requirements analysis and design.