Tivoli Application Dependency Discovery Manager (TADDM) is an IBM tool that aggregates configurations of applications and their dependencies and helps one understand said configurations with reports, graphs, and other auditing tools. TADDM provides three key benefits as follows:
- Understand what one has: By using agent-less discovery of interdependencies between applications, middleware, servers and network components and automated application maps.
- Learn how one’s configuration items (CI’s) are configured and changing over time: By capturing the configuration of each CI, tracking changes to it and providing analytics to report on the history of these configuration changes over time.
- Determine if one’s configuration items are compliant: By providing the capability to compare discovered configuration of CIs to a reference configuration and determine the variations that define violations to local policy.
- Configuration Management Database
- Change and Configuration Management Database
- Enterprise Configuration Management Database
- Tivoli Application Dependency Discovery Manager.
- Common Data Model
- The definitional language used to integrate understanding and the exchange of data between Tivoli management products concerning resources and components of a customer’s business. The CDM is the model used to communicate details about resource instances with the Tivoli Application Dependency Discovery Manager (TADDM) database, sometimes referred to as the CMDB. The CDM is entirely composed of data definitions. These definitions are characteristics that identify resources, their meanings, and any restrictions on their lengths or values. The content of the CDM is obtained by the merging of applicable industry information and data model standards and the data models used by our current products into a single, converged model.
- Domain Database
- The database that a Domain Server uses to store topology and configuration data which is populated using Sensors, DLAs or the TADDM API.
- Domain Manager UI
- The Web UI for administrating a single TADDM Domain Manager Server including: access control, configuring and running discovery, viewing topology maps and configuration details and running reports.
- Domain Server
- An instance of TADDM (including discovery, analytics and DB).
- Enterprise Domain Database
- The database that the ECMDB uses to store topology and configuration data which is populated using synchronization with one or more Domain Servers.
- Enterprise Domain Manager UI
- The Web UI for administrating multiple TADDM Domain Manager Servers including: access control, synchronization and viewing cross-domain topology maps.
- Enterprise Domain Server
- An instance of the ECMDB linking together one or more Domain Servers into a Federated CMDB.
- Product Console
- The Java™ client UI for the Tivoli Application Dependency Discovery Manager.
- Tivoli Application Dependency Discovery Manager
- A robust application mapping and discovery tool that automatically gathers an inventory of all applications and dependencies, helps you understand configurations and helps prove compliance, with detailed reports and auditing tools. TADDM Provides 3 Key Benefits, enabling you, the ITSM user, to do the following things: v Understand what you have: By using agent-less discovery of interdependencies between applications, middleware, servers and network components and automated application maps. v Learn how your configuration items are configured and changing over time: By capturing the configuration of each CI, tracking changes to it and providing analytics to report on the history of these configuration changes over time. v Determine if your configuration items are compliant: By providing the capability to compare discovered configuration of CIs to a reference configuration and determine the variations that define violations to local policy.
Does TADDM use agents?
No, Discovery sensors use standard interfaces like JMX, WMI and SNMP to obtain the information required to gather identity, configuration and the settings of application, system and network components.
What are sensors?
Discovery sensors reside on the TADDM server and collect configuration attributes and dependencies. TADDM offers a wide variety of Discovery sensors to enable out-of-the-box discovery of virtually all components found in the typical data center, across the application software, host and network tiers. Custom sensors for unique components can be rapidly developed.
Is it possible to extend sensors to discover custom components?
Yes. IBM Tivoli offers multiple ways to extend its discovery sensors to gain visibility into custom infrastructure components:
- Field customization: TADDM can be customized in the field to discover custom software components, hosts/Operating Systems and their configurations. TADDM provides simple templates, which can be user-created in minutes to identify these components and their custom configurations. TADDM also provides the ability to easily create and securely execute user-defined (Java, CLI) scripts to capture additional custom configurations. Once discovered, custom components participate in configuration, change tracking and business application discovery.
- Existing or custom data sources: Many customers have configuration data available in spreadsheets, files and other data sources. The Tivoli Universal Data Sensor (UDS) allows for the scheduled importing and transformation of this data into the TADDM model as part of the discovery process, helping TADDM leverage existing data sources and management processes.
How comprehensive is TADDM’s discovery?
TADDM provides the most comprehensive breadth and depth of application infrastructure visibility of any solution on the market:
- Breadth: With over 200 out-of-the-box sensors, TADDM provides complete visibility into business applications built on .NET, J2EE or custom application platforms; with support for all major application platform software including WebSphere, Weblogic, JBoss, Oracle, DB2, MS SQL, Apache, IIS, and SunOne; packaged applications such as PeopleSoft, SAP, Siebel and Domino/Notes; running on all major Windows, Unix, Linux platforms (as well as mixed environments) across a wide variety of networking and storage equipment.
- Depth: TADDM can provide visibility into all of the relevant information needed to optimize service delivery and agility. For example, TADDM identifies:
- Changes to deployed application modules such as EJBs and .NET assemblies
- Dependencies between individual software processes, whether they are running on Windows systems, Linux or Unix, or mixed environments
- Dependencies on critical network services such as LDAP, NFS and DNS
- Logical software to physical network and storage layer dependencies
- Extensibility: TADDM provides rapid extensibility of its solution to meet customer specific needs. For example, the user can create custom software servers in minutes, making them first class objects for discovery and change tracking. IBM Tivoli can create new Discovery sensors. Once created, these sensors then become part of the core product deliverable and are available to all current and future customers.
Can TADDM also automate the process of discovering business applications?
TADDM automates the last piece of application mapping, the automatic discovery of business applications. It does this in two ways, via application templates created by operations after deployment, or via Application Descriptors™ created at development and/or deployment time. By eliminating the requirement to define business applications via a manual-grouping step, TADDM removes the last manual step in creating, maintaining and scaling reliable and definitive application maps. This dramatically accelerates the ability to successfully implement business service management and IT automation efforts.
Since TADDM is agent-free, does it mean that you don’t capture as much information as an agent-based solution?
To the contrary, TADDM discovers significantly deeper configurations and dependencies than any other competitive agent-based solution. TADDM uses standard protocols like SNMP, SSH, JMX and WMI to instrument and discover services and its infrastructure, thus eliminating the deployment and management costs associated with agent based solutions.
How long does it take to install TADDM?
TADDM offers rapid time to value – it installs in less than one day and is extremely easy to configure. The user provides an IP range for discovery and there is no agent installation or agent management. It has a graphical browser-based client with standards-based output options, including HTML, XML, CSV, and PDF.
What is needed to set-up a TADDM Discovery run?
TADDM requires a minimal set of setup information:
- The discovery scope: Typically a valid IP range, a subnet or a specific component, the discovery scope signifies the span of the discovery process.
- Access lists: Access lists specify the read-only access credentials needed to discover and query the components for its appropriate configuration attributes and dependencies. The access mechanism varies based on the type of components discovered:
- SNMP community strings to discover the network elements
- SSH to discover the configuration and dependencies of the hosts/operating systems
- Protocols like JMX, SQL, WMI and other standards access mechanisms to discover application software
- Schedule: TADDM’s discovery process can be executed on demand, as part of a schedule, or driven by externally triggered events.
How does TADDM automatically discover the application infrastructure?
Upon discovery initiation, TADDM’s discovery engine proceeds thru a multi-step process:
- The discovery engine uses standard protocols such as SNMP to inspect the defined discovery scope to identify the IP nodes (address) of all installed devices.
- For each valid IP node in the set, TADDM’s discovery engine launches a discovery sensor. The discovery sensors discover and categorize the component type by matching it to the appropriate signatures in the Data Center Reference Model.
- The discovery sensors then query the component for its configurations and dependencies.
- The discovery process is iterative; each discovery sensor run can spawn a subsequent discovery sensor until then entire infrastructure is discovered (e.g., a host discovery will trigger the discovery of applications and services that reside on the host).
- Upon completion of discovery, TADDM processes the discovered component data to generate a topological representation of the infrastructure.
- Subsequent discovery runs update the topologies, while maintaining a comprehensive change history of the infrastructure configuration and dependencies.
What is the TADDM Operations Portal?
The TADDM Operations Portal allows organizations to aggregate and analyze data gathered by multiple TADDM deployments across separate management domains such as business units or geographies. For example, by leveraging the TADDM Operations Portal, a CIO can rapidly compare and analyze the total infrastructure investment in place to deliver a given business application in two separate geographies. In addition to aggregating data from multiple TADDM instances, the Domain Manager database can be extended to include information from other systems such as asset, license or support systems. The data stored in the Enterprise Manager database can be accessed using the TADDM APIs and SDK, making it instantly sharable with other management products and processes. The TADDM Operations Portal is also available as a JSR 168 compliant portlet to be integrated into other portals and dashboards.
What is the maximum size of the infrastructure you can discover?
TADDM was created to scale horizontally or vertically. For larger infrastructures which are typically distributed across multiple management domains, TADDM offers the capability to consolidate (federate) discovered data across multiple discovery server instances, thus providing a single consistent enterprise-wide view of all services and their supporting infrastructures.
How resource intensive is the discovery process?
TADDM’s discovery process is architected to use minimal system and network resources. Based on lab-based benchmarks, TADDM typically uses less than 1% of CPU utilization (on discovered hosts) and less that 1% of network bandwidth during active discovery.
How long does it take to do a discovery?
A 1000-server environment typically takes around one hour for end-to-end discovery. As discovery time is typically affected by network latency and response times, this number may vary at customer sites. Customers can also scope incremental discovery runs to smaller subsets of the infrastructure, thus optimizing discovery time.
- “$COLLATION_HOME” and “%COLLATION_HOME%” are environment variables that refer to the root directory of TADDM on Unix and Windows systems respectively.
- Usually “C:\ibm\cmdb\dist” or “C:\ibm\taddm\dist” in Windows
- Usually “/opt/ibm/cmdb/dist” or “/opt/ibm/taddm/dist” in UNIX
- %COLLATION_HOME%\etc\collation.properties contains TADDM management settings such as ‘maxumum thread-count during discovery’ and ‘sensor time-out value’
- %COLLATION_HOME%\support\bin\testssh.py can be used to test TADDM SSH connectivity (usage below).
$testssh.py -u <TADDM userid> -p <TADDM password> <ipaddress> "show system"
$control.bat start $control.bat stop $control.bat status
- Some documentation recommends the use of %COLLATION_HOME%\bin\startServer.bat to start a TADDM server.
- Some documentation recommends the use of %COLLATION_HOME%\bin\stopServer.bat to stop a TADDM server.