"Process modelling, information system requirements and applications are core part of our business. We found together with number of our clients, that using BORM we achieve very good results effectively and with a great satisfaction of this full and clear understanding what are the results. Metaedit by Metacase Ltd. is an ideal CASE for implementation tools and techniques we need." says Dr. Jiri Polak, partner of Deloitte&Touche Central and Eastern Europe

Recent developments of this method have concentrated on business use and have been extensively tested within business oriented projects. In detail, the method have been used for a number of large projects including the identification of business processes in Prague city hospitals, as a prerequisite for further cost analysis, the modeling of properties necessary for the general agricultural commodities wholesale sector in Czech Republic, as a tool for business process reengineering in the electricity supply industry and for telecommunication network management in Czech Republic. The methods have also been used for building several Smalltalk-based software applications. These practical projects suggest that the BORM approach is effective and beneficiary in the processes of both describing and subsequently understanding how real business systems evolve, change and behave.
 

Why Process Modeling?

Process modeling forms the basis of Business Process Reengineering as a part of Information Engineering.  It is also a vital first step in the development of Information Systems.  Many current development methodologies stress the highest importance of understanding the business environment in which the proposed system will exist. Process Modeling provides an essential tool to enable software developers, consultants and business users to collaborate to ensure that the necessary understanding of the business context is available to the software developers.  Process modeling provide a unique means for specialist from such diverse areas of expertise, to exchange information and knowledge in a precisely, unambiguously.
 

How to Model Processes?

Existing formal techniques for process modeling arose out of software development methodologies.  Such techniques have provided a reasonable method for modeling processes because of the essential similarities between business and information engineering.  However such techniques bring with them considerable conceptual baggage, and often require the user to have understanding of many concepts, which are relevant solely to the software development process.  On the other hand, these techniques do not fully support the fundamentals required for process modeling.

BORM is fundamentally an Object-Oriented development methodology but differs from other such methodologies in that the extent of knowledge required to understand an object and use it effectively in the design process, evolves throughout the development process in a clear, precise and consistent manner. Initially, objects are defined as business objects, where only knowledge of their activities, relationships and intercommunications is required. Business objects during the design process are changed, via a set of clearly defined and consistent techniques, into conceptual objects. During the implementation phase conceptual object evolve in a similar structured and controlled manner into software objects. Thus at each stage of the development process, BORM requires that the degree of knowledge about an object is only what is required to enable the development process to proceed. Thus Business consultants can participate in the development process without the need to understand software concepts which are the expertise of the software developer and vice versa.  Participants in the development process are required to contribute knowledge solely from their area of expertise.
 

Why is BORM different

• Most object-oriented methods do not adequately specify techniques for discovering the objects in the area of discourse. The most frequently suggested method is simply to look at the textual specification of the requirements and identify the entities from the nouns and noun phrases present. Little guidance is given to techniques, which may be applied in cases where there is no clear requirement specification. Use cases may provide a valuable method to describe interaction with the system, but they provide little practical help with object identification. It is true to say therefore, that many other methodologies start with a set of initial objects without providing any method for discovering the objects and extracting them from the problem domain. 
  The BORM development methodology starts from an informal problem specification and provides both methods and techniques, to enable this informal specification to be transformed into an initial set of interacting objects.The main technique uses here is BORM modified Object Behavioral Analysis (BOBA).

• The second main difference of BORM is that at each identifiable stage of the development process only a limited but consistent set of concepts is available for building the system model. For example, in the design stage no concepts relating to implementation issues can be used.  The progression through these conceptual sets is not merely one of extension, but rather is an evolution of conceptual comprehension.  For example, business objects in BORM have activities (methods) dependent on their states, which is quite a common occurrence in “real world” business processes. However, no contemporary programming language supports such the dependency of methods on the concrete state of the instance. By allowing such dependencies in BORM and not imposing constraints before they are absolutely necessary, we enrich the modeling process.  A second example is the concepts of multiple and single inheritance. These are very important for the software object relationships, but in earlier stages of the design process, we are concerned with the existence of an is-a relationship rather than how they are implemented, by single or multiple inheritance.

• The third main difference of BORM is that it does not rigidly enforce the distinction between static and dynamic aspects of objects. In UML we find object diagrams separate from transition diagrams and collaboration diagrams. As experienced object modelers, we feel that there are occasions where the integration of these different views, provides additional knowledge that cannot be obtained from the single perspective of one diagram. For example, in some cases we need to express the algorithmic core of the modeled system as a message passing between the states of several objects. This approach is particularly important for applications, which will be implemented in pure object-oriented languages.

The four Main advantages of BORM Process Modeling

1. Participant  History Diagram
In BORM, the term, participant, is used to denote all entities in the problem domain that have a role in the process being examined.   A Participant History Diagram shows the progress of the participant through its relevant activities and states. Such a diagram can provide information on the process from the viewpoint of each of its participants. Thus the collection of these diagrams over all participants provides a complete view of the process, from the perspective of its participants, which in BORM is referred to as the Internal View of the process. The internal view of a process in a description of how the process looks from the inside.

2. Process-Participant Interaction Model
In BORM we can diagram the history of all participants in a process, together with all interactions between those histories. Each interaction is a communication between activities in the histories of collaborating participants.  The process itself is expressed by a sequence of such communications, flowing through several participants’ histories.  This flow is referred to as the processes’ activity trace.

The consideration of the activity trace of a process, is a valuable way of identifying all the activities and states of participants necessary for the process.  Many of these activities, essential for the process, are external to the main process flow. This technique is not available in other process modeling approaches.

3. Self Correcting set of Activities
The BORM use of representing a process activity trace enables the developer to easily identify who is involved in each activity and their particular responsibility to that activity. Thus the modeler is constrained by the development method and can only add activities to some participant’s history and which are internally consistent with activities and stages already present in the process model.

The success of any Business Process Reengineering (BPR) analysis is totally determined by the accuracy with which the component activities and their interactions are correctly modeled.
All subsequent stages of BPR analysis are performed on the activities identified in the analysis phase and their attributes. (For example cost analysis, time simulations, skill analysis.)  The approach of BORM is underpinned by a consistent theoretical background and has evolved through a considerable number of practical applications.  This modified Object-oriented approach, with its emphasis on self-consistency, represents a major advance in process modeling methods.

4. A Unified Approach.
The BORM method provides a consistent set of concepts, with concise graphical representations, which are used at each stage in developing the process model.  Moreover, these concepts facilitate a coherent model regardless of any subsequent use of the process model. Thus the developer is easily able to use their model in a wide range of follow-on activities. (For example, Advanced BPR, Data Mining for Information System or in Information System Design)

Conclusion

BORM process modeling has a strong theoretical base and has been used successfully in a number of projects, both large and small, in various areas of Information System Engineering. All of these successful projects required, in their initial stages, the construction of a business process model.  Thus BORM has a proven track record for unified process modeling.