Everyone knows that a CMIS is an important requirement for any organisation seriously seeking to carry out Capacity Management. What there is often more confusion about is what a CMIS actually is, what it contains, and how to create it.
A Capacity Management Information System is defined by ITIL to be a repository for all Capacity Management data. It may be a virtual repository, with data actually stored in multiple physical locations.
Data and Metadata
What exactly is this ‘Capacity Management data’? The answer may depend on your organisation but the CMIS is certainly more than just a place to store your CPU usage data. First of all there is the actual raw data, probably in some kind of time-series form. This will include (according to ITIL) metrics at each of the three Capacity Management layers: business, service and component.
This data will probably be distributed between multiple different monitoring systems and databases. This is usual and is a good thing as it can facilitate allocation of responsibility for different data to appropriate teams. However it is important that there is also a central CMIS Metadata DB which can describe the data available, where to find it and what to do with it.
It might be helpful to think of the CMIS metadata in the following categories:
- What data
- KPIs (Key Performance Indicators, metrics) – including a full description of what the KPI is, what it means when it changes, associated thresholds etc.
- Servers – and network devices, subsystems, any other ‘entities’ that should be reported on
- Applications – KPIs and servers should be linked to the applications and services that they support
- Where the data comes from
- Details of the various data sources that hold the data
- Queries to run to get the data for the individual KPIs
- What to do with it
- Forecast parameters – these might describe KPI seasonality or relationships between different KPIs
- Alerting types – there might be different types of alerts you want to run against different KPIs. See More Intelligent Automated Alerting
- Details of filters to process data in various ways and transform it into different forms
- How to report it
- Slides/pages – how you are going to display the data back to the user, what sort of graph to use and what information to display to them
- Reports – groups of slides and pages which are relevant to different groups
Tools
The question now always comes to tooling. Remember when looking at tools there are three main types of tools you will be looking for to construct your virtual CMIS
- Monitoring tools – these are crucial for collecting the data in the first place. These will include server and network monitoring tools, maybe tools for monitoring response and service times in one way or another. They may include instrumentation in applications and monitoring on throughput and queuing on different platforms.
- Data storage tools – monitoring tools may include their own data warehouses, but for application specific reporting at least you will need some kind of data storage solution. This will need to be scalable and to deal with archiving and summarising of old data to save space as when you have a lot of KPIs being recorded disk space quickly becomes an issue.
- Data aggregation tools – when you have multiple data sources you then need to bring this together centrally. This tool will be based around your CMIS metadata database.
For monitoring, at least at the component level, there are many good toolsets available which are relatively simple to set up and start collecting data from. Many application platforms also have good instrumentation built in which may be available to you. Again for data storage there are many good solutions.
The most difficult bit is typically when it comes to tying them all together with the virtual CMIS. It is true that there are many packages which will provide a data consolidation platform; the important thing to remember though is that none of them will be able to do it ‘out of the box’. Look back at the list of things we need in the CMIS metadata DB and this should be obvious. Hence it is crucial that you have the expertise (and time!) available to put this information into a tool, otherwise it will be of no use as a CMIS.
Business intelligence solutions which can do this type of data consolidation, expensive as they are, will typically require even more expense to actually set them up and configure them for your organisation. One investment bank we were working with last year looked at a few of these types of solutions for a CMIS and found them to be too expensive for their budget; in the end we built a CMIS from the ground up to meet their requirements at a fraction of the prices they were being quoted! Remember that the actual toolsets are only a small part of what is required.
