-The accomplishment of an efficient IT service management is considered a significant success factor in large businesses. Configuration Management (CM) constitutes one of its core disciplines. Off-the-shelf CM systems support the maintenance of the IT by handling the lifecycle of so-called Configuration Items (CIs) and by establishing Change, Configuration and Release Management processes. However, due to the complexity of today's IT infrastructure in large companies, the tailoring of these systems based on concrete stakeholder requirements can become a laborious and error-prone task. We present an approach that enables the configuration of a CM system by leveraging variability management techniques stemming from product line engineering. The synthesis and configuration of a feature model is driven by the Common Data Model, a large domain-specific model that describes CIs and their relationships. We show how our feature-based approach can improve the tailoring of CM systems. Furthermore, we expand on its prototypical realization, elaborate on the integration into the requirements engineering process and discuss its applicability based on experiences obtained from a first evaluation.
IT service management; configuration management; feature modeling; requirements engineering
I.
INTRODUCTION
During the past decades, the technological innovation of
information technology has been the main driving force to
achieve a higher level of efficiency and effectiveness within
businesses [
One of the most important disciplines that ITSM comprises
is Configuration Management (CM) which is responsible for
keeping information about the managed IT infrastructure to be
managed both up-to-date and accurate. According to
Klosterboer [
We were faced with the problem of configuring a CM database as part of an outsourcing project for a company that has to manage a large IT infrastructure with more than 2000 servers. The tailoring of the database, i.e. the creation of its concrete data model, was driven by requirements that had to be elicited from stakeholders. Additionally, the data model of the database had to conform to the Common Data Model (CDM), a domain-specific model from IBM Tivoli that defines types of Configuration Items (CIs) and their relationships.
The manual and indirect tailoring of the database turned out to be very laborious and error-prone: First, the configuration knowledge is elicited indirectly via textual requirements from the customer. Second, the actual configuration has to be carried out by experts with significant knowledge about the database specification, the CDM elements and a considerable number of constraints.
In this context, we present a model-driven approach to
creating a CM database specification that leverages Feature
Modeling [
The remainder of the paper is structured as follows: In section 2, we give an introduction to Configuration Management for IT services, describe the Common Data Model and portray our concrete problem context. Section 3 presents our approach that traces CM database tailoring back to a feature configuration problem. Section 4 expands on the prototypical realization of a tool relevant for our method and section 5 reports on the evaluation experiences gained. Finally, we discuss relevant conclusions and outline future work in section 6.
II.
CM basically denotes “the process responsible for
maintaining information about Configuration Items required to
deliver an IT Service, including their relationships. This
information is managed throughout the lifecycle of the CI.” [
Fig. 1 provides a high-level view on the realization of the
CM system in our project context as well as the connection to
the various service management processes. The system consists
of two main parts: ITADDM 1 and CCMDB 2 [
1 IBM Tivoli Application Dependency Discovery Manager: http://www-01.ibm.com/software/tivoli/products/taddm/
2 IBM Tivoli Change and Configuration Management Database: http://www-01.ibm.com/software/tivoli/products/ ccmdb/ This information comprises CIs and their relationships and is saved in a database called Discovered CI Store.
However, not all the data that has been discovered by ITADDM is relevant for IT service management processes. Thus, the information is filtered and transferred into the CCMDB. The CCMDB, in turn, consists of two logical databases realized in one physical database. These logical databases are named Actual CI Store and Authorized CI Store. 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 a high level of detail and is necessary for root cause analysis, but not for the IT management itself. In contrast, the Authorized CI Store only keeps CIs and relationships that are subject to change and configuration management processes. This information is essential for a failure-free operation of the IT infrastructure.
Fig. 2 shows an example of how part of the data discovered by ITADDM is filtered for its usage in conjunction with IT service management processes. More precisely, the diagram shows parts of the CI Stores’ specifications, which are sets of CI Types and their relationships. The CI Types themselves, their attributes and relationships are defined in IBM Tivoli’s
The Common Data Model3 is a domain-specific model that
describes concepts in the CM domain. According to Tai et
al. [
Discovered CI Store the relationships between those elements”. Thus, it can be seen 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 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 between classes are defined and named according to their corresponding association type. Altogether, almost 1600 unique relationships – defined as associations – exist in CDM.
In order to support the IT service management processes, the stores have to be tailored towards the stakeholders’ requirements. Basically, this tailoring comprises the creation of a specification for the CM databases, i.e. for the Actual and the Authorized CI Store. A specification contains (1) a set of CI 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 relation between classes in CDM. This hierarchy is defined using a Parent attribute in classes, but each parent-child relation is further detailed by a corresponding association. Fig. 3 illustrates the mapping between a store specification and the CDM.
In this paper we focus, however, on the specification of the
addressed here since it is rather driven by technical aspects than by customer requirements. The mapping and transfer between Discovered and Actual CI Store is realized by predefined adaptors with the option to define the hierarchy depth.
The current process of creating a specification for the Authorized CI Store can be characterized as follows:
Elicitation of requirements from the customer: Based on
the current specification of the Actual CI Store, requirements
reflecting the necessary CI Types and relations have to be
elicited from the stakeholder. Our project, for example,
comprised more than 700 requirements [
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 basis of the elicited requirements and the CDM. In practice, requirements are currently mapped to CDM elements in Microsoft Excel spreadsheets.
Common Data Model installedOn
contains sys.operatingsystem sys.cpu
CI Store sys.computersystem contains
sys.momory
Applying the specification: Finally, the specification has to be applied to the Authorized CI Store by entering all elements into a web configuration interface. Furthermore, the former hierarchy of the Actual CI Store has to be retained or recreated.
In its current form, the process turns out to be quite ineffective for the following reasons: First, profound knowledge about possible CI Types and relationships is expected from the stakeholders. Second, available elements are limited by the current specification of the Actual CI Store. Third, consistency between CI Types and relationships is difficult to maintain. Furthermore, terminology and translation issues concerning the textual requirements occur.
III.
FEATURE MODEL SYNTHESIS AND CONFIGURATION
In order to bridge the gap between the (1) Actual CI Store
specification, the definitions in the (2) CDM and the implicit
(3) configuration knowledge of the stakeholders, we introduce
an approach based on Feature Modeling and Feature Model
Configuration [
We try to reduce the disadvantage of the current method by providing a simplified and more coherent view on the Actual CI Store specification in form of a feature model. This model provides a higher level of abstraction for the selection of relevant CI Types and relations that are essential for the stakeholders. The goal is to obtain a specification for the
Our approach (cf. Fig. 4) consists of three main steps: • • •
The approach facilitates the configuration of the feature model on different levels of abstraction. On the highest level, the presented view is intended to be simpler and easier to understand for stakeholders without specific knowledge about the underlying CDM.
The first step of our approach deals with the dynamic creation of a feature model. The model is based on the current specification of the Actual CI Store and allows an adjustable representation of the prospective Authorized CI Store. We introduce four types of features:
Diagram Concept features: root feature describing the underlying logical data model (i.e. the scope of the feature model).
abstraction level of the CDM - Sections. highest CI Type features: representing CI Types contained in the logical data model.
CI Relation features: representing relations between
The feature model is built in three stages. In each stage features of different types are added to the model. All of them are optional, we didn’t need to introduce mandatory features or mutual exclusions. An example of the feature model levels, created by the described procedure, is presented in Fig. 5. The synthesis stages are as follows:
The first stage consists of two steps: the creation of the
creation of CDM Section features (e.g. Administration Section or ComputerSystem Section). These features are either child features of the Diagram Concept feature or of other CDM Section features. This stage of feature model synthesis is initially executed once for all projects.
The second stage of the synthesis comprises the creation of CI Type features corresponding to CDM Sections. The parent feature of these features is a CDM Section feature. This stage is automatically executed on the basis of the CDM Section – CI Type mapping and the Actual CI Store structure. For instance, the CI Types CPU and ComputerSystem belong to the CDM Section ComputerSystem Section and are part of the Actual Diagram Concept CDM Sections CI Types CI Relations
Actual CI Store Administration Section
ComputerSystem Section AdminInfo
ComputerSystem
CPU administers_ComputerSystem contains_CPU CI Store; thus, they are added to the feature model as children of the ComputerSystem Section feature. If the added feature 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 feature model.
The third stage of the synthesis creates CI Relation features. This stage is automatically executed on the basis of 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 as children of the source CI Type feature. Furthermore, for each CI Relation feature, a constraint pointing to the target CI Type feature is added to the feature model.
The second step of the feature-based approach comprises a kind of staged configuration of the synthesized feature model. This configuration is performed by the stakeholders in order to select features directly and, thus, to omit or at least reduce the error-prone elicitation of requirements. We also leverage the choice propagation functionality in feature model tools for the purpose of assuring relationships, which have been added as extra constraints to the feature tree.
In summary, this step extends the current requirements engineering that is carried out for gaining configuration knowledge from stakeholders (cf. Fig. 1 and Fig. 4).
The configuration of the feature model is executed in three stages. The initial feature model is created in the first Feature Model Synthesis stage. In the first configuration stage the CDM Sections relevant for the stakeholder are selected. After that, the second feature synthesis stage is performed and the CI Type features corresponding to the selected CDM Sections are loaded. This allows the execution of the second configuration stage in which the stakeholders select the required CI Types. Based on the selected CI Types, the third feature model synthesis stage is executed and CI Relation features are added to the feature model. The third configuration stage is performed on the basis of the CI relations added in the third synthesis stage. The CI relations necessary for the stakeholder’s IT infrastructure are selected, resulting in the final configuration of the feature model. This configuration is the basis for the specification of the Authorized CI Store.
The last step of our feature-based approach constitutes the creation of the Authorized CI Store specification. This specification is generated on the basis of the final configuration of the feature model (see Fig. 6). The Authorized CI Store specification is subdivided into two parts: a list of 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.
Elicitation CDM Sections Selection of CI Types Selection of
CI Relations
Authorized CI Store Creation
We have realized our approach as an Eclipse plug-in, since
we wanted to be able to embed it with other tools from IBM
Tivoli and since we chose to integrate with FMP4 [
In summary, our plug-in extends FMP, realizes the feature model synthesis and staged configuration as well as it provides adapters for the Actual CI Store in order to obtain the current specification.
As described in section 3, the synthesis procedure creates a
feature model in FMP by leveraging the structure of CDM
Sections and loading the current Actual CI Store specification.
We load subsections just on demand since we faced
performance issues 5 when creating the whole feature model
from a large Actual CI Store in one step. Our plug-in adds
relationships as subfeatures and adds binary constraints in FMP
in order to support choice propagation. Since there exists
another logical hierarchy between CIs (cf. section 2.3),
additional constraints representing it are introduced into the
feature model. For further implementation details such as
naming rules, feature ID definition for traceability reasons, or
constraint realization, we refer to [
Fig. 7 illustrates the feature model view, especially with the ComputerSystem and OperatingSystem sections. Fig. 8 shows a list of constraints of the feature model presented on Fig. 7. For instance, constraints between the features SYS.COMPUTERSYSTEM and SYS.OPERATINGSYSTEM and between relations and whose target CI Types.
5 These are known issues owed to FMP’s meta-modeling and just-intime reasoning capabilities.
We evaluated our approach and the realized prototype in a small-scale setup with some colleagues. Although they did not represent stakeholders, they were familiar with customer projects. Their experience with CDM and the CM system ranged from deep to no experience at all with CDM.
Based on the goal of our work, we wanted to know (1) if the synthesized feature model provides a simplified view on the CDM-based Actual CI Store specification, (2) if our approach speeds up creating the specification and (3) how the tool would be accepted by stakeholders.
Accordingly, we gave a quick introduction into the approach and the tool. Thereafter, the participants performed a test scenario and created an Authorized CI Store specification. Finally, we asked them to fill out a questionnaire with nine questions.
We received very positive answers from the participants
(for details cf. [
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.
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
relationships. Czarnecki et al. [
Barthold et al. [
Some work that deals with mappings between UML
diagrams and feature models comprises for example the
following: Braganca and Macada [
In this work, we have developed a feature-based approach to creating a data specification for a CI Store. We dynamically synthesize a feature model that represents such specifications on a higher level of abstraction and provides a simplified view that is more stakeholder-oriented. This model is configured in 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 complex Common Data Model’s definitions of CIs and relationships.
More precisely, we defined a mapping between features and CDM elements that exploits structural characteristics in order to obtain a hierarchical feature tree. Further CDM relationships are incorporated as extra constraints of the feature tree. We have realized the approach as a tool prototype and have performed a first, small-scaled evaluation.
However, there is definitely room for improvement in this
field and several enhancements to the method are possible. The
current focus was on providing a general view for all
stakeholders on the complex CDM-based specifications.
Stakeholder may be even more enabled to configure this
complex data model by using hierarchically structured feature
models that are tailored towards particular groups. View
integration and derivation with feature models, as proposed in
[
Another reason for extending the approach lies in the conceivable evolution of CI Stores. When IT service management processes change, the modifications have to be reflected in the CI Store specification as well.
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.