=Paper=
{{Paper
|id=Vol-557/paper-4
|storemode=property
|title=How to Configure a Configuration Management System - An Approach Based on Feature Modeling
|pdfUrl=https://ceur-ws.org/Vol-557/paper4.pdf
|volume=Vol-557
|dblpUrl=https://dblp.org/rec/conf/splc/WenzelBR09
}}
==How to Configure a Configuration Management System - An Approach Based on Feature Modeling==
https://ceur-ws.org/Vol-557/paper4.pdf
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.