October 8, 2002

Self Help

The OAMS: a data mart to support information technology operations

by James D. Newman

It seems that most data warehousing initiatives today focus on providing the sales, marketing, and finance departments the information they need to support their customers and understand the financial underpinnings of the company. If you are in the Information Technology Department, and there's a good chance you are if you're reading this magazine, you're always building decision-support systems for the other guys. It's rare, if ever, that you benefit directly from these initiatives.

As IT continues to proliferate and the number of people managing the IT infrastructure diminishes, it is imperative that a knowledge repository is developed that focuses on the critical elements that IT builds and maintains. The Operational Asset Management System (OAMS) that I participated in building for a financial services company provides the very organization that builds these complex data warehouses with a data mart to support IT operations.

Ask yourself if you can tell how any of your enterprise applications are configured. The financial services industry, like many other industries, develops extremely complex applications that encompass multiple servers, operating systems, and networks. These applications often represent the products and services offered by a financial services firm whose customers perform critical financial transactions on a day-to-day basis.

One problem companies often face is the lack of a centralized repository to capture all the components of an application and a roadmap for how those components are interconnected. As distributed processing proliferates, capturing an application's components becomes increasingly complex if you don't get started early.

What's the big deal if you don't have an application viewpoint of the IT infrastructure? It would be great if each application resided on its own set of infrastructure components. That way, if a server failed it would interfere with only one application, one product, and one set of customers. We could then tell the product managers that service has been interrupted, and they should inform their customers.

But we all know the real world doesn't work that way. In the real world, multiple applications reside on a single server and many servers support a single application. On paper these applications often resemble a sloppy spider web. Therefore, if a server fails you can't easily identify what applications or products it affects or which customers are angry because they can't get service. A single day's failure of a critical application within a large bank can cost millions. Most organizations don't have a feasible method to capture and display the interdependencies between applications and their components.

Worse than not understanding how all an application's components are configured is not having the information at all. Many applications in a large company are developed and enhanced over many years. The institutional knowledge needed to recreate this spider web of application components is often contained within the intellectual capital of the developers and the mature employees. The bottom line is that most companies don't have a central place to store and retrieve application component information.

Now ask yourself if you're easily able to track, manage, and deploy IT assets. Most organizations can't quickly and consistently capture key asset information including application components, physical servers, and code segments. Asset management is a crucial financial management function, but asset reuse, particularly of logical components, is truly a valuable function in these days of fiscal austerity.

Mountains of IT infrastructure data are collected every day via a disjointed suite of tools. System management applications are excellent at monitoring a server's performance through measures such as memory utilization and disk capacity. Some systems management applications are excellent at managing the assets (financial, location, and configuration) that comprise an application. Network diagrams may be drawn to capture how a server cluster is attached to its local- or wide-area network. The result, as in other data warehousing scenarios, is that there exists a series of disparate repositories all providing their versions of the truth that aren't easily accessible by IT operations, infrastructure management, applications development, and business partners. Worse yet, because these systems are built on separate platforms and architectures, they don't provide an integrated view of the architecture, components, performance, or business function of the application.

Communication is key. In an environment where computer applications are the company's primary products and services (a bank for instance), it is imperative when a server fails that a product manager is informed about which products will suffer and which customers are involved. It's one thing to have your network operations center (NOC) monitor the integrity of your network and receive an alarm on a server failure. It's another thing for the NOC to be able to analyze which applications are implicated so they can proactively inform the marketing and sales managers.

The Solution

As its name implies, the OAMS is a knowledge repository about a company's applications and application components. It provides an end-to-end application view of infrastructure component dependencies. The OAMS is a data mart solution that assimilates and maintains critical information about an application and its components including: system configurations, logical and physical architecture, relevant business functions, application ownership, contacts, change logs, and the interdependencies to other applications across the enterprise.

The OAMS's goal is also to provide a library facility to track and manage components helping managers to drive greater asset reuse and more efficient application creation.

Within the OAMS, system components are defined and then related to one another. When a planned or unplanned system outage occurs, analysts can track from the source of the outage to determine the impact on related components. This information allows them to work with the appropriate groups to resolve the unplanned outage or notify the correct parties when an outage is planned.

The OAMS is the primary communications vehicle for application information. Its interface provides access to information such as contacts (business and technical), scheduled maintenance activities, change history, and performance statistics.

We built the OAMS to support a multibank holding company with banking assets totaling $38 billion and more than $300 billion under investment management. They have offices in 12 U.S. states and five countries and are leading providers of personal fiduciary, asset management, personal, and private banking as well as master trust/custody, global custody, and treasury management services.

The Design

When we started designing the OAMS, we determined that two aspects of the application were critical to its success. The OAMS's database needed to be highly extensible and provide feature-rich reporting and analysis capabilities. We conducted extensive research to determine if any third-party products could meet the needs of the OAMS. We concluded that no product provided that out-of-the-box functionality. Since the OAMS was a new product, we knew we wouldn't be able to envision all of its potential uses and consequently the needed attributes. The OAMS would have to easily accommodate additional attributes about an application or an application component without significant redesign.

While completing our use cases, we concluded that the OAMS would require a reporting engine that easily could provide multiple views for multiple constituents in both text-based and graphical form. The OAMS had to provide views of the IT infrastructure from multiple perspectives. For instance, an application development manager would want to see all the servers and interdependencies specific to the application. However, a Unix system administrator might want to see which applications and application components resided on a single production server. Finally, the business manager might want to know which products were supported by the applications running upon that server.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC