How to Configure a Configuration Management System – An Approach Based on Feature Modeling Sebastian Wenzel Thorsten Berger IBM Business Services GmbH University of Waterloo Wilhelm-Fay-Str. 30-34 200 University Ave West Frankfurt, Germany Waterloo, ON, Canada wenzel.sebastian@de.ibm.com tberger@swen.uwaterloo.ca Thomas Riechert University of Leipzig Johannisgasse 26 Leipzig, Germany, riechert@informatik.uni-leipzig.de Abstract—The accomplishment of an efficient IT service One of the most important disciplines that ITSM comprises management is considered a significant success factor in large is Configuration Management (CM) which is responsible for businesses. Configuration Management (CM) constitutes one of keeping information about the managed IT infrastructure to be its core disciplines. Off-the-shelf CM systems support the managed both up-to-date and accurate. According to maintenance of the IT by handling the lifecycle of so-called Klosterboer [2], the implementation of CM is very difficult to Configuration Items (CIs) and by establishing Change, accomplish. Many companies have problems with the Configuration and Release Management processes. However, due realization of CM practices. Especially the tailoring and to the complexity of today’s IT infrastructure in large companies, installation of the CM database and the establishment of the tailoring of these systems based on concrete stakeholder change processes present some of the most complicated tasks. requirements can become a laborious and error-prone task. It is critical to design a concrete and accurate specification for We present an approach that enables the configuration of a CM the CM database that reflects all the data required for ITSM system by leveraging variability management techniques processes. stemming from product line engineering. The synthesis and We were faced with the problem of configuring a CM configuration of a feature model is driven by the Common Data database as part of an outsourcing project for a company that Model, a large domain-specific model that describes CIs and has to manage a large IT infrastructure with more than 2000 their relationships. We show how our feature-based approach servers. The tailoring of the database, i.e. the creation of its can improve the tailoring of CM systems. Furthermore, we expand on its prototypical realization, elaborate on the concrete data model, was driven by requirements that had to be integration into the requirements engineering process and elicited from stakeholders. Additionally, the data model of the discuss its applicability based on experiences obtained from a database had to conform to the Common Data Model (CDM), a first evaluation. domain-specific model from IBM Tivoli that defines types of Configuration Items (CIs) and their relationships. IT service management; configuration management; feature The manual and indirect tailoring of the database turned out modeling; requirements engineering to be very laborious and error-prone: First, the configuration knowledge is elicited indirectly via textual requirements from I. INTRODUCTION the customer. Second, the actual configuration has to be During the past decades, the technological innovation of carried out by experts with significant knowledge about the information technology has been the main driving force to database specification, the CDM elements and a considerable achieve a higher level of efficiency and effectiveness within number of constraints. businesses [1]. However, the growing complexity of In this context, we present a model-driven approach to companies’ IT environments has indicated a need for more creating a CM database specification that leverages Feature comprehensive IT management support. One solution of Modeling [3] techniques. It dynamically synthesizes a feature tackling the growing complexity is the introduction of IT model that provides different levels of abstraction over the service management (ITSM) techniques. ITSM provides a database specification, incorporates CI dependencies as process-centered view on the management of IT infrastructures constraints and supports a staged configuration process. In and aims at assuring the quality of IT services. summary, it exposes the structure and configuration options of the database specification more explicitly and provides a more abstract view of it. Figure 1. CM system and processes overview The remainder of the paper is structured as follows: In This information comprises CIs and their relationships and is section 2, we give an introduction to Configuration saved in a database called Discovered CI Store. Management for IT services, describe the Common Data Model and portray our concrete problem context. Section 3 presents However, not all the data that has been discovered by our approach that traces CM database tailoring back to a ITADDM is relevant for IT service management processes. feature configuration problem. Section 4 expands on the Thus, the information is filtered and transferred into the prototypical realization of a tool relevant for our method and CCMDB. The CCMDB, in turn, consists of two logical section 5 reports on the evaluation experiences gained. Finally, databases realized in one physical database. These logical we discuss relevant conclusions and outline future databases are named Actual CI Store and Authorized CI Store. work in section 6. The former one just keeps a subset of the discovered data, but still contains sufficient information that is necessary for the CM system to operate correctly. This information is stored with II. CONFIGURATION MANAGEMENT a high level of detail and is necessary for root cause analysis, CM basically denotes “the process responsible for but not for the IT management itself. In contrast, the maintaining information about Configuration Items required to Authorized CI Store only keeps CIs and relationships that are deliver an IT Service, including their relationships. This subject to change and configuration management processes. information is managed throughout the lifecycle of the CI.” [4]. This information is essential for a failure-free operation of For a more comprehensive introduction to CM, including a the IT infrastructure. definition of Configuration Items, we refer to Alison et al. [5] Fig. 2 shows an example of how part of the data discovered and Lacy et al. [6]. by ITADDM is filtered for its usage in conjunction with IT service management processes. More precisely, the diagram A. System Architecture shows parts of the CI Stores’ specifications, which are sets of Fig. 1 provides a high-level view on the realization of the CI Types and their relationships. The CI Types themselves, CM system in our project context as well as the connection to their attributes and relationships are defined in IBM Tivoli’s the various service management processes. The system consists Common Data Model. of two main parts: ITADDM 1 and CCMDB 2 [7]. ITADDM denotes the Discovery System responsible for discovering, B. Common Data Model collecting and storing information about the IT infrastructure. The Common Data Model3 is a domain-specific model that describes concepts in the CM domain. According to Tai et 1 al. [8], CDM “provides consistent definitions for managed IBM Tivoli Application Dependency Discovery Manager: resources, business systems and processes, and other data, and http://www-01.ibm.com/software/tivoli/products/taddm/ 2 IBM Tivoli Change and Configuration Management Database: 3 http://www-01.ibm.com/software/tivoli/products/ ccmdb/ http://www.redbooks.ibm.com/redpapers/pdfs/redp4389.pdf relation between classes in CDM. This hierarchy is defined Discovered CI Store using a Parent attribute in classes, but each parent-child relation is further detailed by a corresponding association. ComputerSystemCluster OperatingSystem Fig. 3 illustrates the mapping between a store specification federates runsOn installedOn and the CDM. virtualizes ComputerSystem In this paper we focus, however, on the specification of the contains contains Authorized CI Store. Setting up the Actual CI Store is not addressed here since it is rather driven by technical aspects than Memory CPU by customer requirements. The mapping and transfer between contains Discovered and Actual CI Store is realized by predefined MediaAccessDevice adaptors with the option to define the hierarchy depth. D. Authorized CI Store Actual CI Store Authorized CI Store The current process of creating a specification for the ComputerSystemCluster OperatingSystem OperatingSystem Authorized CI Store can be characterized as follows: federates installedOn installedOn Elicitation of requirements from the customer: Based on the current specification of the Actual CI Store, requirements ComputerSystem ComputerSystem reflecting the necessary CI Types and relations have to be contains contains contains contains elicited from the stakeholder. Our project, for example, Memory CPU Memory CPU comprised more than 700 requirements [9]. Analysis of requirements: CIs, meta/administrative information and relationships that are to be transferred from the Actual to the Authorized CI Store have to be identified on the Figure 2. Filtering of CIs among the CI Stores basis of the elicited requirements and the CDM. In practice, requirements are currently mapped to CDM elements in the relationships between those elements”. Thus, it can be seen Microsoft Excel spreadsheets. as a domain-specific language rather than just as a data model for the CI Stores. In fact, many CM tools from the IBM Tivoli Common Data Model family are built upon concepts as defined in the CDM. Technically, it is modeled in UML2 and contains about 750 classes with attributes as well as 82 named association types (e.g. contains, installedOn, virtualizes). Three UML2 Profiles define stereotypes in order to specify technical tool and data mappings. CDM further introduces the notion of Sections, which categorize related classes. They are organized hierarchically and each of the 36 Sections corresponds to a concrete class diagram. Classes that represent real-world CIs realize the interface ConfigurationItem and are subject to IT service management processes. Thus, they embody the main entities that are to be saved in the CI Stores. However, since administrative and meta-information also has to be stored in the CI Stores, all classes derived from ModelObject can be persisted in the databases. Furthermore, concrete relationships CI Store between classes are defined and named according to their corresponding association type. Altogether, almost 1600 sys.computersystem unique relationships – defined as associations – exist in CDM. installedOn contains C. CI Store Specification In order to support the IT service management processes, the stores have to be tailored towards the stakeholders’ sys.operatingsystem sys.cpu requirements. Basically, this tailoring comprises the creation of contains a specification for the CM databases, i.e. for the Actual and the Authorized CI Store. A specification contains (1) a set of CI sys.momory Types including meta/administrative information and (2) a set of relationships as defined by the CDM. Furthermore, a logical hierarchy is introduced, which is based on a specific Figure 3. Mapping between CDM and CI Store specifications Applying the specification: Finally, the specification has A. Feature Model Synthesis to be applied to the Authorized CI Store by entering all The first step of our approach deals with the dynamic elements into a web configuration interface. Furthermore, creation of a feature model. The model is based on the current the former hierarchy of the Actual CI Store has to be specification of the Actual CI Store and allows an adjustable retained or recreated. representation of the prospective Authorized CI Store. We In its current form, the process turns out to be quite introduce four types of features: ineffective for the following reasons: First, profound  Diagram Concept features: root feature describing the knowledge about possible CI Types and relationships is underlying logical data model (i.e. the scope of the expected from the stakeholders. Second, available elements are feature model). limited by the current specification of the Actual CI Store. Third, consistency between CI Types and relationships is  CDM Section features: describing the highest difficult to maintain. Furthermore, terminology and translation abstraction level of the CDM - Sections. issues concerning the textual requirements occur.  CI Type features: representing CI Types contained in the logical data model. III. FEATURE MODEL SYNTHESIS AND CONFIGURATION  CI Relation features: representing relations between In order to bridge the gap between the (1) Actual CI Store CI Types. specification, the definitions in the (2) CDM and the implicit (3) configuration knowledge of the stakeholders, we introduce The feature model is built in three stages. In each stage an approach based on Feature Modeling and Feature Model features of different types are added to the model. All of them Configuration [10,11] techniques as known from Software are optional, we didn’t need to introduce mandatory features or Product Line Engineering [12,13]. mutual exclusions. An example of the feature model levels, created by the described procedure, is presented in Fig. 5. The We try to reduce the disadvantage of the current method by synthesis stages are as follows: providing a simplified and more coherent view on the Actual CI Store specification in form of a feature model. This model The first stage consists of two steps: the creation of the provides a higher level of abstraction for the selection of Diagram Concept feature (e.g. Actual CI Store) and the relevant CI Types and relations that are essential for the creation of CDM Section features (e.g. Administration stakeholders. The goal is to obtain a specification for the Section or ComputerSystem Section). These features are Authorized CI Store. either child features of the Diagram Concept feature or of other Our approach (cf. Fig. 4) consists of three main steps: CDM Section features. This stage of feature model synthesis is initially executed once for all projects. • Feature Model Synthesis The second stage of the synthesis comprises the creation of • Feature Model Configuration CI Type features corresponding to CDM Sections. The parent feature of these features is a CDM Section feature. This stage is • Authorized CI Store Creation automatically executed on the basis of the CDM Section – CI The approach facilitates the configuration of the feature Type mapping and the Actual CI Store structure. For instance, model on different levels of abstraction. On the highest level, the CI Types CPU and ComputerSystem belong to the CDM the presented view is intended to be simpler and easier to Section ComputerSystem Section and are part of the Actual understand for stakeholders without specific knowledge about the underlying CDM. Diagram Concept Actual CI Store CDM Sections Administration Section ComputerSystem Section CI Types AdminInfo ComputerSystem CPU CI Relations administers_ComputerSystem contains_CPU Figure 4. Feature model synthesis and configuration steps Figure 5. Levels of the feature model CI Store; thus, they are added to the feature model as children of the ComputerSystem Section feature. If the added feature Feature Model Actual CI Store represents a CI Type which is not labeled in the Actual CI Store as top-level, a constraint pointing to the feature of its parent CI Type in the logical Actual CI Store hierarchy is added to the Requirements Selection of feature model. Elicitation CDM Sections Selection of Authorized CI Store The third stage of the synthesis creates CI Relation CI Types Creation Selection of features. This stage is automatically executed on the basis of CI Relations the Actual CI Store structure. Those CI relations are added to the feature model, for which the source CI Type and the target CI Type exist in the feature model. They are added to the model Feature Model as children of the source CI Type feature. Furthermore, for each Authorized CI Store CI Relation feature, a constraint pointing to the target CI Type Configuration feature is added to the feature model. Figure 6. Requirements elicitation-based feature model configuration B. Feature Model Configuration The second step of the feature-based approach comprises a IV. PROTOTYPICAL REALIZATION kind of staged configuration of the synthesized feature model. This configuration is performed by the stakeholders in order to We have realized our approach as an Eclipse plug-in, since select features directly and, thus, to omit or at least reduce the we wanted to be able to embed it with other tools from IBM error-prone elicitation of requirements. We also leverage the Tivoli and since we chose to integrate with FMP 4 [14] as a choice propagation functionality in feature model tools for the Feature Modeling tool. FMP turned out to be the most purpose of assuring relationships, which have been added as appropriate one for our purpose. It is available as Open Source extra constraints to the feature tree. software, supports basic Feature Modeling with extra constraints, staged configuration and choice propagation. In summary, this step extends the current requirements Cardinalities are also supported in FMP, but were not necessary engineering that is carried out for gaining configuration for our approach. knowledge from stakeholders (cf. Fig. 1 and Fig. 4). In summary, our plug-in extends FMP, realizes the feature The configuration of the feature model is executed in three model synthesis and staged configuration as well as it provides stages. The initial feature model is created in the first Feature adapters for the Actual CI Store in order to obtain the current Model Synthesis stage. In the first configuration stage the specification. CDM Sections relevant for the stakeholder are selected. After that, the second feature synthesis stage is performed and the CI As described in section 3, the synthesis procedure creates a Type features corresponding to the selected CDM Sections are feature model in FMP by leveraging the structure of CDM loaded. This allows the execution of the second configuration Sections and loading the current Actual CI Store specification. stage in which the stakeholders select the required CI Types. We load subsections just on demand since we faced Based on the selected CI Types, the third feature model performance issues 5 when creating the whole feature model synthesis stage is executed and CI Relation features are added from a large Actual CI Store in one step. Our plug-in adds to the feature model. The third configuration stage is relationships as subfeatures and adds binary constraints in FMP performed on the basis of the CI relations added in the third in order to support choice propagation. Since there exists synthesis stage. The CI relations necessary for the another logical hierarchy between CIs (cf. section 2.3), stakeholder’s IT infrastructure are selected, resulting in the additional constraints representing it are introduced into the final configuration of the feature model. This configuration is feature model. For further implementation details such as the basis for the specification of the Authorized CI Store. naming rules, feature ID definition for traceability reasons, or constraint realization, we refer to [15]. C. Authorized CI Store Creation Fig. 7 illustrates the feature model view, especially with the The last step of our feature-based approach constitutes the ComputerSystem and OperatingSystem sections. Fig. 8 creation of the Authorized CI Store specification. This shows a list of constraints of the feature model presented on specification is generated on the basis of the final configuration Fig. 7. For instance, constraints between the features of the feature model (see Fig. 6). The Authorized CI Store SYS.COMPUTERSYSTEM and SYS.OPERATINGSYSTEM and specification is subdivided into two parts: a list of CI Types between relations and whose target CI Types. selected by the stakeholders and a list of selected CI relations between those selected CI Types. These specification lists are saved in database-specific XML format. Based on these XML files, the Authorized CI Store logical hierarchy is created in the CM system. 4 Feature Modeling Plug-in: http://fmp.sf.net 5 These are known issues owed to FMP’s meta-modeling and just-in- time reasoning capabilities. Figure 8. Feature constraints In summary, the feature-based approach met with favor and appreciation participants of the evaluation. Especially the convenience and the focus on the stakeholder’s interests and goals were emphasized very positively. VI. RELATED WORK Although our approach is – to a certain degree – specific to the CDM, we depict some work that, in a broader sense, deals with variability in data models or data specifications by using Feature Modeling techniques. Usually, feature models are used in various kinds of domain analysis. However, there is some work that uses feature models to provide a tree-oriented-view on fine-grained data with many Figure 7. Feature model example relationships. Czarnecki et al. [16] elaborate on the expressiveness of feature models compared to rich ontology modeling techniques. In their work, they also provide a case study that synthesizes a feature model from a domain-specific V. EVALUATION ontology, i.e. they accomplish a more abstract view on We evaluated our approach and the realized prototype in a domain data. small-scale setup with some colleagues. Although they did not Barthold et al. [17] address the problem of variability in represent stakeholders, they were familiar with customer data models that appears in conjunction with software projects. Their experience with CDM and the CM system variability. They propose an approach to represent and manage ranged from deep to no experience at all with CDM. data variability in entity models. Their approach is based on Based on the goal of our work, we wanted to know (1) if adapters that provide a specific view on the database, i.e. they, the synthesized feature model provides a simplified view on the for example, omit entities or relations that are not relevant for a CDM-based Actual CI Store specification, (2) if our approach certain feature. speeds up creating the specification and (3) how the tool would Some work that deals with mappings between UML be accepted by stakeholders. diagrams and feature models comprises for example the Accordingly, we gave a quick introduction into the following: Braganca and Macada [18] provide a mapping approach and the tool. Thereafter, the participants performed a between features and the elements of Use Case diagrams. They test scenario and created an Authorized CI Store specification. establish a model-driven approach to deriving a concrete Use Finally, we asked them to fill out a questionnaire with Case diagram that represents one product of a product line nine questions. based on the feature configuration. Furthermore, Czarnecki and Antkiewicz [19] treat class and activity diagrams as templates We received very positive answers from the participants containing variability in order to derive concrete model (for details cf. [15]): (1) The tree-based navigation and the instances. They also deal with checking the consistency of support of constraints within the configured feature model were derived UML diagrams. regarded as a significant advantage. (2) All participants also mentioned the time-saving potential. However, some of them also pointed out that time saving depends on the project size, VII. CONCLUSIONS AND FUTURE WORK i.e. the difference could be marginal for smaller projects. (3) In this work, we have developed a feature-based approach Furthermore, participants agreed on the potential to increase to creating a data specification for a CI Store. We dynamically customer acceptance, since less knowledge about CDM is synthesize a feature model that represents such specifications necessary when using the tool. However, experts might miss on a higher level of abstraction and provides a simplified view some additional information that is intentionally omitted in the that is more stakeholder-oriented. This model is configured in feature model. three stages in order to obtain a concrete CI Store specification. The aim of our approach was to reduce the gap between stakeholder’s implicit configuration knowledge and the [10] K. Czarnecki, S. Helsen, and U. Eisenecker, “Staged Configuration complex Common Data Model’s definitions of CIs and Using Feature Models,” Software Product Lines, 2004, pp. 266-283. relationships. [11] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, A.S. Peterson, and C.U.P.P.S.E. INST, Feature-oriented domain analysis (FODA) More precisely, we defined a mapping between features and feasibility study, The Institute, 1990. CDM elements that exploits structural characteristics in order [12] K. Pohl, G. Böckle, and F.V.D. Linden, Software Product Line to obtain a hierarchical feature tree. Further CDM relationships Engineering. Foundations, Principles, and Techniques., Springer, Berlin, 2005. are incorporated as extra constraints of the feature tree. We [13] M. Sinnema and S. Deelstra, “Classifying variability modeling have realized the approach as a tool prototype and have techniques,” Inf. Softw. Technol., vol. 49, 2007, pp. 717-739. performed a first, small-scaled evaluation. [14] M. Antkiewicz and K. Czarnecki, “FeaturePlugin: Feature Modeling However, there is definitely room for improvement in this Plug-in for Eclipse,” In proceedings of the Workshop on Eclipse Technology eXchange, 2004, pp. 67-72. field and several enhancements to the method are possible. The [15] S. Wenzel, “How to Configure a Configuration Management Database – current focus was on providing a general view for all An Approach Based on Feature Modeling,” Diploma Thesis, University stakeholders on the complex CDM-based specifications. Leipzig, 2009. Stakeholder may be even more enabled to configure this [16] K. Czarnecki, C.H.P. Kim, and K.T. Kalleberg, “Feature Models are complex data model by using hierarchically structured feature Views on Ontologies,” Proceedings of the 10th International on models that are tailored towards particular groups. View Software Product Line Conference, IEEE Computer Society, 2006, pp. integration and derivation with feature models, as proposed in 41-51. [16], could provide interesting opportunities. Concerning the [17] J. Bartholdt, R. Oberhauser, and A. Rytina, “An Approach to Addressing actual configuration by the stakeholders, an increase of the Entity Model Variability within Software Product Lines,” Software Engineering Advances, 2008. ICSEA '08. The Third International number of stages would also be possible. Furthermore, the Conference on, 2008, pp. 465-471. synthesized feature model could be extended with additional [18] A. Braganca and R.J. Machado, “Automating Mappings between Use features that reflect supplementary meta information, as Case Diagrams and Feature Models for Software Product Lines,” 11th requested by some evaluation participants. International Software Product Line Conference, 2007. SPLC 2007, 2007, pp. 3-12. Another reason for extending the approach lies in the [19] K. Czarnecki and M. Antkiewicz, “Mapping Features to Models: A conceivable evolution of CI Stores. When IT service Template Approach Based on Superimposed Variants,” Lecture Notes in management processes change, the modifications have to be Computer Science, vol. 3676, 2005, p. 422. reflected in the CI Store specification as well. ACKNOWLEDGMENT We would like to thank our colleagues from the IBM Service Management Department, especially Claudia Dahl and Jürgen Pfaffenberger for supporting this work, as well as the evaluators of the prototype. REFERENCES [1] M. Khosrow-Pour and M. Khosrowpour, Cases on Information Technology And Business Process Reengineering, IGI Publishing, 2006. [2] L. Klosterboer, Implementing ITIL Configuration Management, IBM Press, 2008. [3] K. Czarnecki and U.W. Eisenecker, Generative Programming. Methods, Tools and Applications: Methods, Techniques and Applications, Addison-Wesley Longman, 2000. [4] Office of Government Commerce, “ITIL V3 Glossary: Glossary of Terms, Definitions and Acronyms,” 2009. [5] C. Alison, A. Hanna, C. Rudd, I. Macfarlane, J. Windebank, and S. Rance, An Introductory Overview of ITIL V3, The UK Chapter of the itSMF, 2007. [6] S. Lacy and I. Macfarlane, Service Transition, The Stationery Office Ltd, 2007. [7] H. Madduri, S.S.B. Shi, R. Baker, N. Ayachitula, L. Shwartz, M. Surendra, C. Corley, M. Benantar, and S. Patel, “A configuration management database architecture in support of IBM service management,” IBM Syst. J., vol. 46, 2007, pp. 441-457. [8] L. Tai, R. Baker, E. Edmiston, and B. Jeffcoat, IBM Tivoli Common Data Model: Guide to Best Practices, IBM International Technical Support Organization: http://www.redbooks.ibm.com/abstracts/redp 4389.html (2009.06.10), 2008. [9] C. Dahl, Configuration Management: System Requirements Specification, IBM Corp., 2007.