Development of a CMDB Model toRepresent SaaS OrganizationAssets Relevant for ServiceDelivery
Charlotta Alén
School of Science
Thesis submitted for examination for the degree of Master ofScience in Technology.Helsinki 28.07.2020
Supervisor
Prof. Casper Lassenius
Advisor
MSc (Tech) Ville Kivi
Copyright c⃝ 2020 Charlotta Alén
Aalto University, P.O. BOX 11000, 00076 AALTOwww.aalto.fi
Abstract of the master’s thesis
Author Charlotta AlénTitle Development of a CMDB Model to Represent SaaS Organization Assets
Relevant for Service DeliveryDegree programme Master’s Programme in Computer, Communication and
Information SciencesMajor Computer Science Code of major SCI3042Supervisor Prof. Casper LasseniusAdvisor MSc (Tech) Ville KiviDate 28.07.2020 Number of pages 61+10 Language EnglishAbstractThe growth of an organization, and the resulting increase in the amount of requiredresources, can result in the operations becoming more complex over time. If theseresources are not effectively managed, this can significantly increase the amount ofeffort required for reliable service delivery.
Relevant theoretical background is introduced, including the field of informationtechnology service management (ITSM), the ITSM framework ITIL, and the dis-cipline of configuration management (CM) as both a general and an ITIL process.The configuration management database (CMDB) is introduced as a tool for variousCM processes.
The current state of CM in the company was investigated through interviews withcompany employees involved in various stages of the service delivery process. Theinterview findings were used to identify possible issues to address by improving CMin the company, and to determine a possible solution for the identified issues.
A CMDB was selected as a solution proposal, for which a database model wasformulated based on the interview findings and further research. The initial databasemodel was validated in a workshop setting with a majority of the employees thatwere interviewed for current state analysis.
The thesis is concluded with a revised database model, to represent service-delivery-related company assets in a CMDB, and which can be used as a starting point inthe process of adopting new CM practices. A possible implemenatation method andproduct developments that can affect the model in the future are also discussed.
Keywords Configuration management, configuration management database, CM,CMDB, ITIL, ITSM, SaaS
Aalto-yliopisto, PL 11000, 00076 AALTOwww.aalto.fi
Diplomityön tiivistelmä
Tekijä Charlotta AlénTyön nimi Konfiguraatiotietokantamallin kehittäminen kuvaamaan
SaaS-organisaation palveluntoimittamiselle merkityksellisiä resurssejaKoulutusohjelma Tieto-, tietoliikenne- ja informaatiotekniikan maisteriohjelmaPääaine Tietotekniikka Pääaineen koodi SCI3042Työn valvoja Prof. Casper LasseniusTyön ohjaaja MSc (Tech) Ville KiviPäivämäärä 28.07.2020 Sivumäärä 61+10 Kieli EnglantiTiivistelmäOrganisaation kasvu, ja siitä seuraava vaadittujen resurssien määrän nousu, voivatajan kuluessa johtaa operaatioiden kompleksisuuden lisääntymiseen. Tämä voi mer-kittävästi lisätä luotettavaan palveluntarjoamiseen vaadittavan työn määrää, mikälinäitä resursseja ei kyetä hallitsemaan tehokkaasti.
Teoreettisessa taustatutkimuksessa tutustutaan informaatioteknologiapalvelunhallin-taan (ITSM), ITSM-viitekehykseen ITILiin, ja konfiguraationhallintaan sekä yleis-luontoisena, että ITIL-prosessina. Työkaluksi erinäisiin konfiguraationhallintaproses-seihin esitellään konfiguraatiotietokanta.
Yrityksen konfiguraationhallinnan nykytilaa tutkittiin haastattelemalla yrityksentyöntekijöitä, joiden tehtävät liittyvät palveluntarjontaprosessin eri vaiheisiin. Haas-tattelulöydösten pohjalta pyrittiin tunnistamaan epäkohtia, joihin voitaisiin puuttuaparantamalla yrityksen konfiguraationhallintaa, sekä määrittelemään niille mahdolli-nen ratkaisu.
Ratkaisuehdotukseksi valikoitui konfiguraatiotietokanta, jota varten laadittiin tieto-kantamalli haastattelulöydösten ja jatkotutkimuksen pohjalta. Alustava tietokanta-malli validoitiin työpajassa, johon osallitui valtaosa nykytila-analyysin haastatteluihinosallistuneista työntekijöistä.
Työn päättää päivitetty tietokantamalli, jonka avulla yrityksen palveluntarjoamiseenliittyvää omaisuutta voidaan kuvata konfiguraatiotietokannassa, ja jota voidaanhyödyntää lähtökohtana uusien konfiguraationhallintaprosessien käyttöönotossa. Lo-puksi pohditaan myös mahdollista implementaatiomenetelmää, sekä tuotekehityksenmahdollisia tulevia vaikutuksia tietokantamalliin.
Avainsanat Konfiguraationhallinta, konfiguraatiotietokanta, CM, CMDB, ITIL,ITSM, SaaS
5
PrefaceHuge thanks to both my supervisor and advisor for being able to guide me throughthis process during the hectic time that 2020 has been so far, and to my husband forbeing there for me through this, and our time together in general.
Helsinki, 28.07.2020
Charlotta Alén
6
ContentsAbstract 3
Abstract (in Finnish) 4
Preface 5
Contents 6
Glossary 9
1 Introduction 101.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Background 132.1 IT Service Management . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 ITSM and ITIL 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . 142.4 Configuration Management Database . . . . . . . . . . . . . . . . . . 16
2.4.1 Standards and Existing Models . . . . . . . . . . . . . . . . . 162.4.2 Best Practices and Recommendations . . . . . . . . . . . . . . 17
2.5 CMDB and ITSM Processes . . . . . . . . . . . . . . . . . . . . . . . 18
3 Methods 203.1 Current State Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Solution Proposal - Database Model . . . . . . . . . . . . . . . . . . . 22
4 Current State Analysis 244.1 Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Item Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Applications of Data . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Impressions on Current State . . . . . . . . . . . . . . . . . . . . . . 294.3.1 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7
5 Solution - Configuration Management Database 345.1 Database Model - Initial Proposal . . . . . . . . . . . . . . . . . . . . 34
5.1.1 Universal Attributes . . . . . . . . . . . . . . . . . . . . . . . 345.1.2 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.3 Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.4 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.5 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.6 Supporting service . . . . . . . . . . . . . . . . . . . . . . . . 395.1.7 Third-party source . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Evaluation and Revision of Database Model 416.1 Universal Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.4 Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.5 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.6 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.7 Supporting service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.8 Third-party source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.9 Comparison with Theoretical Background . . . . . . . . . . . . . . . 496.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Discussion 527.1 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Future Modification of Model . . . . . . . . . . . . . . . . . . . . . . 55
8 Conclusions 578.1 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
References 59
A Current State Analysis - Interview Questions 62
B Workshop Materials 64
C Configuration Items and Attributes - Initial Proposal 65
D Configuration Items and Attributes - Final Proposal 68
8
List of Figures1 ITIL 4 service value system. . . . . . . . . . . . . . . . . . . . . . . . 142 CMDB as an integration point for ITSM processes. . . . . . . . . . . 193 Solution model: initial proposal. . . . . . . . . . . . . . . . . . . . . . 354 Solution model: final proposal. . . . . . . . . . . . . . . . . . . . . . . 415 Configuration item: Account. . . . . . . . . . . . . . . . . . . . . . . 426 Configuration item: Contact. . . . . . . . . . . . . . . . . . . . . . . . 43
a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 43b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Configuration item: Customer. . . . . . . . . . . . . . . . . . . . . . . 44a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 44b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8 Configuration item: Environment. . . . . . . . . . . . . . . . . . . . . 45a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 45b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9 Configuration item: Server. . . . . . . . . . . . . . . . . . . . . . . . 46a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 46b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10 Configuration item: Supporting service. . . . . . . . . . . . . . . . . . 48a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 48b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11 Configuration item: Third-party source. . . . . . . . . . . . . . . . . 49a Initial proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 49b Final proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12 CIs to represent software: two models. . . . . . . . . . . . . . . . . . 54
List of Tables1 Interviewees for current state analysis. . . . . . . . . . . . . . . . . . 212 Employees present in the validation workshop. . . . . . . . . . . . . . 223 Challenges - recurring themes in interview responses. . . . . . . . . . 33C1 Configuration item and attribute descriptions - initial proposal. . . . 65D1 Configuration item and attribute descriptions - final proposal. . . . . 68
9
Glossary
Ansible IT automation software used in the company
API Application Programming Interface
CDM Common Data Model
CI Configuration Item
CIM Common Information Model
CM Configuration Management
CMDB Configuration Management Database
GitLab Version control tool used in the company
ITIL Information Technology Infrastructure Library (formerly, cur-rently simply ITIL)
IT Information Technology
ITSM IT Service Management
SaaS Software as a Service
SVS Service Value System
JIRA Issue and project management software used in the company
10
1 IntroductionThe current section describes the motivation behind the topic of the thesis, the prob-lems the research is aiming to solve, and provides a synopsis of the thesis structure.
1.1 MotivationTo be an ethically successful company is, put very simply, to provide value to boththe customers, and the company. Oftentimes the objective is to increase the sizeof the company to provide increasing value for all stakeholders. Growth generallyresults in an increasing number of resources, be these resources hardware, software,or people, all of which can add complexity to the system that is the company. Theincreasing complexity and heterogeneity of IT systems can increase the related costs,since the systems need to remain manageable [1]. To facilitate the growth of thecompany without compromising the quality of the service offered, the operationsneed to be able to grow with the company; they need to be scalable. This appliesnot only to SaaS companies, but to most companies in general.
The company researched in this thesis is currently in a growth phase. For thecompany, this means an increasing number of customers, and to be able provide theirservice to the customers, an increasing number of employees and other resources.The company has experienced rapid growth, and while the difficulties that it is oftenaccompanied by have mostly been avoided, the current operations are not infinitelyscalable as the number of assets continues to increase.
Having control over their assets is imperative for the company to be able to deliverefficient and reliable service to their customers. When the number of assets is lower,it is easier to assert control over all of the company assets, since the number ofvariables is smaller. To continue to effectively manage a growing number of assets,a more organized approach is necessary. Configuration management is a disciplinedesigned for the purpose of having awareness and control over the managed assets.This thesis will investigate a suitable approach and model to apply to the specificneeds of the company in question.
1.2 CompanyThis thesis focuses on a SaaS company, which offers several proprietary softwaresolutions, delivered to customers around the world. According to the Eurostatclassification of companies, the company is considered a “large enterprise” based ontheir number of employees [2]. The software product of the company is very unique,
11
due to which a majority of the different hardware and software resources utilizedfor service provision are highly customized, and often maintained internally. Theservice delivery process associated with the product includes everything from theinitial planning and implementation, to end user support.
Although the rapid growth of the company accentuates the relevance of configurationmanagement, a heavier focus on CM could be justified by the factors mentioned inthe preceding paragraph alone. The high level of customization and maintainingmost resources internally places a significant importance on the ability to trackeach component that can affect the service delivery process. The company havingownership of the entire solution, including user support, would suggest that the sameconfiguration information can be relevant for a significant amount of time. After theinitial effort of adopting new CM practices, the same information can be utilized inlater phases of the service delivery process, which hopefully decreases the amount ofwork required for CM, assuming that an effective solution can be designed to meetthe requirements of the company.
1.3 ObjectiveThe main motivator is to overcome the difficulties concerning reliable service deliv-ery, brought on by the rapid growth of the company and hence required additionalassets. The main issue could be summarized by the company lacking a configurationmanagement approach, which has the scalability to support the growth rate of thecompany. The methods by which this thesis aims to combat this issue is to firstinvestigate the current configuration management practices and requirements in thecompany, and based on the findings, identify a possible approach to configurationmanagement that could be tailored to the needs of the company.
The following research questions were formulated to aid in determining the specificscope and objectives of the thesis. Each question is followed by a reference to thesection addressing the specific question.
◃ What are currently the main bottlenecks in company asset management, andthus a likely priority to be addressed? See section 4.
◃ What could be a suitable configuration management approach to match therequirements of the company? See sections 4 and 5.
◃ What are the relevant assets to be managed with the proposed configurationmanagement approach? See sections 5 and 6.
12
1.4 StructureAfter this introduction, the thesis continues in section 2 by examining prior researchrelated to the field of configuration management. Section 3 will introduce the researchmethods utilized in different parts of this thesis. What follows in section 4 will bethe current state analysis, which will investigate the current situation, and problems,in the company concerning configuration management practices.
Section 5 will describe the solution model created in response to the findings of thecurrent state analysis. This is followed by section 6, describing the model validationprocess and its results, which are the basis for the final, revised version of the proposalmodel.
Finally, in section 7 there will be discussion on the future of configuration managementin the company, including implementation possibilities, and how the effects of internalproduct development could be taken into consideration when moving forward with theprocess. The thesis is concluded in section 8 by summarizing the findings of the thesis.
13
2 BackgroundThis section discusses the theoretical background of the topic through examinationof existing research and practices related to configuration management. The practi-cal background, which considers the current, and past, configuration managementpractices in the company is explored in section 4.
2.1 IT Service ManagementDonna Knapp describes IT service management as “an integrated process approachthat enables an IT organization to deliver services that meet business and customerrequirements” [3]. ITSM simply refers to the set of procedures an IT organizationis conducting during each stage of the service delivery process. There are variousframeworks that provide a model to facilitate the adoption of the ITSM practicesinto the service delivery process of a company.
While currently there are multiple different standards and frameworks for ITSM,ITIL could be considered the de facto framework for IT service management, adoptedby organizations such as NASA, Microsoft, and HSBC [4]. The objective of ITIL isto provide a set of best practice processes and supporting information for an organi-zation to effectively introduce ITSM practices into their operations, thus ensuringthe service delivery process supports the business needs of the company.
2.2 ITSM and ITIL 4The latest ITIL version, ITIL 4, was launched in February 2019, and comprisesof two key components, the ITIL service value system, presented in Figure 1, and“the four dimensions model”. The model consists of four aspects to consider whenapplying the different components of the SVS to service management in the company,in order to ensure that the SVS of the company remains balanced. These aspectsare organizations and people, information and technology, partners and suppliers,and value streams and processes. [5, pp. 14–15]
The central component of the SVS in Figure 1, service value chain, models the chainof key activities required for effective service management [5, p. 242]. Continualimprovement provides a practical improvement model, and guiding principles a seriesof guidelines to unify the service management approach throughout the company,both components aiming at improving company-wide operations [5, p. 15]. Gov-ernance simply refers to the activities directing and controlling the company [5,pp. 80–81]. For the purposes of this thesis the component practices is perhaps the
14
most interesting, since it describes the different processes of the ITIL 4 framework,including configuration management.
Figure 1: Diagram of the ITIL 4 service value system. [5, p. 15]
The ITIL 4 SVS practices can be divided to three categories: general, technical, andservice management practices, which include 14, 17, and three practices, respectively.To gain perspective about the ITIL 4 approach to configuration management, thefocus will be on service management practices. The practice of CM is known asservice configuration management in ITIL 4 and is included in the set of 17 servicemanagement practices. Service configuration management will be explored in thenext section in more detail.
2.3 Configuration ManagementConfiguration management, as a general practice, could be defined as a process whichmakes it possible to monitor and control a system and its changes. CM is in no waylimited to IT systems and organizations; it could be applied to any complex systemto facilitate control over the system for the entirety of its lifecycle. According toAlbert Lester [6] and the ISO 10007:2017 standard [7, p. 2], the CM process can bedivided to five main stages, which are as follows:
1. Configuration management planning.
2. Configuration identification.
3. Configuration change management.
15
4. Configuration status accounting.
5. Configuration audit.
The Configuration management planning process produces a plan for CM activitiesduring the lifecycle of the system. During configuration identification, relevant systemcomponents and their relationships are selected to effectively represent the system.These components will be considered configuration items in the CM process. Theconfiguration change management, or change control in the terms of the ISO standard,refers to the process of evaluating any changes before they are performed in thesystem, and executing them, during the lifecycle of the system. Configuration statusaccounting should occur throughout the lifecycle of the system, and record all changes,be they additions of new CIs, or changes to existing ones. Finally, configuration auditsshould be performed to confirm that the system is adhering to its requirements, andthat the configuration information accurately represents the system. The contents ofthese stages are described very similarly by Lester [6] and ISO 10007:2017 [7, pp. 2–7].
These stages, excluding configuration management planning, are closely reflectedin the ITIL 4 description of what processes are typically required for configurationmanagement: the identification and addition of new CIs to the CM system, updatingconfiguration data based on changes, verifying correctness of configuration data, andidentifying undocumented components through auditing [5, p. 189].
The ITIL 4 service configuration management process provides a framework forCM in an IT organization. The process involves the collection of information aboutvarious CIs, such as hardware, and software, as well as relationships and dependenciesbetween these items. CM should provide the organization with information abouthow each of these CIs contributes to the services they are providing. The ITIL 4approach also highlights the importance of balancing the effort required to maintainthe configuration information with the actual value that information can provide;even if it was technically possible to collect complete information about every singleasset in the company, would this provide any additional value compared to a morelimited selection of CIs? [5, p. 187]
ITIL 4 states that the purpose of service configuration management is “to ensure thataccurate and reliable information about the configuration of services, and the CIs thatsupport them, is available when and where it is needed. This includes informationon how CIs are configured and the relationships between them” [5, p. 186]. Aconfiguration management database offers a method of storing this configurationinformation in a centralized and controlled manner.
16
2.4 Configuration Management DatabaseSimply put, a CMDB can be used store configuration information about a system inthe form of configuration items, and the relationships and interactions between them.The relationship data between the items is imperative from a CM perspective, sinceit can be used to identify, and optimally even predict, the effect CIs can have on oneanother. The contents of a CMDB should provide a comprehensive representation ofthe service being provided through relevant CIs and relationships. An up-to-dateCMDB is a critical success factor for incident management [8], another core processarea of ITSM with focus on “restoring unexpectedly degraded or disrupted servicesto users as quickly as possible, in order to minimize business impact” [9]. Whilethis description is based on ITIL version 3, incident management has retained itsimportance, and purpose, as a service management practice in ITIL 4 as well [5, p.163].
Although the basic concept of a CMDB may appear simple, there can be challengesin determining the suitable scope and coverage of the data selected for the CMDB.The choice of what type of CIs, and attributes, to store in the CMDB should bebased on actually understanding the need and use case for the selected informationto limit the amount of unnecessary information. Automatic collection of detailedCI data can encourage a shift in the balance regarding the nature of data collected,resulting in not enough information about the relationships between items [5, p.189]. An effectively scoped CMDB could be considered to match this descriptionby Brenner et al.: “the CMDB is a logical model of the IT infrastructure and ITservices whose creation and maintenance is the main deliverable of the ConfigurationManagement process” [10]. This does not mean that each and every characteristic ofa CI should be included in the CMDB. The required level of detail is generalized inRance’s statement “you should not include attributes or relationships unless thesecreate more value than it costs to maintain them” [11].
2.4.1 Standards and Existing Models
There are several standards and guidelines for configuration management, for ex-ample ISO 10007:2017, IEEE 828-2012, and SAE ANSI/EIA-649C. This is not thecase for configuration management databases. The ISO/IEC 20000-1:2018 standarddescribes the functionality that is required for CIs, for example, ensuring that CIs arecontrollable and their changes traceable [12]. Standardized CMDB data models arenot as readily available, other than requirements for CIs to have unique identifiers,and data about their relationships with other CIs. The specifics of the data modelare heavily dependent on the organization and their specific needs, as stated in theIEEE 828-2012 standard: “the requirements for the specific type of CMDB tool used
17
for a given project depend on the size and complexity of the project and product.For a small-scale project, a CMDB can be as simple as a spreadsheet“ [13]. However,there are various sources for best practices and recommendations regarding CMDBsand configuration information.
Actual CMDB data models are often proprietary to companies offering their ownCMBD solutions as a service. For example, the BMC Atrium CMBD Common DataModel is an information model utilized by CMDB software offered by BMC. Brenneret al. describe version 2.1.00 of the model as having a strong focus on infrastructuremodeling, and state that “It defines only very few ‘Logical Entity’ classes and doesnot serve well as an information model for ITSM processes” [14, p. 115]. While somenew items have been added between the versions 2.1.00 [15] and a later version 9.1.03[16], many of them “logical entities”, there have been no fundamental changes to themodel, leaving the CDM still more focused on modeling infrastructure components.
DMTF provides an open standard for management information known as the Com-mon Information Model [17], which according to Jelliti et al. would be a suitablemodel to be utilized in a CMDB. They state that the CIM fulfills the requirements ofbeing both extensible, to be able to meet changing configuration management require-ments, and object-oriented, to facilitate attributes universal to CIs of a similar type,and to simplify searching for groups of CIs. They also feel that the CIM contains therelevant classes to represent CIs and their relationships, including process artifactsto be able to utilize the CMDB in ITSM processes other than just configurationmanagement. [18]
2.4.2 Best Practices and Recommendations
Schaaf and Gögetap define a set of requirements that the information model repre-senting the configuration data should fulfill. According to these requirements, theinformation model should be adaptable to changing CM requirements, and addressthe requirements of ITSM processes. In addition, the model should be able representthe relationships between CIs, however complex they may be, and monitor thelifecycle status of CIs. The last information model requirement is the provision ofcommon CI types, and to minimize overhead in the CMDB implementation, thesetypes should be “extendable but ready-to-use data models”, if possible. [19, pp. 2–3]
Not only do the complexity of the system and information requirements of theorganization affect the type of CMDB tool most suitable, they should also affect thelevel of granularity chosen for the CMDB [20]. Granularity in this context refers tothe level of detail in what a single CI represents; is a single server considered a CI, or
18
could the granularity be finer, where the server consists of multiple CIs representingeach of its components? Bonneville considers defining the granularity of the CIs akey factor in whether the CMDB implementation is a success [21].
Unclear granularity also factors in to the choice of approach to the CMDB imple-mentation. Sharifi et al. found that even when taking into account the higher levelof complexity of a top-down approach, it is still preferred over a bottom-up approachdue to its smaller size, ease of use, and time and cost efficiency, in addition to itsclearer granularity. In a top-down approach, the system is first considered in largerparts, going into more detail by creating new CIs and attributes if it is deemednecessary, while the bottom-up approach begins from a very detailed perspectiveby including all assets at the finest level of selcted granularity, and proceeding withaggregates of these more detailed assets, until the highest level of granularity isreached. [22, pp. 278–279].
Brenner and Gillmeister have introduced CMDB patterns to provide more detailedguidance for the implementation of CMDBs. These patterns include multi-valueattributes, which would enable an attribute to contain information about multiplecharacteristics, and rich CI relations, which consist of adding attributes to CI rela-tionships to describe them in more detail. The objective of utilizing these patternsis to reduce the number of CIs, and relationships, while retaining the same level ofinformation in the CMDB, thus reducing unnecessary complexity. These patternsare the most beneficial when combined, that is, assigning multi-value attributes toCI relationships. [23]
2.5 CMDB and ITSM ProcessesThe smallest components of the system, namely CIs, need to be controlled to beable to manage the IT service as a whole. To summarize the chain of relationshipsfrom CIs to ITSM: CIs make up the contents of a CMDB, which can be considereda tool for CM. Service CM is a part of the ITIL 4 framework, that in turn is oneapproach to conducting ITSM. Thus, it can be expected that similar factors canaffect both CMDB practices and ITSM processes. For instance, Marrone and Kolbefound that the higher the level of maturity, referring to the amount of experiencethe organization has related to ITIL, the higher the number of realized benefitsfrom the adoption of ITIL based ITSM processes [24]. This seems to extend toCMDB implementations as well, as Wu found in a study of three organizationsthat although the ITIL framework lists a number of benefits that result from theutilization of a CMDB in the organization, not all of the benefits might be realized inpractice, which can depend on several factors. For example, organizations with more
19
experience related to CMDBs tend to see more benefits from the utilization of one [25].
While the CMDB is an integral part of the CM process in the ITIL framework forIT service management, it can be utilized by other ITSM disciplines as well. Brownand Keller state that “the CMDB also serves as the integration point of changemanagement with other ITIL disciplines, in particular Configuration Managementand Release Management” [26]. Furthermore, Clark et al. also refer to the CMDB asan integration point between different ITSM processes, extending the list of processesinterconnected through the CMDB to the ones shown in Figure 2 [27]. This integra-tion would happen through utilizing the CMDB as a repository for process artifactsof these different ITSM processes. CIs are the process artifacts of configurationmanagement, in addition to which Ayachitula et al. introduce some of the otherITSM process artifacts, including incidents for incident management, changes forchange management, and releases for release management [28].
CMDB
Configuration
Management
Change
Management
Incident
Management
Availability
Management
Capacity
Management
…
Figure 2: CMDB as an integration point for ITSM processes. [27]
20
3 Methods
3.1 Current State AnalysisThe current section describes the methods that were used to examine the currentstate of configuration management in the company.
The objective of the current state analysis was to form as comprehensive a pictureas possible of the current state of configuration management in the company. Thiscould then be utilized to identify possible bottlenecks and determine an issue suitablein scope and nature to be combated in this thesis.
Interviews were chosen as the research method for collecting information aboutthe current state of configuration management in the company. To help reach theobjective of current state analysis, the interviewees were chosen so that a multitudeof viewpoints could be explored, both from technical and non-technical perspectives.This would facilitate the discovery of issues with the widest impact, which if solved,could provide the largest amount of value for the company. The job titles of thechosen interviewees are presented in Table 1, along with the description of their rolein the company, the date of their interviews, and a letter from A to H. Later on, theinterviewees will be referred to by their designated letter.
Due to the qualitative nature of the researched topic, it was determined that personal,semi-structured interviews would be a suitable tool in investigating the current stateof configuration management in the company. In a semi-structured interview, allinterviewees are presented with the same set of questions, however, the intervieweesare free to formulate their response to each question with no pre-determined options[29]. The list of questions created for, and later utilized in, the interviews can befound in Appendix A.
The interviews were conducted through personal meetings with each individualinterviewee on the company premises in Helsinki, Finland. The duration of eachinterview was approximately 30 minutes. The interviewees were not required tocomplete any pre-interview tasks or research, and they were not provided withany materials prior to the interviews. It was confirmed with each interviewee thattheir interview could be recorded for analysis. In the beginning of the meeting,before starting the actual interview, the interviewees were presented with some basicterms related to the subject at hand. They were asked to familiarize themselves withthe terms, which can be found in Appendix A alongside the list of interview questions.
After the interviews, the interview recordings were transcribed to help in the process
21
of analyzing their content. The interview responses were grouped by question, andkeywords describing their content were attached to each response in a process knownas coding [30]. In the systematical approach of thematic analysis, similarly codedtranscript data is then grouped, and frequently appearing codes can be used toestablish patterns and common themes both within individual, and between separateinterviews. These themes and patterns can then in turn be used to form a pictureof the current state of configuration management in the company, and identify asuitable set of challenges to be addressed in this thesis.
Table 1: Interviewees for current state analysis.
Interviewee Role description Date
A Site ReliabilityEngineer
Team is responsible for server platform pro-vision and maintaining the server fleet of thecompany.
Jan 22nd,2020
B NetworkOperationsCenter TeamLead
Team is responsible for maintaining privatedata center network infrastructure, and its op-eration and development in hybrid and publiccloud.
Jan 22nd,2020
C Head ofTechnical 24/7Support
Team lead for first level of customer support. Jan 23rd,2020
D TechnicalConsultant
Responsible for setting up technical integra-tions between customer and company sys-tems, managing data flow, setup, and trans-formations.
Jan 23rd,2020
E SoftwareDeveloper TeamLead
Team is responsible for developing the archi-tecture and scalability of the software.
Jan 23rd,2020
F Service DeliveryManager
Responsible for ensuring agreed service levelfor a specific customer, also involved in serviceand process development.
Jan 24th,2020
G BusinessIntelligenceManager
Responsible for data organization, integra-tion, and interpretation to support decision-making, and ensuring data validity and avail-ability.
Jan 24th,2020
22
Table 1: Continued.
Interviewee Role description Date
H Service DeliveryManager
Team is responsible for ensuring agreed ser-vice level for each customer through con-trolled and scalable development of internalprocesses and best practices.
Jan 27th,2020
3.2 Solution Proposal - Database ModelThe current section describes the methods that were used to develop and validatethe database model for the proposed solution, a configuration management database.
The initial proposal for the configuration management database model was designedusing the results from the interviews, and further research on the company assets.The interview responses provided important insight especially for the process ofchoosing relevant configuration items to be included in the initial database model.The choice of item attributes was more reliant on additional research, both on theassets of this specific company, and the common SaaS company assets in general.The process of developing the database model resembles the activities of the “configu-ration identification” stage of the CM process, described in section 2.3, quite closely.
Table 2: Employees presentin the validation workshop.
Attendee
A Site ReliabilityEngineer
C Head of Technical24/7 Support
F Service DeliveryManager
G Business IntelligenceManager
H Service DeliveryManager
A workshop was deemed a suitable method to validatethe database model proposal. The employees thatwere interviewed earlier (see Table 1) were chosen asthe attendees for the workshop to provide a similarlybroad perspective on the model as they did for thecurrent state analysis. Five out of eight intervieweeswere able to attend the workshop, listed in Table 2.The workshop was conducted as an online meeting,with a duration of approximately one hour. The at-tendees were provided with supporting materials priorto the meeting. However, there were no requirementsto study the materials beforehand, since it would becovered in the workshop. The pre-workshop materialsincluded an entity-relationship diagram of the initialdatabase model (see Figure 3), and descriptions of theselected CIs and their attributes, which can be foundin Appendix C.
23
In the beginning of the workshop the attendees were presented with a short summaryof the findings from the current state analysis, which can be seen in Appendix B,along with the agenda of the workshop. This included the general impression onthe importance of configuration management and current state in the company, andthe challenges of the current system that appeared to be most widely experiencedthroughout the company. The attendees were also introduced to the solution proposal:a CMDB, and what it means as a concept.
To begin with the validation of the solution proposal, the attendees were presentedwith the diagram of the database model (see Figure 3), accompanied by elaborationon to how items, attributes and relationships are presented in the diagram. Thiswas followed by focusing only on the selected configuration items and inquiring theattendees whether they felt that appropriate items were selected for the model, orthat any relevant items were missing. Next, a similar process was conducted for eachindividual item, where the discussion would focus on the attributes of the item. Theworkshop was concluded by answering any remaining questions and collecting anyadditional comments or feedback from the attendees. The attendees’ commentaryand feedback were collected in the form of written notes during the workshop.
After the workshop, the database model was updated based on the notes collectedduring the workshop, updated model shown in Figure 4. This resulted in the additionof one configuration item, and some attributes to the existing configuration items.The updated item and attribute descriptions can be found in Appendix D. It wasnoted that due to changes that are currently being made into the software architectureof the company, some of the selected attributes would not be necessary in the future.However, it was concluded that the proposed model, after the updates, would still berelevant until the transition to new software architecture is complete, which can beseveral years into the future for some existing customer environments. This factorwill be discussed in more detail later in the thesis.
24
4 Current State AnalysisThe objective for the current state analysis was to find the baseline of configurationmanagement currently in place in the company. This included determining thecomposition of the system, and identifying processes and bottlenecks related to thecurrent solution. Establishing the baseline helped refine the scope of the thesis, froma general objective of somehow improving the CM in the company, to having actualissues to address and design a solution proposal for.
Throughout the interviews, the general consensus was that configuration manage-ment in a software company is extremely important. An effective configurationmanagement system would increase reliability and scalability, both for the serviceand the company as a whole, and decrease the amount of time and work required toprovide a dependable service for customers. Since the company is in a stage of rapidgrowth, increasing scalability is imperative.
4.1 Configuration ItemsTo get started with mapping the current situation regarding configuration manage-ment, it was necessary to determine the various components that form the system.The current section describes the process of identifying and classifying current con-figuration items, and the findings of said process.
4.1.1 Identification
The identification of current configuration items was conducted by asking the inter-viewees to specify assets they felt were relevant to their position and duties in thecompany. Despite the varying backgrounds of the interviewees, similarities in theconfiguration items emerged throughout the identification process. The similaritiesremained on a higher level, while the more detailed descriptions were more dependenton the on the area of expertise of each interviewee.
First example of a type of asset that was frequently mentioned by interviewees ishardware. Specifically, servers were brought up by people working in many differentareas related to service provision, both technical and non-technical. This demon-strates relevance of servers as a core element to service delivery. People workingwith infrastructure, for example interviewee B, went into more detail about hard-ware assets, specifying hardware items such as network switches, routers and firewalls.
25
Most of the interviewees considered some kind of software assets to be relevantto their position. The more detailed descriptions ranged from specific softwarecomponents to complete software services, the level of detail largely dependent onthe point of view of each interviewee. For most, relevant software configurationitems included customer specific environments, which consist of various softwarecomponents, such as authentication modules, data storage, and integration interfaces.Environment backups were also considered relevant configuration items for serviceprovision. Software assets included both internal and external services.
Documentation was considered essential from a service delivery perspective. Thetypes of documentation mentioned by interviewees included customer specific docu-mentation describing individual customers and products that are in use for each one,customer contract documents, and technical documentation on different hardwareand software assets. JIRA tickets were also mentioned as a documentation method,used for both issues related to individual customers, and higher-level issues, such asinfrastructure.
During the process of identifying configuration items, the way interviewees commonlydescribed their relevant configuration items often involved grouping them by the typeof the asset, for example software or hardware. This can already be considered arough classification of configuration items. Grouping the items by their type appearsto be logical classification system based on the most interviewees, regardless of theirarea of expertise, used it to describe configuration items relevant to them at least tosome degree. Other possible configuration item classifications will be discussed inmore detail in the next section.
4.1.2 Classification
Classification of configuration items can help to recognize similarities between theitems, and to possibly unify the future methods of configuration management. A verybroad level grouping emerged through the item identification process, which classifiesthe configuration items by their type, for example hardware, software, or document,as described in the previous section. Other possible classification systems were alsoexplored during the interviews. First, by asking the interviewees to classify the itemsthey had described in any way they felt logical, and then by asking the intervieweesto describe the level of criticality they felt appropriate to their configuration items.
The prompt for the interviewees to classify their items lead to descriptions, of varyinglevels of detail, which could be summarized as use cases of the items. In manycases, this type of description leads to a subclassification of certain types of item, for
26
example a business service describing the software product as a whole, and technicalservice referring to the individual software components. Other classifications wouldseparate internal, external, and supporting services, and development, test, andproduction services. Some interviewees went into more detail in their classifications,for example grouping servers by their use case, such as file storage and transfer, cal-culations, or backup storage. However, the hierarchy the interviewees had a tendencyto form, where the use case is a subclass of item type, can be very subjective. Itcould be possible to also consider all items having a certain use case, irrespective ofitem type, for example.
Another interview question was posed to gauge the level of criticality the intervieweesconsidered the configuration items they had mentioned earlier. The configurationitems were mostly considered to be critical, where the item, if non-functional, wouldhave an immediate effect on customer business. For example, as stated by intervie-wee F, “The service will not be functional if the infrastructure, environments, andinterfaces are not functional”. However, some items were considered to have a lowerlevel of criticality, where the effect would either not be immediate, or not be directlyrelated to customers. This would suggest that the level of criticality is dependent onthe use case of an item. The presence of differing criticality levels would make thelevel of criticality another possible classification for configuration items.
The classification of configuration items can be very subjective, and largely dependenton the scope and objective of the configuration management system. Several possibleclassification methods were identified through the interviews, both directly fromthe interviewees, and from similarities in their responses to further questions aboutconfiguration items. There appeared to be some correlation between certain methodsof classification, and other aspects related to the configuration items. For example,the use case, and thus level of criticality, seemed to affect how the item in questionis monitored.
4.2 Item MonitoringThe current section describes how the identified configuration items are currentlymonitored regarding the state of the item, changes in the items, and dependenciesbetween them, as well as how this monitoring data is currently utilized.
4.2.1 Data Collection
The interview process revealed that the configuration items are under various levelsof supervision. This seemed to be dependent on the type of the item, but perhaps
27
more heavily on the use case of the item, and therefore its criticality. An exampleof this would be the difference in the level of monitoring between a production anddevelopment environment for an individual customer, of which the former is morecritical and thus under stricter supervision.
For the purposes of monitoring configuration items, multiple tools are in use, evenwithin individual teams. The scope of monitoring depends largely on the team,for example not all teams monitor items on a customer-specific level. The varioustools are mainly used for different purposes, but many of the interviewees statedthat there is some overlap in the monitoring data between the various monitoringtools and methods. Some of the tools update their data automatically, however forseveral of the tools the information has to be updated manually, which can lead tooutdated and conflicting information. In addition to the presence of multiple sourcesof information, there is not always a definite priority tool that would always have themost accurate information for all items. Due to this, several interviewees felt that itis sometimes difficult to determine the most accurate and up-to-date information, orthat acquiring this information requires an excessive amount of effort.
Change and dependency monitoring also involves large amounts of manual workand expert knowledge, and is mainly conducted internally on a team level. There isno centralized system where all changes would be identified and described, or whatitems they are affecting, therefore it is usually necessary to either know where tofind relevant information, or who to ask for it. Many interviewees felt that somedependencies are often not determined before an effect is observed. Even thoughthere is documentation in the wiki, it is not exhaustive, and has not been createdfrom a configuration management point of view.
System configurations for several components, for example servers, routers, andsome core software components, are stored in scripts and code, which can containsettings and deployment instructions. The software Ansible facilitates automateddeployment of these item configurations, and management of infrastructure as code.It can be used to share a specific configuration among items of similar type, forexample. Detailed information about the current configuration of the item wouldneed to be checked from the configuration file, or directly from the component itself.There are tools to monitor the current status of various infrastructure components,with alerts integrated with internal messaging software used in the company.
Code-based configurations, for items such as many infrastructure components, arestored in GitLab, which gives access to a change history for the configurations. Inaddition, changes are documented in JIRA tickets, which is also the case for manyother configuration items where GitLab is not used. The tickets can contain technical
28
information about the changes, links to the code in GitLab, and other tickets thatare somehow dependent on the ticket in question. Most of this information needs tobe updated manually, for example dependencies between items and items affectedby a specific change are not automatically detected but need to be discovered anddocumented manually.
For application instances, information about the current state, such as version num-ber, can be found in several internal tools, on the server where the application isrunning, as well as on a customer-specific wiki page. Some aspects of environmentstatus monitoring, for example monitoring for application errors, can be automatedthrough scheduled actions, however, some of the monitoring is still manual work.Adoption of a more extensive monitoring tool is currently in progress for severalenvironments. Even though changes are mainly monitored manually, certain changesto the environment configuration are automatically updated in some of the internalmonitoring tools.
Document assets are mostly maintained manually, although for some items, such asJIRA tickets, certain technical information can be updated automatically. Due tothe amount of different systems where different types of documents can be found, theworkload required to keep everything up-to-date can be significant, and the mainte-nance process susceptible to human error. Change and dependency monitoring indocumentation is mainly based on the functionality of the software that is used tomaintain it.
Currently, monitoring of the current status of configuration items is on a relativelycomprehensive level, however, the information is quite scattered in various systems.Much of the information is updated manually, which is not only time-consuming,but can lead to the presence of conflicting data between systems that should containidentical information. Locating relevant information from the various tools andsystems can take a considerable amount of time, especially for inexperienced users.There is sometimes no designated main source for certain information, in which caseidentifying the most accurate data can further increase the workload. Change anddependency monitoring relies heavily on manual processes and occurs mainly withinindividual teams.
4.2.2 Applications of Data
An important objective for any company is to be able to offer their service, and thatis ultimately what all of the monitoring data is utilized for. A growing customer baseincreases the number of configuration items required for successful service provision,
29
which in turn increases the complexity of the system. Operating models need scale tofuture demands, and in several teams the monitoring data is used to develop currentmethods towards more standardized and scalable processes, or there are plans to do so.
Many of the interviewees considered maintaining change history for configurationitems an essential application of the monitoring data. According to interviewee A, atleast in their team, currently the main function of change history is to have a typeof audit trail. However, it is also utilized for various other functions. The historycan help identify the root cause behind a change in the future and facilitate therestoration of the original state of the item, in case it is deemed necessary. “You cango through Git history to see that ‘this change was made for these reasons’, and gainsome insight as to how to reverse the change and what might need to be taken intoconsideration,” as described by interviewee A in more detail. Several intervieweesdescribed the change process from their point of view, and generally the processfollowed a similar pattern, regardless of team. First, the initial changes are createdin a low-risk, often internal, environment. After testing and validation, the changesare replicated in either a production environment or another low-risk environment,until eventually the validated changes are moved to production. Change history isnecessary to be able to reliably replicate the changes during each step of the process.The details of the process can vary based on, for example, the magnitude of thechange, and criticality of affected items.
There was considered to be much variation in the level of documentation arounddependencies between items, and without a comprehensive dependency mapping,understanding of the item dependencies relies heavily on the expertise of individualpeople and their ability to share their knowledge. Due to the complexity of the entiresystem and the level of current processes, monitoring interactions between items isreactive, in the sense that first an effect is observed, which then leads to action. Thedegree of how far the effects of changes can be predicted before testing, especiallyoutside of the changed item, is quite low. Since predicting the effects of a change isextremely difficult, changes that can potentially have a wide impact, or affect criticalitems, go through stricter change control and more rigorous testing. All changes aretested, however, for well-known cases the process can be lighter.
4.3 Impressions on Current StateThe next section describes the interviewees’ perceptions regarding the current stateof configuration management in the company. During the interview process, theinterviewees were asked what they considered to be some strengths and weaknessesof the current configuration management process, and whether they had any ideas
30
for improvement.
4.3.1 Strengths
One of the major strengths of the current system that was touched upon by multipleinterviewees is the presence of highly capable people. Several aspects of the processare heavily reliant on the experience and abilities of individual people, which canof course increase the workload for these individuals. Optimally, every employeewould be able to benefit from the abilities of these experts in a more scalable manner,which would minimize the amount of manual and repeated work for all parties. Itwas also felt that the need for communication can in some cases add some overheadto the process. This people-and-communication-centric approach is likely a remnantfrom the earlier days of the company, when their employee base was much smaller.Due to its rapid growth, the company has not had time to completely adopt theprocedures and mindset of a much larger company. Interviewee G outlined this intheir response to whether configuration management is important: “Yes, especiallysince we are a growing company, which is when the lead time for communicationcan increase exponentially. In a small company it does not matter that much, butwhen there are large amounts of data it can mean several weeks’ worth of workloadon an organizational level. In theory you can add more people, but it is expensive,difficult, and increases complexity.”
Another strength that was specified in the interviews is the possibility of beingagile, which is facilitated by the efforts of experienced, diligent people. Changes canbe made quickly, since there is often no strict form to the change process. Sincedevelopment of new, more standardized processes is underway, this might not be thecase in the future, at least to the same degree. However, it is to be expected, when theobjective is to reach a balance between efficiency and reliability in a growing company.
The versatility and customizability of some of the utilized solutions was considered tobe a strength in the current configuration management system. However, it was notedthat the customizability offered by an open-source solution comes with the caveat ofrequiring additional work to maintain and develop the solution further. On a similarnote, the company having ownership of most of the components used to provide theservice was considered both a strength, since the company has more control over theprocess, and a weakness, since there is more room for error. While not exactly anaspect of the current configuration management system, it does pose the question ofwhat has more value to offer towards reliable and efficient service delivery; internalcontrol over the process, or reducing internal workload by outsourcing some elementsof the process.
31
4.3.2 Limitations
One of the most prominent issues, based on the interview process, is the scattered-ness of information. To combat this, in addition to the occasional inconsistenciesin information, several interviewees felt that a centralized database for informationon configuration items would be useful. This idea was taken a step further by oneinterviewee proposing this database be integrated with JIRA, which is already usedfor change management. This type of JIRA integration could facilitate automationwhen it comes to analyzing the effects a change can have on configuration items, andpossibly identify items that might be affected by a certain change.
Another perceived issue was the amount of manual work currently required, bothfor data collection and utilization. This was considered by the interviewees to beinefficient and susceptible to human error. They felt that the amount of manualwork, combined with the perceived scatteredness of information, is not scalable tofuture demands regarding efficient and reliable service delivery. Several teams havealready started the process of increasing automation in their operations, and furtherautomation of processes would be well-received in other teams.
Many interviewees felt that a factor that is adding to the amount of manual workis the scarcity, or for some situations the complete lack of standardized processes.The presence of multiple potentially valid, yet different, processes to reach the sameobjective was considered confusing, since it is not always clear which is the preferredprocess. However, most interviewees felt that this issue has been acknowledged in thecompany, and in some teams the development of processes has already begun. Thedevelopment of more standardized processes could reduce the workload of individualpeople with specialized experience, since they would be able to share their knowledgein a way that does not require additional effort every time their experience is required.What some interviewees felt was a lack of prioritization could be an extension tothe issue of lacking standardized processes. For example, in the event that thereare multiple simultaneous change requests, there is sometimes no standard systemdetermining what should be prioritized. It was felt that often the party that is themost insistent has their request completed first.
4.4 SummaryThe current section summarizes the key findings from the current state analysis anddiscusses their effect on the scope of the thesis.
32
As summarized by interviewee A, with reference to configuration management andits importance: “In a company of this scale, it is the root of reliability. Uncontrolledchange leads to uncontrollable problems.” The general impression on the current stateof configuration management was that although the current model has been adequatefor a smaller company, due to the increasing complexity of the system, developingthe configuration management process further is important. Especially now that thecompany is in a phase of rapid growth, the company has multiple increasing factors,such as the customer base and number of configuration items. An effective modelfor configuration management would be scalable, both to future demands, and thevarious functions already present within the company.
Configuration items are already being monitored, to a degree which depends on theitem. However, the collected data can be lacking from a configuration managementperspective. For example, information about dependencies between items can bevery limited, and the effects that items may have on one another are often not knownbefore they are observed in practice. Change history is collected for items for whichit is deemed relevant. Some examples of how the monitoring data is applied includereactive issue resolution, and change management.
The interview process revealed some potential areas for improvement, for examplethe amount of manual work, both in maintaining up-to-date data about configurationitems, and in its practical applications. The lack of a central and prioritized sourceof information was considered problematic, as finding the most accurate data acrossmultiple sources could be time-consuming, and in the event of conflicting data couldlead to even more effort needed to obtain the desired information. The workloadcould increase even further due to incomplete processes, or the lack of a definitivebest practice process in many aspects of service delivery.
Some of these issues have already been acknowledged in the company, and in severalteams the development and adoption of new processes has already begun, or tentativeplans are in place for future development. The main objective is to improve thereliability and efficiency of service delivery. A number of issues could be tackledto help achieve this goal, such as reducing the amount of manual work, and thussusceptibility to human errors, through automation, and standardizing processes,ensuring that they can be completed by more people, and would not be as dependenton a few individuals. In general, any reductions in overhead would facilitate higherlevels of efficiency. Table 3 summarizes the challenges that were most frequentlyeither described or specified by interviewees during the interview process.
33
Table 3: Challenges in the current system - summary of recurring themes ininterview responses.
ThemeInterviewee
CountA B C D E F G H
Amount of manual work • • • • • • 6/8
Heavy dependence oncommunication and cooperation
• • • • • • • 7/8
Incomplete standardization ofprocesses
• • • • 4/8
Limited inter-item relationshipand interaction monitoring
• • • • • • • • 8/8
Scarce, dispersed, orcontradictory information
• • • • • 5/8
34
5 Solution - Configuration Management DatabaseThe current state analysis resulted in the identification of challenges in the currentconfiguration management system of the company. The issues that emerged mostfrequently throughout the interviews can be seen in Table 3. A possible solutionthat could combat many of these issues is a configuration management database,which would function as a centralized, prioritized source of information on bothconfiguration items and their inter-item dependencies. A functional CMDB woulddecrease the amount of manual work required to both store and acquire informa-tion, since it would be considered the main source of information for the selectedconfiguration items. Thus, any changes in the configuration items would only needto be recorded in the one place, and the information would be readily available. Thistype of standardized source of data would also heavily support the development ofstandardized processes, which in turn would decrease the need to depend on onlya few individual experts. These factors together would make service delivery bothmore efficient and more reliable.
5.1 Database Model - Initial ProposalThe current section describes the initial database model that was developed to rep-resent assets of the company as configuration items, and the mutual relationshipsof these items. The model is shown in Figure 3 as an entity-relationship diagram.Although the relationships are represented in the diagram by either optional ormandatory one-to-one, one-to-many, and many-to-many connectors, the type of therelationships was not a priority in the development of the model and was not focusedon during the validation process. General descriptions of the item attributes can befound in Appendix C. This model was presented to the attendees in the validationworkshop.
5.1.1 Universal Attributes
There are several similarly titled attributes, present in multiple items, which sharea definition and purpose. These attributes will be introduced in this section, andtheir descriptions are excluded from the itemwise introductions that follow. Firstof these attributes is _id, present in every configuration item, which can be usedto identify each unique item. Another attribute shared by multiple items is Name,which is simply there to provide a human-readable identifier for each individual item,in addition to the unique identifier code _id. Name can be the actual name for anyof the items such as customers, people, or services, and the hostname for servers.Finally, the attribute Criticality, which is used to indicate the importance of the
35
item. The scale lowest-low-medium-high-highest is used in the initial database model,the different levels describing the level of impact the item has on service delivery.
Criticality is one of the very few attributes that does not have a predetermined valuecurrently in place. The proposal is to have the level determined based on otherattribute values, with the option of manually overriding the value to account for anyunusual customer requirements. Since the criticality of an item can be affected byseveral factors, this classification process will be further discussed in section 7.
Contact
_id
Name
Role
Type
Server_id
Cores
Criticality
Data center
Disk space
IP addresses
Memory
Model
Name
Networks
Type
Environment_id
Criticality
Host server
Linked environments
Linked servers
Memory
Name
Software version
Subtype
Supporting services
Third-party sources
Type
Customer
_id
Contacts
Environments
Name
Supporting service_id
Criticality
Name
Software version
Type
Third-party source_id
Criticality
Name
Figure 3: Solution model: initial proposal.
5.1.2 Contact
The Contact item can be used to represent different types of contact personnelrelevant to a customer, both internal and external. It was deemed relevant to includethis in the configuration items for the model, since for reliable service delivery, itwould be important to know who to contact in case of critical events or questions,
36
for example. The connection between customer and relevant contacts is facilitatedby including the Contact items in the attributes of Customer.
In addition to the universal attributes _id and Name, described in section 5.1.1,the Contact item has the attributes Email, Role, and Type. The Email attributeprovides a means of reaching the contact, their email address, which is the generalmethod of customer communication in the company. Role describes the contact’srole, and thus the people responsible for different areas of service delivery relatedto that specific customer. The Type attribute can be used to differentiate betweeninternal, meaning people within the company, and external contacts.
5.1.3 Customer
The Customer item can be used to represents a customer of the company. The inclu-sion of the item in the solution seemed self-evident, since the customers are in the focalpoint of any company offering software as a service. Without customers, there wouldbe no need for the company’s product in the first place. The number of attributeswas kept quite small at this stage, because there already is a comprehensive customerdatabase in the company, with more focus on the business side instead of technical.The possibility of connecting the Customer items in the CMDB to the customerentries in the existing customer database could be considered in the future, whichlead to the decision to limit the attributes in the Customer item to only the essentials.
The attributes of the Customer consist of the universal attributes _id and Name(see 5.1.1), and item-specific attributes Contacts and Environments. Both of theitem-specific attributes are references to other configuration items, described onan item-level in sections 5.1.2 and 5.1.4, respectively. The Environments attributeidentifies all of the software environments that belong to the customer, which makeup a large part of the product the customer has purchased from the company. TheContacts attribute is a collection of all contacts, both internal and external, relevantto service provision for each customer. Inclusion of this information is essential to beable to minimize possible communication-related overhead. Both the Environmentsand Contacts attributes can include references to multiple Environment and Contactitems.
5.1.4 Environment
The Environment item can be used to represent any of the software instances ofthe company, including both customer instances, and different types of internalenvironments. Since the software environments form almost the entirety of the
37
product of the company, it is vital to include the item in the database model. It isalso an attribute of the Customer item, described in 5.1.3.
The attributes of the Environment item include the universal attributes _id, Criti-cality, and Name, described in section 5.1.1. Memory and Software version containbasic information about the environment. Memory is the amount of memory allo-cated for the environment, which is an important factor to consider when planningserver allocations on a company level. Software version is the current version of theenvironment and can be used to identify all environments affected by version-specificissues, for example. The remaining attributes are references to other configurationitems relevant to the current Environment item.
The Host server attribute represents a single Server item, described in 5.1.5, wherethe environment is stored, whereas Linked servers can refer to multiple Server itemsthat are otherwise connected to the environment, such as backup or file servers.The inclusion of these attributes facilitates the identification of environments, andcustomers, affected by changes to specific Server items, and the expected impact onservice delivery.
Linked environments refers to other Environment items that are somehow connectedto the selected Environment. The connection could be, for example, the environ-ments having dependent processes through shared interfaces. A possible use case forthis information could be the need to duplicate a customer’s production setup in abackup environment due to hardware failure, which might require changing settingsin a linked Environment to refer to the backup environment, now functioning as atemporary production system.
The Supporting services attribute can refer to any number of Supporting service items(see 5.1.6) that are connected to, or a part of, the environment. The attribute isincluded in the solution is to provide a means to track different software componentsthat may have an effect on the environment. The attribute Third-party sourcesis included for similar reasons, and can refer to any number of Third-party sourceitems (see 5.1.7). Third-party source items represent external sources of data thatare somehow utilized in the environment, hence having varying levels of impact onits operation.
The Type attribute divides the environments into two groups: internal and external,the latter generally being more critical than the former due to having a more directimpact on service provision. The Subtype attribute can be used to further classifythe environments to, for example, production, test, or development environments.These Type-Subtype combinations can be used when determining the criticality of
38
environments, since they generally correlate with how important the item is forservice provision. This facilitates some automation in the classification of items,the objective being if not to determine the final level of criticality, then at leastprovide an acceptable default value, which can then be refined if considered necessary.
5.1.5 Server
The Server item can be used to represent the different servers of the company. Serversare at the heart of the infrastructure of the company, since a majority of customerenvironments, and supporting services, are running on internal servers, along withmost customer data being stored on company servers. As such, they were deemedrelevant to be included in the solution model. The item is also an attribute of theEnvironment item, since the Host server and Linked servers attributes refer to Serveritems.
The attributes of the Server item include the universal attributes _id, Criticality,and Name, described in section 5.1.1. A number of attributes are used to describethe hardware specifications and physical properties of the server, the first of whichbeing Data center. The attribute describes the physical location of the Server whichis pertinent in, for example, ensuring that the company complies with legislation andregulations governing data collection and storage in all their operations, regardlessof location. The physical location of the server is also important simply to be ableto correct issues with the hardware.
The attributes Disk space and Memory provide the amount of disk space, and memoryon the server, respectively. The attributes should include at least the total amountfor both. The attribute Memory could also include the amount that has already beenallocated for environments on the server, and the amount that can freely be allocatedto additional environments. This information could help simplify the process ofrelocating environments and designating servers for new environments. For the Diskspace attribute, in addition to total disk space, the amount currently available, orcurrently in use, could be included to centralize the status monitoring of availabledisk space.
The attribute Type can be used to classify Server items based on their use case,which could be, for instance, file storage, backup, or calculation. The Model attributecontains information about the make and model of the server, and the attributeCores contains the number of processor cores. Currently these three factors are usedto classify the different server setups, which can be deduced from the hostname ofthe server. However, there are some older servers that do not adhere to the current
39
naming scheme. Since the more current server hardware configurations are quitestandardized within the company, these three attributes can provide a comprehensivegeneral picture of the server. Including these attributes in the solution model facili-tates centralized storage of this information, and can be more secure than includingit in the hostname, since access to a CMDB can be easier to control. In a SaaScompany with a very particular product, the exact technical architecture can bea significant competitive advantage, which is why it is essential to keep its detailsconfidential.
A very relevant attribute to include in the solution is Networks, which providesinformation about all the networks the server is connected to. A network failurecan impact service provision from slightly impeding regular operation, to preventingcustomers from accessing their service entirely. The ability to identify all serversaffected by a network failure can not only facilitate more effective recovery fromnetwork faults, but also aid in ensuring comprehensive network redundancy. TheIP addresses attribute contains both public and private IP addresses of the server,which are used to identify the server within the network, both by any automateddeployments or processes, and personnel needing to access the server.
Some consideration was put into including two additional configuration items inthe initial model, Data center and Network, which could then be referred to in theData center and Networks attributes. However, it was decided that it would notbe necessary, as it would add complexity to the solution without providing muchadditional value at this point. This matter will be discussed further in section 7.
5.1.6 Supporting service
The Supporting service item can be used to represent various software componentsand services. It is also an attribute of the Environment item, to facilitate a connectionbetween environments, and all supporting services that can affect them. Due tothe large number of different services, and the limited scope of this thesis, the itemwas designed to be very general, in order to facilitate the representation of differenttypes of services and components, even if only to a primitive degree. Although thelevel of detail of the Supporting service item is quite limited, it would facilitate theidentification of other items affected by failures in certain supporting services, forexample, which is why it was included in the solution model.
In addition to the universal attributes _id, Name, and Criticality, described insection 5.1.1, the item has two attributes: Software version and Type. The purposeof the Software version attribute is to be able to identify all environments that are
40
affected by a specific version of the service. The Type can be used to classify thedifferent services based on their use case, for example authentication, integration, orconnectivity. This can be useful information when, for example, trying to diagnoseissues concerning a specific function, but without certain knowledge about whichspecific service is causing the issue. If all of the services involved in the function canbe identified, they can be prioritized when investigating the issue.
5.1.7 Third-party source
The Third-party source item can be used to represent any third-party data sourcesthat are utilized by the company, such as external sources for currency conversionrates or weather data. It is also an attribute of the Environment item, to facilitate aconnection between environments, and all third-party data sources that can affectthem. Since, for example, disruptions in the data sources can affect regular processingof customer data, it was deemed relevant to include an item representing these datasources in the solution model. The initial proposal of the item has no item-specificattributes, only the universal attributes _id, Name, and Criticality described insection 5.1.1.
41
6 Evaluation and Revision of Database ModelThe current section describes the validation and revision processes of the databasemodel introduced in section 5. The final version of the database model was revisedfrom the initial model based on feedback gathered during the validation workshop.
Customer
_id
_status
Contacts
Environments
Name
Contact
_id
_status
Name
Phone number
Role
Type
Supporting service_id
_status
Criticality
Name
Software version
Type
Environment_id
_status
Accounts
Architecture
Criticality
Host server
IP whitelist
Linked environments
Linked servers
Memory
Name
Software version
Subtype
Supporting services
Third-party sources
Type
Third-party source_id
_status
Criticality
Impact
Name
Account
_id
_status
Password
Server
Type
Username
Server_id
_status
Age
Cores
Criticality
Data center
Disk space
Encryption
IP addresses
Maintenance status
Memory
Model
Name
Networks
Subtype
Type
Warranty
Figure 4: Solution model: final proposal. New items and attributes italicized.
The final proposal is shown in Figure 4 as an entity-relations diagram similar to
42
the initial proposal in Figure 3. The revised item and attribute descriptions can befound in Appendix D. No items or attributes had to be removed from the initialproposal, and no changes were made to the existing inter-item relationships.
6.1 Universal AttributesOne universal attribute was added to every configuration item: _status. This wasdone to make one essential function of a CMDB more explicit, that is, the ability tomonitor the lifecycle status of each CI. The _status simply indicates the currentstatus of an item. No other changes were made to the universal attributes.
6.2 Account
Account
_id
_status
Password
Server
Type
Username
Figure 5: Configuration item:Account - added based onworkshop.
Account is an entirely new configuration itemadded to the final version of the databasemodel proposal. The item and its attributescan be seen in Figure 5. During the work-shop, the need to include certain account in-formation in the model emerged. Since sev-eral different types of accounts are in use,and they all share a similar schema, it wasdecided to create an additional configurationitem to represent the different types of ac-counts.
The Account items can be connected to relevantenvironments through the new Accounts attributein the Environment item, and to the server it canused to access through the Server attribute in the Account item. In general, accountsare unique to a server, however, since environments can be linked to multiple serversthrough different types of processes, Environment items can refer to multiple Accountitems in the Accounts attribute.
The Type attribute indicates the protocol used to connect to the relevant server;the protocols most widely utilized in the company being FTP and SFTP. Theattributes Username and Password represent the account credentials, username andpassword, respectively. However, the inclusion of the Password attribute depends onthe implementation of the CMDB, since it would need to be stored in accordance withall information security practices in the company. As a possible alternative to storing
43
the password in the database, the Password attribute could contain informationabout where the password can be found.
6.3 ContactAs can be seen in Figure 6, not much was altered in the Contact item based onthe validation workshop. The only change, apart from the new universal attribute_status (see 6.1), was the addition of the Phone number attribute. This attributerepresents the phone number of the contact, to provide an additional method ofreaching each contact. The general practice in the company is that email is the pri-mary method of communication, and phone calls are reserved for more urgent matters.
Contact
_id
Name
Role
Type
(a) Initial proposal.
Contact
_id
_status
Name
Phone number
Role
Type
(b) Final proposal.
Figure 6: Configuration item: Contact - before and after work-shop.
6.4 CustomerOther than the addition of the universal attribute _status, described in section6.1, the Customer item remained unchanged through the validation and revisionprocesses, as can be seen in Figure 7. It was agreed that the selected attributeswould be sufficient at this stage, and that since most of the additional customerinformation is present in the existing customer database, the possibility of linkingthe Customer items with the customer database is something that could be useful inthe future.
44
Customer
_id
Contacts
Environments
Name
(a) Initial proposal.
Customer
_id
_status
Contacts
Environments
Name
(b) Final proposal.
Figure 7: Configuration item: Customer - before and afterworkshop.
6.5 EnvironmentThe revision of the initial model resulted in multiple new attributes being added tothe Environment item, as can be seen in Figure 8. The new Accounts attribute wasalready brought up in section 6.2, which describes the Account items the Accountattribute can refer to. Since one environment can be required to connect to multipleservers, the attribute can refer to multiple Account items. These items can representany account information relevant to the environment.
The next attribute is related to the very fundamentals of the main software product.A new type of distributed architecture is being developed at the company, which isthe reason for the addition of the attribute Architecture. It simple describes whetherthe environment is using the current or the new type of architecture, as this affectsthe way the environment is hosted and operated.
For environments operating on the new type of architecture, the Host server andMemory would not be needed in the same format, since the environment can, inessence, be hosted on multiple servers, and be dynamically allocated resources froma server cluster. However, it was agreed that due to the time it takes to completelytransition to the new architecture, the initial solution supplemented by the newattributes would be relevant for a long enough time, thus no fundamental changeswere required. The value of the Architecture attribute could be used to change therequirements for the Host server and Memory attributes, for example, to facilitateutilizing the CMDB for environments running both types of architecture, for theentirety of the transition period.
45
Environment
_id
Criticality
Host server
Linked environments
Linked servers
Memory
Name
Software version
Subtype
Supporting services
Third-party sources
Type
(a) Initial proposal.
Environment
_id
_status
Accounts
Architecture
Criticality
Host server
IP whitelist
Linked environments
Linked servers
Memory
Name
Software version
Subtype
Supporting services
Third-party sources
Type
(b) Final proposal.
Figure 8: Configuration item: Environment - before and afterworkshop.
Finally, the IP whitelist contains the IP addresses, or address ranges, that have beenpermitted to access the environment. The need for this attribute to be includedin final model was brought up explicitly during the workshop. It can be used, forinstance, to help diagnose issues the customer might have in connecting to theirenvironment.
6.6 ServerSeveral new attributes were added to the Server item as a result of the revisionprocess, which can be seen in Figure 9.
46
Server
_id
Cores
Criticality
Data center
Disk space
IP addresses
Memory
Model
Name
Networks
Type
(a) Initial proposal.
Server
_id
_status
Age
Cores
Criticality
Data center
Disk space
Encryption
IP addresses
Maintenance status
Memory
Model
Name
Networks
Subtype
Type
Warranty
(b) Final proposal.
Figure 9: Configuration item: Server - before and after work-shop.
The purpose of many of the new attributes added to the Server item is to helpmonitor the lifecycle, and related events, of the server in question. These attributeswere requested to be added to the database model during the workshop. The firstof these is Age, which describes the age of the server. This could be the actual ageof the server, or the date the server was commissioned. The age of the server canaffect its use case: older servers can be replaced by newer ones and moved fromproduction use to testing or development, for example. The newer servers are usedfor the more critical operations to minimize risks that often come with age anduse, such as faults due to wear to the machine, or more limited support from themanufacturer. Centralizing this information can help in capacity planning whenexpanding the server fleet, or decommissioning old servers, for example.
47
The Maintenance status attribute can indicate whether the server is currently un-dergoing maintenance, or any scheduled maintenance operations. The last of theselifecycle related attributes is Warranty, which contains the date when the warrantyof the server will expire, or for servers that are no longer under warranty, an indicatorof that fact. This information can affect the proceedings when it comes to mainte-nance operations on the servers, for instance, the for a server still under warrantythe operation might lead to replacing the machine, whereas for servers where thewarranty has expired, different type of maintenance could be conducted.
A fairly simple attribute Encryption was requested to be added, to provide anindicator of whether the Server is encrypted or not. Some customers require thatall their data is stored only on encrypted servers, therefore it is important for theencryption status of each environment to be readily available, in case, for example,the customer environments need to be relocated to another server, or resources needto be allocated for customers requiring disk encryption.
The Subtype attribute facilitates more detailed classification of Server items, togroups such as production, test, or development. Similar to the Environment item,this can facilitate more automation in assigning criticality levels to Server itemsthrough increasing the number of variables that the criticality can be dependenton. The reason why this attribute was not included in the initial proposal was theprevailing impression that servers could be concurrently hosting both production andtest environments, for example. However, during the workshop it became apparentthat this is not always the case, hence the inclusion of the Subtype attribute in therevised proposal.
The Type or Subtype attribute could also be used to indicate whether the server isused for environments running the current, or the new type of architecture, sincethis can affect the attributes that are relevant for a Server item, similar to what isdescribed in section 6.5 for Environment items. In the new distributed architecture,server resources are dynamically allocated for environments. This can lead to, forinstance, the attributes representing physical aspects of the server being subject tochange, since the resources can be allocated from a different server in the cluster eachtime. Being able to differentiate between servers based on the type of architectureused makes it possible to make certain attributes optional for certain instances ofServer items, for example. This would facilitate the usage of the same CMDB,and database model, for both types of architecture, at least for the duration ofthe transition period. Workshop attendees agreed that this would be a very fea-sible way to proceed, as the complete transition to the new architecture can take time.
48
During the development of the initial database model, the inclusion of a Networkitem was briefly considered. This item would have expanded on the Server item’sNetworks attribute, by describing, for instance, devices included in the Network.However, it was decided that being able to monitor individual network devices isnot a priority at this stage, and that it would be sufficient to only use the Networksattribute to describe networks a server is connected to. This decision was supportedby workshop attendees.
6.7 Supporting service
Supporting service
_id
Criticality
Name
Software version
Type
(a) Initial proposal.
Supporting service
_id
_status
Criticality
Name
Software version
Type
(b) Final proposal.
Figure 10: Configuration item: Supporting service - before andafter workshop.
As shown in Figure 10, the Supporting service item was not affected by the revision ofthe initial database model, except for the addition of the universal _status attribute,described in section 6.1. Nonetheless, some comments were made that should betaken into consideration and could be considered concrete areas of improvement forthe future. The core of the feedback was that since the Supporting service item isvery general, it can be used to represent various resources, however, this can alsolead to a very disorganized category that can become virtually useless quite easily.It was not considered a priority to change this item now, but rather to be aware ofthis possible pitfall when moving forward.
Instead of modifying the original Supporting service item, more specific items couldbe created based on future requirements and resources available. An example of thisprocess was already conducted based on the validation process. The initial proposalrepresented different types of accounts using the Supporting service item, however,a specific need to include account information emerged during the workshop. As a
49
result, it was decided to separate the accounts into their own type of configurationitem, as described in section 6.2.
6.8 Third-party sourceIn addition to receiving the new universal attribute _status (see 6.1), the Third-partysource item went through one modification based on the validation process, as shownin Figure 11. It was suggested that instead of an arbitrary scale representing thecriticality of the item, there could be a description of what would happen if a specificThird-party source item fails, and specific instructions on how to proceed. To addressthis, the Impact attribute was added. The attribute should contain the informationmentioned earlier: practical impact and instructions in case of failure. The decisionto not replace the original version of the Criticality attribute was made to facilitatethe identification of items based on their level of criticality, regardless of item type,since most of the items contain the Criticality attribute.
Third-party source
_id
Criticality
Name
(a) Initial proposal.
Third-party source
_id
_status
Criticality
Impact
Name
(b) Final proposal.
Figure 11: Configuration item: Third-party source - before andafter workshop.
6.9 Comparison with Theoretical BackgroundThe final model proposal is quite simple, with a relatively small number of configu-ration items and attributes. This is in accordance with the guideline of adjustingthe model to the specific needs of the organization, which at this point is to be-gin the CM process with only the core assets and their most important characteristics.
The top-down approach of developing the CMDB model seemed more intuitive andlogical, given the somewhat limited scope of this thesis and the introduction of severalkey assets during the interviews for current state analysis. These key assets were
50
mostly of a higher level of granularity, such as servers, environments, and customers.Fortunately, the top-down approach is usually the preferred option due to severalfactors introduced in section 2.4.2, according to Sharifi et al. [22, p. 279]. While thegranularity of the model is currently quite coarse, it is possible to increase the levelof detail in the future if required. For instance, individual supporting services can beseparated from the Supporting service type of CI into their own item. This makesthe model extendable and adaptable to possibly changing CM requirements, whichis also a requirement of a CMDB information model as mentioned in section 2.4.2.
As mentioned in section 2.4.2, it is important for a CMDB to be able to track notonly the CIs themselves, but the relationships between them. These relationshipscan be seen in the model in Figure 4, and are described in section 5 in more detail.The attribute _status was added to each CI to make a fundamental feature of aCMDB information model explicit and accentuate its importance, the feature beinglifecycle status monitoring. These two aspects were stated by Schaaf and Gögetap asone of the requirements for a CMDB information model [19, p. 3].
Brenner and Gillmeister advocated for the use of CMDB patterns, introduced insection 2.4.2, which included multi-value attributes and rich CI relations to reducecomplexity of the CMDB without compromising the amount of information [23]. Themulti-value attribute pattern has been utilized in the proposed model, for examplethe Contacts attribute of the Customer item, and the Linked servers attribute of theEnvironment item. There are currently no rich CI relations in the model, however, itcould be modified to include instances of this pattern. For instance, the Host serverattribute of the Environment item could be replaced by including the host server inthe Linked servers attribute, and creating a rich CI relation hosts/isHosted betweenthe Environment and host Server in question. Nonetheless, the ability to actuallyadopt these patterns is dependent on the implementation, hence the low level of focuson the exact nature of the CI relationships, and the exclusion of rich CI relations fromthe model. The implementation method might also affect the ability to use multi-value attributes, in which case they would need to be replaced by additional attributes.
The drawback of developing a solution that should be suitable for most, is that oftenit will not be optimized for anyone due to being too general. A general solution mightnot be able to address unique or very particular needs an organization might have,and while the CDM (see section 2.4.1) provides quite a large number of possibleCIs in their ready-to-use model, this can lead to the user tracking CIs that bringthem no real value, simply because the items are readily available. These factorsapply to the CIM (see section 2.4.1) as well to some extent, even though it doesnot appear as rigid of a model as the CDM. At this stage of the CM process inthe company, the abundance of item classes included in the CIM schema would not
51
provide the company with any additional value over the developed model. However,the data types, item classes, and inter-item relationships provided by CIM couldbecome useful in later stages of the CM development process, at least as helpfulguidelines if nothing else. The proposed model is likely a more suitable solution forthe company, since it has been developed based on their requirements; the focus ison the key assets and characteristics and can address very specific needs. However,adoption of the proposed model into any other company would presumably requiresome modifications to the model for it to be effective in their CM practices.
6.10 SummaryThe initial proposal of the database model was modified based on feedback from avalidation workshop. The validation and ensuing revision of the model resulted inseveral additions to the database model. Most of the additions were new attributes toexisting items, with the exception of one new configuration item, Account, and its at-tributes. No items or attributes needed to be removed from the database model basedon the aforementioned validation workshop, at least at this stage in the configurationmanagement process. When compared with the requirements, best practices, and ex-isting data models described in section 2.4, the proposed model fares quite well, sinceit adheres to a majority of the recommendations, and at least at this point seems abetter fit to the company than the models it was compared to, the CDM and the CIM.
The database model might need to be modified in the future due to fundamentalchanges to the core software of the company, since some attributes could be rendereduseless by the changes to the software. However, it was not deemed necessary toremove attributes on this account, since the attributes are relevant for the currentsoftware architecture, which will still be in use while the company is adopting thenew architecture. The transition process is still in the beginning stages; therefore,the current architecture will still be in use for quite some time. If modification ofthe model becomes current, the best practice compliance of the model can make thedevelopment process much simpler.
52
7 DiscussionThis section discusses several aspects related to the future of the configuration man-agement process: classification of the configuration items, possible implementationoptions, and modifications to the database model based on future requirements andresources available for configuration management.
7.1 ClassificationThe attribute Criticality was introduced in section 5.1.1. Many of the configurationitems in the model have it as an attribute, however, currently it is not somethingthat is defined for all of the company assets. Hence, the value that would be usedfor the CIs should be derived, during the implementation of the CMDB at the latest.For Third-party source items the criticality would likely have to be set manuallybased on the item’s effect on service provision. For more complex items, such asEnvironment and Server, the business impact, and thus criticality, depend largelyon their use case, which is why the Type and Subtype attributes could be used todetermine a suitable level of criticality.
Generally, internal environments can be considered more critical, or having a moredirect business impact, than external environments. These values are representedby the attribute Type. Further division by use case could be as follows, from leastto most critical: development, testing, and production, which are represented bythe attribute Subtype. A logic for automating the initial criticality of items couldbe created based on these attributes, where Criticality is first set based on whetherthe environment is internal or external, then, if a Subtype is available, the Criticalitycan be adjusted based on its value. For example, there could be two environments,Environment X and Environment Y. They are both external environments, andthus classified as having a criticality level of high, on the previously used scale oflowest-low-medium-high-highest. However, Environment X is a development envi-ronment and has a lower impact on service delivery, which is why the Criticality isadjusted to medium. Environment Y is a production environment, and due to itsdirect impact on the customer, has its criticality adjusted to highest. This is a verysimplified example, aiming to demonstrate the type of logic that could be built toautomate some of the classification of the items, which could provide a reasonabledefault value when new items are initialized.
53
7.2 ImplementationThe objective should not be to automate everything right from the beginning, orto create a perfect model containing every company asset, but rather to create asolid foundation by starting from aspects where the ratio between value providedand time spent is as favorable as possible. For example, contact information, such asemail addresses, change relatively infrequently compared to the deployed softwareversion of an environment in a company where the product is constantly being devel-oped. Thus, it might not make sense to spend large amounts of time automating theprocess of updating contact information, if environment data is still updated manually.
It was stated during the interviews and workshop that large amounts of informationcan be obtained through APIs for both environments and servers. Server config-urations can also be obtained from Ansible playbooks. These sources can quitereadily be utilized for automatic data collection through either existing softwareor customized solutions. Due to the numerous environments, servers, and theirproperties, automating the related data collection could significantly reduce theamount of work required to ensure the data in the CMDB remains accurate.
There are some technical details to consider before the implementation regardingsome configuration items. In the case of Supporting service items, or any items thatare separated from Supporting service to their own item type, it should be decidedwhether one item is to represent each version of a specific service, or each item is torepresent an instance of the service for each environment. Figure 12 visualizes thedifference quite well. The advantage of the “One CI per product” model is simplicity:fewer configuration items, and fewer dependencies to manage. The “One CI perinstallation” model has the benefit of facilitating item monitoring on an individuallevel. This can include, for example, change history for each item. However, thesecond model increases complexity of the database model, and contains significantlymore data.
One possible implementation method is to customize an instance of the companysoftware. While not a trivial amount of effort to create an instance to act as aCMDB, the company software facilitates a fair bit of customization and this could bea feasible approach. The existing customer database has been similarly implementedby customizing company software. Several types of integration would be availablethrough company software alone, including API functionality, and importing datathrough text files. Custom scripts could be created to scrape relevant data fromAnsible playbooks and store it in a format suitable for integration, after which thefiles can be processed similarly to customer implementations in the company.
54
SoftwareProduct
SoftwareProduct
SoftwareProduct
SoftwareProduct
One CI per product
SoftwareInstance
SoftwareInstance
SoftwareInstance
SoftwareInstance
SoftwareInstance
SoftwareInstance
SoftwareInstance
SoftwareInstance
One CI per installation
Figure 12: Two models of using configuration items to represent software. [31]
Some benefits of utilizing company software would be the fact that most people whowould likely end up using the CMDB should already be familiar with the companysoftware, which can decrease the amount of training required to be able utilize iteffectively. This applies to the implementation of the CMDB as well to some extent,as the integration process is not entirely different from many customer projectsin the company. No external consultants would need to be hired for training orimplementation, since the experts of the software can be found within the company.The relatively low amount of training, and the ability to utilize internal software andexpertise could make this a very economical solution, assuming that its suitabilityis sufficiently investigated beforehand. Identifying insurmountable obstacles onlywhen the implementation is already well underway could cost any financial advantagethat utilizing internal resources might have over purchasing a ready-made solutionfrom a third party. Lacy and Norfolk found, through interviewing representativesfrom various organizations, that commissioning the entire CMDB solution from anexternal supplier would not be the preferred method for any of the participants, butthat most would prefer some degree of internal involvement in the process [32].
55
7.3 Future Modification of ModelThe purpose of the database model proposal in this thesis is merely to provide astarting point for the future development and implementation of a configurationmanagement system for the company. It is highly probable that the model wouldneed to be modified to accommodate the new requirements that are introduced withthe new software architecture. The model could also be expanded to facilitate themonitoring of a larger set of company assets on a more detailed level.
The Supporting service item would be a fairly logical place to start expanding themodel, if only to prevent it from becoming cluttered with information that is toogeneral to be of much real use. Different services could be separated to their owntypes of configuration item, similar to the Account item type that was created for thefinal version of the model proposal. This would allow for more detailed monitoringof individual services and, for example, the creation of service-specific descriptionson the impact of item failure, and directions on how to proceed, similarly to whatwas requested during the workshop for the Third-party source item.
The different software environments and servers contain numerous other propertiesthat could be added as attributes to the Environment and Server items, if considerednecessary in the future. Many of these attributes could also refer to newly createdconfiguration item types, separated from the Supporting service item. Even if theaddition of new attributes would be technically simple, it should always be consideredwhether the addition provides any value, since adding unnecessary information canclutter the database. If the objective is to make important information readilyavailable, it should be ensured that the added information is actually relevant.
As was mentioned in section 6.6, the configuration items Network and Data centercould be created to facilitate more detailed tracking of each type of item. Referencesto these items could then replace plain values in the Networks and Data centerattributes of the Server item. The creation of additional items should of coursebe considered carefully, as they will likely add complexity to the system. Not allinformation might need to be tracked to the same degree of detail, since not allinformation provides the same amount of actual value to the company.
The new software architecture could have a major effect on the database model,especially after it has been adopted for all environments in the company. A possiblenew configuration items could be Cluster, which would contain attributes referring toall Server items in the cluster. The attributes describing total memory or disk spaceof Server items could be added to the Cluster to describe these aspects on a clusterlevel, which would be more relevant for the distributed architecture. The host for
56
Environment items could be changed from an individual Server to the correspondingCluster, and Server items could be focused on monitoring the lifecycle of serversmore than their direct effect on environments.
57
8 ConclusionsThe current section summarizes the key concepts and findings from earlier sections,discusses possibilities for future research, and concludes this thesis.
The theoretical background of the thesis examined the broader field of IT servicemanagement, which also encompasses the discipline of configuration management.The background included the introduction of the ITIL ITSM framework, and itsrelationship with configuration management. The process of CM was explored fromboth a general and an IT-specific perspective, which also included the concept of aconfiguration management database.
The empirical research began with the conduction of interviews to ascertain thecurrent state of CM in the company. The interviews were systematically analyzedto identify the main bottlenecks of the current system. A solution to these quitewidely experienced challenges was determined to provide most value for the company.Based on the findings from the current state analysis, it was determined that aCMDB would be a valid approach to CM in the company. The database model wasdeveloped based on the earlier interviews and further research into the different typesof assets in the company. The initial proposal of the model was designed to includecompany assets most relevant to reliable and efficient service delivery.
The initial database model was evaluated by collecting feedback in a workshop settingfrom several of the people that were interviewed for current state analysis. Thedatabase model was revised based on the feedback, which resulted in the additionof a new CI, and new attributes to the existing CIs. The workshop also providedinsight to how the development of the core software can affect some of the CIs, whichmay necessitate modification of the database model in the future.
There will still be several aspects to consider before starting the CM implementationin practice, concerning CI classification, implementation method, and how the devel-opment of the core product will affect the CM requirements of the company. Althoughfor the most part CI classification is quite a straightforward process, for attributesthat currently have no predetermined value, it will require some planning beforehand.Automation opportunities should be explored for the classification process to decreasethe amount of manual work required to maintain the data in the CMDB.
The implementation method requires planning, and the validity of the selectedmethod should be confirmed before beginning the implementation in practice. Onepossibility would be to utilize company software, and the expertise of the employeesto implement the CMDB. This option would minimize the expenses from purchasing
58
third-party solutions, including software, technical implementation, and training.
The main software of the company is experiencing changes to its architecture, whichwill affect the relevance of certain CIs and attributes in the future. The databasemodel should be modified to reflect the changing requirements, which in practice willlikely include removing certain attributes and creation of additional CIs. However,this modification process is not a priority on the implementation timeline, since theproposed model will be relevant until the new software architecture has completelyreplaced the current one.
8.1 Future ResearchBased on the findings, the thesis reached the objectives and provided answers to theresearch questions introduced in section 1.3. However, since the overall scope of thisthesis was quite limited, there are many opportunities for future research topics. Mostof the CIs in the final database model can be identified in other SaaS products aswell, which allows for the model to also have applications outside the focus companyof this thesis. The developed model provides a simple starting point for CMDBmodel development, focused only on the core assets. While the model is extensi-ble, it does not initially provide the abundance of items that are provided by morecomprehensive model such as the CDM or CIM, which might not be needed in all cases.
One possible research opportunity is the practical implementation of a CMDB basedon the model, which is logical step forward from the planning and design that wasconducted for this thesis. The implementation process could involve testing of theimplemented system, and analysis of the model. For example, the effect the use ofthe implemented CMDB might have on different service level performance metricscould be analyzed to determine the level of realized benefits.
Some comparison was performed between the developed model and both the CDM,and CIM, however, this comparison could be performed in much more detail. Addi-tional research could be conducted into how the model could be developed further,for example, by including different process artifacts to support additional ITSMprocesses. There are also other stages to the configuration management process (seesection 2.3), for which the database model was developed. If the creation of themodel could be considered “configuration identification”, where the relevant CIs andrelationships are determined, the processes for the latter stages could be researched aswell, using the database model as the base for the CM solutions to be designed. Thiscould include designing methods for configuration data collection, change detection,and auditing.
59
References[1] Giese, H. & Seibel, A. & Vogel, A. A Model-Driven Configuration Management
System for Advanced IT Service Management. Proceedings of the 4th Interna-tional Workshop on [email protected] at the 12th IEEE/ACM InternationalConference on Model Driven Engineering Languages and Systems (MODELS2009). Denver, Colorado, United States, 2019, p. 61.
[2] Eurostat. Small and Medium-Sized Enterprises (SMEs). EuropeanCommission. Available at: https://ec.europa.eu/eurostat/web/structural-business-statistics/structural-business-statistics/sme. [Accessed 22.07.2020]
[3] Knapp, D. The ITSM Process Design Guide: Developing, Reengineering, andImproving IT Service Management. Plantation, Florida, United States: J. RossPublishing, 2017, p. 1.
[4] AXELOS. What Is ITIL R⃝?. AXELOS. Available at: https://www.axelos.com/best-practice-solutions/itil/what-is-itil. [Accessed 15.07.2020]
[5] AXELOS. ITIL R⃝ Foundation ITIL 4 Edition. Norwich, United Kingdom: TSO,2019.
[6] Lester, A. Project Management, Planning and Control, 7th Edition. Oxford,United Kingdom: Butterworth-Heinemann, 2017, p. 105.
[7] International Organization for Standardization. Quality Management - Guide-lines for Configuration Management (ISO 10007:2017). Geneva, Switzerland:ISO, 2017.
[8] Macfarlane, I. & Rudd, C. IT Service Management: A Companion to the ITInfrastructure Library. Reading, United Kingdom: itSMF Ltd., 2001, p. 17.
[9] Steinberg, R. ITIL R⃝ Service Operation. Norwich, United Kingdom: TSO, 2011,p. 57.
[10] Brenner, M. & Garschhammer, M. & Sailer, M. & Schaaf, T. CMDB - YetAnother MIB? On Reusing Management Model Concepts in ITIL ConfigurationManagement. In: State, R. & van der Meer, S. & O’Sullivan, D. & Pfeifer, T.(eds). Large Scale Management of Distributed Systems. DSOM 2006. LectureNotes in Computer Science, vol 4269. Heidelberg, Germany: Springer, 2006, p.271.
[11] Rance, S. ITIL R⃝ Service Transition. Norwich, United Kingdom: TSO, 2011, p.93.
60
[12] International Organization for Standardization & International Electrotechni-cal Commission. Information technology — Service management — Part 1:Service management system requirements (ISO/IEC 20000-1:2018). Geneva,Switzerland: ISO, 2018, p. 18.
[13] IEEE Computer Society. IEEE Standard for Configuration Management inSystems and Software Engineering (IEEE Std 828TM-2012). New York, NewYork, United States: IEEE Standards Association, 2012, p. 3.
[14] Brenner, M. & Schaaf, T. & Scherer, A. Towards an Information Model for ITILand ISO/IEC 20000 processes. 2009 IFIP/IEEE International Symposium onIntegrated Network Management, New York, New York, United States: IEEE,2009.
[15] BMC. BMC Atrium CMDB Common Data Model, version 2.1.00. BMC, 2007.
[16] BMC. BMC Atrium CMDB Common Data Model, version 9.1.03. BMC, 2017.
[17] DMTF. Common Information Model (CIM). DMTF. Available at: https://www.dmtf.org/standards/cim. [Accessed 27.07.2020]
[18] Jelliti, M. & Sibilla, M. & Jamoussi, Y. & Ghezala, H. A Model BasedFramework Supporting ITIL Service IT Management. In: Bider I. et al. (eds)Enterprise, Business-Process and Information Systems Modeling. BPMDS 2010,EMMSAD 2010. Lecture Notes in Business Information Processing, vol 50.Heidelberg, Germany: Springer, 2010, p. 213.
[19] Schaaf, T. & Gögetap, B. Requirements and Recommendations for the Re-alization of a Configuration Management Database. Proceedings of HPSUA,2007.
[20] Müller, T. CMDB in 5 Steps: A Project Guideline for Implementing a Configu-ration Management Database [White paper]. iET Solutions, 2016, p. 10.
[21] Bonneville, A. IT Configuration Management: Implementing a CMDB [Whitepaper]. Baccou Bonneville Consultants, 2011, p. 11.
[22] Sharifi, M. & Ayat, M. & Ibrahim, S. & Sahibuddin, S. A Novel ITSM-basedImplementation Method to Maintain Software Assets in Order to Sustain Orga-nizational Activities. 2009 Third UKSim European Symposium on ComputerModeling and Simulation, Athens, Greece: IEEE, 2009.
[23] Brenner, M. & Gillmeister, M. Designing CMDB Data Models with Good Utilityand Limited Complexity. 2014 IEEE Network Operations and ManagementSymposium (NOMS), Krakow, Poland: 2014, pp. 9–13.
61
[24] Marrone, M. & Kolbe, L. Impact of IT Service Management Frameworks on theIT Organization: An Empirical Study on Benefits, Challenges, and Processes.Business & Information Systems Engineering 3, 2011, p. 14.
[25] Wu, MS. The Benefit and Cost Factors of CMDB Implementations: An Inves-tigation of Three Organizations in Taiwan. Procedia - Social and BehavioralSciences 147, 2014, pp. 67–68.
[26] Brown, A. & Keller, A. A Best Practice Approach for Automating IT Man-agement Processes. 2006 IEEE/IFIP Network Operations and ManagementSymposium NOMS 2006, Vancouver, Canada: IEEE, 2006, p. 35.
[27] Clark, D. & Dublish, P. & Johnson, M. & Kowalski, V. Labrou, Y. &Negritoiu, S. & Vambenepe, W. & Waschke, M. & Wiles, V. & Wurster, K.The Federated CMDB Vision: A Joint White Paper from BMC, CA, Fujitsu,HP, IBM, and Microsoft [White paper]. 2007, p. 4.
[28] Ayachitula, N. & Buco, M. & Diao, Y. & Maheswaran, S. & Pavulvuri, R.& Shwartz, L. & Ward, C. IT Service Management Automation - A HybridMethodology to Integrate and Orchestrate Collaborative Human Centric andAutomation Centric Workflows. IEEE International Conference on ServicesComputing (SCC 2007). Salt Lake City, Utah, United States: IEEE, 2007, p.579.
[29] Edwards, R. & Holland, J. What Is Qualitative Interviewing?. London, UnitedKingdom: Bloomsbury Academic, 2013, p. 29.
[30] Corbin, J. & Strauss, A. Basics of Qualitative Research (3rd ed.): Techniquesand Procedures for Developing Grounded Theory. Thousand Oaks, California,United States: SAGE Publications, Inc., 2012, p. 65.
[31] Klosterboer, L. Implementing ITIL Configuration Management. Boston, Mas-sachusetts, United States: Pearson Education Inc., 2007, p. 75.
[32] Lacy, S. & Norfolk, D. Configuration Management: Expert Guidance for ITService Managers and Practitioners - Revised. Swindon, United Kingdom: BCSLearning and Development Limited, 2014, p. 115.
62
A Current State Analysis - Interview Questions
Configurationmanagement
The process of maintaining information about configura-tion items, their relationships, interactions, and changesthroughout the lifecycle of an item.
Configurationitem
A unique asset (necessary for successful service delivery)which is monitored in a configuration management system.For example, a piece hardware or software, a service com-ponent, or a document.
1. What is your role at the company, and what does it entail?
2. What would be some relevant configuration items from your point of view?
3. How would you classify these items? For example: business service, technicalservice...
4. How critical are these items for service delivery?
5. How is the current configuration monitored? For example:
• What configuration items are currently in use?
• What is the current state for each configuration item? For example:
� Status, version, settings...
6. How are configuration changes currently monitored?
• Customer level changes:
� Configuration items added or removed
• Configuration item level changes, for example:
� Status, version, settings...
7. How are configuration item interactions and relationships currently monitored?For example:
• What effect would a state change of a configuration item have on...
� a customer operation level (criticality)?� other configuration items? Which items, and how are they affected?
8. How is the monitoring data utilized? For example:
63
• Does the data affect the process for making changes in different configura-tion items?
• Is the data collected somewhere, and how is it collected?
• Are changes in the configuration automatically detected? Is the changedata collected automatically?
9. How do you feel about the current state of configuration management?
• Strengths
• Weaknesses
10. Do you have any ideas for improvement?
11. Do you think configuration management is important? Why, or why not?
12. Is there anything else you think might be important to this research, thatwasn’t mentioned?
64
B Workshop Materials -Agenda and Summary ofCurrent State Analysis
2
Agenda
• Current state analysis – Summary
• Proposed model
• Configuration items
• Item attributes
3
Current state analysis - Summary
• General impressions:
− Configuration management is important to be able to provide reliable service
− Current way of doing things is not really scalable, even though things have worked so far
− Automation and standardization of processes would generally be well received, and is already underway in several
teams
• Challenges:
− Information can be scattered across multiple systems, and there isn’t always a clear main source to turn to
− Large amount of manual work in keeping CM data up-to-date and finding relevant data across multiple sources
− The ability to monitor dependencies between items can be limited in the current situation
• Solution proposal: Configuration Management Database
− A central database to store data about configuration items, and the relationships between them
65
C Configuration Items and Attributes -Initial Proposal
Table C1: Descriptions of configuration items and attributes provided forworkshop attendees.
Contact
_id code unique to contact
Email email address for contact
Name name of contact
Role role of contact
Type internal/external
Customer
_id code unique to customer
Contacts reference(s) to customer’s Contact item(s)
Environments reference(s) to customer’s Environment item(s)
Name name of customer
Environment
_id code unique to environment
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Host server reference to Server item hosting the environment
Linked environments reference(s) to Server item(s) connected to theenvironment in some way, excluding host server
66
Table C1: Continued.
Linked servers reference(s) to Environment item(s) connected tothe environment in some way
Memory amount of memory allocated for environment
Name name of environment
Software version current version of environment
Subtype for example: production, test, development, reserve
Supporting services reference(s) to Supporting service item(s) used inthe environment
Third-party sources reference(s) to Third-party source item(s) used inthe environment
Type internal/external
Server
_id code unique to server
Cores number of processor cores
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Data center physical location of server
Disk space amount of disk space on server
IP address IP addresses for server, public and private
Memory amount of memory on server
Model make and model of server
Name name of server
67
Table C1: Continued.
Networks networks server is connected to
Type for example: file, backup, calculation
Supporting service
_id code unique to service
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Name name of service
Software version current version of service
Type for example: integration, authentication
Third-party source
_id code unique to source
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Name name of source
68
D Configuration Items and Attributes -Final Proposal
Table D1: Descriptions of configuration items and attributes updated basedon workshop results. New attributes italicized.
Account - new item
_id code unique to account
_status lifecycle status of account
Password password for account
Server reference(s) to Server item(s) account is used toconnect to
Type for example: FTP, SFTP
Username username for account
Contact
_id code unique to contact
_status lifecycle status of contact
Email email address for contact
Name name of contact
Phone number phone number for contact
Role role of contact
Type internal/external
69
Table D1: Continued.
Customer
_id code unique to customer
_status lifecycle status of contact
Contacts reference(s) to customer’s Contact item(s)
Environments reference(s) to customer’s Environment item(s)
Name name of customer
Environment
_id code unique to environment
_status lifecycle status of environment
Accounts reference(s) to Account item(s) that are used in theenvironment
Architecture type of architecture in use: current/new
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Host server reference to Server item hosting the environment
IP whitelist IP addresses able to access environment
Linked environments reference(s) to Server item(s) connected to theenvironment in some way, excluding host server
Linked servers reference(s) to Environment item(s) connected tothe environment in some way
Memory amount of memory allocated for environment
Name name of environment
Software version current version of environment
70
Table D1: Continued.
Subtype for example: production, test, development, reserve
Supporting services reference(s) to Supporting service item(s) used inthe environment
Third-party sources reference(s) to Third-party source item(s) used inthe environment
Type internal/external
Server
_id code unique to server
_status lifecycle status of server
Age age of server
Cores number of processor cores
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Data center physical location of server
Disk space amount of disk space on server
Encryption encryption status: true or false
IP address IP addresses for server, public and private
Maintenance status maintenance status of server
Memory amount of memory on server
Model make and model of server
Name name of server
Networks networks server is connected to
Subtype for example: production, test, development, reserve
71
Table D1: Continued.
Type for example: file, backup, calculation
Warranty warranty status and expiration date
Supporting service
_id code unique to service
_status lifecycle status of service
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Name name of service
Software version current version of service
Type for example: integration, authentication
Third-party source
_id code unique to source
_status lifecycle status of source
Criticality level of importance to service provision (lowest -low - medium - high - highest)
Impact impact of item failure, instructions on how to pro-ceed
Name name of source
