Discovering your devices before consolidating services as part of a merger or acquisition
There are a few times when the data discovered by Tivoli Application Dependency Discovery Manger (TADDM) can be crucial to a business. These are:
- Discovering the devices you have in a data centre before either moving to the cloud or closing data centres completely due to consolidation.
- Before bidding for new work (such as taking on a new customer) TADDM can give you a detailed report as to what you are taking on. This is especially important for Managed Service Providers (MSPs).
- The last option is when you have either taken over a company or your company has been taken over as part of an acquisition and you are undergoing a period of consolidation or systems and services.
It is the last option that I want to concentrate on in this blog.
There are 2 different types of usage that would be particularly useful for a company involved in a merger or acquisition.
- Firstly it can help you get an idea of what systems you have acquired. A TADDM level 1 scan discovers basic information about the active computer systems in a data centre. This scanning is also known as credential-less discovery as no login information is required to run this. Consequently, level 1 discovery is shallow but will collect the host name, operating system name, IP address, fully qualified domain name, and Media Access Control (MAC) address of each discovered interface which can go some way to making a plan to consolidate.
- Secondly and more importantly when a merger occurs companies will inevitably find that they will have duplicate services or applications and will decide to decommission one or the other. In these cases it is crucial to understand the dependencies that other products have on the systems you are about to close down. TADDM has the ability to do this and this blog will show an example of how this works.
Discovering what devices you have
TADDM level 1 discovery initiates the StackScan Sensor that uses the IDD technology scanner (created in IBM’s Zurich Labs). Optionally it also uses a tool called NMAP for discovery of non-IBM computer systems. The Sensor today understands z/OS®, Z/VM®, OS/400®, AIX®, Solaris™, HP-UX, Linux®, Windows®, Cisco and Alteon however adding in NMAP adds an additional 4,000 signatures.
The StackScan Sensor performs the following steps:
- It sends a small number of low-level ICMP and TCP/IP packets to perform its stack analysis.
- For the discovery of active ports, rapidly closing TCP connect attempts are issued according to a configurable list of ports.
For each system it discovers using this method TADDM assigns a confidence level to indicate how certain it is on the accuracy of its discovery. If the operating system confidence level is below the threshold, the operating system is modeled as a general computer system. The threshold by default is 35%.
The image below shows a system that has been discovered at a 75% confidence level and assigned as a Linux system.
Discovering Dependencies between Systems, Applications and Databases
In the second usage example we will look at how TADDM can show the dependencies (or connections) that exist between discovered systems. For example if we look at a discovered Database we can simply show the dependencies that exist on the database by using TADDM’s details view as shown below. This will give us all direct connections.
However what is not so obvious from this view is where there are indirect dependencies that we need to know about. For example we may know that a CRM system is used by customer services and the sales team but are there other systems that take a feed? TADDM has the ability to build a topology view by taking a single instance (in this case a database) and building a complete topology view of dependencies based on this single core CI. To do this we use TADDM’s “Grouping Patterns” wizard which allows for a query (SQL or MQL) or specific instances to be chosen. This can be anything that TADDM has discovered be it a system, a Hypervisor or an application. In this case we have chosen the database that we are interested in.
As part of this process you also select how wide you want the topology to be. You can display:
- CoreCI
- HigherUp
- HigherDown
- LowerDown
Once this has been done and we have run the rule within TADDM to create the topology we can select the view and open. In the first image we can see that we have selected just to show the CoreCI.
By selecting the LowerDown option we add the database, the DB2 instance, the Linux server and the VMWare ESX server the Linux image is built upon within onto the Topology.
The third image with the HigherUp option now selected shows the topology as before but now it also displays the Apache Web Container that is connecting to the database.
The last image with the HigherDown option selected shows the topology as before but now it also shows connections that come from dependencies above the CoreCI. This reveals many other dependencies including 2 other servers (both Windows and Linux) and some WebSphere applications. Without TADDM these potential dependencies may have been missed which could have resulted in downtime to a core business service.
This example shows that TADDM can take a single CI and build a complete map showing what will be affected if that database is closed down. This is invaluable information for any business planning the process of consolidation which invariably takes place when 2 companies are merged.
License Rental option for short term discovery
From a pricing point of view if a business wanted to implement a discovery solution using TADDM for a short term deliverable (e.g. a Data center migration or consolidation exercise) the perpetual pricing route could be prohibitive as IBM charge a single install license and a price per device. Depending on the number of devices you have the install license was likely to make up the majority of the cost of the software purchase price.
However if the project is planning to deliver between 6-12 months (in fact anything less than 24) then the rental option is considerably cheaper. The base cost still exists but it is now a smaller monthly charge and as you now only pay for the devices as and when you use them you do not start paying for all your devices from day one.
There is still a charge for our service to get the software deployed and running but this would be there anyway and because we have many years of project experience we will be able to deploy the project in the shortest time possible (not withstanding that the pre-requisites MUST be met).
If you are interested in a quote or a quick discussion on how TADDM works then please contact me at simon.barnes@orb-data.com.
Visits: 77
