Management Middleware for Integrating Decentralized ...

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Management Middleware for Integrating Decentralized Heterogeneous Corporations Ulrike Baumöl, Reinhard Jung, Robert Winter University of St. Gallen, Institute of Information Management Mueller-Friedberg-Str. 8, CH-9000 St. Gallen (Switzerland) {ulrike.baumoel¦reinhard.jung¦robert.winter}@unisg.ch Abstract One of the major current business trends is gaining market power by mergers and acquisitions and by selling off those business units which are considered inefficient or which no longer represent core competencies. The goal of our paper is to conceptualize an IS architecture which on the one hand enables a speedy integration of decentralized and heterogeneous business units and on the other hand facilitates their selling off. Such a "Management Middleware" is developed basing on the data warehouse concept. The core of the Management Middleware is an information pool in which specific decision relevant information of the entire corporation are stored. In contrast to a data warehouse, the information pool is not a read-only data store, but a read-write information junction which allows for information input by decentralized units and, at the same time, allows the access to information stored by headquarters or other units. Only a two way information center supports the creation of management information and at the same time enables a decentralized, but integrated decision-making and corporate management. The decentralized business units own data marts which contain specific decision relevant information adapted to their individual decision problems.

1. Introduction One of the major current business trends is gaining market power by mergers and acquisitions and by selling off those business units which are considered inefficient or which no longer represent core competencies. The result of these restructuring activities are large, often multinational companies with many decentralized business units. The benefits are numerous, but nonetheless there are some challenges which can lead to decisive inefficiencies if not properly addressed. A major problem is the integration as well as the separation of reporting systems, Executive Information Systems, and (from an organizational point of view) decision processes. Due to time restrictions and business dynamics, it is neither effi-

cient nor possible to completely integrate systems and processes of acquired business units. Therefore, a standardized IS architecture should be designed which enables decentralized units to make decisions based on decentralized as well as centralized information. Furthermore, such an architecture simplifies the separation of a business unit from the corporate body. The managerial foundations of organizational decentralization and its consequences for information supply are analyzed in section 2. In recent years, data warehousing emerged as a promising approach to overcome many information supply problems. In section 3, the data warehousing process is discussed from a managerial perspective. However, elaborate (and expensive) information modeling is needed for developing an appropriate data warehouse solution for a decentralized organization. For operational systems (e.g. Enterprise Resource Planning systems), information and process modeling tasks are supported by industry reference models. Therefore, the role of reference models for informational processes is discussed in section 4. Based on the discussions in sections 2 through 4, the “Management Middleware” approach is conceptualized in section 5. A bi-directional variant of a data warehouse based on a reference schema of managerial information could serve as an information pool that supports not only controlling and aggregation, but also planning and budgeting in a decentralized, homogeneous company. Of course, the Management Middleware concept is only outlined at this research stage. Hence, a summary of open research questions concludes the paper in section 6.

2. Management holdings Many monolithic, large companies have recently been restructured according to the organizational principle of a "management holding", or are currently under restructuring. Prominent examples in the German-speaking countries are DaimlerChrysler, Mannesmann, SAir Group (formerly Swissair), Novartis (formerly Sandoz and Ciba Geigy), Lufthansa, and in a “pure“, maybe even

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1


radical form Hoechst. Once a conglomerate of many different companies under one roof, now only one company, the management holding, is visible with no obvious connection whatsoever to its daughter companies. The business model of a management holding differs significantly from those of companies led by an operational management. The primary goal of a management holding is to meet the overall profitability and the efficiency targets for the company. The major tasks of a management holding, therefore, are decisions regarding buying and selling business units and controlling the overall efficiency of the company. In contrast to the tasks of an operational holding, a management holding is concerned with strategic decisions rather than operational ones [1]. Due to the increasing globalization and a strong tendency to merge national companies into multinationals, the resulting entities tend to be geographically widely distributed. As a consequence, communication can only be efficient when it is done via networks and mostly electronically. Within a network of partnering companies, we expect most traditional businesses to emerge into • either the role of providers of (exclusive or shared) services/products • or the role of service/product integrators. Service providers pursue economies of scale by “producing” for a large number of service integrators, thereby utilizing some core competency or key technology. Service integrators create specific value-added solutions for

Service Integrator

Service Integrator

Service Integrator

Exclusive Service Provider Shared Service Shared Provider Service Provider

small segments of end-consumers, maintain brands, and maintain customer relationships. To exploit networking benefits, service integrators and service providers must be able to communicate and (if applicable) distribute services using a common infrastructure. Only the lower, more technical layers of such a “business bus” (e.g. TCP/IP networks, HTTP protocols, XML specification language) are available today. Research and standardization is still needed to specify the upper, business oriented layers of the business bus (e.g. service level agreements, product catalogs). The business architecture of the information age (cf. Figure 1) allows service providers and service integrators to collaborate using the business bus. If particular services/products are provided exclusively for one single “customer” (i.e. service integrator), it may be useful to bypass the business bus and to create individual communication / coordination standards. For end consumers, it is of course possible to integrate services/products individually by direct access to the business bus. Such network-based business architectures of the information age (cf. Figure 1) begin to emerge in the financial services sector. E.g., Quicken’s “insuremarket” (www.insuremarket.com ) offers financial advice and insurance products from various companies. The web site’s structure is modeled after life events and consumer’s information needs instead of traditional insurance product lines.

Shared Service Provider

Service Integrator

Shared Service Provider

Exclusive Service Provider

Public Service

Public Service

Exclusive Service Provider

Business Bus Figure 1: Business architecture of the information age

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2


However, one of the main problems of managing and controlling a heterogeneous company organized as described above is to create a flexible though standardized controlling system. When we look at the reporting system of such a company, it becomes obvious that a high number of different reports and performance indicators is created for the individual business units, which are useful for the management of these decentralized units, but are not suitable for managing the entire holding. By various acquisitions and sell offs, Mannesmann AG has emerged from a leading producer of certain steel products to a diversified company that is very active in promising businesses (e.g. telecommunication). Although its business unit "Engineering" could be controlled by the performance indicator "order volume" (and others), this indicator is totally inappropriate for other business units or for the entire holding structure that comprises telecommunications, automotive, and steel tube businesses. A performance indicator which can be used for managing such a heterogeneous entity must allow for a high degree of generalization (e.g. Capital employed, Return on Investment). As a consequence, we do not only need a very flexible reporting system on the level of the management holding, but also a range of highly standardized performance indicators which allow management to exercise control over the entire holding structure. Moreover, we have to concisely define what is meant by a management information and performance indicators. A management information can either be a detailed, non-aggregate figure, an aggregate figure, or a qualitative statement which all serve as a basis for the decision making process. Performance indicators constitute a subset of management information with some specific characteristics: They are always aggregate, and their components can either be aggregate or non-aggregate. This differentiation is important because information is lost during the aggregation process. An information system, therefore, has to support the disaggregation of such information in order to enable analyses (e.g. of deviations), but also in order to enable the communication of performance indicator calculations from the top management level to lower organizational units [11]. According to the above mentioned tasks, the basic organization of the reporting system has to be as follows: • On top management (holding) level, we have the highest degree of generalization and thus also need the highest level of standardization. This means that the performance indicators used on this level must be clearly and concisely defined for all the management levels below. A typical performance indicator on this level is, for example, the profit. In order to be able to calculate corporate profit, all individual profits of business units must be calculated consistently. Other-

wise the aggregation of the individual figures would result in a meaningless value derived from heterogeneous sources (e.g. gross and net profits). • On the business unit management level, various performance indicators are needed in addition to the performance indicators created for the management holding. The performance indicators have to meet less strict requirements with regard to generalization and standardization. Here, we only need standards for the lower management levels due to the same reasons as mentioned above. • On the lowest management level, the operational management, we do not need standards as far as a company-wide management is concerned. The only standard needed here is that for the individual operational unit itself. However, it must be observed that all the lower management levels nevertheless have to obey the standardization rules of the management holding. Thus an information system is needed which supports the information flow between the different and often geographically distributed levels (business units), provides a meta model of performance indicator definitions, and enables an integration of the performance indicators from different levels into aggregate performance indicators.

3. The data warehousing process A lot of publications deal with data warehousing from a rather technical point of view (e.g. [3]). We consider data warehousing as an infinite process which aims at an efficient and effective information supply. Hence, in this paper we take the business perspective in order to describe the characteristics and limitations of data warehousing.

3.1. Characteristics of data warehousing In today’s large companies the operational IT environment is usually the result of one or more decades of changing development paradigms and a long line of technological innovations. Therefore, the IT environment is in most cases very heterogeneous. As far as data or information supply is concerned, we face a variety of proprietary data sources, ranging from flat files and hierarchical databases to relational or even object oriented databases; some companies already have created “legacy” data warehouses or data marts. On the one hand, these heterogeneous data sources contain transactional data from daily operations, i.e. they are mission critical. On the other hand, however, they are not appropriate to support management decision processes because they don’t provide historical data, they are implemented by unsuitable means (e.g. sequential files, highly normalized ta-

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3


OLAP Business intelligence layer Ad hoc queries

Data mining

Meta data

Data mart layer • business unit views • mostly aggregate data • denormalized relations

Core data warehouse layer • integrated/consistent data • not transaction-oriented • non-redundant data • non-aggregated data • normalized

Operational systems layer • transaction-oriented systems (OLTP) • transaction-oriented database systems • legacy data warehouses

Figure 2: The data warehouse architecture bles, detailed data) and, most important, they lack data integration. From a management perspective, two main reasons for the significance of data warehousing can be ident ified: • Today’s markets require immediate response to new trends as regards management and control. Hence, the time needed to provide management with actual, a ggregate data and information becomes crucial if not mission critical. There is no chance of manual info rmation supply by a hierarchy of specialized pe rsonnel. • A manual information supply implicates avoidable i nefficiencies because a big portion of the “information work”, namely the collection of detailed data (from various sources), is usually done redundantly but could be done automatically. Figure 2 illustrates a data warehouse architecture which represents an abstract view on the various arch itectures of our research partners’ data warehouses∗. ∗

The Competence Center "Data Warehousing Strategy" (CC DWS, datawarehouse.iwi.unisg.ch) was founded at the University of St. Gallen, Switzerland, in January 1999. The CC DWS is a joint, twoyear research project of the Institute of Information Management and ten large German and Swiss companies from the insurance, logistics, telecommunications and consulting industry, and the Swiss depar tment of defense.

Other authors (e.g. [3][9]) present quite similar arch itectures. The basis of every data warehouse architecture is the operational IT environment and especially its data sources. The next layer deals with the so-called ETL pr ocesses, i.e. extraction, transformation, and loading of d etailed data into the core data warehouse. In contrast to transactional databases, the core data warehouse comprises both actual and historical data in order to support all kinds of analyses. Since the data within this central component of the architecture is detailed and not aggr egate, it is necessary to define specific views on the core data warehouse for the business units. If the views are materialized, i.e. if controlled redundancy is introduced, we call the set of views for one business unit a data mart. These views usually provide aggregate data and denormalized or even multidimensional data structures. The top layer of the architecture, called business intelligence, comprises end-user tools for ad hoc queries, online an alytical processing (OLAP), and data mining. As regards the characteristics of the core data war ehouse, it has to be mentioned that other approaches exist. Some authors favor (1) a core data warehouse which already contains aggr egate data or

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4


(2) so-called independent data marts [6], i.e. data int egration takes place in independent, small-scale data warehouses. We did not integrate these approaches into our arch itecture due to the following reasons. Most of our partner companies are not able to anticipate all future requir ements as regards the granularity of the data. Therefore, it is advisable to preserve the degrees of freedom for future data mart projects by populating the core data warehouse with detailed data only [8]. Moreover, aggregate data on the core data warehouse level imposes restrictions on the drill-down depth of business intelligence tools. The idea of independent data marts is also critical because ind ependent data marts cannot efficiently serve top manag ement information requirements due to their lack of data integration and they may lead to complex integration problems in the long run [4].

3.2. Limitations and potentials of data warehousing The idea of an integrated data supply for management support is not new. Management Information Systems or Executive Information Systems have been discussed e xtensively for decades. However, some good concepts could not be implemented until powerful database ma nagement systems and business intelligence tools became available. Today tools are available for every layer of the architecture and for data transformations between the layers. Only as far as metadata is concerned, there is still a lot of technological work to be done. Almost every component of the data warehouse architecture "produces" metadata as well as it needs other components metadata (cf. Figure 2). The challenge is to integrate not only data, but also metadata in order to support all user groups of the data warehouse (developers, users, administrators etc.). From our point of view, the most challenging tasks in the area of data warehousing are methodological ones. One of those tasks is the data integration as regards the conceptual schema, i.e. the design of the core data war ehouse. The data elements as they are used in the oper ational IT environment represent the business units' views on data. As soon as more than one business unit takes part in a discussion about "their" definition of perfor mance indicators or ratios (sometimes they even refuse to support the IT department) such as, for example, contr ibution margins and revenues, the real challenge becomes obvious. The problem becomes more difficult if different divisions or even daughter companies from completely different industries are involved. Data integration means to integrate similar data elements from different sources

(and, therefore, definitions of different business units!) into a common definition e ither (1) by agreeing on a suitable definition and modifying the affected operational systems or (2) by preserving individual definitions and integrating the data elements on a more abstract level. It is obvious that the first alternative will face serious resistance because the operational systems are almost a lways mission critical and cannot easily be modified. The second alternative means consensus on an abstract level which is much easier to accomplish. The idealistic and primary function of a data war ehouse is to provide top management with appropriate information supply. This goal cannot be achieved in a short-term project. Instead of building an enterprise wide data warehouse in a big-bang approach, most companies build up their warehouse over a longer period of time by implementing smaller increments, i.e. providing info rmation supply to business units. Thus, it is much easier to accomplish project budget approval through, for example, short-term cost savings. However, this strategy leads to a warehouse which grows bottom-up. In order to be able to meet top management requirements further on in the development process it is necessary to ensure a goal-driven design, i.e. the solution is a combined topdown-bottom-up approach.

4. Reference models The basic idea of a reference model is to provide a generalized schema plus adaptation rules so that specia lized schemas can be derived consistently, i.e. without violating integrity constraints. Hence, the adaptation of reference models can be compared to configuration pro cesses, thereby differing significantly from other inform ation modeling paradigms like component based modeling (reuse of partial detailed schemas) or object oriented modeling (inheritance of abstract schema comp onents). In information systems development, the utilization of reference models has been initially discussed for the data view of integrated systems (e.g. [14]). Subsequently, reference schemas have been proposed by software vendors not only for data structures (e.g. [13]), but also for business processes (e.g. [5][15]). Recently, not only software vendors, but also researchers have proposed reference models (e.g. [10] for electronic markets). Various other approaches also claim to be based on reference models. E.g., the Workflow Management Co alition created a workflow reference model [17], or ISO defined the well-known OSI reference model [7]. But while the former is quite abstract so that adaptation to actual workflow schemas is not an easy task, the latter is more a regulation of protocol and service definitions than

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5


a template for actual systems development. If usable for systems developments, reference models should allow for the configuration of “executable” schemas. When grouping available reference models by process type, another problem becomes apparent: While reference schemas for transactional business processes (e.g. order entry, materials management, financials) are widely available, informational processes seem to have evaded this kind of standardization. As a consequence, executive information systems are usually implemented as indivi dual software, while for transactional systems, standar dized business packages are utilized whenever available and adaptable to specific needs. This may be due to the fact that management pro cesses are automatically interpreted as core competencies of any company so that standardization would be more harmful than helpful. If properly made, however, refe rence models do not restrict systems development to some pre-defined standard. Instead, the model integrates mu ltiple perspectives that provide a framework for individual adaptation, thereby preserving some basic integrity co nstraints and basing systems development on a common terminological and architectural foundation. For informational processes, the most important co mponent of reference models is a complete data view, i.e. a data schema that implies all potential aggregations, thereby allowing consistent schema clustering and r efinement operations to be applied [16]. If only certain, validated aggregation rules have been used to derive a ggregate schemas, schema refinements can also be fo rManagement holding (MH)

mally validated. Since adaptations cannot validate overall integrity in such an environment, the predominant pro blem of disaggregation (as discussed e.g. in [12]) is solved. Based on an abstract "reference" schema and a set of adaptation rules, specialized schemas can be derived without having to guarantee consistency by special disaggregation procedures (e.g. [2]). As a consequence, management middleware should be based on an abstract schema that is derived from the d etailed data view by selected, integrity-preserving aggr egation procedures.

5. Management middleware Today's data warehouse architectures are designed as read-only systems, i.e. the direction of the data and i nformation flow is from operational systems to the core data warehouse and onwards to management or analyt ical systems (upstream). In order to serve as a manag ement middleware, the warehouse architecure has to be adapted. It is especially important that both the manag ement holding and the daughter companies are able to push data from their individual data marts into the core data warehouse (downstream). Furthermore, the data warehouse must not only contain historical data but also forecasts and plans. In Figure 3 an adapted data warehouse architecture serving as a management middleware is depicted. The daughter company, for example, uses its actual data in order to calculate the actual ROI and the planned ROIs for subsequent periods and pushes the reDaughter company 1

Daughter company 2

Daughter company 3

Data mart layer ROI targets Daugther companies‘ • actual ROIs • ROI plans Core data warehouse layer

actual op. data MHs ROI targets

Actual ROI ROI plans

past future

Operational systems layer

Figure 3: A modified data wareh ouse architecture serving as a management middleware

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6


Examples of relevant performance indicators:

abstract

detailed

Level 1

Reference model for high-level performance indicators

Level 2

Reference models for industry-specific performance indicators

Level 3

• Return on investment (ROI) • Return on capital employed (ROCE) • Capital turnover

Example: Insurance industry • Number of sold insurances • Total gross insurance premium • Total number of customers • Total risk ensured Example: Life insurances • Number of sold life insurances • Total cash surrender value • Total number of customers • Total number of persons insured

Reference models for line-of-business-specific performance indicators

Figure 4: Schematic hierarchy of reference models sulting values into the warehouse which are later on analyzed by the management holding. The management holding then communicates ROI targets for all its daughter companies by writing the values into the war ehouse. The basic concept of a management middleware is only feasible if data integration within the core data warehouse is achieved as regards management data. Therefore, we advocate to utilize a hierarchy of reference models of performance indicators which enables a sea mless integration of the management information of a ce rtain level into the reporting schema of the next higher level, because management information on each higher level need to fulfill a higher degree of generalization. In Figure 4 a schematic hierarchy of reference models is d epicted. These models, once available, enable data int egration among heterogeneous companies either through performance indicator consolidation within the same level or consolidation on the next higher level, i.e. through generalization. As a consequence, upstream data flow will be possible. In order to facilitate downstream data flow as well, either disaggregation mechanisms or agreements have to be established.

as downstream data flow is concerned. Moreover, a comprehensive hierarchy of reference models has to be elab orated. Finally, research on the concepts impact on its o rganizational environment seems to be imperative because it is very likely that the process of establishing perfor mance indicator transparency on all management levels will face some resistance. As a next step we are going to validate our concept within a large multinational co mpany.

7. References [1]

R.N. Anthony, Planning and control systems - a framework for analysis, Harvard University, Boston, 1965.

[2]

G.R. Bitran, A.C. Hax, "On the Design of Hiera rchical Production Planning Systems", Decision Sciences, Vol. 8 (1977), pp. 28-55.

[3]

C. Bontempo, G. Zagelow, "The IBM data warehouse architecture", Communications of the ACM, Vol. 41 (1998), pp. 38-48.

6. Conclusion and further research issues

[4]

The data warehouse concept seems to offer some interesting opportunities for the management and control of heterogeneous companies such as, for example, ma nagement holdings. We outlined the "management middleware" concept which might represent a suitable basis for this. In order to realize such a concept it is necessary to enhance data warehouse technology, especially as far

S. Chauduri, U. Dayal, "An Overview of Data Warehousing and OLAP Technology", ACM SIGMOD Record, Vol. 26 (1997), No. 1, pp. 6574.

[5]

T. Curran, G. Keller, and A. Ladd, SAP R/3 Business Blueprint: Understanding the Business Process Reference Model, Prentice Hall PTR, 1997.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7


[6]

S.R. Gardner, "Building the Data Warehouse", Communications of the ACM, Vol. 41 (1998), pp. 52-60.

[7]

ISO, Open Systems Interconnection – Basic Re ference Model, IST7495, 1983.

[8]

S. Kelly, Data Warehousing in Action, Wiley & Sons, Chichester, 1997. R. Kimball et al., The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying Data Warehouses, Wiley & Sons, Chichester, 1998.

[9]

[10]

M.A. Lindemann, B. Schmid, "Elements of a Re ference Model for Electronic Markets", Proceedings of the 31st Annual Hawaii International Conference on Systems Science HICCS'98 , Vol. IV, pp. 193-201.

[11]

T. Reichmann, Controlling – Concepts of Management Control, Controllership, and Ratios, Springer, Berlin et al., 1997.

[12]

L.P. Ritzman et al. (eds.), Disaggregation – Problems in Manufacturing and Service Organizations, Martinus Nijhoff, Boston et al., 1979.

[13]

SAP AG, SAP Information Model, Walldorf/Baden, 1994.

[14]

A.-W. Scheer, A. Hars, "Extending data modeling to cover the whole enterprise"; Communications of the ACM, Vol. 35 (1992), pp. 320-328.

[15]

R.M. vanEs, H.A. Post (eds.), Dynamic Enterprise Modeling, Kluwer, Deventer, 1996.

[16]

R. Winter, "Towards an Integration of Structured Techniques for Data Modeling and Function Modeling in Information Systems Development", in: J. Dias Coelho et al. (eds.), Proc. 4th European Conference on Information Systems, Lissabon, 1996, pp. 1003-1010.

[17]

Workflow Management Coalition, Workflow Management Coalition Terminology and Glossary (WFMC-TC-1011), Technical report, Brussels, 1996.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8