The Bendigo and Adelaide Bank Limited (BABL) has long understood the benefits of implementing configuration management capability into our organisation. However, until recently we did not believe that technology made this easy enough to achieve.

That was until we worked with IBM (and their development partner Aricent), to turn the issue into a strategic outcome which has just become generally available as part of TADDM 7.3 fix pack 5.

The issue

BABL have in the past evaluated IBM’s configuration management offering - Tivoli Application Dependency Discovery Manager (TADDM). The outcome was that while we were comfortable that the product could deliver business benefits for us, the difficulty in discovering our full midrange server fleet was considered a barrier.

The concern was that for TADDM to be able to discover our midrange servers behind firewalls BABL would need to either open ports on our firewalls, implement anchor gateways each side of the firewalls, or integrate with IBM Tivoli Monitoring (ITM). The outcome of the TADDM evaluation at the time was that none of these options were desirable.

The Strategic Idea

The challenge was put to IBM to develop TADDM so that it would meet BABL’s following requirements:

1. It could discover our technical components in all secure zones
2. It did not require breaching BABL’s existing IT Security policies; and
3. It did not introduce any new infrastructure that would need to be maintained by BABL

IBM recognised that there was existing capability to perform Asynchronous Script Discovery (ASD) utilising the BigFix infrastructure, but it required manual intervention (to generate the discovery request in BigFix, and load the response data back into the TADDM database).

IBM decided that further developing the ASD discovery capability so that it no longer needed manual intervention would meet BABL’s requirements (as we already use BigFix for endpoint management) and was aligned with IBM’s strategic direction. Aricent therefore began developing the new TADDM capability, with BABL involved in testing.

The first fully-supported limited-release of the capability came into existence and was called Automated Asynchronous Script Discovery (AASD). The below diagram captures the high-level integration architecture of the solution:

The general discovery lifecycle this involves for a TADDM administrator is:

1. A profile (with the relevant sensors) and scope is defined.
2. The discovery is initiated from the command line on the TADDM Discovery Server.
3. The discovery request progress can be tracked either from the command line, or from the BigFix portal.
4. Once the result files are returned to TADDM, discovery progress can be tracked like other discovery methods - from the Discovery Server command line or the Overview section in the Discovery Manager Console.
5. All processed results files can be tracked like other discovery methods - from the Discovery Server command line or the History section in the Discovery Manager Console.

The Outcome of TADDM 7.3.0.5 for our TADDM Implementation

Before the limited release of AASD, BABL had only been able to prove off the discovery of midrange servers that were not behind a firewall from the TADDM Discovery Server.

With the introduction of AASD capability, we were immediately able to build a TADDM implementation that could easily discover all servers using the existing BigFix infrastructure (including credentials). This is now providing visibility of the technical components, their level 2 configurations, and the relationships between them.

Some limitations that have been encountered are:

1. You can only use sensors that support script-based discovery.
   Script-based sensors are the strategic direction for IBM, but at this stage not all sensors offer that capability.
2. The Custom Application Server sensor cannot be used.
   CustomAppServerSensor does not support script-based discovery. While this point has already been made, the impact of not being able to utilise the Custom Server definitions in the Discovery Console to identify unknown processes is important to specifically recognise.
3. When configuring AASD, you nominate a single BES server.
   If your BigFix implementation utilises multiple BES servers, this may cause issues. For BABL, this was a problem for the dev\test environment. All midrange servers are clients of the production BES server, and the dev\test BES server maintains almost no clients. Therefore, to test AASD, we manually migrated BigFix clients from the production BES.

The Business Benefit of TADDM 7.3.0.5

Prior to the development of the AASD capability, BABL were only able to discover the midrange servers that were not behind firewalls (while still adhering to our IT Security policies). With AASD, BABL are now able to discover the full fleet of midrange servers.

The key deliverable that BABL are now focussing on is providing a semi-automated understanding of what technical components are required to facilitate each business application in our organisation. In the past, without the AASD capability, the understanding we would have gained from such an exercise would have been too incomplete to deliver any business benefit.

BABL are currently working on importing and promoting the TADDM technical components into IBM Control Desk (ICD is BABL’s service desk tool). From there, we will establish relationships between those authorised technical configuration items (CIs), and the manually maintained authorised business application CIs that already exist in ICD. This critical understanding will have wide-ranging benefits, including:

• Ensure true business impact is understood in all our service tickets
• Mature IT’s understanding of the criticality of the services they provided
• Assist IT in the communication with business application owners re what is the underlying health of their application

BABL are now confident that the development of AASD, which is now available with TADDM 7.3 fix pack 5, has provided BABL with the springboard to continue down our maturity path with configuration management.