BMM: A Business Modeling Method For Information Systems Development

An important premise of most of the contemporary methods for developing Software and Information Systems is that a good understanding of the application domain is essential for a comprehensive definition of its requirements. However, when these methods are applied to the enterprise context, it is very unclear what an application domain means. To solve this problem, we elaborate the notion of business system and propose a method based on such notion for modeling application domains of Enterprise Information Systems (EIS). This method helps EIS development teams to get comprehensive knowledge about EIS application domains. This knowledge is expressed in terms of the fundamental concepts of a business system: goals, technologies, business rules, business processes, business objects, actors, job structure, and events. The method is described in terms of three methodological components: a product model, a process model, and a team model. This structure facilitates the explanation, understanding and application of the method.


Introduction
An enterprise is a business organization that may be seen as an activity system whose main parts, called business processes, are designed and executed to reach a set of pre-defined goals [1]. The execution of the enterprise's business processes is normally supported by a kind of software application called Enterprise Information Systems (EISs). Some common types of EISs are the following: enterprise resource planning applications (ERPs), legacy applications, Online Transaction Processing applications (OLTP), Enterprise Application Integration (EAI) applications, e-business systems, e-commerce applications, management information systems, and executive information systems.
Developing an Enterprise Information System (EIS) is a very complex process that involves solving not only the technological problems associated with the EIS architecture and its components, but also the organizational and social problems related to the EIS application domain. In the enterprise context, the application domain of an EIS can be seen as the business system or target organization that is supported by the EIS.
A good understanding of the EIS application domain is a critical factor for ensuring the success of the requirements elicitation activity -the first stage of the requirements engineering process. One of the sources to elicit requirements is the domain knowledge that EIS developers are supposed to have.

The EIS application domain
EISs are open systems. They are part of wider systems called application domains in the IS/SD terminology. The main objective of an EIS is to provide information services to its application domain (e.g., supplying information to support decision making, process execution, and process control).
But what exactly is the application domain of an EIS? Many authors consider the EIS application domain as the business process that the EIS supports (e.g. the finance process of an insurance company). The problem of this approach is that it does not directly consider other important elements of an enterprise, such as enterprise goals, business rules, technology, and events. A more holistic approach is needed to define the application domain of an EIS.
Following a system approach, we define the domain of an EIS as a business system, that is, a human activity system designed to achieve pre-defined goals with the support of technologies [1]. A business system is part of a major system: the enterprise. A production enterprise, for example, is structured into several business systems, such as the engineering system, the production system, the marketing system, the personnel system, the finance system, and the accounting system. An enterprise is, therefore, seen as a set of business systems. Each business system has associated one or more EISs, as shown in Figure 1. Relationships between an enterprise, its business systems and its EISs A business system is comprised by an organized set of activities called business processes that are designed and performed by a group of actors with the purpose of achieving a set of pre-defined goals. Actors are organized into a job structure composed by business units (e.g. departments, divisions, sections). Actors have associated roles that define the responsibilities for performing processes. Each process requires, uses or involves a set of business objects (e.g., personnel, clients, raw materials, products and clients) and one or more technologies (e.g., information systems, production methods, techniques or instruments). A business process is triggered by an event (e.g., the arrival of raw material or a service order) which may modify the state of the objects involved in the process. A process is regulated by business rules (e.g. laws, policies, norms and procedures).
The relationships between a business system and its EISs are also illustrated in Figure 1. The EIS objective is to produce the information needed by actors in a business system. Actors request information from an EIS to perform business processes. The EIS supplies the requested information by processing the data stored in its database. An EIS database is a model of the business objects associated with the business system. Each relevant object of the business system is represented in the database by a data object, which captures the state and behavior that the business object has in the business system at a given time. The business processes and the events that occur in the business system, or in its environment, generate data that are used by the EIS to update the database.
The tight relationships that exist between a business system and its EISs suggest the need for modeling the business system as a previous phase or stage in the process of developing an EIS.

The Business Modeling Method (BMM): scope and components
In this section, we introduce the BMM method for business modeling. This method uses the notion of business system developed in Section 2, in order to create business models that can be used in the development of EISs.
BMM can be used in most existing IS/SD methods. Figure 2 exemplifies the placement of the BMM method in the context of the WATCH method, -an EIS method for developing web applications [19].
In the WATCH method, business modeling is performed after the project planning step, which is one of the initial activities of the management processes, and before the requirements definition and specification phase.
A method engineering common practice is to structure a method into three components: a product model that describes the generic structure and characteristics of the product to be elaborated using the method; a process model that describes the structure and dynamics of the activities needed to produce the product; and a team model that describes the roles of the team's members to be played during the application of the method [19].

Requirements
Definition & Specification  By following method engineering practices and principles, we structured the BMM into the three components: 1. The BMM product model. This is a model that describes the generic concepts that characterize any business system and the relationships between these concepts. It defines the structure of the business model and indicates what must be captured and represented during the business modeling process. 2. The BMM process model. It describes the activities that the modeling team must follow to build a business model. 3. The BMM team model. It describes an appropriated way of organizing the business modeling team and describes the roles that the members of this team must play during the business modeling process. Each of these components is described in detail in the next three sections.

The BMM product model
Based on the notion of business system elaborated in Section 2, we built a product model that identifies and represents the set of generic concepts that may be found in any business system. This model is shown in Figure 3 using a UML class diagram. The importance of this model is that it identifies the set of business concepts that must be represented during the process of modeling the application domain of an EIS: the business system. The BMM product model is composed by two methodological elements: • A set of meta-models. The meta-models describe, in more detail, the generic business concepts identified in Figure 3. Each meta-model represent a generic business concept and its relationships with other business concepts. The meta-models are used during the business modeling process to determine what types of specific business concepts must be represented in the business model. • A business model structure. This structure defines the content of a business model produced using the BMM method. It indicates how to organize a business model and the types of diagrams that must be used to represent the specific business concepts that characterize a particular business system. The structure is shown in Table 1. According to this structure, a business model is composed by a set of seven models. Each model is an instantiation of its corresponding meta-model.

Business Goal
Technology Business Process Fig. 3. The BMM product model An important decision to be made during the business modeling process is the notations and languages that the modeling team must use to represent the structure and behavior of the business concepts described by the meta-models. We chose UML [24] as the main modeling language. UML is the de facto standard for modeling software and is used by many well-known methods involving business modeling (see, for example, [4], [16] and [17]). Additional notations used in BMM are also indicated in Table 1. In the next sub-sections, we explain the set of meta-models of the BMM product model. A more detailed description of this model is given in [22] and [27].

Business Goals
Goals are the reason of being of a business system. They are established by actors (e.g., top managers and stakeholders) to comply with business interests and needs demanded by the environment. Goals may be classified according to their scope into: vision, mission, and objectives. A vision is a purposive statement on how the stakeholders envisage the enterprise or business system in the coming future. A mission is a broad purposive statement that establishes the reason of being of the enterprise. An objective is a state or condition that contributes to the fulfillment of the mission. Objectives can be classified into several categories: general or specific, quantitative or qualitative. Figure 4 captures the goal concepts and the relationships that must be present in a business model.

Business processes
To reach its goals a business system must design, organize, and perform a set of activities called business processes. A business process is a set of structured and hierarchical activities designed for reaching business goals. Figure 5 shows the definition of the process concept and its relationships.
Process may be organized into several categories. Figure 5 illustrates two of the most common categorizations of business processes. Primary and support processes, for instance, are categories associated with the value chain of an enterprise [28]. The stereotype <<incomplete>> means that not all the process categories are included in the diagram shown. The business processes of a business system must be modeled as a hierarchy of processes and activities at several levels of abstractions. Figure 6 illustrates the way of structuring a business process using the UML extension for business modeling proposed by Ericksson and Penker [16]. The depth of the hierarchy depends on the complexity of the business system being modeled. It should be noted that each business process located at the lowest level of the hierarchy is, in turn, decomposed into a set of activities, whose relationships are modeled using an UML activity diagram [24].
Each activity is described as a set of coordinated tasks and actions. A task is the minimal unit of work that can be assigned to a human actor. An action, on the other hand, is a unit of work that is executed by an automated actor (e.g., a software component, a computer program, or an EIS).
The workflow through organizational units and the separation between manual and automated processes are also important aspects of the business processes that are required to be represented in a business model. Swimlanes [24] and WF nets [26] are two modeling notations that can be applied for this purpose.

Actors, business units and business structure
Business processes are carried out by actors. An actor may be either a person or a machine capable of performing defined actions or tasks. Actors may be external or internal to the scope of the business system. External actors are part of the business system environment. They interact with the business system to fulfill their needs or provide resources. Clients, suppliers, shareholders, and actors belonging to other business systems are examples of external actors. Internal actors, on the other hand, are part of the business system.
Instead of modeling actors as persons, we are more interested in representing the roles they play in a business system. Each role is responsible for performing a set of tasks which are part of one or more business processes.
Actors are assigned, according their roles, to business units (see Figure 7). Business units are organized into a hierarchical business structure, which is commonly represented in the organization chart of the enterprise. This chart defines the enterprise structure expressed in terms of authority lines that govern the relationships among business units.

Technologies
Business processes use technologies to perform their activities more efficiently and effectively. For instance, information and communication technologies, such as computer networks, EISs, and databases, are commonly used to support the efficient execution of business processes in many enterprises.
Depending on the purpose of the enterprise, different technologies are applied to support business processes. In an oil industry, for example, many complex technologies are used to explore, produce, deliver, and transform oil into finished products. In addition to information and communication technologies, an oil industry uses geological, petrochemical, mechanical, transportation, automation and control technologies.
Most business processes are highly tied to the technologies they apply. The influence of the technologies in the business processes becomes more apparent in the middle and low levels of the business process hierarchy. Many low level processes, activities are determined by the technologies they use.

Business rules
Business processes are delimited not only by the technologies they use, but also by the business rules they must comply. A business system must adhere, for instance, to the government regulations and laws imposed by its operating environment. Similarly, a business system must satisfy the policies, plans and standards established internally by the enterprise managers.
Processes are therefore regulated or controlled by a set of business rules. These rules may be of different types, as shown in Figure 8. Modeling a business process involves the previous identification and modeling of the business rules that control its execution.
A business rule may be composed by other rules forming a hierarchy whose leaves are made of low level rules that are expressed in terms of conditions and actions as indicated in Figure 8. Low level rules are important for the design of EISs. They can be either embedded into the EIS code or stored separated in a rule base, in order to be processed by a rule engine during the execution of programs.

Business objects
The execution of a business process involves a set of entities called business objects. A business object is a concrete or abstract thing that is relevant to the business system. For instance, resources such as people, money, raw materials, equipment, and data are types of business objects that are required to carry out processes. Clients and suppliers are also types of business objects that participate in many processes. The most common types of business objects are identified in Figure 9.
Each business object has associated a type that describes its structure and behavior. The structure is defined by a set of attributes. Each attribute represents a known property of the object. At a given time, each object is in some state. This state is determined by the set of all the values assigned to the attributes of the object.

Events
Processes are activated by the occurrence of events. An event is an action of very short duration that takes place inside or outside the business system. It signals the starting or ending point of a process. Events may be programmed or non-programmed (casual). For instance, the occurrence of the starting time of an activity that is established in a plan or schedule is a programmed event; whereas the occurrence of an accident or an equipment fault is a non-programmed event.
Events are also classified into external and internal. External events occur in the environment of the business system. The arrival of a service order is an example of external events caused by an external actor or another business system. Internal events happen into the business system. Reaching a production quote and the occurrence of a programmed time for starting (or stopping) a production process are examples of internal events.
An event may change the state of one or more business objects of the business system (see Figure 10). A change of state implies changes in some of the attribute values of a business object.

The BMM Team Model
An important element of any method is the organization of the team that will develop the product. Defining the roles of the team members is crucial to the application of the process model, because it helps the team leader to select the right people and assign the appropriate activities to them. In this section, we describe the structure of a business modeling team and the roles of its members.
A business modeling team can be organized in many different ways depending on the size and complexity of the business system. For small and medium size EIS projects, the business modeling team can be composed by: • A team leader who is responsible for planning, organizing, directing, and controlling the effort and resources needed to model the business system. The BMM team leader is normally the EIS development project leader. • One or more adviser users that bring to the modeling process their knowledge about the business system. • One or more business analysts who interpret the user's knowledge and represent this knowledge using the modeling languages indicated in the product model. Business analysts are responsible for building the components of a business model that are shown in Table 1. • One or more business system managers who are responsible for validating the business model.

The BMM Process Model
This model describes the workflow that is needed to produce a business model during the development of an EIS. The workflow is presented in Figure 11 using an UML activity diagram. This diagram shows only the flow of control between the activities (steps) needed to build a business model.
As illustrated in Figure 11, the business modeling process starts after the EIS project has been planned. The main inputs to the process model are the business system documentation and the knowledge that the actors have about their business system. The output of the process model is a business model, that is, a document that describes the business system that will be supported by the EIS under development. The business model will be then used as a framework for defining and specifying the user's requirements during the Requirement Analysis & Specification phase of the EIS development process (see Figure 2). The BMM process model is composed by nine steps. As indicated in Figure 11, the execution of these steps is cyclic and iterative.
− The cyclic execution of the modeling process. The modeling process evolves through a series of cycles. A cycle is a complete execution of the steps 1-8 (see Figure 11). In each cycle, the BMM team produces a version of the business model. Each version is validated at the end of a cycle. If the business system managers agree on the version, the modeling process is finished and the business model is delivered to the development team, in order to proceed with the EIS Requirements Definition & Specification Phase (as shown in Figure 2). Otherwise, a new modeling cycle is initiated to enhance, correct or improve the most recent version of the business model. − The iterative execution of the modeling process. In each step, the BMM team produces a deliverable, that is, a sub-model or component of the business model version to be delivered at the end of the cycle. The deliverables produced in each of the intermediate Steps 1-7 are verified (reviewed) by the users and the BMM team before advancing to the next step. The Step 0 determines when the modeling process moves from one step to the next, or when the process must return to any previous step to add, modify or correct elements of the sub-models being produced. In Step 8, the business model version is assembled and must be validated or approved by the business system manager before initiating a new cycle or concluding the modeling process.  In Table 2, we describe in more detail the activities that the BMM team must perform in each step and each cycle. For small and medium size EIS projects, two and three cycles of the process model are required to produce an acceptable business model. Table 2 illustrates a three cycle process that was applied in a medium size organization to produce a business model for an EIS that manage the imports and exports of scientific, cultural, and technological products in a Venezuelan custom office [29].
In the first cycle, the process model focuses on identifying the business concepts that are present in a business system, according to the BMM product model (see Figures 3-5, 7-10). The second cycle creates the models (diagrams) for each type of business concept using the modeling languages indicated in Table  1. The third cycle concentrates on the relationships that are present between the business concept models.

Applying the BMM method
To apply the BMM method in an EIS development project, the team leader must firstly instantiate the three models that compose the method, as shown in Figure 12. From the product model described in Section 4, the team leader uses the meta-models to derive the structure and content of the business model. By using the process model described in Section 6, the team leader may derive the specific process to be applied in constructing the business model. Finally, the team leader must use the team model introduced in Section 5 to define the way the modeling team will be organized and the specific roles to be played by each of its members. In order to illustrate the application of the method, we use a real example drawn from a free zone organization, in which the method was fully applied. ZOLCCYT is a scientific, cultural and technological free zone located in Mérida, Venezuela. Its mission is to promote the development of the scientific, cultural and technological sectors (SCT), in that city, by creating incentives to local and national enterprises to produce SCT goods and services. To achieve its mission and objectives, the ZOLCCYT organization is structured into a set of business processes that are represented in the value chain shown in Figure 13. ZOLCCYT was interested in developing an EIS to support the fiscal operations needed to control the import and export activities of the SCT companies that are registered into the ZOLCCYT fiscal regime.
The EIS application domain was defined as a business system composed by business processes PF.3 -PF.6. It is referred to as the Fiscal Regime Business System (FRBS). The FRBS main objective was defined as "to enforce the application of the ZOLCCYT fiscal regime, as stated by the law, by registering SCT enterprises and authorizing, supervising, and controlling their import and export operations".
To develop the FRBS business model, a BMM team was firstly organized by instantiating the team model described in Section 5. The structure of this team is shown in Figure 14 using the VISIO™ notation for organization charts. Then, the BMM team itself instantiated the process model that is described in Section 6. The resulting process is shown in Table 2. Following this process, the BMM team then produced the set of models that integrated the FRBS business model. Figures 15A -15D present some of the most important results that were obtained during the process of modeling the FRBS. The complete ZOLCCYT business model of the FRBS system comprises a total of seven models. Table 3 summarizes the content of the models and gives an idea of the amount of effort required to model a medium size business system. The content of the models refers to the number of diagrams and the number of business concepts in the diagrams that were identified and represented in each model. The modeling languages that were applied, in this case, are also indicated in Table 3. The model was completed in two months by a team composed by four people.

Comparing the BMM method
The BMM method integrates the main concepts included in the most known methods for business modeling: RUP's business modeling [4], EKD [13], Business Modeling with UML [16], and Marshall's Enterprise Modeling [17]. The differences among BMM and these methods are summarized in Table 4. The expressive power ot the five methods are similar. All of them include constructs to model most of the business concepts that are present in any enterprise. Except for BMM, the technologies are not considered by the other models. We believe that modeling the technologies used in a business system is important, since most business processes apply tecnologies to achieve their objectives. Another major difference between the five methods is concerned with their structures. Only BMM and RUP include a team model as part of the method. A team model is important since it explains the roles required to apply the method.

Conclusions
We have presented in this paper a business modeling method, called BMM, which helps EIS development teams to plan, organize, and control the process of modeling EIS application domains. BMM guides a business modeling team to get comprehensive knowledge of a business system before initiating the requirements engineering processes. This knowledge is expressed in terms of the main concepts of a business: goals, technologies, business rules, business processes, business objects, actors, job structure, and events. A good separation of concerns was achieved by structuring the method in three methodological components: the product model, the process model, and the team model. This way of designing and presenting the method facilitates its explanation, understanding and application.
BMM has been fully used in the development of two EISs. In the first case, BMM was used to develop an EIS for managing import/export operations in a free zone organization (as shown in Section 7). In the second case, the method was used to support the development of a geographical information system for an electricity company in Venezuela. These two case studies provided real-world environments that were complete and complex enough for the purpose of evaluating and improving the method. These experiences are reported in [27] and [29]. BMM has also been included as a business modeling phase in METAS, a method for planning the integrated automation of industrial plants [30]. The method is also been used as a teaching instrument for developing small projects in several courses on information systems and software engineering conducted at the University of Los Andes in Mérida, Venezuela.
Based on these application of the BMM method to real problems, we found that the method helps EIS development teams to get: • A better understanding of the EIS application domain. We believe that by modeling the concepts present in the business system, developers can get a more comprehensive knowledge of the business and the nature of problems that the EIS must solve. • Better elicitation and analysis of EIS requirements. The business models produced by the BMM can be used effectively in the process of eliciting requirements in EIS projects. The Business Processes Model, in particular, can be used to identify and describe functional requirements based on the business processes captured in that model. • A better separation between manual and automated process. The business model documents the workflow of a business system and establishes the separation between processes that must be automated and processes that must be performed manually. This separation facilitates the elicitation, analysis and validation of requirements. • An initial definition of business objects, rules, events, and automated processes. The BMM helps the EIS developers to identify and model aspects of the EIS system that are normally identified in later phases of the conventional EIS development methods. The business object model, for instance, can be used as the initial version of the database conceptual design. The rules, events and processes model, on the other hand, can be used as input to the process of designing the EIS architecture and its components.