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 papers in this issue of the 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. This paper focuses on the business concepts that underlie information technology (IT) systems.

The Enterprise Solutions Structure (ESS) project is IBM's response to this challenge. As indicated in the introductory paper of this issue,¹ ESS has provided substantial experience in real-world engagements, based on lessons learned from a number of previous projects. This experience 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 seen in Figure 1. The figure shows that a set of standard business concepts can organize particular knowledge about 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.

Figure 1

This paper contributes 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 set is a high-level semantic framework that 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 metalanguage, and this paper represents the current state of this work.

The paper 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--This section discusses a set of generic concepts and their interrelationships, organized into three main subsections:
  • 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 transboundary 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--This section is a discussion of business terminology as the source of variations on basic business concepts for individual businesses, and gives an overview of methods for representing detailed business information in the form of models.

• Relation to IT architecture--This section is on 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 paper² in this issue describes the creation of a metalanguage of architecture for technology-based information systems. This metalanguage 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 paper extends the idea of a metalanguage to consider issues of the business to be supported by IT solutions. Our concern is with 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 paper 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.³ 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,⁴ and the other is an opportunity to expand into unoccupied environments.⁵ Today the use of information technology is creating both the necessary source of novelty and the expansive environment that is driving the rapid evolution of business.

We are in the midst of a 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 are banks, and vice versa
• Companies outsourcing necessary functions to other companies, including the most intimate form of outsourcing, customer service

Figure 2 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 subniches. These changes in the way of doing business create new ideas and expectations of even better, more innovative performance on the part of technology. In turn, pressure is put 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 innovation increases the expectations that to be in business means to be able to provide Internet sales capability. This capability, in turn, drives the need for increased security and payment processing, which drives technology providers to support increased expectations.

Figure 2

The 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 metalanguage proposed here provides a semantic framework for speaking about common business concepts and relating 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 motivation for our framework is the need 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 influence the creation of this business system architectural framework. These principles, listed below, are the key to ensuring that the business system architecture effectively addresses the architectural objectives.

• Orthogonal--We want the set of chosen concepts to divide business information in a way that is nonoverlapping. This aims at two results: one is that we can divide the analysis space cleanly for purposes of understanding requirements and partitioning work. The other 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, thus requiring that they be small in number and structured to be 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 so that we can divide the generic business domain space, and then further analyze actual businesses. Thus, 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 the framework 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 need to be supported in technology-based information systems.

Primary business concepts. Figure 3 depicts the concepts of a metalanguage 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 in which to read relationships. The reader should assume all relationships can be many-to-many, with complementary verbs that read in 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. As a result, 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 from trunks, each level of recursion potentially has a different meaning. The variation in meaning at different levels of abstraction 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 that defines the boundary where the business accepts the driving requirements and commits to various forms of value delivery.

Figure 4

The subsections that follow define the concepts in this architecture, starting with the drivers, then moving on to a discussion of the boundary concepts, and finally a definition and explanation of each of the concepts in the business delivery system.

Drivers of the business. This subsection 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."⁶ 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. 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. We can not only understand the fundamental sources of information system requirements, we can 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, they 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 is an insurance company. It operates by defining various situation types, analyzing the likelihood of various outcomes, and helping its clients manage the risk-ridden situations in their business and personal lives.

Business purpose. Business purpose is an expression of the reason why the business exists. A number of stakeholders make demands on the business, and the purpose of the business is to satisfy 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 fleshed out 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.

We are concerned with business purpose because 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 in which 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 cite certain specific areas in which attaining 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 viewpoint 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. The second set of concepts are the boundary concepts.

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. The reason is that some business role-players are outside the business making demands, whereas 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 and provides an understanding of how responsibilities are partitioned in the business. This identification helps to partition business behavior, which is a major factor in designing software and allocating work on application development or implementation projects, or both.

The concept of role-player brings together aspects that are often separated: the role itself and the player of the role. We now take a closer look at these constituents of the role-player concept. They are brought together here because either one 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 one another. 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 enable 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 one another: Some roles require other roles (the role of a store manager can only be played by someone who is a regular employee), whereas some roles preclude other roles (a bank teller may not be a loan approver).

The players of roles may be individual humans, organizations, and devices. An individual human 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, 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, the additional factor of accountability 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 situation 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 that says that agreements are composed of more granular agreements such as terms and conditions, conditions of fulfillment, and conditions of satisfaction.

It is important in 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 form the heart of the business as a system for delivering value, based on its commitments. F

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.

Figure 5

Functions as we are defining them here provide definition to role-players in the business. This definition is demonstrated by the way in which the accounting function defines the accountant, the management function defines the manager, and 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. It is also the place 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.

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,⁷ or viable system.⁸ 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.⁹

Figure 6 is one example that is provided for purposes of illustrating how a completely generic set of functions can be constructed that follows 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 humans 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 "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 for physical sensing (temperature, etc.) and for chemicals. 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 radio 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 stored memory of the business. 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 organization with the ability 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 and measurements and data accessed from memory.
• The resource maintainer has the responsibility of ensuring that the organization is supplied appropriately. It acquires and allocates resources, determines the value of required resources, and 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, i.e., "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 or avoid risk, or both. 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 satisfy 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 desired 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. Both physical behavior and information-bearing behavior are 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 humans, whereas some subset is either supported or performed by software.

Behavior can be seen as having structure. This perspective may be arbitrary, but it is useful to apply some principles to the way in which 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 the figure can be interpreted as organizations or as business functions as we 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-directed--bringing things into the business (money, information, or other resources) or outward-directed--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 consists of 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 with which it interacts. 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 fifteenth day 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 such things as 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 or response level of the business. From stimulus to ultimate response is the structure that we have called a "process." At another level inside, the business behavior is assigned to and performed by a responsible internal role-player. At the bottom, some leaf-level behavior 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 that 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 trade-off between individuals and devices in performing the work. This level is 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." (See, for example, Lloyd and Galambos.³) By whichever name it is called (activity or task) it is suggested that the responsibility level be mapped 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, follow:

• 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 be supplies, devices, components, or environmental resources. These category sets influence one another. Supplies are almost always either mass or countable 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, whereas 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, but some are used for storing potential energy. We need to be able to 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. It 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 humans. In our concepts we have separated aspects of people into their capabilities, which form a business resource and their relationship to one another as role-players. We can say things like "Three years of VisualAge* experience is worth ," and then negotiate with individuals, with 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 aspect 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 a 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 resources 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 an 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 one another which are generally of the "piece or 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; Transmission Control Protocol/Internet Protocol 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 accounts include payable, receivable, ledger, and 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. It 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.¹¹

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 have already discussed in this paper. 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 terminology provides the foundation and much of the material for many other business modeling and system development work products.¹²

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 set of factors is exactly what 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, and departments. They can also be potential organizations (business functions, as we 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: subsecond, minutes, hours, days, years, etc., can be measured.
• Whether the behavior is boundary-crossing (selling, advertising, emitting) can be determined.
• 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.
• There can be 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 trade-offs 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 humans 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, and 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 those 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 make the 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 in which 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 ensure 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 introductory section of this paper 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, and the concepts on the right are explored in detail in another paper in this issue on the conceptual framework for IT systems.²

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 have seen, business function is a major partitioning concept that 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 the 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 interfaces of the component. It also drives and is embodied in 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 /i> 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 have 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 paper with a brief description of the interaction of technology with business that is driving continuous change in the marketplace. This description 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. It 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 approach is a way to handle 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 paper 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.

Acknowledgments

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

Cited references and notes