IT Management

Let’s Put a Man on Jupiter!

In today’s IT industry, you can’t but help be bombarded with the buzz on Business Service Management (BSM). Conceptually, it’s the most obvious idea one could imagine, “Let’s manage our IT infrastructure from the point of view of the business processes that run on it!” And while we’re at it, let’s put a man on Jupiter.

If I had to tackle one of the above, I’m not 100 percent sure which one I would bite off first, but in the spirit of sticking to our topic, let’s concentrate on BSM, with an emphasis on mixed mainframe and distributed IT environments.

To frame our topic, let’s first briefly summarize what a successful BSM solution might look like. If we’re to achieve our objective of “managing our IT infrastructure from the business point of view,” it’s obvious our solution will require two elements. The first is a representation of the IT infrastructure and the key indicators that allow us to manage that infrastructure. This will allow us to ensure that each component in the infrastructure is available and performing as designed. The second need would be a representation of “the point of view of the business.” In other words, what end-user or business-facing processes are running on the IT infrastructure, and what are the critical metrics regarding the performance and availability of those processes?

The answer is quite simple: We build a mapping between our two models and away we go! If only it were that easy! The reality is that building these models is neither simple nor straightforward, and once you solve that problem, maintaining them on an ongoing basis is even more difficult. But where do you store this information? The answer is a Configuration Management Database (CMDB), a database that contains all relevant information about the components of the information system used in an organization’s IT services and the relationships between them.

The next question appears to be how to gather and store the relevant components within the CMDB. The industry has responded with the introduction of automated discovery products. These products scan the network looking for IT assets, and then pull detailed configuration information about those assets. What about the z/OS environment? Scanning the network to discover the thousands of servers and desktops is well-suited to the typical discovery product, but I doubt most organizations are going to discover they have four rogue mainframes that were lost in the last reorganization!

For z/OS, the goals are slightly different. While in the distributed world, it’s much more likely to have a 1:1 correspondence between critical applications and hardware infrastructure; in the mainframe space, this is almost never the case. So, in order to map the z/OS infrastructure to its supported processes and applications, it becomes necessary to peer into the box at the critical software subsystems that define the environment. So, how deeply does one peer? Should we represent each and every table and tablespace in DB2? Or, is it sufficient to know that a DB2 subsystem exists?

I will assert its better to represent the higher-level object. It’s suitable for change management and other Information Technology Infrastructure Library (ITIL) processes, and it’s the most easily related to higher level business processes. It also facilitates integration and connection to existing infrastructure management solutions such as monitoring, automation, optimization, and other management products. For example, if a space management product detects a tablespace approaching capacity, it can alert the appropriate DB2 subsystem, passing along the necessary contextual information to allow for association to a business process. A change management solution can leverage the CMDB to identify an affected DB2 subsystem, again passing along all the necessary contextual information to the DBA team.

So, is any of this really practical? I believe it is. There is a wealth of very mature and viable solutions in the market today for incident, problem, and change management. Service and event impact analysis also are emerging from the base of a very mature set of solutions around monitoring and platform performance and availability tools. The emergence of automated discovery and relationship mapping solutions feeding a centralized CMDB is making it possible to tie all this together.

So, is it as hard as putting a man on Jupiter? Perhaps not, but in terms of enabling IT and business operational alignment, implementing a CMDB with automated discovery and relationship mapping capabilities is becoming more realistic and achievable with every passing day. Z