Populate and maintain CMDB, assess IT architecture, plan DR

Populate and maintain CMDB
IT operations teams, IT helpdesk, IT architects desperately need the information about the current business applications: their architecture and inter-dependencies so that they would know what affects what and whom to call if anything breaks. Change Management Data Bases (CMDBs) and Service Management systems are invented to not only keep this information available but also to keep it current.

what you pay to deploy a CMDB what you get for deploying a CMDB

If you are from a large IT organization chances are you already have one or a few CMDBs and a Service Management system. Therefore, if you are the top IT executive you assume that CMDB/Service management problem is solved. After all you already paid for it. If you are lucky, indeed the basic information like the amount of RAM or a list of installed packages is collected in one place. However, ask your operations teams - here are the two most likely scenarios that are happening right now regarding the most important information: business applications documentation:
  1. The CMDB vendor is expected to populate your CMDB with business application data some time in the future.
  2. There is an ongoing and never-ending process with a team manually creating application diagrams based on the trivial network connectivity diagrams that the vendor actually delivered instead of the promised application diagrams. (If your organization is large enough you are probably in this process for years already and guess what? The documentation that was created was likely incomplete right from the beginning and is already outdated and does not correspond to reality by now.)

Our application discovery platform RejuvenApptor™ relies on automated identification and diagramming of the logic of the business applications. Our business application models are driven by DevOps-like modeling but are read-only so that the legacy environments are also modeled. Most of the information gets collected automatically and we ask only certain targeted questions instead of relying on the interviews entirely. Contact us to have your business applications reflected in the CMDB - even including the details about their operations that IT staff already forgot about.

Two applications share DB instance

To understand why mostly-manual efforts are not just time-consuming but are also error-prone look at this example diagram. Information collected from three servers belonging to an HP uCMDB deployment showed that its dedicated MS SQL server was, in fact, also used by another business application. This is a common example of undocumented IT complexity that RejuvenApptor™ can discover automatically.

Disaster Recovery planning
"Grey" or "shadow" IT is a recognized cause of major business interruptions. Actual application architecture documentation is critical not just for ongoing operations and incidents resolution. It is also critical to systematically evaluate the applications for single points of failure to ensure their high availability.

The application dependency diagrams that we generate are important for the disaster recovery planning (disasters do not happen every day but they do happen and it is better to be prepared). They can drive the decisions about the order of applications recovery (if a critical application "A" needs application "B" to run you would have to recover "B" first) and the backup strategy (so that the most critical servers and databases are backed up with higher priority).