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.