Overview
I am exploring the subject of enterprise modeling. An enterprise is basically a business, but I suppose the term "enterprise" is used to avoid confusion with historically abused and overused phrases such as "business modeling". To understand why this might be interesting to a computer scientist or logician like you or I, you will have to read on.
I started my research in the area of formal software specification methods, mostly interested in reasoning about graphical models of software design using the Object Modeling Technique (OMT). OMT has long since been replaced by the Unified Modeling Language (UML) which provides a far more expressive set of notations with a much more rigorously defined semantics. UML is a cornerstone of Model-Driven Architecture (MDA), which is the idea championed by OMG that software should be developed and maintained directly from specifications expressed largely in graphical form.
It has not escaped the anyone's attention that there are excellent applications of MDA to enterprise modeling. Enterprise modeling shares much in common with software modeling, both in principle and in practice. In principle, enterprises are systems and can be modeled using many of the same abstractions as are used in software. In practice, enterprises implement computer systems that support the work of the enterprise. Furthermore, as the enterprise evolves, it finds ways to improve its efficiency and effectiveness through efforts such as process improvement which often include automation. Hence, in the limit, an enterprise model can be thought of as a plan for the eventual automation of the entire enterprise. This latter statement, of course, is only meant to emphasize the opportunity that exists in applying software engineering methods to enterprise design, and is not meant to suggest that full automation is either possible or desirable. From this broad perspective we can recognize that an enterprise model has the potential of providing the the framework for bringing all aspects of the enterprise together under a conception, and can thereby provide the proper foundation for further evolution.
Despite the large-scale character of enterprise modeling, I am interested several smaller scale concerns. Such concerns give rise to my plan to:
- develop techniques for querying an enterprise model regarding its behavioral properties,
- explore the concepts of adaptive behavior in enterprise models, and
- apply and extend techniques of model driven engineering to the management of enterprise models.
In the next few sections, I provide some more insights into these topical areas.
Business Processes
A business can become successful for many different reasons, but at some point most successful businesses mature and begin to document exactly what it is that defines them. Whatever kind of work it is that a business performs, there is a way of working that defines the resources that go into doing the work of the business and what comes out as a result. This way of working is, in a simplified sense, a set of procedures and an organization that implements them.
In object-oriented software designs, procedures cannot exist by themselves - they are encapsulated within objects which execute the procedures as needed. When objects collaborate to do work, an object may execute its procedures and/or invoke procedures of other objects. To illustrate, consider three objects a, b, and c with procedures f(), g(), and h(), respectively. We use the notation a.f() to indicate that object a has been invoked to perform procedure f(). Each of the following expressions then indicate the invocation of a procedure:
a.f() b.g() c.h()
When we combine these operations, as exemplified in the UML sequence diagram shown Figure 1, we also have a procedure. Here we have four objects a, b, c, and some object. Time elapses as you move down the vertical life-lines of each object. Arrows represent interactions among objects. Solid arrows indicate that the object at the tail initiated interaction with the object at the head; dashed arrows represent a response to a previously initiated interaction. The message being communicated is the label on the arrow; here we imagine each object being sent a message to perform a procedure. Before object a can complete procedure f() it invokes and waits for object b to completely perform its operation g(). Object b sends a message to object c requesting that it perform procedure h() twice in succession before b completes procedure g().
Figure 1. An example of a possible process.
This composite procedure cannot be performed by a single object but is achieved by the interaction of multiple objects. In general, someone has to provide a plan that specifies how objects will interact to do work when they are prodded into action in the future. But it is up to the objects to perform their tasks as specified by that plan when the actual need arises. As a result of the interactions among objects, the entire system of which the objects are a part achieves its designed behavior. The planned or designed interactions of objects in response to some stimulus is called a process model. When specific objects perform the series of interactions called for by the plan, we have a instance of the process model, or more simply, a process. The process model is the plan, and a process is the plan put into action. The diagram shown in Figure 1 could meaningfully represent a process, but the process model that these objects are implementing is at this point, unknown.
If we examine the processes being performed in a business environment, we see that many of the objects that are interacting and performing procedures are actually people and not software components. These people have well defined jobs that specify their duties/responsibilities, and they are trained on how to perform the tasks that they will be faced with. In a mature organization, the training each person receives is made concrete in the form of written procedures. If these procedures are designed properly, each person would have a handbook to provided detailed stimulus-response instructions to be performed by them acting in the capacity of their job - they would not need to know the "bigger picture" of how their actions affected the job other others performed or how their actions affected the enterprise as a whole. The designer of these handbooks would have the task of ensuring that the collection of all such handbooks, when put together and examined collectively, meets all the requirements for the correct operation of the enterprise, including the all processes terminated with the correct result. For example, if the designer:
- provided a handbook to a customer service representive that provided instructions for adding a vehicle to an insurance policy,
but
- failed to provide a handbook to the receptionist that explained that requests for vehicle changes had to be sent to to the customer service representative,
then a request for a vehicle change that was presented to a receptionist might never complete. As such, the designer of such written procedures must be able to see the behavior of the enterprise as a whole, and be confident that the workflow designs fit together to produce the intended results, in all cases.
In the example above, the objects which were doing work for the enterprise are people, but other objects could also be involved. Such other objects could include software components, computer systems, or machines. Other objects could include external entities such as other companies.
Consider briefly some of the needs of an insurance broker, which provides insurance services to people like you and I such as the evaluation of insurance needs, procurement of insurance, and numerous services related to the lifecycle of the insurance policy such as making changes. Figure 2 provides a simple UML Use Case diagram to illustrates the needs of a Customer. We'll explore the service PolicyChange highlighted in red.
Figure 2. Use Case for a customer of an insurance brokerage.
When a Customer utilizes the PolicyChange service, it initiates a business process within the insurance brokerage that has many steps that can take place over a long period of time. Figure 3 shows a possible business process in response to a PolicyChange request. Here we see persons such as a Customer, a PLCSR, a PLCSR_TECH, and an Insurance Company. We also see a computer system, MIS. The Customer is being modeled as an object that sends a changePolicy() request to a PLCSR. A PLCSR is a Personal Lines Customer Service Representative, who would be trained to handle changes only to personal lines insurance policies such as auto and home insurance; commercial insurance would be beyond the scope of the job for a PLCSR. A PLCSR_TECH is a technical person whose job it is to notify an insurance company of a change to an insurance policy. Hence, the PLCSR requests that the PLCSR_TECH execute a changeRequest(). An InsuranceCompany is a party to the contract that we call an insurance policy; the other party is the customer. The MIS object is a computer system that stores information about all the business of the insurance brokerage, and has a calendar against which followup tasks are posted. These followup tasks are called "suspenses" for the reason that the person creating the suspense is suspending the execution of procedure that they are following until some point in the future.
If the sequence diagram in Figure 3 is examined, it will be noticed that the PLCSR created a suspense in the MIS object, which sometime later caused a suspenseDue() notice to be sent to the PLCSR. This is an example of a failure. The InsuranceCompany did not respond properly to the original request in a timely fashion. It is also an example that sets the stage for the brokerage to adapt to this failure by the insurance company. The MIS generated a suspenseDue() later in time, and this provides an opportunity to correct the failure. Here, the PLCSR inquired with the company about the status of the change, apparently determined that everything was ok, and then rescheduled the suspense to come due again at a later date. Before the suspense comes due again, the insurance company has done its job by delivering an updated policy to with the insurance brokerage and to the customer. Here, no adaptation was needed, but the precursor to adapation (the wake-up call from the MIS) was observed.
Figure 3. A business process.
The lesson to be learned from this simple example is that, even though the process model may call for a certain sequence of actions to take place, it should also account for the failure of some objects to perform the task that has been requested of them. Apparently the process model at work here has some sort of adaptation strategies built in.
Enterprise modeling looks at the enterprise as a system - not a computer system, but a system in the more general sense of the term. Systems have boundaries, resources, structure, rules, inputs, and outputs. A business process model describes how work is to get done within the enterprise. Since people make up a substantial portion of the operating resources of the enterprise, it is important that that the enterprise model account for the possibily of widespread failure where people do not perform their jobs or perform them incorrectly. Such considerations fall within the realm of adaptations strategies.