The word enterprise in this context means any institution which is engaged in any type of activity -- manufacturing and/or simple information processing. Typical examples of enterprises are banks, insurance companies, ticket reservation systems, production systems, factories, etc.

By enterprise modeling we mean a precise description of an enterprise's structure and operations, utilizing just a few easily understood terms for this purpose.

What does precise description mean? It means describing the enterprise in a way which is clearly understandable to people. Actually, the goal of enterprise modeling is a bit broader -- computers, too, need to be able to "understand" the information and thus to simulate it.

One can say that enterprise modeling is a new type of programming in which the executor of the "program" is not the computer, but rather the enterprise as a whole; it is made up of employees, as well as equipment (including computers).

Why is this so important, and why is it that this problem has become so current lately? The main reason is that the structure of enterprises and the algorithms of functioning have become very complicated (think of the operations of a bank for an example of this), while at the same time, because of the introduction of computers in enterprise work, intuitive solutions and algorithms are no longer sufficient to make sure that the enterprise operates successfully. The formalized portion of the enterprise's operations must be as large as possible.

A justified process of business process reengineering (BPR) can take place at a company only on the basis of a sufficiently precise model of existing processes (as-is model). BPR requires the logical assessment of various possible reengineering options, as well as simulation experiments with the model.

What does present-day software engineering offer us in this respect? We have a new generation of specification languages, as well as the necessary engineering tools.

These new specification languages are used to service the design process that pre-dates programming. First and foremost, the languages are distinctly graphical in nature. System descriptions in a formal language are logical only if the descriptions are easily perceived, if they help to understand the system much better than does the natural-language description of the same system. The graphical nature of the description (currently in a two-dimensional space) is one of the best ways to make easier the perception of a system. It is not an accident that when people explain certain concepts, they often use graphic elements. The new generation of specification languages has turned these elements into "official" descriptive resources with precisely defined semantics.

Let us illustrate this with one example. Obviously one of the major achievements in the area of specification languages over the last several years has been the Object Modeling Technique developed by Rumbaugh, et al. The basic idea of the OMT is very simple: systems must be described with simple (and as narrowly constructed as possible) sentences, and these sentences must be presented graphically. Moreover, each noun must be represented by a single node. Take a look at these sentences:

"A bank holds accounts". "A customer has one or more accounts in the bank". "A customer can commission a transaction". "A transaction concerns a specific account". "A transaction may be either a withdrawal or a pay-in". "The bank consists of the head office and several divisions". "The bank owns the central computer". "Divisions own their own PCs".

This group of sentences can be described with the OMT diagram that is illustrated in Figure 1.

Figure 1. Example of OMT diagram

And here something wonderful happens: if we present a complex system in OMT form (which requires a bit of training), it becomes easily reviewed and understood. Even though we are not cognizant of the processes that are taking place in our brains as this happens, we can nevertheless conclude that to understand a system means to create a model of the system in our consciousness (our brain) which is similar to that which we see in an OMT image. If the description of the system is presented in natural language (i.e., in linear text), then it takes us a while to "translate" it into OMT form in our brain. One can say that the graphical languages serve to shorten this translation process quite considerably.

Of course, OMT can be used only to describe the static structure of an enterprise. What follows is the most essential part of the process: formalization of the business processes in which the company is engaged. The term "business process" has been accepted recently to describe the chain of activities which an enterprise performs in order to reach its goals. These activities may include work done by people, as well as work done by computers and other technical equipment. Again we are faced with the question of the language in which these business processes are "programmed". It is clear that traditional programming languages are useless in this purpose, because in that case we must program not just the computer, but the entire enterprises, complete with the people who perform tasks at a much higher level.

One of the most developed specification languages to model business processes (and enterprises as a whole) at this time is GRAPES-BM, which is the result of many years of work by a number of authors (among the participants in the process were the Institute of Mathematics and Computer Science of the University of Latvia, the Rîga Institute of Information Technology, Siemens/Nixdorf and Infologistik GmbH).

The modeling of business processes in the GRAPES-BM language is based on two fundamental concepts:

-- Task

-- Event

Both of these concepts must be perceived intuitively, in the way in which they are described in the Webster's dictionary. The concepts are not given formal definitions, because the concepts are too broad (just like sets in classical mathematics). This marks a fundamental difference from programming languages, in which purely intuitively understood concepts are of no use. The intuitive concepts are then supplemented with formal properties ("attributes") that allow for precise characterization and for a simulation of most of the description on the computer. The specific properties of tasks which must be included are the following:

• Triggering conditions;
• Performers;
• Duration;
• Branching conditions (decisions).

For events they are:

• Event category (message, material flow, timer, user-defined category);
• Event description (type);
• Transfer time of the event.

Figure 2. Example of business process

the respective model be simulated on the computer. Here we must take into account the fact that the closer the language is to a natural language (and in the case of GRAPES-BM, this is an issue), the more complicated is the precise semantic definition of the language. This precise semantic definition has already been worked out for GRAPES-BM, and it is based on a formalization of the concept of transaction. We will not explore these issues in greater detail in this article.

Specification languages, no matter how convenient and expressive they might be, are only one part of the problem. In order to use a high-level graphical specification language properly, the proper tools are needed. In the case of programming languages, the necessary tool is called a compiler. In the case of specification languages, however, the tools are quite different.

In order to illustrate this issue, let us look at one of the most well-developed system engineering tools -- GRADE Modeler. This tool is based on the aforementioned GRAPES-BM specification language, and it was developed in Latvia (by the Institute of Mathematics and Computer Science and the DATI company) on the basis of an order from Siemens/Nixdorf and Infologistik GmbH. More than 100 man-years were invested in the development of the tool, including its early versions. That only goes to show how complicated such tools are.

Figure 3. Functions of GRADE Modeler

Figure 3 provides a schematic illustration of the functions which are performed by this tool. One of the functions, as you can see in the figure, is BUSINESS PROCESS MODELING. What does this function mean from the perspective of the tool. First of all, it means that there must be a very well-developed graphical editor for the drawing of business processes. The business process illustrated in Figure 2, in fact, was drawn with this specific tool. A diagram drawer of this type, no matter how convenient, is by no means simple. First of all, it must ensure that elements in the diagram are placed automatically. Only the symbols of the tasks were placed by hand in Figure 2. Connections between these symbols (events) were placed automatically by the editor. If we are not satisfied with the automatic placement, we can manually move the task and the connection symbols. The connections move along with the task symbols. The fact that both automatic and manual placement is possible is one of the best features of this editor. We can also "ask" the editor to use various layout options -- e.g., in table form, where columns correspond to the performers of each task. The editor can do all of this automatically.

There is another problem. In Figure 2, we are looking at a very simple business process. In real life, business processes are very complicated, and therefore they must be structured. That means first drawing a rough business process, detailing the tasks which are contained therein by their own business processes until we reach the level of elementary tasks (meaning those tasks which are easily understood). The editor enables the structuring. The editor also has many different prompters which make the construction of diagrams easier. Along with the construction of diagrams, the editor also monitors the syntactic correctness of the diagram.

Similar editors exist for the realization of other functions illustrated in Figure 3. The OMT diagram from Figure 1 was too created with the help of the GRADE editor; the diagram can be amended and supplemented easily, and the connective elements will be placed automatically by the editor.

An important component in the editors is the data dictionary, which is established automatically as the diagrams are constructed. The data dictionary allows us to perform various global changes, i.e., we can change the name of a task or event in all diagrams with a single command. The editor also allows us to obtain various reports on diagrams, to look at diagrams from various perspectives, etc.

All of the diagrams which are constructed in this way are maintained in a common repository, and together they form the model of the system that is under review. In the event of real systems, the model is usually very complicated, with as many as several thousand diagrams. The largest system which has been successfully modeled with the GRADE Modeler involved more than 6,000 diagrams.

When the system model is constructed, we can use another GRADE Modeler component, BUSINESS PROCESS SIMULATION. With the help of this component, we can look at the model at work (in keeping with the degree of precision with which we have described the process). The animator will show us how the business processes process the incoming events, the places where queues are formed, the performers that are overloaded, the performers that are idle, etc. That way we can obtain various statistics about the model and find bottlenecks in the organizational structure and the functioning rules.

Even though the simulation is, in many instances, very important, the fact is that the most important benefit of the GRADE Modeler is the fact that it provides a precise description of the structure and operations of the existing system or the system that is to be designed. Only then can the detailed design and programming of the respective information system be begun.

A few words in conclusion. There is an erroneous view abroad that information technologies involve nothing more than the purchase and programming of computer equipment. In the case of simple systems, perhaps that is the case, but in the case of complex systems (ministries, banks, insurance companies, factories, etc.), it is much more important (and complicated) to design the systems as such, to understand precisely their structure and operations, and to evaluate the various options. Only then can those system fragments which are fully formalized be entrusted to the computer.