IBM Tivoli Application Dependency Discovery Manager

IBM Tivoli Application Dependency Discovery Manager (TADDM) is a robust application mapping and discovery tool that automatically gather an inventory of all applications and dependencies, helps you understand configurations and helps prove compliance, with detailed reports and auditing tools.

 

An Introduction to TADDM

 

So it's been an interesting year. We've expanded into all manner of new areas, sometimes through outright acquisitions and sometimes through mergers. It's been a bit of a bumpy ride, we've lost a few key staff members along the way, but we should be able to get by. We've got pockets of people that know their area inside out, but no one who can tell me what the complete enterprise setup is. I'm being told that our key sales application is having issues; that the documentation that we have isn't quite up to date for the latest release; and that Joe, our lead developer on the sales application, was one of the key staff members that we lost en route. The support staff are doing their best, but the simple one-system one-application setup that we had before has been replaced by the full function multi-system application, that needs (we don't actually know for sure) just about everything we own up and running, so that it works. Surely, there has to be a better way than this?

If anything in the previous paragraph rings a bell with you, then you might just be interested in TADDM!

TADDM - What is it?

 

So what exactly is TADDM? Tivoli Application Discovery and Dependency Manager or TADDM for short, is a software application that discovers applications within your environment. Not only does it discover the applications, it also determines relationships or dependencies between those applications.
In the process of discovering the applications TADDM also discovers the hardware and network components within your environment and builds dependencies for those as well. Therefore, once TADDM has completed the discovery process, it can tell you which applications run on which systems (physical or virtual) AND what they are dependent upon - identifying the underlying software, hardware and network components.

TADDM stores all of the discovery information in a relational database (CMDB) where it is available for further processing. This includes using the TADDM console (GUI) to display topology maps of physical and application infrastructures, showing exactly which components are dependent upon which other components. Imagine, for example, how useful that type of information would be when faced with decommissioning an old server (by yesterday)?

TADDM stores information from each discovery scan and can use the information obtained from each scan to identify changes that have taken place. Imagine, for example, the ability to identify the changes that have taken place for your main production application server whilst trying to resolve why it is now failing to start?

TADDM - How does it work?

 

The discovery process is driven by a discovery profile. The discovery profile defines the level of the discovery determining the details to be returned. TADDM supplies three default discovery profiles:

• Level 1 - this discovery profile does not require any user credentials or agent. It is intended to build an IP device map of your environment and the running operating system (where possible). This type of discovery is very useful when you do not know what devices exist within your environment, possibly as a result of a recent acquisition or merger.
• Level 2 - this discovery profile performs a shallow discovery using operating system credentials only. This will validate the operating system currently executing on the discovered devices and also return a list of the currently executing applications (processes). This type of discovery will identify a large part of your environment, with the exception of detailed information of application infrastructure.
• Level 3 - this discovery profile performs the most detailed level of discovery and is intended for discovery of detailed application infrastructure, physical servers, deployed software, networks, etc.

The TADDM supplied discovery profiles cannot be modified, but they can be used as a template for creating a new discovery profile of similar content. User created discovery profiles can be modified to suit individual discovery requirements.

In addition to the discovery profile, TADDM requires a scope to be set. The scope defines the limits of the discovery process in terms of hostname/IP address, IP address range or network subnet to be discovered. The scope set can include multiple networks or ranges as well as specifying addresses to be excluded from discovery processing.

The last part of the discovery requirements is specification of user credentials to be used during the discovery process. For a Level 1 discovery, user credentials are not required as this is an agent-less and credential-less discovery, used to build a database of IP devices on the network. For Level 2 discoveries, operating system credentials are required to allow TADDM to create a session with the target operating system. Once a session has been created, TADDM will interrogate the target system to obtain information about the currently executing processes. For Level 3 discoveries, TADDM will use all of the credentials supplied to extract information about the application infrastructure, database servers, network switches, etc. attempting to return as much information as possible. When suitably configured to use the WebSphere Application Server (WAS) client-side certificates and associated user credentials, the Level 3 discovery can perform a detailed discovery of WAS without having to reconfigure WebSphere (as was required in earlier TADDM releases).

TADDM - Architecture

 

TADDM supplies over 100 sensors out-of-the-box, covering the main stream operating systems, application servers, database servers, network switches, etc. If there isn't an out-of-the-box sensor available to discover one of your components, TADDM can generally be configured to discover unknown components using a combination of custom server templates and custom server extensions.

TADDM uses a combination of Simple Network Management Protocol (SNMP), secure shell (SSH) and Windows Management Instrumentation (WMI) to perform the discovery. If TADDM determines a specific IP device:

• is running a version of UNIX or Linux, SSH is used for the discovery process
• is running a version of Windows, WMI is used for the discovery process
• otherwise, SNMP is used for the discovery process

If the target servers to be discovered are separated from the TADDM server by a firewall, TADDM requires that an anchor server be defined on the other side of the firewall. This is used as a communications pipe by TADDM communicating directly with the Anchor Server using SSH and the Anchor Server then performs the discovery on behalf of the TADDM server. The discovery results are then fed back to the TADDM server via the Anchor Server. The TADDM server functions by default as an Anchor Server for discovery of servers not separated by a firewall.

If any of the target servers to be discovered are Windows servers, TADDM requires a Windows Gateway to be defined. As discovery of Windows based targets is performed using WMI, the TADDM server uses the Windows Gateway server to launch the WMI based discoveries. If the Windows Servers to be discovered are separated from the TADDM server by a firewall, an Anchor Server is also required as described above. A single Windows server can be used to host both the Windows Gateway and the Anchor Server functionality, assuming that SSH is installed on the Windows server for communicating with the TADDM server. The diagram below summarises the TADDM architecture requirements.

Information returned from the discovery process is stored in the TADDM relational database (CMDB) as Configuration Items (CIs). The information is stored according to the Common Data Model (CDM) schema. The CDM defines a structure for holding objects and attributes relating to those objects within the RDBMS. It also defines criteria for describing relationships between those objects, such as database server DB2 runs on operating system AIX and operating system AIX runs on computer system object Pseries-570.

TADDM - What are the benefits?

 

One of the primary benefits of TADDM is that it provides the ability to understand what components exist within the enterprise and how they relate to one another. After the initial discovery process has completed, it is likely that TADDM has identified a number of components that have dependencies, such as an application server and a database server. To manage these related components more easily, they can be grouped into business applications and services. This can be done manually through the TADDM console interface, semi-automatically using custom server templates or automatically using application templates. Using business applications and services definitions allows TADDM to provide a visual business application topology view showing each business application or service and how the individual components relate to one another.

Changes
TADDM records changes that have been made to each discovered component between discovery executions. This provides an audit trail of changes at the individual component level and also at the business application or service level. Changes can be displayed directly through the TADDM console or through the TADDM reporting interface.

Compliance
TADDM can help ensure that computer systems throughout the enterprise are compliant. TADDM provides the functionality to compare objects that have been discovered. This functionality can be used to compare a compliant reference computer system with other systems discovered by TADDM. Built-in TADDM reports showing inventory and compliant computer systems can then be used to assist with compliance audit requirements.

One example of using TADDM to verify compliance is shown when a customer had standardised on the IBM Tivoli Monitoring (ITM) product as the enterprise wide monitoring solution. TADDM was used to perform a "gap analysis" showing which ITM components were running where within the enterprise and, possibly more importantly, where ITM was NOT running within the enterprise.

Integration
TADDM provides integration with a number of IBM service management products, in addition to supporting the industry standard discovery library (DL) format. The DL format is based upon an XML based schema known as Identity Markup Language or IDML. The IDML schema defines the syntax of files, known as books that contain information to be shared amongst different applications. TADDM can load this information into the CMDB using a supplied bulkload utility.

TADDM also bundles a restricted license version of IBM Tivoli Directory Integrator or TDI. TDI is a powerful meta-data integration utility program with support for multiple file formats, protocols and APIs. IBM provides a number of different "connectors" supporting various data sources and targets, each of which helps to remove the complexity of adding or extracting data held within the CDMB.

Asset management

Achieve greater efficiency in asset management by managing all your asset types on a single platform.

 

As organizations grow more complex, successful asset management becomes a key focus for the business. It needs to protect itself from risk, reduce costs and achieve compliance: so you need to develop and maintain policies, introduce standards, deploy processes and establish metrics.

By providing a comprehensive set of tools for managing IT assets, our Asset Management solution helps companies:

• Support regulatory compliance initiatives (Sarbanes-Oxley, Basel II) by understanding your IT assets
• Closely align IT with business requirements through IT asset cost and usage information
• Reduce IT asset cost by redeploying under-utilised assets and avoiding software over-licensing
• A central repository for all relevant contract, lease, warranty and license data, providing essential cost data reqired when negotiating contract renewals
• Reduce IT asset costs throughout their lifecycle through asset standardisation via compliance and reconciliation checks
• Improve Service Desk quality & incident resolution time with accurate IT asset information

Read more: Asset management