The Chicken and Egg of IT Transparency
Global financial services organizations today face a major challenge—not knowing what they have is the first barrier to delivering better information technology. You can’t manage what you can’t measure, but you can’t measure what you can’t see.
Unfortunately, as any business leader can confirm, barriers such as these cost money to break down, and entering a new phase of IT efficiency and operational excellence will come with some cost. Equally unfortunate, return on investment is typically difficult to justify prior to the expenditure and the net benefit even harder to articulate—two points often raised in defense of doing nothing. Yet what we tend to miss is the idea that what we really want to know is how one infrastructure asset relates to other assets—where are its dependencies?
That said, we often meet visionary people in our industry who are willing to push their organizations and bring together disparate IT teams to reap benefits from shared investments and solutions. But they face multiple obstacles.
Most large financial services firms have spent many years decentralizing IT, giving autonomy and power to local users and business units and pushing design choices further away from the CIO’s office. Technology purchasing decisions are being made further down the corporate food chain, while the power behind the technology itself continues to move up. At today’s prices, a business service generating a multimillion-dollar revenue stream may be running on technology that costs only a few thousand dollars. This technology can be replaced cheaply and quickly, so why should anyone worry too much about how it is configured, where it is deployed and what it impacts? If it breaks, we just buy more.
Throw service management and frameworks such as ITIL, or the information technology infrastructure library, into the mix and we introduce the blue-eyed boy of IT, attempting to unite technology teams with promises of service maturity. New processes threaten to disrupt kingdoms, and service management tools serve to prove just how un-enterprising most IT departments have become.
Some IT shops are bouncing back with a push to re-centralize and leverage economies of scale and knowledge-sharing in the provision of shared IT services. Yet to be successful, firms still need an accurate view of what assets they have. To truly understand what is out there, there must be a simple approach to connecting the dots across disparate systems, infrastructures and organizations. Unfortunately each system is typically surrounded by security and design foibles that limit how we can access them and accurately capture the assets—while also concealing critical relationship and configuration details.
People make the world complicated too. Power, political domains and teams in silos all require careful communication, bridging, inclusion and owner permission to access their kit. Access is often only provided once the “what’s in it for me” question has been addressed.
Despite these specific issues and barriers, the biggest problem is where to begin. Creating some type of system of record, such as a CMDB (configuration management database), seems like a good starting point. This can underpin all other service-orientated activity, and once we know what we want to record, designing the repository is relatively straightforward. Well, maybe not. A CMDB holds attribute data about a variety of different classes of configuration items and their relationships. The only thing in common between these configuration classes is that they have attributes, relationships and, usually, multiple instances.
So we have hit another barrier—the design and enterprise approval of the CMDB—and we are still no closer to discovering what assets are out there.
We might adopt a different approach and think instead about what service we want to provide to our internal business customers. If we can identify this, we can determine the policy and processes we need to agree on and implement to make IT function like a business. Unfortunately, this also requires a comprehensive design activity to build the required service processes—or at least a commitment to adopt known service management best practices across the organization.
Every Journey Starts With a Map
What if instead we could deal with the easy part first, automatically discovering and mapping our IT assets and relationships and profiting immediately from the benefits this provides?
We can be more confident that the commitment to auto-discovery will provide extended returns on investment if the techniques and tools we use meet a few key requirements. The most sophisticated auto-discovery technology allows users to select which attributes they discover for each class of configuration item; distribute and integrate the captured data with the future CMDB choice; and cross-reference discovered data with known data about vendor and product versions, patches and licenses, thus multiplying the value of the initial purchase.
From collective experience on customer sites from the financial services world, we’ve learned there are two immediate benefits to deploying an auto-discovery tool prior to implementing a CMDB and service management processes. The first is that we can explore which configuration attributes are important and determine how they will be captured.
The second is that the act of automatically collecting the data relieves the infrastructure and application teams from maintaining their own inventories. It also means that they don’t have to first agree on the service management strategy or the supporting solution—both extremely time-consuming and costly processes. Instead, they can free up resources to focus on providing effective decisions and actions, and thus deliver true customer satisfaction.
A service management framework such as ITIL and supporting standards such as the International Organization for Standardization (ISO) 20022 format necessitate building a CMDB, which in turn requires a data model to both define what we populate the CMDB with and identify supporting processes and procedures to answer the why, how and who. Red tape and disparate IT teams don’t make for rapid consensus on these types of solutions—and we may end up designing a camel where a horse would have been perfectly adequate. Technology, process, people, complexity and centralized-versus-decentralized management take time to bring into line but they all have one thing in common: the need for discovery before design and service management solutions building begins.
Charles Rattray is director of professional services for Tideway Systems, a provider of IT automation software.