The power of Tivoli

IBA Group
Mark Kobayashi-Hillary

The IBM Tivoli Management Framework (known as the TMF) is a systems management platform from IBM. It was originally a separate company and product, but IBM purchased Tivoli in the nineties and the product has been developed extensively since then within IBM’s software division.

The TMF is designed using a CORBA-based architecture and its real strength is that it can be used to manage a large number of remote devices in a very robust way.

Tivoli is an entire framework of tools that can be linked, rather than just a single software product, so it is very powerful and can be used in many ways. There are endless different ways in which the tools can be integrated to deliver a solution.

At IBA, we recently delivered a solution to a client that involved us connecting these tools together to create a fully integrated system:

• Tivoli Network Manager; the tool to help visualize and manage a complete network.
• Tivoli Netcool/OMNIbus; the tool that provides a complete operations management infrastructure, including the ability to identify and correct critical network issues.
• Tivoli Netcool Impact; an intelligence tool that adds context to events, helping you to manage events on the network and using intelligence to determine whether an event is critical or not.

Even this short example alone gives you an idea of the power of Tivoli. It is not just about visualizing your network with a series of graphical representations, but about adding a layer of intelligence into the network itself – almost like a self-healing network so your team only needs to manage the critical issues.

To those not involved in managing networks all this might seem quite dull, but every company needs their network to be up and running and as reliable as possible, business doesn’t happen without it, so the team keeping the network running are really ‘keeping the lights on’ at your business. Do they have the right tools for the job?

Want to improve communication between business and IT? Use ITIL

IBA Group

Mark Kobayashi-Hillary

I used to manage the equity trading technology for the French bank SG. It was a pretty big job, with business analysis and support teams in all the major equity trading locations around the world, as well as a development team over in India.

We had a bespoke system built in Lotus Notes to handle change and service requests from the business. As each bug or request was found, the business analysts would assess the importance of the change, along with the business people assessing the priority of their service requests.

So as each version of the trading platform was released to the users, a list of service requests soon built up. The problem was that to the business people, everything was a high priority. They always felt that the system should be more malleable. They never had any concept of how IT systems that are endlessly changed can also become unstable – even more difficult to manage in a globally connected bank trading system that has to operate across time-zones stretching from Japan to the USA.

At the time, we tried moving to an Agile methodology where the system was being updated with fewer changes, but on a much more frequent basis. It helped to give the business users the impression of constant progress, but it never helped with the fact that a service request that was not considered urgent might sit at the bottom of the list for months, or even a year, never touched because it is always replaced by more urgent requests.

By using ITIL my team could have improved this service desk considerably. Less important changes would no longer languish unloved, they would have been highlighted and alternative solutions or workarounds proposed. Even a less important request is still a request that needs to be addressed and the single-point-of-contact rules within ITIL help to avoid it getting lost between teams of business analysts, programmers, and project managers – all tied up trying to deal with urgent enquiries.

The real difference is that in my old company, the IT department controlled the process of listing and prioritising the service requests. Within ITIL, the focus of the change and service request process is always the business user. By adhering to the ITIL guidelines:

1.     It would be the business user that asks for changes

2.     The business user would be updated on progress without the need for status review meetings – it would be a function of how the IT team works

3.     The business user could directly handle queries about their request – without ‘assumptions’ coming from the IT team

In this sense, ITIL is not just a conceptual list of service practices; it is a common sense package of processes that ensure the business user builds confidence in their IT team through open and transparent communication.