Infrastructure IntelligenceTo fully take advantage of strategic IT solutions, you have to know how they relate to business operations each and every day
by Darin Stewart Continued from Page 1 Available ResourcesThe KPIs developed from LOB views, SLAs, and licensing obligations can serve as the starting point of a requirements document to be passed off to a design and implementation team. When full requirements have been established, the developers will need to work closely with the IT department to catalog the information they have to work with and identify any gaps. IT professionals can also be instrumental in identifying key points of failure affecting your KPIs. These individuals will have enough experience with the systems in question to point out subtle relationships that would otherwise be missed. The first step is to identify what's currently being monitored. It's common to find that close attention is being paid to the network, application servers, and database servers. When one of these systems goes down, everyone knows it immediately — so they're closely monitored. Despite the importance of these systems, monitoring often consists of little more than confirming they're alive and paging someone if they're not. Although this approach may meet the obligations of the IT department, it won't satisfy most decision makers. These individuals want to understand how system resources are being used and by whom. Even legitimate uses of company resources may result in undesirable consequences and require attention. A system load test run by IT may bring a call center to its knees if the two departments are on the same network. As a result, customers are forced to endure unreasonable wait times while your customer service representatives wait for a record to be retrieved. Similar situations can be identified from storage system information if sufficient detail is captured. You should develop a matrix showing the relationships between desired information (your KPIs), system components currently in use, and currently deployed monitoring tools. Monitoring tools can range from top-of-the-line packages such as Unicenter from Computer Associates, HP OpenView, and IBM Tivoli's Service Level Advisor, to shareware tools such as Big Brother (recently acquired by Quest Software Inc.) and MRTG. The resulting maps should be created by line of business with one matrix per LOB view. These maps, once refined, will provide a rough sketch of your final data marts. Most important, empty cells in the map will identify information-gathering gaps that you'll need to fill. Based on these monitoring matrices, you can then develop a comprehensive list of data sources. The list will include all logs and reports available from any source. In addition to logs currently utilized, all logs that can be generated but currently aren't should also be accounted for. Reports must also be examined in detail; even if the standard output of a tool is an HTML-formatted report of limited utility as a data source, the underlying trace logs may be available although not openly published. In addition to textual logs, many tools store monitoring information in SQL-compliant databases. These sources are generally much easier to use as data sources than raw logs and should be taken advantage of wherever possible. Bridging the GapThis inventory will reveal a wealth of available information that must now be mapped to existing data models. This mapping can be challenging: Relating server outages and bandwidth utilization to point-of-sale transactions and quarterly revenues at first appears to be an insurmountable impedance mismatch. However, transactions and incidences in both realms must occur at a given point in time. With sufficient date and time granularity in the data warehouse, business and technical data points can be correlated both as a snapshot and over time. Beyond that, relationships between system information and departments, individuals, inventory, and other dimensions can be addressed according to your data model. As part of modeling and mapping the new data to the old, you'll need to address the sheer volume of new data. A single adequately monitored data center of even moderate size will generate a staggering amount of data. This data can be controlled to an extent within the tools themselves; most allow you to configure the frequency and verbosity of their output. (Throttling data gathering at the source in this manner does carry the risk of losing data that may be critical to supporting a given KPI, however.) Output settings of monitoring tools should be viewed as nothing more than a first-level filter. The real work should be done as part of the data transformation process as the data is moved to the data warehouse. For example, Web server logs and clickstream information are notoriously difficult to warehouse at a detailed level. However, valuable metrics can be culled from these logs by summarizing behavior. For example, visit duration for every page in a Web site may be available for every distinct visitor. Although this information may be valuable, it's also a lot of data to manage; summarizing this information as an average duration for each page may be more feasible. Similarly, filtering information as part of the extract-transform-load process can get around configurability limitations. A monitoring tool may indicate several status states (green, yellow, and red, for example) for every component being monitored. If red is the only state of interest and the others can't be suppressed from the output, they can simply be filtered out as part of the data warehouse load or stored out as a simple count. Data modelers and architects will be able to determine appropriate levels of detail and summarization. These decisions will naturally depend on reporting and analysis requirements but must also take capacity planning into account. Incorporating infrastructure intelligence into an existing BI or decision-support system can dramatically increase demands on system resources in terms of both storage and processing. Storage demands can be managed through summarization, but you must carefully consider roll-off and archiving policies and processing demands when planning the integration. Furthermore, data warehouses often have rigidly defined maintenance windows. If the current system is even marginally complex in terms of data sources or data transformation, its maintenance window may already be fully utilized. This may also be the case if there's simply a lot of data to load each night. In this situation, adding the new data sources may push the load beyond its allotted time. These scenarios must be resolved before infrastructure intelligence is integrated with the existing system. If they aren't and the maintenance window is violated, the project is doomed from the start. With careful planning, however, infrastructure intelligence can open new dimensions of analysis and understanding across the enterprise. Over time, it may even bridge the chasm between IT and management. Darin Stewart [darin@centerspan.com] is director of information management for CenterSpan Communications. RESOURCESBig Brother: www.bb4.com Computer Associates' Unicenter: www.ca.com/software/unicenter/index.htm HP's OpenView www.openview.hp.com IBM Tivoli's Service Level Advisor: www.tivoli.com/products/index/service level-advisor MRTG: mrtg.hdl.com Related Article at IntelligentEnterprise.com "Leveraging Your IT Resources - The Smart Way," July 23, 2001: www.intelligententerprise.com/010723/411trust1_1.jhtml
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
