Challenging the Unpredictable Changeable Order Management Systems

Overview

Joachim Berlak
Technische Universitaet Muenchen, Germany

Bernhard Deifel
Technische Universitaet Muenchen, Germany

Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Abstract

This chapter deals with the changeability of order management systems (OMS). OMS are here referred to complex commercial off-the-shelf software (CCOTS) used, for example, for enterprise resource planning (ERP). Due to turbulent conditions in the business environment, a permanent need for change is the defining challenge for enterprises. However, far too often the rigidity of today's CCOTS-OMS does not allow users to implement the intended changes in the business organization. In order to deal with this challenge, a cybernetic model of order management is presented in this chapter. Additionally, a decision oriented software engineering and architectural design for CCOTS-OMS is sketched. The authors are convinced that these approaches enhance the changeability of the development and operation of CCOTS-OMS as well as their co-operation with a business organization.

Introduction

The inevitability of rapid change in the competitive environment of business is a commonly agreed fact (Das & Elango, 1995; Tetenbaum, 1998). The changing business environment, coupled with maturing sales and procurement markets, results in enormous pressures on enterprises in their efforts to be competitive (Vollmann, Berry, & Whybark, 1993). Hence, companies have to operate their businesses under increasingly complex, turbulent, uncertain and unpredictable conditions. Significantly, the dynamic features of this turbulent environment are not just the outcome of the interactions between enterprises (Chakravarthy, 1998; Reinhart et. al., 1999; Schreyoegg, 1999). Furthermore, this turbulence is generated by the business environment itself (Emery & Trist, 1965).

To cope with these conditions, a permanent need for change will be the defining feature in the future business landscape (Bower, 1994; Milberg, 1997). However, especially small and medium-sized enterprises (SMEs) are challenged by the turbulence on sales and procurement markets. According to the European Council (1996), these enterprises can be characterized by less than 250 employees and 40 million € sales volume per year. SMEs commonly produce parts, subassemblies, products and/or service for large-scale manufacturers (Hauser, 2001). Hence, SMEs are located at the lower levels of their encompassing supply chain (see Figure 1).

Figure 1: An exemplified supply chain and the bullwhip effect

A supply chain starts from the origin of the raw material and ends once the product has been consumed by a customer (Fredenall & Hill, 2000). The so-called "bullwhip effect," which is presented in Figure 1 and typical for supply chains, may be one explanation for the turbulent, uncertain and unpredictable conditions often perceived by SME suppliers (Forrester, 1961). This effect comprises unexpected changes in demand patterns that continue to escalate further down the supply chain (Chopra & Meindl, 2000). Due to distortions of information flows and a minimal communication between the participating companies, a small wave in the middle of the ocean (steady customer demand) ends up as a tidal wave near the shore (fuzzy demand appreciated by suppliers). In addition, other factors like the ongoing globalization of competition and the growing pressure on costs and shareholder value, as well as an increasing individualization of products, causes external turbulences for SME suppliers (see Figure 2).

Figure 2: Need for organizational change vs. OMS rigidity (Berlak & Deifel, 2002)

As mentioned before, SMEs deliver products and/or services by the transformation of orders from their encompassing supply chain and/or an internal sales plan. Accordingly, this so-called order management process is formed by the interaction of man and the structural and process organization, as well as the used technology (e.g., an OMS). In order to stay competitive, an enterprise acts like a closed feedback system using performance measurement to evaluate the effectiveness and efficiency of the order management process. In case of deviations due to external turbulences or internal insufficiency, essential changes are initiated.

However, far too often these changes in the business organization and/or processes can not be implemented as intended. The lack of ability of today's order management systems (OMS) to support necessary organizational changes is a substantial cause for this problem. An empirical investigation regarding Suisse SMEs revealed that almost 47% confirmed the interference of their existing OMS with organizational changes. Furthermore, only 35% deployed an OMS with suitable functionality to cover their changing requirements (see Figure 3).

Figure 3: Results of an empirical investigation of Suisse SMEs (Hafen et. al., 1999)

Reasons for the rigidity of OMS are various will be described later on. As a consequence, research is challenged to develop changeable OMS, which adequately support business changes. Furthermore, the entire co-operation between a business organization and the OMS must be tailored towards changeability.

The research project CHANGESYS of the Research Consortium for Software Engineering (FORSOFT), which is funded by the Bavarian Research Fund, focuses on this challenge.

In this applied science research project, an interdisciplinary team of researchers in the field of industrial management, mechanical and software engineering is working closely together with different companies like Rohde and Schwarz (an OMS user) and OCE Printing Systems (an OMS user and manufacturer), as well as ADICOM (an OMS manufacturer). The main research objective is to get a comprehensive understanding of the correlation of organizations and OMS in the case of changes (see Figure 4). In addition, concepts to enhance the changeability of OMS, organizations and the co-operation between both are developed.

Figure 4: Structure of the research project CHANGESYS

In this chapter, corresponding research results are presented. First, a cybernetic model of order management is developed. This approach communicates a mutual understanding of the interdisciplinary synergy of an organization and the OMS. Furthermore, a decision-oriented approach, which allows a systematic derivation of an architectural design for such kind of software, is sketched. Additionally, decision orientation is applied for the first steps of architectural CCOTS-OMS design. Finally, a conclusion and an outlook for future research are presented.

Basic Terms and Definitions

In this chapter, basic terms and definitions are introduced.

Order Management

The term order management denotes, in general, the value creation process initiated by certain customers and/or sales plan, covering all planning and execution tasks from the order receipt to the final delivery of the manufactured product (Anderson & Pine, 1997). However, this term is widely defined and used in literature and practice (Darr, 1992). In order to declare the term order management, the following model is applied (Figure 5).

Figure 5: Order management (Berlak, 2001)

In this context, the order management process encompasses all activities and organizational units that are necessary for the transformation of orders into products. Thereby, the preliminary tasks for inquiry and offer handling are excluded. On that basis, software used for the support of the order management process is examined in further detail.

Order Management Systems

In general, an information system consists of hardware, an operating system, and the software application, as well as the appropriate data (Broy & Denert, 2001). The prevailing work focuses on business software, which encompasses administration applications (e.g., for financial accounting, etc.) and management information systems, as well as office automation and communication software (Meyers & Oberndorf, 2002). Due to the diversity of business software, the generic term order management system (OMS) is introduced and defined as follows: OMS are complex commercial off-the-shelf business software (CCOTS) which support the order management. Hence, business software for the following fields of application can be assigned to OMS (see Figure 6): Factory Data Collecting (FDS), Production Activity Control (PAC), Production Planning and Control (PAC), Enterprise Resource Planning (ERP), Workflow Management (WFM) or Supply Chain Management (SCM).

Figure 6: Order management systems (Berlak, 2003)

The different types of software subsumed by the term OMS are described in the following:

• A Factory Data Collection software (FDC) is a tool to receive, capture, process and analyze shop floor data by sensors or manual data input terminals (Jansen, 1993). FDC usually exists in combination with PAC, PPC or ERP software.
• Production Activity Control software (PAC) coordinates the operational implementation of production plans (Meinberg & Topolweski, 1995). However, there is no unique definition of the term PAC (Scheer, 2000). General tasks of a PAC software are machine and resource scheduling, capacity planning, and manufacturing order release, as well as order progress control (Maucher, 1998). An empirical investigation of 320 PAC applications indicates that these systems are linked in 95% of cases with a super-ordinate PPC or ERP software (Köhler, 1999). Furthermore, approximately 50 % of the examined PAC systems are connected with a FDC software in order to enable a highly realistic production activity control.
• Production Planning and Control software (PPC) is used for computer-aided planning, controlling and monitoring of the technical order management spanning the order request until the final delivery (AWF, 1985). Hence, PPC software possesses a large variety of functionality including, for example, order scheduling as well as capacity and resource planning (Scheer, 2000). The first PPC software programs emerged in the 1950s (Maucher, 1998). In the last ten years nearly all industrial companies with more than 500 employees implemented such software (Kernler, 1995). ERP software evolved by the extension of PPC software with other business functionalities (O' Leary, 2000).
• Enterprise Resource Planning software (ERP) is an integrated and packaged software for the entire order management (Davenport, 1998). ERP packages consist of certain modules, for example, financial and accounting, selling, stock management, production, personnel management, customer care or service (Hiquet, 1998).
• A Workflow of Management software (WFM) is responsible for the processing, control and management of organizational workflows (Jablonski et. al., 1997). WFM software is evolved by technological developments in the areas of the document management systems (Gulbins et. al. 1998), active databases (Dittrich & Gatziu, 1996) and groupware software (Khoshafian & Buckiewicz, 1995). WFM systems can be used to support the activities carried out in the order management process.
• Supply Chain Management software (SCM) enables the optimization of inplant and inter-company order management by new simulation functionality (Evans et. al., 1996). Today, SCM software is usually set up on existing ERP systems offering a memory resident simulation, analyze and configuration of a supply chain model. After planning different scenarios, the simulation results can be transferred back to the ERP software. At present, SCM vendors try to enhance their software with ERP functionality. On the other hand, ERP vendors try to include SCM simulation functionality (Harnwell, 1998).

In summary, the generic term OMS is used for the above mentioned FDC, PAC, PPC, ERP, WFM and SCM software tools. Mainly, OMS are CCOTS and therefore developed for a specific application field where they offer predefined functionality (Broy & Denert, 2002). The main difference between CCOTS and an individual software is that the CCOTS have to be adapted to a business organization before use, where as the individual software is developed for one specific customer (Cockburn, 2001). This so-called customizing of OMS is carried out by setting certain parameters and data tables within the software. For example, up to 8.000 tables and parameters must be adjusted in the OMS SAP R/3 (Hiquet, 1998). Thus, the customizing is associated with high financial expenditures for management consultants and software developers (Weiss, 2000). As a consequence, enterprises tend to "never touch a running system" once their OMS is customized (Wallace & Kremzar, 2001). This in turn stimulates an emerging dilemma: Necessary organizational changes due to turbulences on sales and procurement markets cannot be implemented due to the rigidity of an running OMS. Hence, the next section deals with the fundamentals of an OMS changeability.

Changeability of Order Management Systems

The term changeability is defined and discussed differently in literature, a unique definition did not yet intersperse itself so far (Duerrschmidt, 2001). The emphasis of past investigations was situated mainly in the disciplines of production management and economics where changeability describes a general ability of an enterprise to adapt to changing business conditions and environments (Kotter, 1996). In the software engineering community, this term is not often used and relatively uncommon. Hence, the prevailing work postulates the following model for changeability regarding CCOTS-OMS (see Figure 7).

Figure 7: Context of changeability and OMS operation (Berlak & Deifel, 2002)

CCOTS-OMS are developed according to certain goals (e.g., return on investment, market shares, etc.) and restrictions (e.g., development tools, costs, etc.) of the software manufacturer. Core requirements for the OMS result from the application field (e.g., user requirements, etc.). Due to their characteristics, CCOTS-OMS are configured to a specific organization before use (Configuration State n). During operation, OMS act as a service provider for tasks of the order management process. Hence, the changeability of OMS can be described as follows.

As long as the order management process does not change, the entire cooperation between the OMS and the organization is in a steady state. However, if the business environment changes significantly, the order management process must be adapted accordingly. The OMS ability for change consists of two change potentials, flexibility and responsiveness.

During operation of the OMS, software modifications can be achieved by the implemented software functionality. The so-called flexibility of the OMS describes a predefined change potential identified and implemented by the software manufacturer during the OMS development. If changes can be realized by the flexibility of the OMS, the user is able to solve the occurring problems on his own (e.g., resetting parameters, using alternate functions or data, etc.). If the existing OMS flexibility is not sufficiently supporting the changes of the order management process, another change potential must be assessed.

The so-called responsiveness shows the background of the predefined and implemented change potential of an OMS. Here, humans' problem-solving ability and creativity is used to modify and/or expand the OMS to deliver an optimal problem solution. For example, OMS interfaces can be used to develop additional software solutions (e.g., self-developed add-on solutions). As another opportunity, organizational changes could be initiated to solve the order management problems without using additional OMS functionalities. With a more timely and/or costly expenditure, an update of the existing OMS or, additionally, software solutions from other vendors could be installed in order to solve the problem.

In summary, the changeability of OMS can be characterized by the change potentials of flexibility and responsiveness. Hereby, flexibility is implemented in the OMS during software development. However, responsiveness means to find solutions for not assumed problems when the flexibility of an OMS is exceeded. Building upon these definitions, the cybernetic model of order management is introduced in the following.

Cybernetic Model of Order Management

In order to communicate a mutual understanding of the interdisciplinary synergy of an organization and OMS, this cybernetic approach was developed. The term cybernetic belongs to control engineering and describes a closed feedback system that remains stable despite disturbances (Wiener, 1948). A control loop consists of a regulated system, a measurement unit and a controller. The latter affects the controlled system, whereby the success of the adjusting measure is steered. Figure 8 presents the cybernetic model of order management.

Figure 8: Cybernetic model of order management (Berlak & Deifel, 2002)

According to this model, enterprises are treated as open systems exposed to a dynamic business environment, in which they fulfill orders by delivering products. Hence, the order management process encompasses all organizational activities for transforming customer and/or sales plan orders into products. In order to be competitive, a measuring system for the process' effectiveness and efficiency is used. In case of occurring deviations, changes in the order management's organization and process structure are initiated. As can be seen later, the selection of an adequate organizational change strategy is negotiated with the controller of the OMS control loop in order to select an optimal strategy for the entire company. Today, this connection is often lacking. Organizational change strategies, like moving from a MRPII based production planning towards a Kanban strategy, are often initiated without the coordination with the OMS control loop. The results range from higher efforts and less profits to a worse case stop of the implementation.

In order to ensure an optimal effectiveness and efficiency of the order management process, an adequate software support by an OMS is needed. Therefore, the OMS control loop is responsible to deliver suitable solutions for the occurring tasks and problems from the organizational control loop. Discrepancies between required and offered solutions may be identified by using a measuring system. In case of inefficiencies, the OMS has to be modified by the application of an adequate controller strategy. As mentioned before, the selection of an optimal strategy of the OMS controller works in close cooperation with the organizational control loop to achieve a global optimum. This cooperation is symbolized in Figure 8 by the connected gear wheels. In the following, both control loops are described in further detail.

The Control Loop Organization

The main goal of the organization control loop is the efficient operation of the order management process. Therefore, a measuring system based on a key-performance-indicator (KPI) is used, based on research results from Frese (1992), Theuvesen (1996) and Werder (1999). Hence, efficiency is referred to as the decisive and decision relevant criterion for the evaluation of alternative organization structures, business processes and organizational measures. The measurement system forms the base for a comparison of actual and nominal values. The latter are determined by method tool set consisting, for example, of benchmarking techniques, time series analyses and market/customer opinion polls.

In case of exceeding KPI-specific threshold values, the organizational controller has to intervene. Hence, changes in the structural and/or sequence organization of the order management process are initiated concerning coordination, decision, information, control and motivation aspects. Therefore, the controller uses a strategy database consisting of certain strategies (e.g., outsourcing of activities). Heinen (1991) defines a strategy as the global way to reach certain goals, which represent the nominal values mentioned before. Every strategy may be determined by the attribute's expenses, benefits, restrictions, context and measures. The evaluation of expenses, benefits and restrictions of a strategy is carried out in close cooperation with the OMS controller. The same procedure takes place for the selection of an entire optimal strategy whose measures are implemented afterwards. For further details about this control loop it is referred to in Berlak (2001) or Berlakand Deifel (2002).

The Control Loop OMS

The OMS control loop acts as a service provider to deliver optimal solutions for the occurring tasks and problems of the order management process. Hence, an OMS offers several functions and services, which are recorded by an appropriate measuring system. Mainly, measuring criteria like the effectiveness, efficiency, convenience or suitability of the services are addressed. Deviations clarify that the occurring problems in the order management process cannot be solved by adequate services. For example, if a key account customer requires a daily instead of a weekly delivery, and the existing OMS has just the flexibility to plan weekly, the problem cannot be solved. In such a constellation the OMS controller must change the structure and/or the processes of the OMS. Hence, the flexibility and/or the responsiveness of the software system must be addressed for these adaptations.

In principle, four main strategies for the OMS controller can be performed. First, the entire OMS or its modules can be replaced. Secondly, the existing OMS and/or its modules can be extended by purchased or self-developed software modules. Thirdly, the OMS and/or its modules can be reengineered. And fourthly, the users can be trained. For the selection of a suitable strategy the close coordination and cooperation with the organizational control loop is substantial.

A substantial part of the OMS control loop is its coupling for the systematic evolution of a CCOTS-OMS. In Deifel (2001) a concept for process modeling is presented, which places decisions explicitly into the focal point of each software development activity. Hence, it's possible to create a holistic and systematic transition from the identified deviations of the OMS control loop, over to requirements engineering, up to the architectural software design. The developed process model describes gradual steps from system-independently structured requirements to the aspects and variations of a first architectural design.

The above mentioned flexibility of an OMS is supported by a software architecture, in which several variations are contained and whose activation is to a large extent systematically enabled. However, the responsiveness of a CCOTS is influenced by two other substantial factors. For a vendor, independent reaction and adequate disclosure and standardization of interfaces is required. On the other hand, the responsiveness of the software producer can be improved by facilitating the advancement of the OMS accordingly. This requires a systematic version-spreading and evolutionary development of the CCOTS-OMS.

In the following section, this decision-oriented approach to CCOTS-OMS software development is described in further detail.

Decision Oriented Software Development

The OMS control loop has two main influences on the OMS. Firstly, it influences how the OMS should be customizable, i.e., how the shipped and installed software should be adaptable to customer's problems. The second influence refers to the evolution of the installed software. The two subjects are comparable to problems in the product line area. There a distinction between specifics and commonalties of different software systems in the same application domain is made. Customization relates to the problem of how to derive specifics of individual customers, whereas evolution is a problem of how to define a common reusable architecture for a product line. The OMS control loop results in a decision: whether a customization of the installed software suffices, whether it triggers the evolution of the OMS, or even both. Furthermore, it constrains what has to be done in the follow-up operations.

In this section, the focus is on the evolution of CCOTS-OMS. In Deifel (2001) and Deifel, Schwerin and Vogel (1999), the basics of the decision oriented software development process were presented. Here, the main ideas of this concept are sketched and related to the described OMS control loop. Firstly, the tri-section of development process models into roles, activities and work products is described. Then, an overview over elements of decision oriented development processes is given before the model of work products is introduced. Finally, techniques supporting the description of the introduced model elements are presented.

Roles, Activities and Work Products

A classical principle for modeling development processes is the distinction of the main element types' roles, activities and work products (Derniame, Kaba, & Wastell, 1999), which are shown in Figure 9. The distinctions aim at a clear structuring of the development processes in order to support efficient resource planning, adequate task sharing, traceability and consistency tests between different work products.

Figure 9: Elements of the development process

The elements of the development process are:

• Role: Roles define tasks and responsibilities of persons who participate on the development, so-called actors.
• Work product: These are central work pieces and results of the development. The most important work product is the developed CCOTS system. Further, in order to reach a systematic development, different work products are necessary to document guidelines and substantial intermediate results. Between different work products exist dependencies, which are described by means of an extra model of work products.
• Activity: Work products are stepwise results of development activities, which are executed by actors. Activities are triggered by predefined initial states of related input work products. They finish when their output products reache a specific final state. The execution of different activities only is coupled by product states. This differentiates this from many existing process models which prescribe a certain sequence of activities.

On that basis, the next section deals with the decision oriented approach for the software development process.

Decision Oriented Software Development Process

The observation that each software development has to pass a sequence of different decision situations led to the idea to model development processes focusing on these. In principle, a decision situation consists of the following elements:

• Problem space: The focused problem of a decision situation.
• Decision object: Factors which directly influence the resulting solution. In each decision situation more than one decision object can participate.
• Alternative: For a given problem space, different possible solutions are defined. The derivation of alternatives is a central part of each decision situation.
• Measurement criterion: In order to select the best solution, alternatives have to be evaluated. Measurement criteria drive what is measured in alternatives.
• Objective function: With the objective function, the optimization criterion of a decision problem is described. An objective function constrains the minimization or maximization of single measurement criteria and their mutual weights.
• Solution: The solution represents the final selected alternative. It represents the optimum of derived alternatives with respect to the given objective function.
• Guidelines: Guidelines serve for the systematic derivation of alternatives.

Figure 10 gives an overview of correlations between different elements of a decision situation. The elements of a decision situation are represented by different work products, whereas one work product may even be mapped to different elements within one decision situation at the same time.

Figure 10: Elements of a decision situation

During the execution of the decision oriented software development process, the contents of assigned work products are filled stepwise. When each work product has reached a certain predefined state the decision can be made. The steps of work are made within the activities mentioned before. It is differentiated between two kinds of activities, the preparations and the decisions. Within preparations, work products are filled without any preceding decision situation. Compared to the structure of decisions is predefined of a decision situation.

As stated in Deifel (2001), this kind of modeling of the development processes fundamentally increases traceability of development steps and their flexibility. The order of activities is only restricted by mutual dependencies of associated work products. Such dependencies will be demonstrated for work products in architectural design later on in this section.

Development activities within a decision oriented development process can be described schematically with predefined templates. Within this section only the contents of such templates can be sketched, for further details see Deifel (2001). Decisions are described with items like problem space, associated roles, decision objects, measurement criterion, objective function, solution, guidelines, restrictions and method. The template for preparations consists of the associated decision situation, roles, input- and output-work products, guidelines, motivation and method.

Work Products for Software Development

As mentioned at the beginning of this section, work products are in the eye of the decision oriented software development process. Now, the concept of modelling work products introduced in Deifel, Schwerin and Vogel (1999) as well as Deifel (2001) is presented. Important is to describe types of work products and their mutual relationships. In the following paragraphs, a concept for a model of work products is described, consisting of:

• Product types: Basic characteristics of a work product are described by its attributes. Product types may be aggregated of other product types. Similarities between work product types are be expressed by hierarchical generalizations/specializations, which is used here in the sense of a classical "is a"-relationship.
• Product relationships: Relationships between work products can be expressed by associations. These associations have the same meaning as relationships in E/R-modeling (Chen, 1976). They can be described more precisely by attributes. Further, work products corresponding to an association can be assigned to roles with respect to the specific association.
• Model states: The execution of activities depends on model states. The state of a work product is represented by currently associated attributes, its' currently aggregated work products and its' associated work products. The state of an association describes currently defined associations of association types. The model state is defined by currently defined work products, their states and the state of associations.
• Description of the model: Within the current paper we use graphical and textual elements for describing the model of work products. A considerable description further can contain also formal techniques (Deifel, 2001). For the graphical notation it is referred to the notation of UML-class diagrams (Rumbaugh, Jacobson, & Booch, 1999).

Work Products Decision Oriented Development

Within activities, work products are adequately mapped to the elements of the corresponding decision situation. Due to the same contents, alternatives and the solution of a decision situation are allocated to the same product types. In order to manage complex decision situations, alternatives may be structured hierarchically to divide the problem space into problem parts. To represent this, AND- and OR-aggregations are used. AND-aggregations denote the decomposition of a problem space into corresponding problem parts and OR-aggregations denote alternatives for a corresponding problem part.

Decision Oriented Architectural Design

In the last section, a model for decision oriented software development was presented. Deifel (2001) describes how to elicit requirements for CCOTS and how to develop a consistent requirements specification, which reflects a compromise between customer needs, development costs and development time. The elicitation for requirements is done within the cybernetic model of order management described in the above section. Within this section, a systematic architectural design for CCOTS-OMS, with an intensive use of a model of work products, is outlined. At the beginning, a definition of the term software architecture is given. Then, the concepts of aspects and variations are sketched. In the end, a model of work products for architectural design is presented.

Software Architecture

In literature (Shaw, Garlan, 1996; Jacobson, Griss, & Jonsson, 1997), the most common understanding of software architecture is that it represents a hierarchical decomposition of a software system into subsystems. Each of these subsystems defines some unit of the entire software and is interconnected via interfaces to other components by predefined communication mechanisms. Despite this common understanding, these terms are usually used in very different contexts. Hence, a new approach defined a formal model based on FOCUS (Broy & Stolen, 2001) to get a more precise understanding of these technical terms (Bergner, Rausch, Sihling, & Vilbig, 1999).

In general, software architectures aim at the fulfillment of content requirements, with respect to certain decision requirements, by using some general design principles for the decomposition of the software system. In this context, Boehm (Shaw & Garlan, 1996) talks about an intermediate abstraction between user needs and the final system structure that helps to bridge the gap between user requirements and the software. Others motivate the purpose of software architectures by their support for some pre-selected requirements (Jacobson, Griss, & Jonsson, 1997) like supporting development, maintenance, reuse and evolution of a software.

In the context of this work, software architectures consist of both the decomposition of the system into its subsystems, as well as a mapping from applied design principles to the resulting subsystems. Design principles are represented in this product model by so-called architectural styles. It should be accentuated here that this mapping of an intermediate abstraction to the final system structure is no sufficient motivation for the existence of software architectures. For a decision oriented design, the objective function and the corresponding measurement criteria, i.e., why a specific design principle has been chosen, have to be documented as well.

Aspects and Variations

This subsection sketches a first structuring of requirements into aspects and variations. Both base on the principle of the separation of concerns (Dijkstra, 1976; Tarr, Osher, Harrison & Sutton, 1999), which analyses a problem space with respect to different concerns and describes those separately. Together with research efforts in aspect oriented programming in the late nineties this classical approach regained popularity. New attempts aim at the integration of such basic concepts even in earlier phases (Clarke, Tarr & Osher, 1999; Kiczales, Lamping & Mendhekar, 1997; Walker, Baniassad & Murphy, 1999). In the following, instead of the term concern the term aspect is used synonymously. Also it is assumed that CCOTS can be decomposed reasonably into aspects.

Briefly, each product of a product type aspect describes a specific aspect of requirements from a CCOTS. It consists of the attribute description, which informally describes the aspect. Each aspect aggregates all associated requirements. Generally, requirements can be aggregated to different aspects. For example, in financial software the aspects could be billing, balancing, graphical representations or statistics, etc. In this case, the separation focuses on required functionality of the software system.

Usually, some requirements and, consequently, aspects are not mutually independent. In order to indicate this, the association type "correlates" is introduced. For example, usability and input/output are two separate aspects of a CCOTS. High usability can only be reached if especially the input/output of a software can be accessed comfortable with respect to the users' needs. To indicate that usability has an effect, the association "correlates" is used.

Different customers ask for different requirements, even within the same application area of a CCOTS. Therefore, differences and commonalties have to be described adequately. This description has to be independent from a realization structure in order to fully contain customers' requirements and to avoid an unintentional multiple realization of the same requirements within different parts of a CCOTS. Further, requirements have to be abstracted from individual customers due to the large number of CCOTS-OMS customers.

Such varying requirements are modeled within the model of work products with variation-types and variations. Variation-types are a specialization of aspects and allow respectively describe variations from different perspectives. In addition to requirements, each variation-type aggregates, mutually excluding variations. A variation aggregates requirements of the variation-type to which it belongs. A variation-type may be, for example, the country language for textual output of a software system. Variations of this variation-type are, e.g., English, German and French. Some requirements are aggregated to each variation of a variation-type. They describe the commonalties of a variation-type, which is called a common kernel. Every other requirement of the variation-type is aggregated to exactly one variation. Hence, all requirements which are aggregated to a variation and which do not belong to the kernel describe the specifics the variation. The identification of common kernels helps to identify reuse potentials in the software to be developed.

Due to time and cost limitations, a CCOTS manufacturer cannot realize all customer requirements. Furthermore, between different variation-types, variations, aspects and requirements are different kinds of relationships, which have to be taken into account during development and during runtime. For example, some variations of a variation-type may require variations of another variation-type in order to fulfill its purpose. Table 1 gives a short overview of the introduced relationship-types.

Table 1: Overview of relationship-types

Associations			Description
Correlates	Variation-type	Requirement	The realization of a requirement is not independent of a variation-type
expects	variation	variation	If the first variation is activated, then the second variation also has to be activated
excludes	variation	variation	Associated variations may not be activated at the same time
wish	variation	variation	Associated variations should be preferred in realization
correlates	variation-type	aspect	At least one of the requirements which are aggregated to the aspect correlates with the associated variation-type

Description of Variations

In order to describe aspects and variations, extensions of existing specification techniques are needed. It can be distinguished between so-called external specifications and internal. External specifications serve for giving an overview over an existing model of development products. For this purpose UML-class diagrams specialized by stereotypes are used. Product types are represented by stereotypes of UML-classifiers and association types are represented by stereotypes of UML-relationships. Thus, earlier approaches for describing variations of product lines are extended by so-called feature trees (Lam, 1998; Hamer, van der Linden, Saunders & te Sligte, 1998; Davis, 1995; Traz, 1995; Griss, Favaro & d'Alessandro, 1997) and integrated with more general approaches, like class diagrams.

Further specifications describe technical contents of development products in detail. For a comprehensive description of a CCOTS, relationships of internal descriptions to versioning, variations and realization states of requirements also have to be specified. Specifications which describe detailed technical contents and their relationships to the mentioned issues are called internal specifications. In order to reuse well-established description techniques like UML-notations or other tabular descriptions, coloring techniques in order to represent such additional aspects are used. For graphical techniques, background coloring is used by partitioning the drawn graph with Voronoi diagrams and coloring the areas. In tabular specifications cells are colored. This approach generalizes earlier approaches for describing specific aspects in singular description techniques like ER-diagrams, state-diagrams and system structure-diagrams (Kang, Cohen & Hess, 1990; Cheong, Anande & Jarzabek, 1998) or state-charts and activity-charts (Harel, Lachover & Naamad, 1990). To distinguish different variations, different presentation styles for graphical elements (e.g., dotted instead of solid lines) or labels (e.g., italic instead of normal font) are used.

Architectural Elements

Now, the product types for architectural design are described. Table 2 gives an overview of the mapping of decision elements work products describing architectural work products.

Table 2: Overview decision elements

Decision element	Architectural work product
Decision object	Content requirement
Measurement criterion	Decision requirement
Guidelines	Architectural styles
Alternative	Architectural alternative
Objective function	Objective function
Solution	Software architecture

In this context, the work products architectural style, architectural alternative and software architecture represent software architectures in a general sense and therefore can be described with an architecture description. However, they are different in their role in the decision oriented design. For each role, different additional aggregations or associations are necessary for documenting the complete content of a product. To demonstrate this difference, separate products are defined. Architectural elements are described separately, the terms content requirement and decision requirement should be clarified. The terms differentiate requirements for software with respect to their use in the software architecture. Content requirements denote those requirements that directly have any representation in a software system. Examples for this are all functions software has to fulfill. Compared to this, decision requirements cannot be found directly in software architecture. They are fulfilled more or less in different alternatives. For example, maintainability is a decision requirement. The following paragraph briefly sketches content and purpose of the different architectural elements. For a detailed description it is referred to Deifel, Schwerin and Vogel (1999).

The construction of architectural alternatives in the decision-oriented design depends mainly on content requirements and architectural styles (see Figure 11). Further, existing software parts must be taken into account and reduce the possible space of architectural alternatives. The architectural alternatives with their AND- and OR-aggregations span a space of possible software architectures. The final software architecture is a composition of selected architectural alternatives. Each architectural alternative describes a part of a software architecture, which shall fulfill a subset of requirements.

Figure 11: Elements of architectural design

Architectural styles represent experienced knowledge for good architectural design in history and support the derivation of new architectures. They are descriptions of generic architectures, which are independent of specific software systems and of specific content requirements. Architectural styles support the construction of architectural alternatives.

Finally, the software architecture represents a unique decision of alternative architectures. The software architecture is the basis for all further development steps. It documents the complete architecture and the rationale which lead to this decision.

Architectural alternatives, architectural styles and the final software architecture have to be described in an appropriate way. For this purpose, the products architecture description and element are defined. Architectural elements may be refined in an adequate way, like component, interface, connector, protocol, architectural style, etc. In Deifel, Schwerin and Vogel (1999) one refinement solution is described. Other refinements are possible as well.

The architectural description describes the constituents of architecture and their relationships. Hence, it represents a typical description of software architecture. Compared to this, an architectural element is a generic element of an architecture description, which usually is related to a large variety of subtypes. It describes a part of an architecture description.

Activation Styles

In the last section, the general view at architectural design as a process of different development decisions was sketched. Now, the impact of variations on architectural design is described. Hence, for a software design, requirements and variations have to be selected and especially their activation styles and their technical realization mechanisms have to be chosen.

• Selecting Activation Style: With the activation style of a variation, the way users of a CCOTS can activate their specific variations is meant. Briefly, activation styles of predefined variations can be classified into parameterization and modularization (Conrade & Westfechtel, 1997; Karhinen, Ran & Tallgren, 1997). By parameterization, the software realizes all possible combinations of different variations within one product. In this case, setting configuration parameters of this product activates the variations. Compared to this, modularization denotes software that is separated into different modules. Here, a user can set his configuration state by selecting and combining appropriate modules. A special case for modularization of a CCOTS is the separation of a software into different products which are shipped independently. As is later shown, criteria which influence the selection for activation kinds come from customer requirements, marketing, development and logistics.
• Selecting Realization Mechanism: Depending on the selected activation style, a matching realization mechanism has to be chosen. This step may be supported by configuration management, by special techniques within programming languages (e.g., inheritance and polymorphism) or directly by manually programming branches within the program flow.

The decision for the activation style and appropriate realization mechanisms for variations is one of the first steps of architectural design. The rest of this section concentrates on activation styles. Hence, important decision requirements for different activation styles are presented.

Decision Requirements for Selecting Activation Styles

For each variation type an adequate activation style has to be selected. Generally, a larger modularization comes together with higher logistical efforts and a stronger cross-linking of modules. Further, the selected activation style constrains applicable realization mechanisms and consequently influences development costs and time. In the following, main absolute criteria and relative criteria, which are both adapted from the taxonomy for requirement changes introduced in Deifel and Salzmann (1999), are presented.

• Absolute Criterion: Time of Change: This duration indicates when a change has to be done:
  • Runtime: The change has to be done during runtime of the software. For example, production systems may change their configuration without stopping the production.
  • No Runtime: The change can be done when the software is not running.
• Absolute Criterion: Product Separation: In order to increase the return on investment, a marketing strategy may be to reach a clever separation of the CCOTS into different products which are sold independently.
  • Product Separation: The CCOTS can be separated into different products.
  • No Product Separation: Every variation has to be sold within one integrated product.
• Absolute Criterion: Delivery Time: Closely related to the product separation criterion is the development and logistics criterion on delivery time. Suppose different variations of a CCOTS can be developed concurrently. Then the most flexible way is that the variations can be delivered asynchronously as well.
  • Synchronous Delivery: all variations are delivered synchronously after a CCOTS has been developed. This leads to easier test procedures and an easier logistics.
  • Asynchronous Delivery: the completion time of different variations is different. This leads to a more flexible development.

Both criteria, "product separation" and "delivery time," require the possibility to modularize the CCOTS. Note that this is incorporated with an increasing number of modules; the system complexity and logistics efforts increase as well (Karhinen, Ran & Tallgren, 1997).

• Relative Criterion: Change Frequency: Another customer criterion is to support requirement changes adequately within the software in order to reach a high usability. Depending on the change frequency, the need for a comfortable configuration of the software system is different. Two different periods can be distinguished:
  • Long-term periods: the intermediate time between two requirement changes is relatively long.
  • Short-term periods: the intermediate time between two requirement changes is relatively short.

Activation Styles

Now, four activation styles, which can be found in practice, are presented. It is not taken into account the possibility to define variations with script programming and open interfaces. It is presumed that a variation already is developed and can be activated. The main difference between the activation styles concerns "how" and "when" a user has to choose the activation of a variation. It can be distinguished between purchase time, installation time and runtime. First, activation styles are introduced and then later related to decision requirements.

• Activation Style: Setting of Runtime Options: Here, all variations of a variation type are purchased and installed at once on a computer. A user can activate variations during runtime by changing settings of the program, e.g., switching radio-buttons or control-buttons within predefined windows.
• Activation Style: Automatic Configuration/Runtime Installation: This activation style does not presume that all variations have to be purchased and consequently installed on a computer. The software can be extended with new variations during runtime (e.g., the addition of plug-ins in commercial web-browsers). This presumes two steps: An automatic installation of new variations and, afterwards, an automatic reconfiguration of already installed software. The new functionality is included within modules that are connected to the already installed software. Hence, the user is passive and responsible for making the new module available.
• Activation Style: Installation Selection: Here a user activates a variation during the installation time of the software. In this case he buys all functionality of a variation type together with the purchased package. During installation he selects which variations should be activated. Usually installation selection is supported by installation programs or by editable configuration files. The main reason for using installation selection is the possibility to support static changes like static modularization (i.e., dividing the software into parts which can be exchanged when the software is not running), or the static setting of program options. Changes of activations of variations are done by reinstallations of the software.
• Activation Style: Purchase of Different Products: A software producer may develop software as a package of different separately offered products. In this case a customer has to select variations by purchasing adequate products. The activation/deactivation of a variation is done by separate installations/de-installations corresponding products.

Decision Situation for Activation Styles

At first sight, the presented activation styles seem to be very simple. But the main reason for the presentation of the different styles becomes clearer if the selection criteria are mapped to activation styles within a decision situation.

Table 3 shows such mapping.

Table 3: Mapping of activation styles with a decision situation

		Runtime options	Runtime installation	Installation selection	Purchase of different products
Absolute	Time of change	Runtime	Runtime	No Runtime	No Runtime
	Modularization	No	Yes	No	Yes
Relative	Change frequency	Short	Short	Long	Long

Note again that all required absolute criteria must be fulfilled in a selected activation style. Compared to this, relative criteria should be fulfilled as far as possible. As can be seen in the table, each activation style allows a different combination of the two absolute criteria. Therefore in order to cover all "must"- cases, each activation style is necessary.

Finally, a summary and an outlook for future research activities is given.

Conclusion

The objective of this chapter is to give advice on how to enhance the changeability of order management systems (OMS). OMS are here referred to complex commercial off-the-shelf (CCOTS) software used to support the order management, like, e.g., enterprise resource planning software (ERP). In this context, the order management process encompasses all activities and organizational units of an enterprise, which are necessary to transformation, customer and/or sales plan orders, into deliverable products. Due to the turbulences on sales and procurement markets, the permanent need for change will be a defining feature in the future business landscape. However, far too often these organizational changes can not be implemented as intended due to the lacking ability of today's CCOTS-OMS.

In order to enhance the changeability of OMS and organizations, the cybernetic model of order management was introduced. This model covers organizational and information-technical views on order management applying systems and control theory to couple business processes and supporting software adequately. The organizational control loop is responsible to ensure the effectiveness and efficiency of the order management process by initiating structural and/or process changes of the business organization in case of identified inefficiencies.

Closely cooperated is the OMS control loop, where OMS are regarded as service providers for tasks and problems from the order management. Inefficiencies of provided services lead to adaptations of OMS structure and/or processes. The OMS control loop is connected to the software development by means of the presented decision-oriented approach. Hereby, software development is seen as a collection of activities, mainly structured by decisions. The decision orientation uses work products for describing aspects, variations and architectural elements. Aspects and variations serve for structuring requirements of the whole market of an OMS. Basing on those architectural elements helps to systematically derive an architectural design, which is easily changeable due to a high traceability of the underlying model of work products.

Future research should focus on the profound specification of the presented cybernetic approach. Further, the architecture derivation should be focused in more detail, e.g., finding mechanisms, which support a systematic realization of presented activation styles.

References

Anderson, D. M., & Pine, B. J. (1997). Agile product development for mass customization. Chicago: Irwin.

Ausschuss fuer Wirtschaftliche Fertigung, E.V. (Ed.), (1985). AWF-Empfehlung - Integrierter Einsatz in der Produktion. Eschborn: AWF.

Bergner, K., Rausch, A., Sihling, M., Vilbig, A., & Broy, M. (1999). A formal model for componentware. In M. Sitaraman & G. Leavens (Eds.), Foundations of component-based systems. Cambridge: Cambridge University Press.

Berlak, J. (2001). Changeable order management. In A. D' Atri, A. Solvberg& L. Willcocks (Eds.), Proceedings of the OESSEO 2001-Open Enterprise Solutions: Systems, Experiences and Organizations. Rome: Luiss Edizioni.

Berlak, J. (2003). Methodik zur struktuierten Auswahl von Auftragsabwicklungssystemen. Unpublished doctoral dissertation, Utz, Munich.

Berlak, J., & Deifel, B. (2002). Activation styles for changeable Order Management Systems. In M. Khosrow-Pour (Ed.), Issues and trends of Information Technology management in contemporary organizations (pp. 70–74). Hershey, PA: Idea Group Publishing.

Bower, J. L. (1994). Jack Welch: General Electric's revolutionary. Harvard Business Review, 4, 1–22.

Broy, M., & Denert, E. (2000). Software pioneers: Contributions to software engineering. Berlin: Springer.

Broy, M., & Stolen, K. (1999). Specification and development of interactive systems: FOCUS on streams, interfaces, and refinement. Berlin: Springer.

Chakravarthy, B. (1997, Winter). A new strategy framework for coping with turbulence. Sloan Management Review, pp. 69–82.

Chen, P.P. (1976). The entity-relationship model - Towards a unified view of data. ACM Transactions on Database Systems, 1(1), 9-36.

Cheong, Y. C., Anande, A. L., & Jarzabek, S. (1998). Handling variant requirements in software architectures for product families. Las Palmas: ARES II.

Chopra, S., & Meindl, P. (2000). Supply chain management: Strategy, planning and operations. New York: Prentice Hall.

Clarke, S., Tarr, P., & Ossher, M. (1999). Designing for evolution with subjects. Los Angeles: ICSE'99.

Cockburn, A. (2001). Agile software development. New York: Addison-Wesley.

Conradi, R., & Westfechtel, B. (1997). Towards a uniform version model for software configuration management. Boston: Harvard University Press.

Darr, W. (1992). Integrierte Marketing-Logistik: Auftragsabwicklung als Element der marketing-logistischen Strukturplanung. Wiesbaden: DUV.

Das, T. K., & Elango, B. (1995). Managing strategic flexibility: Key to effective performance. Journal of General Management, 20 (3), 60–74.

Davenport, T. H. (1998). Putting the Enterprise in the Enterprise System. Harvard Business Review, 7–8, 122–131.

Davis, M. J. (1995). Adaptable reusable code. Seattle: SSR'95.

Deifel, B. (2001). Requirements Engineering komplexer Standardsoftware. Munich: Technische Universitaet Muenchen.

Deifel, B., & Salzmann, C. (1999). Requirements and conditions for dynamics in evolutionary software systems. Proceedings of the International Workshop on the Principles of Software Evolution, IWPSE99, Fukuoka.

Deifel, B., Schwerin, W., & Vogel, S. (1999). Work products for integrated software development. Munich: Technische Universitaet Muenchen.

Derniame, J. C., Kaba, B. A., & Wastell, D. (1999). Software process: Principles, methodology, and technology. Berlin: Springer.

Dijkstra, E. (1976). A discipline of programming. New York: Prentice Hall.

Dittrich, K. R., & Gatziu, S. (1996). Aktive Datenbanksysteme: Konzepte und mechanismen. Bonn: MITP.

Emery, F. E., & Trist, E. L. (1965). The causal texture of organizational environments. Human Relations, 18, 21–32.

European Commission (Ed.). (1996). Definition of small and medium-sized enterprises. Brussels: European Commission.

Evans, G. N., Naim, M. M., & Towill, D. R. (1996). Educating the supply chain: An holistic approach. International Journal of Materials and Product Technology, 11 (5/6), 464–476.

Forrester, J. W. (1961). Industrial dynamics. Boston: Pegasus Communications.

Fredenall, L. D., & Hill, J. E. (2000). Basics of supply chain management. New York: Lewis Publishers.

Frese, E. (1992). Handwoerterbuch der Organisation. Stuttgart: Schaefer-Poeschel.

Griss, M., Favaro, J., & d'Alessandro, M. (1997). Featuring the reuse driven software engineering business. Object Magazine, 11, 37–45.

Gulbins, J., Seyfried, M., & Strack-Zimmermann, H. (1998). Dokumentenmanagement. Berlin: Springer.

Hafen, U., Kuenzler, C., & Fischer, D. (2000). Erfolgreich restrukturieren in KMU. Zurich: VDF.

Hamer, P., van der Linden, F., Saunders, A., & te Sligte, H. (1998). An integral hierarchy and diversity model for describing product family architectures. Las Palmas: ARES II.

Harel, D., Lachover, H., & Naamad, A. (1990). Statemate: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering, 16 (4), 240–255.

Harnwell, C. (1998). Supply Chain Management - mehr als "nur" ERP-Systeme. IT Management, 11, 27–29.

Heinen, E. (Ed.). (1991). Industriebetriebslehre: Entscheidungen im Industriebetrieb. Wiesbaden: Gabler.

Hiquet, B. D. (1998). SAP R/3 implementation guide. London: Macmillan Technical Publishing.

Jablonski, S., Böhm, M., & Schulze, W. (Eds.). (1997). Workflowmanagement: Entwicklung von Anwendungen und Systemen. Heidelberg: dpunkt.

Jacobson, I., Griss, M., & Jonsson, P. (2001). Software reuse. New York: Addison Wesley.

Kang, K., Cohen, S., & Hess J. (1990). Feature-oriented domain analysis feasibility study. Pittsburg: Carnegie Mellon University.

Karhinen, A., Ran A., & Tallgren T. (1997). Configuring designs for feuse. Boston: Harvard University Press.

Kernler, H. (1995). PPS der 3. Generation: Grundlagen, Methoden, Anregungen. Heidelberg: Huethig.

Khoshafian, S., & Buckiewicz, M. (1995). Introduction to groupware, workflow and work group computing. New York: Wiley.

Kiczales, G., Lamping, J., & Mendhekar, A. (1997). Aspect-oriented programming. Berlin: Springer.

Köhler, C. (1999). Der elektronische Leitstand - Befehlsempfaenger oder Partner der Werkstatt ? VDI-Z, 132 (3), 14–20.

Kotter, J. P. (1996). Leading change. Boston: Harvard Business School.

Lam, W. (1998). A case study of requirements reuse through product families. Annals of Software Engineering, 5, 253–277.

Maucher, I. (Ed.). (1998). Wandel der Leitbilder zur Entwicklung und Nutzung von PPS-Systemen. Munich: Hampp.

Meinberg, U., & Topolewski, F. (1995). Lexikon der Fertigungsleittechnik. Berlin: Beuth.

Meyers, B. C., & Oberndorf, P. (2001). Managing software acquisition: Open systems and COTS products. New York: Addison-Wesley.

Milberg, J., & Reinhart, G. (Eds.). (1997). Mit Schwung zum Aufschwung: Muenchner Kolloquium 1997. Munich: Utz.

O' Leary, D. E. (2000). Enterprise resource planning systems. Cambridge: Cambridge University Press.

Reinhart, G., Duerrschmidt, S., Hirschberg, A., & Selke, C. (1999). Reaktionsfaehigkeit fuer Unternehmen: Eine Antwort auf turbulente Maerkte. ZWF, 94 (1/2), 21–24.

Rumbaugh, J., Jacobson, I, & Booch, G. (1999). The unified modeling language reference manual. New York: Addison-Wesley.

Scheer, A. W. (Ed.). (2000). Aris: Business process modeling. Berlin: Springer.

Schreyoegg, G. (1999). Organisation: Grundlagen moderner Organisationsgestaltung. Wiesbaden: Gabler.

Shaw, M., & Garlan, D. (1996). Software Architecture - Perspectives on an emerging discipline. New York: Prentice Hall.

Tarr, P., Ossher, H., Harrison, W., & Sutton, S. M. (1999). N degrees of separation: Multi-dimensional separation of concerns. Los Angeles: ICSE'99.

Tetenbaum, T. J. (1998). Shifting paradigms: From Newton to chaos. Organizational Dynamics, 26 (4), 21–32.

Theuvesen, L. (1996). Business reengineering. Zeitschrift fuer betriebswirtschaftliche Forschung, 48 (1), 65–82.

Traz, W. (1995). DSSA: Pedagogical example. ACM Software Engineering Notes, 6, 49–62.

Vollmann, T. E., Berry, T. E., & Whybark, D. C. (1997). Manufacturing planning and control systems. New York: McGraw-Hill.

Walker, R. J., Baniassad, E. L. A., & Murphy, G. C. (1999). An initial assessment of aspect-oriented programming. Los Angeles: ICSE´99.

Wallace, T. F., & Kremzar, M. H. (2001). ERP: Making it happen: The implementers' guide to success with enterprise resource planning. New York: John Wiley & Sons.

Weiss, A. (2000). Getting started in consulting. New York: John Wiley & Sons.

Werder, A. V. (1999). Effizienzbewertung organisatorischer Strukturen. Wirtschaftswissenschaftliches Studium, 28 (8), 412–417.

Wiener, N. (1948). Cybernetics. New York: MIT Press.