Why did my data change and why didn't i know?

Ensure Service Model accuracy in your CMDB

by tekwurx

Why did my data change and why didn't i know?

Ensure Service Model accuracy in your CMDB

by tekwurx

by tekwurx

Knowing your application dependency maps are changing and being able to validate this change is key to effective Business Service Management. But has this become a game of chance?

The goal of application dependency modeling with BMC Discovery is to find out what hardware and software support which business applications and then to build the applications into service maps.
A dynamic, automatically maintained application map enables you to understand key relationships between the business and IT. But how do you know if these application maps are / should be changing and more importantly whether the changes are correct?

First lets look at the top 3 most common reasons for change.

Discovery Issues

A building block to any application map is the successful discovery of the hardware and software that form part of that application. However it is possible during the normal course of business for discovery issues to impact on the accuracy of the application map.

For example, if credentials change, a password expires, a discovery account gets locked out or other factors affect the successful discovery of application related data then, if unnoticed, eventually the host or component will “age” out of BMC Discovery – this will include removal from the application map.

False Match

Creating application maps within BMC Discovery, whether through TPL or through CAM, requires identifying Software Instances / Discovered Processes that comprise the application. This identification normally involves selecting a unique identifier and then using this unique identifier to match that and other instances – called a fingerprint.

As you progress with discovery of new hosts, software and processes then the fingerprint can start matching these newly discovered items which could be nothing to do with the application. Once the components are matched the items are added to the application map.

Valid Change

A valid Change seems a strange one to add here because by its very nature it should automatically be validated and either added or removed from the application map. So let us look at a scenario:
An application map has been created and verified as accurate. Further down the lifecycle of the application the Database is moved from one instance to another. This may have a couple of outcomes depending on the move:

  • If the original DB instance is still running and discoverable then the application map will continue to contain the old instance. If the new DB instance does not match the fingerprint then the new DB will not be pulled into the application map. OUTCOME: Showing incorrect database dependency
  • If the original DB instance is stopped or removed then this will drop out of the application map. If the new DB instance does not match the fingerprint then the new DB will not be pulled into the application map. OUTCOME: Showing no database dependency
  • If the original DB instance is still running and discoverable then the application map will continue to contain the old instance. If the new DB instance matches the fingerprint then the new DB will also be pulled into the application map. OUTCOME: Showing incorrect database dependency
  • If the original DB instance is stopped or removed then this will drop out of the application map. If the new DB instance matches the fingerprint then the new DB will be pulled into the application map. OUTCOME: Showing correct database dependency

How do you know the maps are changing?

We have just looked at 3 reasons for change occurring to Application maps within BMC Discovery. As stated before, the question remains – How do you know? Over the lifetime of your application modeling project how do you know which application components have changed since the day the model was approved and signed off and more importantly how do you know that the changes are correct / expected / accurate?

BMC Discovery has a wealth of in-built reports and the ability to create generic reports. This enables you to list out applications and their components, to run history based reports to compare an entity at 2 points in time – but is this feasible if you have created 100’s or 1000’s of application maps?

Is having to manually run reports to look for change the best use of time and resource? In the case of the valid match scenario described above – how would running reports in BMC Discovery enable you to understand that there have been changes to an application that BMC Discovery has not seen?

These are the questions that we have been working through with uChange – the Application Change Alert module that forms part of the uControl suite from Tekwurx.

Rather than having to manually run reports and check for changes to application maps uChange continually monitors and maintains the application map in BMC Discovery and pro-actively alerts you to any changes.

These alerts include:

Discovery Issues

If hosts or components are ageing and dropping out of the application map you receive an alert which includes the application, component(s) that caused the alert and the reason for alert.

Unseen Changes

uChange also enables you to compare application map data seen by BMC Discovery against a Gold-Source of data. This enables uChange to alert in situations where the application architecture has been changed (detailed in Gold Source) but the fingerprints within BMC Discovery have not identified the new application components. An alert is received which details the application, component(s) that caused the alert and the reason for the alert.

False / Valid Match

When new components match the fingerprints for the application map you receive an alert which includes the application, component(s) that caused the alert and the reason for alert. uChange allows you to reject the additional component (false match) and remove from the application map or accept (valid change).

About Tekwurx

TekWurx was founded in 2013 by Steven Hicks and Nik Dimmock.
After spending over 8 years working with customers and partners on BMC Discovery projects (formerly know as BMC ADDM) and seeing the same challenges and same “consultancy” solutions used on each account we realized that there was opportunity for a significant change to delivery – an approach where the customer could start “delivering” themselves. uMap™, the first module released by Tekwurx as part of the uControl™ suite for BMC Discovery is just that. uMap™ provides the ability for an end user, with no exposure or experience with BMC Discovery, to be able to produce Business Application service models without any complex coding.

For further information please contact info@tekwurx.com

Top