Configuration management

 

 

The objective of Configuration management process is:

  • To identify, record and control configuration items including their versions, properties and relations.
  • To ensure integrity of configuration items during their whole life cycle in order that only authorized items are used and only authorized changes of items are performed.

Administrator IS, CSOB Leasing:

ObjectGears Configuration management enabled us to interconnect incidents, planned work and documentation with real configuration items like hardware, applications, databases or network elements.

Configuration items can vary in type - from service, hardware device to software and documentation. Configuration items are stored in Configuration database CMDB).

Configuration management process interfaces number of other entities and processes.

Configuration management identifies, records and controls configuration items in a Configuration database (CMDB).

ObjectGears Configuration management records relation to configuration items at these main entities:

  • Project (project scope meaning added, modified and removed configuration items)
  • Task (affected items - subject of the task)
  • Work schedule (planned activities with stating affected items)
  • Knowledge Base (items concerned in the article in the Knowledge Base)
  • Incident, Problem and other entities of the Incident and Problem management process (items related to Incident/Problem and other entities)
  • Release (items that are part of the release package)
  • Changes (items that are subject of changes)

When the user displays a configuration item in ObjectGears, he/she can immediatelly see all the above stated connections.

 

Watch a video showing synergic effects of Configuration management with Processes and Resource planning and reporting time spent on projects, tasks, incidents etc.

Examples of screens

(Examples stated hereinafter represent only a sample from the whole number of configuration items types.)

Hardware device

This entity is used for servers, enclosures, disk storages, back up libraries, switches and other network elements, printers, projectors and other physical devices. Key attributes are vendor, device type, serial number, owner, inventory number, location, purchase date, end of support date, environment...

Hardware device detail

Machine (OS server, System)

Machine (OS server) detail

Server running on hardware device - operating system. Key attributes of the entity are operating system, name, FQDN, type (server, workstation, cluster, cluster service, farm, appliance...), farm, on which the system runs as virtual machine, or hardware device, on which system runs as physical (native) server, membership in farm/cluster, IP address, the way of getting IP address (DHCP reservation), Windows domain, CPU, RAM, disks, environment, security zone...

Database server

Database server providing particular databases, that runs on Machine (OS server) - see above stated example of configuration item. Key attributes are instance name, database server version and Machine, on which the database server is installed.

Database server detail

Database

Database detail

Database containing application data. Key attributes are name, database server handling the database, recovery model, collation, date of the last back up, size, compatibility mode...

Relationships between entities depend on your situation and needs. You can see the default model of system, hardware, application or e.g. project layer in the documentation. The model is adapted to your needs at the time of implementation. Entities and properties that are not necessary are hidden. New features are are added or current ones modified.

Discovery

Configuration database can be filled in manually, by means of basic ObjectGears infrastructure functions or by specialized Discovery solutions. We are partners of JDisc.

 

JDisc discovery software

You will learn more in a special article and video about Configuration database, Discovery and Enterprise Architecture Repository.

 

Integration with Enterprise Architecture Repository

Configuration items shall be transferred to Enterprise Architecture Repository, where you can use them to model architecture. This is true also vice versa for data that have been modelled in Enterprise Architecture Repository (e.g. processes) and should be transferred back to Configuration database, where you can treat them further as configuration items in various processes. ObjectGears CMDB is fully integrated with Sparx Enterprise Architect for bidirectional transfer of whatever Sparx EA data.

JDisc discovery software

You will learn more in a special article Archimate and Configuration database CMDB.

 

Application portfolio management and application lifecycle

We can look at the application portfolio as a whole, solving issues of overall hosting, strategic direction, application life cycle and migration strategies. Take a closer look at these questions.

 

Application catalogue and processes using configuration database

We should display relevant data from the configuration database CMDB to users outside IT in form of good looking pages that will provide all the necessary scenarios. E.g. list of applications can be displayed by form of an application catalogue and allow:

  • Report incident related to the application
  • Request installation
  • Navigate to a detail of the Configuration item
  • Display application components – we can see on which server the application is running, we can click for server detail… We can create any scheme that we want correspondingly to our data model and to what we want to say with the data
  • Display map of processes that the application supports.
  • Display the documentation

Application catalogue is using data from Configuration database CMDB and provides users with further scenarios

You can learn more about the application catalogue in the documentation and in a special article about Application catalogue and CMDB and in video How to create application catalogue.