Systems Journal "A Standard for Business Architecture Description" - 1999

This is an experiment with deconstructing an existing article while reconstructing it in more of a linked-up web-like form.


The full pre-publication article is downloadable here.

The published version is available here for a fee to IBM.

Context of article

This article is one of a series published together in a special issue of the IBM Systems Journal. It focuses on the business concepts that underlie IT systems, as shown on the following roadmap for the series:

The full article is downloadable from here.



A complete architectural specification of an IT system includes information about how it is partitioned and how the parts are interrelated. It also contains information about what it should do and the purpose it must serve in the business. This article provides a set of business concepts that partition the world of business meaning. It discusses the purpose of such an architectural view of business, and ways that it can be used. A set of generic concepts and their interrelationships organize business information content In terms of requirements on the business, the boundary of the business, and the business as a system for delivery of value. Methods are introduced to explore variations on the basic business concept patterns. These concepts are positioned to describe IT systems that support the business, and they are used to manage the work of IT system development and deployment.


Business today is inextricably intertwined with information system technology.  From the smallest home office business supported by a shrink-wrap business suite, to the multinational corporation with multiple monolithic legacy applications, it is impossible to be in business today without confronting the issues of supporting the business with software.  The articles in this issue of IBM Systems Journal are based on the premise that a set of interlocking semantic frameworks are necessary in order to understand and create the software solutions for the enterprise of today and the future.
The Enterprise Solution Structure (ESS) project is IBM’s response to this challenge.  As indicated in the introductory article to this issue[1], ESS has provided substantial experience in real world engagements, based on lessons learned from a number of previous projects.  This has led to a refined set of technical reference architectures and solution customization techniques.  The success of this undertaking is based on standard architectural principles and semantics, starting with an understanding of how business issues drive information systems requirements, as shown in Figure 1.  The figure shows that a set of standard business concepts can organize the particular knowledge about a any given enterprise.  This organized business knowledge gives rise to requirements for enterprise information systems.  These requirements can be satisfied in two general ways: one by the traditional custom development approach, and the other by matching patterns of requirements to patterns of existing assets.  Both of these approaches lead to the development of enterprise solutions, but the ability to reuse existing assets provides major economies.

This article is a contribution to the discussion of appropriate business concepts for organizing enterprise knowledge.  It provides a set of standard business concepts, and guidance as to how to use them to instantiate organized knowledge about specific enterprises.  This is a high-level semantic framework which has been developed over a considerable length of time.  The concepts that are presented here have been abstracted from experience with many specific enterprise business models, various IBM generic industry reference models, and several years of experience in organizing business terminology for specific businesses.  The ESS project has produced several versions of a business meta-language, and this article represents the current state of this work.


This article is organized into the following sections:

  • Purpose of a business system architecture - This section discusses the purpose of an architectural view of business and how it is used.  It also defines what is meant by a business system architecture in the context of an overall architecture semantic framework, as well as criteria for inclusion of a concept in this particular document.
  • Business concepts - A set of generic concepts and their interrelationships organized into the following three sections.
    • Requirements on the business - The set of concepts that represent relationships of the business to the world at large, which impose requirements on it as a business system.
    • Boundary of the business - The set of concepts that deal with business boundaries and trans-boundary agreements
    • The business delivery system - The set of concepts that provide understanding of how the business delivers value by keeping its commitments.
  • Sources and representations of variability - A discussion of business terminology as the source of variations on basic business concepts for individual businesses, as well as an overview of methods for representing detailed business information in the form of models.
  • Relation to IT architecture - Points of intersection between concepts in the business architecture and concepts in the IT system architecture description standard.

Purpose of a Business System Architecture

A companion article[2] in this issue creates a meta-language of architecture for technology-based information systems.  This meta-language enables architects to communicate with a common set of concepts about how information systems can be designed in a modular way with commonly understood interfaces.  This article extends the idea of a meta-language to consider issues of the business to be supported by IT solutions.  Our concern is to understand how the domain of business can be understood according to some common generic concepts.

A dictionary definition of architecture is, “a unifying or coherent form or structure.”  This definition is appropriate for the kind of architecture that is addressed by the ESS project.  Such an architecture is used for two purposes:  to understand and to build.  In this article we are trying to understand the meaning of business knowledge by using an architecture of key business concepts.

A valid question may be raised as to why we should be concerned with an architecture of business concepts, in the context of building software systems.  After all, IT architects do not create businesses, they create technology-based information systems.  However, the systems that they create do have a fundamental impact on businesses.  In addition to purely technical issues, information systems architects need to be concerned with the content and usage of the systems that are built.

An analogy is often drawn between the architecture of buildings and the architecture of software systems.[3] One lesson from that analogy is that architects of buildings start with a fundamental understanding of the purposes to be served by those buildings.  Architects of suburban homes need to understand something about the behavior patterns of young, growing families.  Architects of manufacturing plants need to understand patterns of configurable assembly lines.  Architects of high-rise office towers and architects of mini-malls need to understand patterns of business behavior in core business districts and outlying areas respectively.  In a similar fashion, architects of enterprise systems need to understand patterns of business behavior and patterns of technology and how they work together to enable businesses to achieve their strategic and tactical goals.

The building analogy only goes so far in understanding business and its IT support.  Another perspective on business enterprises is to think of them as living systems, undergoing an ongoing process of evolution.  This analogy helps us to understand the relationship between businesses and information systems technology.  Evolution is the result of two basic conditions.  One is a source of novelty[4], and the other is an opportunity to expand into unoccupied environments[5].  Today the use of information technology is creating both the necessary source of novelty and the expansive environment that is driving rapid evolution of business.

We are in the midst of technology-driven and technology-enabled business evolution, as networks and information technology create new business eco-niches.  Examples of evolution taking place in this new marketplace ecosystem include:

  • A book store, a bank, and a car dealership that come into your home.
  • Insurance companies that think they're banks, and vice versa.
  • Companies outsourcing necessary functions to other companies, including the most intimate form of outsourcing, customer service.

Figure 2 below shows how this accelerating evolution is being fueled by technology.  Technological innovations give rise to increased opportunities:  new ways to do old things better, and whole new things to do (such as make and sell technology products).  These opportunities give rise to business innovations, and companies move in to take over new niches and sub-niches.  These changes in the way of doing business create new ideas and expectations of even better, more innovative performance on the part of technology.  This in turn puts pressure on technology providers to support still more new and innovative forms of business behavior.  An example of this cycle is that the technology innovation of the Internet has created new opportunities for companies to reach their customers (not to mention all the opportunities to provide Internet hardware and software).  The increased reach provided by the Internet has enabled business innovations such as on-line automobile shopping.  This increases the expectations that to be in business means to be able to provide Internet sales capability.  This, in turn, drives the need for increased security and payment processing, which drives technology providers to support increased expectations.

Figure 2

This mutually evolving relationship between business organizations and IT systems requires the ability to capture and portray business and technical information in a way that makes the two sets of information easy to interrelate.  The meta-language proposed here provides a semantic framework for speaking about common business concepts, and relate them clearly to concepts that describe IT systems.

The semantic framework must support two key architectural motivations that arise from the effort of building information systems.  One of these motivations is the need to clearly articulate the issues that most strongly drive requirements.  Our framework needs to zero in quickly on the most important things to be studied to get an effective understanding of the business, or type of business, to be supported by the IT solution.

The other key architectural motivations for our framework is that it needs to provide clear guidance as to how to organize work.  The work of building information systems is most effective if it is organized as a value-chain.  This means that teams of people work on building things that become part of, or support, other things being built by other teams.  We want our business architecture to help the partitioning and relationships of work effort.

In order to support the architectural objectives noted above, there are several principles that inform the creation of this business system architectural framework.  These principles are key to assuring the business system architecture effectively addresses the architectural objectives noted above.

  • Orthogonal - We want the set of chosen concepts to divide business information in a way that is non-overlapping.  This is aiming at two results: one is that we can divide the analysis space cleanly for purposes of understanding requirements and partitioning work.  The other result is that we can see interesting intersections of disjoint concepts.
  • Complete - We want a set of concepts that taken together cover the totality of business concerns, albeit at a necessarily very high level.
  • Memorable - We want a set of concepts that can easily be remembered as teams and individuals discuss the business opportunities being considered.  This means that they need to be small in number, and of a structure that makes them memorable.
  • Rich - We want the set of concepts to be able to produce interesting further classifications, thereby carving the business domain at its joints.  Ideally we should be able to create multiple levels of types, even, so that we can divide the generic business domain space, and then further analyze actual businesses.  This implies that our concepts should be semantically interesting in their own right, and not some overly abstract meta-meta construct, such as “thing-relationship-thing.”
  • Generic - Even though we want some richness and memorability in this framework, it will not do for it to be specific to any single business, or even any particular industry.
  • Appropriate - Finally, we want our concepts to be truly business concepts, and not information technology constructs in disguise.  This means that it should not be a database design or software model, as might be the case if we force-fit an entity-relationship paradigm or object modeling paradigm into this arena.

Business Concept Architecture

The concepts in the business architecture description provide a semantic framework for speaking about common business concerns.  At the level of building or deploying instances of information systems in actual businesses, this concept architecture provides a mechanism for organizing the complex, chaotic domain-specific language of the business.  For our purposes, this semantic structure provides a common set of concept patterns to be able to understand the types of content that needs to be supported in technology-based information systems.

Primary Business Concepts [Upper Ontology]

Figure 3 depicts the concepts of a meta-language for business systems.  Please note that these are not objects as would be found in an object-oriented model.  The principles of object modeling do not apply in this case, because we are talking about concepts, not software constructs. The arrows provide guidance as to the primary direction to read relationships.  The reader should assume all relationships can be many-to-many, with complementary verbs that read the other direction.

Figure 3


A key characteristic of this model is that it is designed to produce fractal patterns of information structure. Fractal patterns are those that repeat themselves at any scale on which they are examined.  An example of a fractal pattern in nature is the branching of a tree from the trunk and major limbs all the way out to the most minuscule stems and twigs.  Note that at the most basic level, each of these concepts is recursive, as indicated by the looping relationships on each of the concept boxes.  This means that a business location is composed of business locations, a business resource is composed of business resources, and so on.

Another implication of Figure 3  is that groupings of these concepts form intrinsic patterns.  For instance the relationships among role-players, function, and behavior are mutually defining.  These mini-patterns are fractal, by virtue of the recursions on the basic concepts.  Furthermore, the whole pattern is replicated at various levels of business organization.  In the same way that twigs are different than trunks, each level of recursion potentially has a different meaning.  This is particularly important in using this scheme to partition the work of building applications.

Requirements on the Business System

Figure 4 allows us to separate the architectural concepts into three sections: those that address the requirements imposed on a business, those that address the business as a system that exists to deliver against those requirements, and a set of concepts that define the boundary where the business accepts the driving requirements and commits to various forms of value delivery.

Figure 4

The following sections define the concepts in this architecture, starting with the drivers, and then moving on to a discussion of the boundary concepts, and then finally a definition and explanation of each of the concepts in the business delivery systems.

Drivers of the Business

The following is a discussion of concepts that articulate requirements placed against the business as a system.

Business Situation

The concept of a business situation as used here is derived from a body of work in an interdisciplinary field known as situation semantics.  A brief definition of a situation is "a structured part of reality that … [a person] somehow manages to pick out.”[6]  A situation is composed of a whole set of things in the world, their current state, and their interrelationships.  It is very powerful to think about classes of situations, such as .  At their most inclusive business situations are composed of all the environmental, societal, technological and marketplace factors that exert an influence on the business. Situations can represent reality beyond the business - a whole environment or industry - "the financial services marketplace".

A business situation is the source of requirements that are placed on a business, largely by the state of affairs outside the business.  It can both motivate and constrain what the business can aspire to accomplish.  A situation is created in large part by role-players, inside and outside the business, and it can be altered by the outcomes produced by the business.  A recursive relationship on situation means that a situation is composed of any number of other situations.

From an architectural point of view, the concept of situation allows us to reason about the external factors that are driving the business.  This allows us not only to understand the fundamental sources of information system requirements, it can enable us to predict such requirements before the business itself has articulated them.  We are looking for factors and trends in the marketplace that call for information system functionality, such as a move toward integrated supply chains in an entire industry.

Situations can be desirable, in which case the business will attempt to sustain them, or undesirable, in which case the business will attempt to change them.   Situations can arise from natural causes, or in the case of business, quite commonly are the result of legal issues.

The concept of situation is actually the heart of most service businesses, which manage more or less complex situations on behalf of their clients.  A classic example

Business Purpose

Business purpose is an expression of the reason that the business is in existence.  A number of stakeholders make demands on the business, and the purpose of the business is the satisfaction of those demands.  These stakeholders include customers, suppliers, creditors, debtors, shareholders, community groups, and employees.  The most fundamental purpose of any business is to produce a result expected by its customers.  Also critically important are the satisfaction of the shareholders or owners of the business, and fulfilling the requirements of employees.

Business purpose is both motivated and constrained by the situation that the business finds itself in.  In turn, the expressed purpose motivates the role-players.  The purpose is supported by the commitments made on behalf of the business.  And, it is fulfilled by the outcomes produced by business behavior. The recursive relationship on business purpose means that a high-level reason for being can be expressed in any number of goals and objectives.  A measure of business effectiveness is the extent to which the more detailed and specific goals and objectives work together to support the more fundamental purpose, or reason for being.

The reason we are concerned with business purpose is that any investment in information systems and technology must be justified by how it supports the goals and objectives of the business.  As we investigate the business, there are a number of areas we can look for statements of purpose.

Business purpose is expressed in many forms, using various different terms.  Mission statements, also called value statements, credos, or principles, are the operational, ethical and financial guiding lights of companies.  They articulate the goals, dreams, behavior, culture and strategies of the business.  Vision statements articulate the long term objectives of the business in terms of target marketplace, products and services, as well as the desired financial position (revenue, profit, etc.).  Critical success factors call out certain specific areas in which satisfactory results will ensure the achievement of business goals.

Business Outcome

The concept of a business outcome can be seen as a generalization of the concept of product.  Other types of outcomes are services, byproducts, and interim outcomes that are produced in the course of business activity.

A business outcome is mandated by a commitment and exists to fulfill some purpose.  It is produced by business behavior and consumes resources in the process.  The recursive relationship states that an outcome can be composed of outcomes (as products are bundled into higher level products, for instance).

From an architectural view we are concerned with outcomes such as products and services because these are often exactly what information systems are built to support.  In terms of structuring work and forming a conceptual architecture of the IT system, the variations in product lines and other outcomes of business processes are very strong differentiators.

Business Boundaries

[At the time of the article I kind of forced some subjects into the general category of boundaries.  Subsequently I did a lot of work on the idea of business boundaries.  I will post material about that, and I hope I remember to come back here and link to it.]

Business Role-Player

The concept of business role-player lies on the boundary between the requirements that drive the business, and the business delivery system.  This is because some business role-players are outside the business making demands, while others are inside the business fulfilling demands.

As external entities, business role-players are key factors in the creation of business situations.  As internal entities they are motivated by the purposes pursued by the business.  Business role-players are bound by commitments that are made on behalf of the business.  They are defined by the function they perform or are responsible for, and they perform business behavior.  They have resources assigned, in the form of capabilities of either people, groups of people, or devices.  Recursive relationships among role-players mean two things.  A containment relationship says that one role-player is part of another, as in the standard organization chart. It is also possible for one role-player to report to another, without actually being a part of it as a larger entity (such as a project team that reports to a steering committee, without being contained by the steering committee).

From an architectural point of view, identification of the various types of role-players in the business is extremely valuable.  An understanding of how responsibilities are partitioned in the business.  This helps to partition business behavior, which is a major factor in designing software and allocating work on application development and/or implementation projects.
The concept of role-player brings together aspects that are often separated: the role itself and the player of the role.  We’ll take a closer look at these constituents of the role-player concept below.  They are brought together here because either alone does not meet the architectural concerns of organizing key knowledge and driving development work.

Roles exist in distinct types, including customer, employee, regulator, sales or distribution channel, and supplier, as well as more general types such as performers, managers, and recipients of various types of outcomes.  Roles, job titles, and organizations all may exist in many-to-many relationships to each other.  Roles may be formal (job title) or informal (committee membership).  Roles can be even more granular, such as “opportunity noticer” or “call recorder”.  A role is characterized by capabilities, skills, abilities, etc., which enables it to be matched with potential players who have those characteristics.  A role implies a set of responsibilities.  Job titles are created to group a number of compatible roles along with their attendant responsibilities.  Roles exist in a number of complex relationships to each other:  Some roles require other roles (the role of a store manager can only be played by someone who is a regular employee), while some roles preclude other roles (a teller may not be a loan approver).

The players of roles may be individual human beings, organizations, and devices.  An individual human being is one type of legal entity (the other type of legal entity is a legally constituted organization).  Organizations include groups of people of all types.  Within some context there are replicated organizations (field offices, project teams) and singular organizations (the Board of Directors).  An organization can be formal (a department), informal (a committee), or legally constituted (a corporation).

Assignment of the appropriate human being, organization, or device to a role implies a kind of pattern matching that lines up capabilities needed by the role with capabilities of the potential fillers of those roles.  If the role-player is a human being there is the additional factor of accountability that can be applied.  A key issue for IT system builders is the indirection of accountability.  When responsibility is assigned to a device that would otherwise have been assigned to a person, accountability is shared between the creator of the system and the deployer of the system.  This has major implications for builders of applications that increasingly play roles that directly interact with stakeholders of the business.

Business Commitment

Business commitments comprise the glue that binds businesses and other organizations at their boundaries.  A business commitment is the result of an agreement between business parties, or role-players.  Business commitments may be binding, contractual agreements, or they may be more informal.

Meaningful business commitments support the various levels of business purpose.  Business commitments are binding on the role-players who are party to them.  They mandate certain outcomes that are to be produced by the business.  As a result, commitments govern business behavior.  Commitments have a strong recursive element which says that agreements are composed of more granular agreements such as terms and conditions, conditions of fulfillment, and conditions of satisfaction.
It is important for information system development for us to understand the types and extent of business commitments in the business at hand.  In some cases these commitments are the heart and substance of much of the information system functionality.  The clearest example is that of an insurance company, whose very product, the insurance policy, is nothing more or less than a set of contractual commitments.  Much of the architectural structure, and the partitioning of work, can be driven by an understanding of the business commitments.

Business Delivery System

The third set of business concepts includes those that are squarely in the middle of the business as a system for delivering value, based on its commitments.

Business Function

The business function is a key concept in this semantic framework.  The concept of business function can be thought of as a virtual or idealized organization within the business, as shown in Figure 5.  It is true that organizations are established to perform specialized functions in the business.  It is also true, however, that frequent reorganization within any business is a recognized fact of life.  So functions are idealized conceptual structures that are stable over time and in the face of managerial reorganization whims.  As stable concepts, functions provide a point of commonality in describing different businesses that otherwise exhibit significant variation.

Functions as we are defining them here provide definition to role-players in the business.  This definition is demonstrated by the way the accounting function defines the accountant, the management function defines the manager, the underwriting function defines the underwriter.  Business functions may be concentrated and housed in specific business locations.  Specific functionality is invoked as required during the course of business behavior. They are one of the main points of recursive definition, because high-level business functions are easily seen to be composed of multiple more granular levels of functionality.

From an architectural point of view we are interested in functions because they provide us with a key partitioning opportunity.  If functionality is partitioned in a meaningful way, it can stand the test of time and the vagaries of political reorganization.   This is also the point where we can talk about software performing or supporting specific aspects of the business, independently of how any business is organized at any point in time.

Figure 5

Function definitions are not completely deterministic, which is the source of a long-standing criticism of functional decomposition as a technique. There is an element of subjectivity, based on the viewpoint and the principles being applied in the partitioning of the domain according to functions.  For this reason it is important to be as explicit as possible about the principles that are used to create the particular partitioning scheme.  The principles used here include:  The functions defined should be as independent as possible from existing or typical organization structures.  They should together constitute a set of functions that are typically required for any living[7], or viable system[8].  Since we are focusing on the information system aspects of the business system, they should constitute a complete set of functions that could give rise to a cognitive view of the business system[9].

Figure 6 below is one example that is provided for purposes of illustrating how a completely generic set of functions can be constructed that follow the principles noted above.  There are several information processing functions, abstracted from a combination of a living systems model, the Viable Systems Model, and a cognitive architecture.  They are unlikely to be mistaken for any existing or traditional organization chart.  Each one is a socio-technological subsystem in its own right, potentially containing both human beings and computing technology.

Figure 6

The points below define each of these business functions, starting with the most primitive ones that are equivalent to simple patterns of neurons and synaptic matrices, similar to the simple cognitive agents of Marvin Minsky’s[10] “society of mind”.  From these simple functions, progressively higher-level and more complex domains emerge.

  • The perceiver is a sensing mechanism, relying on both human and machine capabilities.  Computers support human perception via user interfaces.  Machines maintain direct environmental perception via probes physical sensing (temperature, etc.) and chemical probes.  The perceiver senses the occurrence of activity that is of interest to the business (such as a request to place an order, or the arrival of a shipment). It recognizes the existence and identity of some entity of interest to the business (such as customer Doris Smith).
  • The transmitter moves information within the business and between the business and external entities.  It requires a medium such as air waves, wires, or paper to move information from one location to another. It transforms information from one form (language or protocol) to another, and amplifies and filters information as required.
  • The expresser provides the means of conveying information to entities inside and outside the business in a form that is accessible to them.
  • The memory maintainer is the highly distributed function of maintaining the business's stored memory. It stores the values of information in various forms of business memory, including time-stamped records and groups of records in the databases of the business, as well as scenarios and anecdotal memories of employees. It keeps memories of agreements, rules, roles, etc.  It provides the ability to compare information in stored memory with external conditions or other information, so as to maintain the quality of information used in business decisions.
  • The locator provides the ability for the organization to locate physical entities in three-dimensional space or logical entities in arbitrary, cognitive space.
  • The producer performs the fundamental product and services production work of the business.  It accepts assignments for work to perform and reports on results of work completed and in progress.  It moves physical resources, i.e. solids, liquids and gasses, creates parts and components from raw materials, creates larger units from previously existing components, and acts on numeric data from counts, measurements, and accessed from memory.
  • The resource maintainer has the responsibility of assuring that the organization is supplied appropriately.  It acquires and allocates resources, determines the value of required resources, rejects inadequate resources. It compensates suppliers of resources, and keeps track of the level and state of resources.
  • The business relationship maintainer cares for the relationship between the business and the key role-players, including customers, suppliers, regulators, partners, agents, broader community stakeholders, internal organizations, and employees).  It negotiates deals and performs transactions such as selling and delivering goods and services, billing customers, collecting payment due, ordering goods and services from suppliers, and paying suppliers.  It provides the ability to broadcast a message to a more or less inclusive audience within or external to the business.  It also provides the ability to reproduce business configurations.
  • The arbiter provides business norms of behavior - "how we do things around here".  It codifies specific rules of business behavior, defines roles, accepts rule definitions from external sources, such as laws and regulations, and rewards behavior that conforms to business norms, while punishing behavior that does not.
  • The commander is responsible for the accomplishment of goals created by the direction setter.  It assigns these goals to the producer as bottom-line, operational goals.  It creates specific work assignments for business units and watches over activities in progress.
  • The direction setter forms purposes, or intentions to pursue opportunities and/or avoid risk.  It recognizes large and small opportunities, from individual sales potential to whole new marketplaces.  It formulates new types of goods or services that will be provided by the business within its marketplace.


Business Behavior

Business behavior is an ordering of tasks or activities that accomplish business goals and satisfies business commitments.  It may include manual or automated operations that complete units of work.  Business behavior can be triggered by events in the environment or by internal initiatives or conditions.  It is justified because it either generates value for the business or mitigates costs to the business.

Business behavior is what produces the outcomes that fulfill the purpose of the business.  Behavior is governed by commitments.  It is performed by role-players.  As an end-to-end set of activity, behavior can invoke various functions within the business.  Behavior manipulates various resources in the business in order to produce the desire result, and it is enabled by resources of all kinds.  Business behavior is quite recursive, although we will discuss various reasons and methods for imposing specific structure on aspects of business behavior.

The architectural purpose for understanding business behavior stems from the opportunity to support or replace it with automation.  From an architectural point of view we are looking for structure that can help us organize the work of building software components and create interfaces from one component to another, and from the software world to the world of human activity.

It is important to stress that we are talking about business behavior of all kinds.  There are both physical behavior and information bearing behavior involved.  We are generally only interested in physical behavior to the extent that it is accompanied by information or provides an opportunity to capture useful information about the business.   Much of the business behavior that is covered by this concept is performed by human beings, while some subset is either supported or performed by software.

Behavior can be seen as having structure.  This may be arbitrary, but it is useful to apply some principles to the way we view this structure.  Various methods have applied specific terms to specific levels of business behavior.  We will do this as well, keeping in mind that almost any term we choose will be hopelessly overloaded, and defined in completely different ways by other practitioners and methods in the industry.

Fundamental to the structure of behavior is a concept we will call a “process”.  A process, as used in this discussion, is a complete sequence of business behavior that is triggered by an event and produces a meaningful business result as shown in Figure 7.  Figure 7 depicts an interaction between the business and one of its stakeholders.  What we see here is that the process continues until a meaningful business outcome results, in this case the delivery of a product to the customer who initiated the process.  In the course of this string of activity, various areas of the business must get involved.  These unlabeled areas in Figure 6 can be interpreted as organizations or as business functions as we’ve defined that concept.  The fact is, processes, as defined here, do cut across, or invoke, both organizations and functions in the business.



Figure 7

Major subclasses of business processes are transactions, transformations, services, and maintenance.  Transactions can be primarily inward - bringing things into the business (money, information, or other resources) or outward - sending things out (bills, products, byproducts and waste).  Transformation (conversion) processes take resources as input (material and energy, or information) and transform them into other (value-added) states.  Service businesses are particularly defined by their processes which are, in effect, their products.  These service processes can be either passive from the customer viewpoint (haircut, restaurant meal, airline flight) or collaborative (consortium, information retrieval).

Part of the structure of business behavior are events or triggers that initiate activity within the business.  They are the stimuli that prompt the business to act.  Many business events occur at the interface point between the business and one of the external entities that it interacts with.  For example, an inquiry may trigger activity that leads to an order, or a trouble call may trigger dispatch and repair activity. Other events are internal triggers based on specific conditions or predefined time intervals.  For example, an inventory level may trigger a reorder point, or the 15th of the month may trigger an automatic billing cycle.  Externally generated events can be solicited, and therefore expected, or predictable to an extent (e.g. sales, stimulated by marketing campaigns). Unexpected events are things like typhoons, stock market movements, or the appearance of new technology.  Though unexpected in the sense of not being under the control of the business, they can in many ways be anticipated and provided for with contingency plans.

Figure 8 depicts the kind of structure that can be discussed with respect to business behavior.  What we see here is that a business event and outcome occur at a stimulus/response level of the business.  From stimulus to ultimate response is the structure that we’ve called a “process”.  At another level inside the business there is behavior that is assigned to and performed by a responsible internal role-player.  At the bottom there is some leaf-level behavior which manipulates a discrete business resource in some meaningful way.  At an intermediate level there can be some number of identifiable groupings of behavior that are called out for the sake of convenience of analysis and understanding.  At any of these levels business behavior is governed by rules, which dictate how flows should be initiated and directed.


Figure 8

The reason for attempting to structure this behavior is to make clear architectural decisions about which behavior to support, how it should be supported, and how to allocate the work of building software components to support it.  The leaf-level is the place that behavior directly touches resources and devices, and it is where we see a tradeoff between individuals and devices in performing the work.  This is the level where it is most reasonable to analyze time durations that aggregate together to allow us to simulate business behavior.

These levels have been expressed in a representation of application architecture with the terms “process”, “activity”, and “service”.  In another representation “process” is replaced by “procedure” and elsewhere the “activity” level is replaced with “task”.[11]  By whichever name it is called (activity or task) it is suggested to map the responsibility level from Figure 8 to use cases, when the business behavior involved is to be supported by the IT solution.

Business Resource

The concept of business resource represents all those things that are required by a business to sustain its processes and create its outcomes.  Resources break down into five general categories:  physical things, energy, monetary value, information resources, and various kinds of capabilities.

Business resources are consumed in the course of producing outcomes.  They are housed in specific locations.  They are manipulated by business behavior and enable that behavior to take place.  Resources in the form of the capabilities of people, groups and devices are assigned as role-players.  The recursive relationship on the resource concept indicates that there can be many levels of composition and interrelationship among resources of all kinds in the business.

From an architectural point of view resources are important because the business spends much of its time and effort in acquiring, using, maintaining, and tracking its various resources.  This is a key source of requirements for information systems.  As we allocate work to study the business, the range of resources, and their further classification, is a major organizing principle.  The major types of resources, along with various resource-related issues, are outlined below:

  • Physical resources represent tangible, molecular things that are used and consumed by the business.  Two intersecting type structures help categorize physical resources.  Resources may be mass (sand, sugar, hydrochloric acid), countable (pencils, transistors), or identifiable (individually tracked and accounted for).  Resources may also be supplies, devices, components, or environmental resources.  These category sets influence each other.  Supplies are almost always either mass or countable type resources.  Environmental resources (land, water, trees) tend to be mass types, but may also be identifiable (a particular lake, a large oak around which a courtyard is constructed).  Components are either identifiable or countable, while devices (tools and machines) are usually identifiable. Physical resources are always quantifiable, and almost always have additional physical characteristics (weight, dimensions, quality, color) that we are interested in.  Many physical resources (devices) require energy, while some are used for storing potential energy.  We need to be able track the life cycle of physical resources, for depreciation and inventory purposes.
  • Energy is a factor that should be considered more than it generally is in business models.  Energy is either kinetic (producing physical motion), thermal (expressed in terms of temperature measures), or potential (stored in a medium for future release).  Physical resources store or contain energy (fuels, batteries) and device-type resources consume energy.
  • Money can be promised (to be available in the future) or actual.  In can be incoming (billings, receivables), outgoing (payments, liabilities), or static (balances).  Monetary resources are assigned to accounts (which are logical locations).  Money provides valuation for all other types of resources used by the business.
  • Capability is a major resource of all businesses, from the skills, knowledge, attitudes, and experience  of human beings.  In our concepts we have separated aspects of people into their capabilities, which form a business resource and their relationship to each other as role-players.  We can say things like "Three years of Visual Age experience is worth ...", and then negotiate with individuals, with that monetary valuation as one aspect of the negotiation.  Capability as a business resource is subject to many levels of aggregation and identification.  We sometimes talk about the core competencies of a business, and this is a capability consideration.  The ability to manage and apply capabilities in an effective manner is largely a matter of externalizing the tacit knowledge of individual employees and making it explicit.  This in turn becomes a major opportunity for the application of information technology.
  • Information resources represent the kinds of things that can be known by the individuals and organizations in the business.  What does it mean for an business to know something?  It means that it has stored data (physical or electronic), or that its member individuals know it.  There are many types of information resource that the business needs to be concerned about.  A few of those include: identification of things of interest to the business, relationships among those things, characteristics of things, including quantities and other forms of measurement, descriptions, categorizations, histories, templates, plans, and documents of all kinds.  A key form of information as a business resource is the business rule.  A business rule is an information resource that is expression of business policy.  Business rules can be found in relation to almost all of the concepts in our conceptual architecture.  A business rule may:
  • provide a set of conditions that govern business behavior
  • provide the criteria for when an action is successfully or unsuccessfully completed
  • stipulate what other actions can or cannot be performed as a result of successful or unsuccessful completion
  • specify the  response to some external event that impinges on the business
  • govern relationships that need to apply among various business entities.

Business Location

The final concept that we will discuss is that of business location.  Business locations come in two main varieties: physical and logical.  Business locations house resources and functions. Locations exist in recursive relationships to each other which are generally of the “piece/whole” variety.  This means that location is often an arbitrary process of carving up space into pieces as a matter of convenience.

Architectural interest in locations differ, based on whether they are physical or logical.
Physical locations have to do with space.  Space defined in three, two, one, or zero dimensions corresponds respectively to volumes, surfaces, lines, and points.  Points can be of two types: coordinate (x,y; latitude, longitude) or referential (on the fourth floor of the building; next to the car).  Our main architectural concern with physical location is to determine work locations for deployment of technology.  Physical locations correspond very closely to the location concept in the application description standard for IT systems.

Logical locations include accounts, postal addresses, and network addresses (phone numbers; TCP/IP addresses, etc.).  Clearly IT systems are interested in networking addresses.  They are also concerned with accounts as types of logical location.  Some of the basic categories of account include payable, receivable, ledger, personal. Accounts are often one of the top-level categories in business thinking.  This point of view stems from the preeminence of the accounting discipline in the history of business, and of computing systems.  From the overall perspective of this business concept architecture, accounts are assigned a lesser position, as logical locations, or buckets, for monetary resources.

Variations on Concepts

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.

Mapping Business and IT Concepts

In the introduction to this discussion we noted a symbiotic relationship between businesses and IT systems.  We said that this relationship calls for the ability to capture and portray business and technical information in a way that makes them easy to interrelate.  In this section we will discuss some key relationships that bridge between the concepts in the business system architecture and the IT system architecture.

Figure 9 is a graphic portrayal of some of the key relationships that bridge these two conceptual architectures.  The concepts on the left are the concepts previously discussed here, while the concepts on the right are explored in detail in a companion article in this issue on the conceptual framework for IT systems.[14]


Figure 9


The first thing to notice is the single relationship between the business situation and the total set of IT concepts.  What this is saying is that information technology is intrinsic to the business situation, most especially in the form of the legacy environment that is always present in any business.  As we have seen, the business situation provides both motivation and constraint on what the business can aspire to accomplish, and the current state of available and actual information technology is a major factor in this situation.

Another business concept that maps to the whole world of information systems is the concept of business function.  As we’ve seen, business function is a major partitioning concept which provides a means of considering generic, or logical organizations.  This viewpoint is also a powerful means to partition information systems along functional lines.  Each functional partition contains both human and technological capability, and through its recursive decomposition, or fractal nature, this concept allows meaningful partitioning of the complete IT architecture at any number of levels.

The concept of business behavior is a key to organizing IT functionality.  Behavior is defined and performed by such software components as workflow engines.  The behavior of a component is made externally accessible through the component’s interfaces.  It is also drives and is embodied the IT concepts of collaboration (which is a sequence of operations that realizes a use case scenario).

The most salient feature of Figure 9 is the number of relationships between the IT concept of component and various business concepts.  We have already seen that components actually perform business behavior, within the boundary of automation, and capture key information about external human behavior as well.  Components, as modular units of technological functionality also provide the expression of business semantics, such as the existence and interrelationships among business resources and business outcomes.  Business role-players and the commitments among them are also subjects to be supported and expressed in software components.

It is easy to see that several of the IT concepts are closely related to the concept of business resources.  All hardware, software, and combinations in the form of devices, systems and applications constitute resources of the business.  The IT concepts that express these hardware and software resources are component (as we’ve seen) and node, a hardware platform onto which components in the form of deployment units can be placed, as well as connection, a kind of network or communication path (LAN, WAN, dial-up, infrared, wireless, satellite, etc.) that joins two or more nodes, thereby supporting interactions among components.

Finally, note that nodes, or hardware platforms, are directly related to business locations, where such platforms can exist in physical space.

Concluding Remarks

We began this article with a brief description of the interaction of technology with business which is driving continuous change in the marketplace.  This provided a motivation to understand this interaction on a conceptual level.

We have created a business concept architecture, drawing on some models from general systems theory and on a cognitive architecture of the human brain.  This is a companion piece to similar work that has explored the concepts relevant to understanding architectures of IT systems.  Our conceptual architecture tries to understand the sources of requirements imposed on business systems, and the key areas of interest in the business system itself.

We have discussed various methods of extending and refining business patterns, via a more detailed set of business models produced by a work product based methodology.  This is an approach to handling the continuum from commonality to variability that is a significant challenge for leveraging investments in information systems technology.

Finally, we have mapped business concepts to information technology concepts.  Throughout this discussion we have maintained a focus on how this business conceptual architecture can help drive the content understanding for the IT system, and partition the work of building it.

This article lays the groundwork for additional work in subsequent phases of ESS in the area of articulating variations on the business architectural concepts and relating them to the set of IT system architectures at a more detailed level.


The author would like to thank in particular the following people for their insightful influence on this article:  Martin Cooke, Don Crocker, Ed Kahan, Jim Reigrut, Srini Chari, Genie King, Juan Zumbado, Emily Plachy, Deborah Leishman, Tim Lloyd, Burnette Blakeley, John Fetvedt, John Cameron, David Redmond-Pyle, Jack Ring, Ralph Hodgson, Mark Simos, Steve Johnson, Pat Gongla, Rock Angier, Kathy Yglesias, David Ing, Ian Simmonds, and Stephan Haeckel.


[1]Plachy and Hausler, 1999

[2]Youngs, et al, 1999

[3]See Lloyd, et al, 1999 for a reference to Christopher Alexander in this regard.

[4]Biological evolution is driven by changes in DNA produced by mutation, bacterial recombination, and symbiogenesis.  Symbiogenesis is the process whereby long-ago bacteria formed such inextricable associations with each other  that they created whole new life forms.  Every cell in every plant and every animal on earth contains myriad independently reproducing mitochondria, each with their own DNA and RNA, that are the living descendants of these symbiotic relationships. Lynn Margulis refers to our cells as “cellular corporations.”  Margulis, 1997.

[5]Species tend to emerge to fill empty eco-niches.  Generally this follows catastrophic events, such as asteroid collisions or the oxygen crisis.  Occasionally this is the result of new environments being created.  An example of non-catastrophic opportunism is the existence of some 170 of species of fish of the same genus found only in Lake Victoria in East Africa.  They evolved from a river-dwelling ancestor when earth movement suddenly created one of the largest bodies of fresh water on the planet. Rothschild, 1990.

[6]Devlin, 1991

[7]James Grier Miller provides a functional view of a living system which includes 19 distinct subsystems.  Within the realm of information processing he articulates the functions of memory, input transducer, encoder, decoder, decider, and channel and net.  He claims that the 19 subsystems apply at all levels of living system, from a cell to a multinational organization.  Miller, 1978

[8]The Viable Systems Model talks about five major subsystems for communication and information processing.  These are the operational units, a normative function, a command and control function, an R&D function that is oriented toward the future and the external environment, and an executive function that resolves high-level disputes in the organism or organization.  Clemson, 1984

[9]The human brain can be viewed from an architectural perspective, with low level functions collaborating to give rise to all cognitive capabilities.  Trehub, 1991

[10]Minsky, 1985

[11]See, for example, Lloyd, et al, 1999

[12]Leishman, 1999

[13]McDavid, 1996

[14]Youngs, et al, 1999

Biographical Sketch

Doug McDavid is a senior consultant in IBM Global Services.  He specializes in business semantic modeling in support of  information systems development.   He has almost 30 years of experience in information management, information systems and application development in telecommunications, insurance, brokerage, banking, and the public sector. He has been an innovator in the use of modeling to align business and information technology strategies, and has published and presented his ideas widely.