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 The complexity of enterprise infrastructures is growing exponentially. Distributed, heterogeneous IT architectures are required to support the complex business models and processes typical of strategic business applications. The success or failure of your business depends on the health and well being of these systems. This dependency makes monitoring and management of your infrastructure critical. But even the best system monitoring won't move an organization forward if the information stays buried in the IT department. In order for decision makers to take advantage of the technology supporting their enterprises, they must be able to see how it relates to the business information they digest each day. A sales manager in a mail order company, for example, may be perplexed about why customer returns spike without reason from time to time. Even with access to extensive business intelligence (BI), the cause of the surge can't be determined. Unbeknownst to the frustrated manager, the servers in order fulfillment (notorious across the IT department) crash on a regular basis. While IT struggles to get the servers back online, orders are delayed, incorrectly filled, or simply lost. A week later, angry customers are lining up to return their purchases. Meanwhile, business managers can only watch as their margins tumble, never realizing that the servers they got such a good deal on are costing them a fortune in lost sales and customers. An integrated view of the two situations would quickly reveal the root cause. By correlating system monitoring data points with more traditional business-oriented information, you can get an overall picture of the state of the enterprise: Comprehensive cause-and-effect relationships can be identified that are otherwise hidden. The only way to provide such a view is to move beyond system management and into infrastructure intelligence.
Greater Than the Sum of its PartsIT managers have had to choose between comprehensive, management suites and cobbling together their own solutions from various tools, logs, and custom scripts. The suites can provide a holistic view of your systems but often rival the key components of the infrastructure itself in complexity and cost. Homegrown solutions are certainly cheaper and can provide crucial data on key components, but the overall picture is nearly impossible to pull together. In both cases, the information available is generally transient and isolated from any business decision-support system. In contrast, infrastructure intelligence is the process in which a structured, summarized historical record of this information is created and integrated with BI. The key to implementing infrastructure intelligence is developing a comprehensive set of key performance indicators (KPIs) for your business systems. These KPIs often include metrics such as server fail-over frequency, bandwidth utilization, and concurrent user connections. To identify the KPIs for your infrastructure, you must first establish line-of-business (LOB) views of your IT systems. Each of these views should represent a subsystem supporting some aspect of your enterprise such as sales support, engineering, Web presence, and so forth. These views will often overlap, such as when a single network supports multiple business units. This overlap can be addressed when the new data sources are mapped to your current BI mechanisms, usually in the form of a data warehouse. Initially, it is sufficient to simply group systems and their components into units of interest. With LOB views established, it is essential to review the commitments affecting those units. These commitments generally take the form of service-level agreements (SLAs) and licensing. SLAs are the binding contracts between an LOB and its customers and partners, both internal and external. Although essential to the operation of a business unit, SLAs are notoriously difficult to enforce. By identifying the performance metrics governed by each agreement, you can begin tracking the data points necessary to monitor compliance. By correlating this information with other BI information, you can judge the appropriateness of current SLAs and even model the impact of proposed changes. For example, when new services are first brought online, their owners may be overly optimistic about unplanned outages and overly conservative about scheduled downtime. These perspectives will invariably be reflected in the SLAs. If this is the case and actual outage durations, both planned and unexpected, are tracked over time, subsequent agreements can be tailored to your advantage. Scheduled downtime can be trimmed and allotments for unscheduled outages increased to reflect a more realistic view of operations. The result is that even though overall availability remains unchanged, penalties for unscheduled outages are reduced or eliminated. Similarly, you can more accurately assess licensing needs if usage and access patterns are tracked over time. When a new application is acquired, it's common to purchase a fixed number of named seats based on the number of people needing access. In most cases, you'll find that the application has only two or three power users requiring continual access. The majority of licenses will be tied up by more casual users needing only occasional access to a certain report. As these patterns emerge over time, actual licensing needs can be determined and agreements renegotiated. For example, 100 named seats could easily be replaced by an application service provider model, offered by many BI providers, based on actual usage. The historical analysis available through infrastructure intelligence would facilitate the necessary ROI and determine when such a move makes sense.
|
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
|
|
|











