ENTERPRISE MODELING:MODELING ARCHITECTURES

MODELING ARCHITECTURES

Architecture of Integrated Information Systems (ARIS)

In the architecture of integrated information systems (ARIS), we can distinguish two different aspects of applications:

1. The ARIS concept (ARIS house), an architecture for modeling enterprises, particularly de- scribing business processes

2. The ARIS house of business engineering (HOBE), representing a concept for comprehensive computer-aided business process management.

Both applications are supported by the ARIS Toolset software system, developed by IDS Scheer AG. We will discuss tool support for enterprise modeling in Section 5.

The ARIS concept consists of five modeling views and a three-phase life cycle model. The integration of both leads to 15 building blocks for describing enterprise information systems. For each block the ARIS concept provides modeling methods, meta structures of which are included in the ARIS information model.

As we have already discussed static and dynamic modeling views (see Section 3.1), we can skim over the creation of modeling views. ARIS views are created according to the criterion of semantic correlation similarity, that is, enterprise objects that are semantically connected are treated in the same modeling view. The ARIS modeling views are (see Figure 15):

• Data view: This view includes the data processing environment as well as the messages trig- gering functions or being triggered by functions. Events such as ‘‘customer order received,’’

‘‘completion notice received,’’ and ‘‘invoice written’’ are also information objects represented by data and therefore modeled in the data view.

• Function view: The business activities to be performed and their relationships form the function view. It contains the descriptions of each single activity (function) itself, the associations be- tween super- and subordinate functions, and the logical sequence of functions. Enterprise goals that guide the performance of the functions and the application systems that support their execution are also components of this view.

• Organization view: Departments, office buildings, and factories, are examples of organizational units that perform business functions. They are modeled according to criteria such as ‘‘same function’’ and ‘‘same work object.’’ Thus, the structure as well as the interaction between or- ganizational units and the assigned resources (human resources, machine resources, computer hardware resource) are part of the organization view.

• Output view: This view contains all physical and nonphysical output that is created by business functions, including services, materials, and products as well as funds flows. Because each output is input for another function—even if this function is probably carried out by an external partner—input–output diagrams are also components of this view.

• Control view / process view: In the views described above, the classes are modeled with their relationships relative to the views. Relationships among the views as well as the entire business process are modeled in the control or process view. This enables a framework for the systematic inspection of all bilateral relationships of the views and the complete enterprise description using a process-oriented perspective.

The ARIS concept provides a set of methods that can be used to model the enterprise objects and their static and dynamic relationships. For each view at least one well-proven method is provided. Because ARIS is an open architecture, new modeling methods, such as UML methods, can easily be integrated into the meta structure. Figure 16 gives examples of ARIS methods for conceptual mod- eling.

Up to now, we have discussed enterprises, particularly business processes, from a management point of view, that is, without any particular focus on information technology. The aforementioned application programs (components of the function view), computer hardware (a component of the organization view), and data media (components of the data view) contain only system names, not IT descriptions. These are included in the ARIS concept by evaluating the IT support provided by each ARIS view.

• Function views are supported by the application programs, which may be described in more detail by module concepts, transactions, or programming languages.

• Organization views, along with their production resources and the computer resources respon- sible, may be detailed further by listing network concepts, hardware components, and other technical specifications.

• Data views may be detailed more precisely by listing data models, access paths, and memory usage.

• Output views group the various types of output, such as material output and information ser- vices. Here again there is a close alignment with the supporting information technology. In material output (e.g., entertainment technology, automobiles, and machine tools), more and more IT components (e.g., chip technology), along with the necessary hardware, are used. Other service industries, such as airline reservations, are closely linked with IT as well.

• The fact that the respective views can be combined within the control view means that there is a definite link with IT, as demonstrated by the above arguments.

Using a phase model, enterprise models are thus transformed step by step into information and communication technology objects (see Figure 17).

The starting point of systems development is the creation of an IS-oriented initial strategic situ- ation in Phase 1. ‘‘IS-oriented’’ means that basic IT effects on the new enterprise concepts are already taken into account. Some examples of these relationships might be creating virtual companies through communication networks, PC banking, integrated order processing and product development in in- dustry (CIM), or integrated merchandise management systems (MMS) in retail.

Strategic corporate planning determines long-term corporate goals, general corporate activities, and resources. Thus, planning has an effect on the long-term definition of enterprises, influencing corporate goals, critical success factors, and resource allocation. The methods in question are similar to management concepts for strategic corporate planning. Provided actual business processes have already been described, this occurs in a general fashion. At this stage, it is not advisable to split up functions into ARIS views and then describe them in detail.

In Phase 2, the requirements definition, individual views of the application system are modeled in detail. Here as well, business-organizational content is key. Examples of business processes should be included at this level. However, in this phase more conceptual modeling methods should be used than in the strategic approach because the descriptions for the requirements definition are the starting point for IT implementation. Modeling methods that are understandable from a business point of view should be used, yet they should be sufficiently conceptual to be a suitable starting point for a

consistent IT implementation. Therefore, it makes sense to include general IT objects, such as da- tabases or programs, at this level.

Phase 3 calls for creating the design specification, where enterprise models are adapted to the requirements of the implementation tool interfaces (databases, network architectures, or programming languages, etc.). At this time, actual IT products are still irrelevant.

Phase 4 involves the implementation description, where the requirements are implemented in physical data structures, hardware components, and real-world IT products.

These phases describe the creation of an information system and are therefore known as buildtime. Subsequently, the completed system becomes operable, meaning it is followed by an operations phase, known as runtime. We will not address the operation of information systems, that is, runtime, in great detail.

The requirements definition is closely aligned with the strategic planning level, illustrated by the width of the arrow in Figure 17. However, it is generally independent of the implementation point of view, as depicted in the narrow arrow pointing to the design specification.

Implementation description and operations, on the other hand, are closely linked with the IT equipment and product level. Changes in the system’s IT have an immediate effect on its type of implementation and operation.

The phase concept does not imply that there is a rigid sequence in the development process, as in the waterfall model. Rather, the phase concept also includes an evolutionary prototyping procedure. However, even in evolutionary software development, the following description levels are generally used. Phase models are primarily used because they offer a variety of description objects and methods.

The ARIS concept in Figure 18 is enhanced by the phases of the buildtime ARIS phase model. After a general conceptual design, the business processes are divided into ARIS views and docu- mented and modeled from the requirements definition to the implementation description. These three description levels are created for controlling purposes as well. This makes it possible to create the links to the other components at each of the description levels.

The ARIS concept paves the way for engineering, planning, and controlling enterprises, particu- larly business processes. The ARIS house of business engineering (HOBE) enhances the ARIS con- cept by addressing comprehensive business process management from not only an organizational but an IT perspective. We will outline how ARIS supports business management in the design and development stages, using ARIS-compatible software tools.

Because business process owners need to focus on the ‘‘one-shot’’ engineering and description aspects of their business processes, ARIS HOBE provides a framework for managing business pro- cesses, from organizational engineering to real-world IT implementation, including continuous adap- tive improvement. HOBE also lets business process owners continuously plan and control current business procedures and devote their attention to continuous process improvement (CPI). Compre- hensive industry expertise in planning and controlling manufacturing processes is a fundamental component of HOBE. Objects such as ‘‘work schedule’’ and ‘‘bill of material’’ provide detailed description procedures for manufacturing processes, while production planning and control systems in HOBE deliver solutions for planning and controlling manufacturing processes. Many of these concepts and procedures can be generalized to provide a general process management system.

• At level I (process engineering), shown in Figure 19, business processes are modeled in ac- cordance with a manufacturing work schedule. The ARIS concept provides a framework cov- ering every business process aspect. Various methods for optimizing, evaluating, and ensuring the quality of the processes are also available.

• Level II (process planning and control) is where business process owners’ current business processes are planned and controlled, with methods for scheduling and capacity and (activity- based) cost analysis also available. Process monitoring lets process managers keep an eye on the states of the various processes.

• At Level III (workflow control), objects to be processed, such as customer orders with appro- priate documents or insurance claims, are delivered from one workplace to the next. Electron- ically stored documents are delivered by workflow systems.

• At Level IV (application system), documents delivered to the workplaces are specifically pro- cessed, that is, functions of the business process are executed using computer-aided application systems (ranging from simple word processing systems to complex standard software solution modules), business objects, and Java applets.

HOBE’s four levels are linked with one another by feedback loops. Process control delivers information on the efficiency of current processes. This is where continuous adaptation and improve-

ment of business processes in accordance with CPI begins. Workflow control reports actual data on the processes to be executed (amounts, times, organizational allocations) to the process control level. Application supporting modules are then started by the workflow system.

In the fifth component of the HOBE concept, Levels I through IV are consolidated into a frame- work. Frameworks contain information on the respective architecture and applications, configuring real-world applications from the tools at levels II and III as well as application information from the reference models (level I). Frameworks contain information on the composition of the components and their relationships.

Information Systems Methodology (IFIP-ISM)

Olle et al. (1991) give a comprehensive methodology for developing more traditional information systems. The designation ‘‘methodology’’ is used at the same level as ‘‘architecture.’’ The seven authors of the study are members of the International Federation for Information Processing (IFIP) task group, in particular of the design and evaluation of information systems working group WG 8.1 of information systems technical committee TC 8. The research results of the study are summarized in the guideline ‘‘Information Systems Methodology.’’

The design of the methodology does not focus on any particular IS development methods. Rather, it is based on a wide range of knowledge, including as many concepts as possible: IDA (interactive design approach), IEM (information engineering methodology), IML (inscribed high-level Petri nets), JSD (Jackson system development), NIAM (Nijssen’s information analysis method), PSL / PSA (prob- lem statement language / problem statement analyzer), SADT (structured analysis and design tech- nique) as well as Yourdon’s approach of object-oriented analysis.

This methodology is described by metamodels of an entity relationship concept. It features the point of view and stages of an information system life cycle, distinguishing data-oriented, process- oriented, and behavior-oriented perspectives (see Figure 20). Creating these perspectives is less a matter of analytical conclusion than simply of reflecting a goal of addressing the key issues typical in traditional IS developing methods.

Entity types and their attributes are reviewed in the data-oriented perspective. The process-oriented perspective describes events (business activities), including their predecessor or successor relation- ships. Events and their predecessor or successor relationships are analyzed in the behavior-oriented perspective.

From a comprehensive 12-step life-cycle model we will select three steps, information systems planning, business planning, and system design, and then examine the last two in detail in terms of their key role in the methodology.

Information systems planning refers to the strategic planning of an information system. In business analysis, existing information systems of an entire enterprise or of a subarea of the enterprise are

analyzed. The respective information system is designed in the step system design. This concept also includes a comprehensive procedural model, including a role concept for project organization.

With regard to ARIS, this concept has some overlapping areas. In others there are deviations. What both concepts have in common is their 2D point of view, with perspectives and development steps. There are differences in their instances, however. For example, Olle et al. do not explicitly list the organization view but rather review it along with other activities, albeit rudimentarily. The process definition more or less dovetails with ARIS’s function definition. Data and functions or events and functions are also strictly separated from one another. The three perspectives linked together are only slightly comparable to ARIS control view. The step system design blends together the ARIS phases of requirements definition and design specification, with the emphasis on the latter.

CIM Open System Architecture (CIMOSA)

The ESPRIT program, funded by the European Union (EU), has resulted in a series of research projects for developing an architecture, Computer Integrated Manufacturing Open System Architec- ture (CIMOSA), for CIM systems. CIMOSA results have been published by several authors, including Vernadat (1996). This project originally involved 30 participating organizations, including manufac- turers as the actual users, IT vendors, and research institutes. Although the project focused on CIM as an application goal, its mission was to provide results for general enterprise modeling. One of CIMOSA’s goals was also to provide an architecture and a methodology for vendor-independent, standardized CIM modules to be ‘‘plugged’’ together, creating a customer-oriented system (‘‘plug and play’’).

The CIMOSA modeling framework is based on the CIMOSA cube (see Figure 21).

CIMOSA distinguishes three different dimensions, described by the three axes of the cube. The vertical direction (stepwise derivation) describes the three description levels of the phase concept:

requirements definition, design specification, and implementation description. These levels are for the most part identical with those of the ARIS life cycle.

In the horizontal dimension (stepwise instantiation), concepts are individualized step by step. First, basic requirements (generic requirements, building blocks) are defined, then particularized in the next step according to industry specific requirements (partial requirements). In Step 3, they are broken up into enterprise-specific requirements (particular requirements).

This point of view makes it clear that initially, according to CIMOSA, general building blocks should be used to define standards, after which the building blocks are grouped into industry specific reference models. In the last step, they are used for developing enterprise-specific solutions. In ARIS,

the degree of detailing an information model is defined while the granularity issues are addressed.

By directly entering content-related reference models, the CIMOSA architecture, it becomes clear, combines general methodological issues regarding information systems and application-related CIM domains.

The third dimension, stepwise generation, describes the various views of an information system. This point of view has goals similar to ARIS regarding the creation of views, although not all the results are the same. CIMOSA divides description views into function view, information view, re- source view, and organization view. Function view is the description of events, although it also includes a combination of other elements such as events and processes, including performance and exception handling. Information view refers to the data view or object definition. Resource view describes IT and production resources, and organization view implies the hierarchical organization.

CIMOSA also breaks up the entire context into various views, although it lacks a level for reassembling them, as opposed to ARIS with its control and process views. This results in the fact that in CIMOSA, descriptions of the individual views are combined with one another. For example, when resources are being described, they are at the same time also allocated to functions. The CIMOSA modeling concept does not feature an output view.

The CIMOSA concept develops an architecture suitable for describing information systems, into which content in the form of standardized reference models, all the way to actual software generation, can be entered. Despite the above-mentioned drawbacks, it considers important points. Based on this concept, modeling methods are classified in CIMOSA and described by metamodels, all the while adhering to an event-driven, business process-oriented view. Furthermore, enterprises are regarded as a series of multiple agents communicating with one another.

Despite the considerable financial and intellectual efforts spent on CIMOSA, its practical contri- bution so far has been minimal. Business users involved in the project have so far reported few special applications resulting therefrom, with the exception of the car manufacturer Renault with a repair service application for manufacturing plants and the tooling company Traub AG with an application for optimizing individual development of tools. To date, a CIMOSA-based modeling tool has not been used much in practice.

The main reason for the lack of success in real-world applications is presumably its very theo- retical design, which does not incorporate commercially available IT solutions (standard software, for example). Considering the general lack of interest in CIM concepts, the extremely specialized focus of this approach seems to be working to its disadvantage.

Zachman Framework

A framework for describing enterprises, quite popular in the United States, was developed by J. A. Zachman. This concept is based on IBM’s information systems architecture (ISA) but has been enhanced and presented by Zachman in numerous talks and seminars.

This approach (see Figure 22) consists of six perspectives and six description boxes. In the ARIS terminology, Zachman’s description boxes would equate to views and perspectives would equate to the levels of the life-cycle model.

Perspectives are listed in brackets along with the respective role designations of the party involved: scope (planner), enterprise model (owner), system model (designer), technology model (builder), components (subcontractor), and functioning system (user).

The areas to be viewed are designated by interrogatives with the respective actions listed in brackets: what (data), how (function), where (network), who (people), when (time), and why (ration- ale). Perspectives and files to be viewed are at a right angle to one another. Every field in the matrix is described by a method.

Contrary to ARIS, the Zachman framework is not capable of being directly implemented into an information system and the relationships between the description fields are not entered systematically. Furthermore, the relationship of Zachman’s framework with the specific creation of output within the business process is not apparent.

Initial approaches for supporting tools are becoming apparent, thanks to cooperation with Frame- work Software, Inc.