Infrastructure Impact Assessment

Here, IIA would be performed at a level high enough--and quickly enough--to be useful for securing optimal levels of infrastructure funding, such as communicating infrastructure requirements to business decision-makers. It also should be detailed enough--and performed early enough--to provide meaningful guidance to technical decision-makers. Existing application resources could be articulated generally in terms of infrastructure patterns--specifically the seven basic infrastructure patterns we believe characterize the vast majority of application architectures: host, two-tier, n-tier, hub and spoke, office automation, remote and electronic commerce. New application initiatives would be matched with existing well-understood patterns to better predict impact on physical (servers, desktops and networks), human (helpdesk staff and installers) and budget resources.

For example, a new two-tier Oracle SQL*Net-based application should act similarly to existing two-tier pattern applications based on that same middleware. They do not have to be exactly the same, but comparable--close enough for high-level planning. Based on our research, for example, it is likely that such applications will not flourish over high latency frame relay networks.

Once strategic and existing infrastructure patterns are identified, IT staff can use gap-analysis techniques to pinpoint infrastructure weaknesses and strengths--not in terms of technology, but in terms of business objectives. For example, a business seeking to deploy two-tier applications for customer support across WAN links could identify additional costs for successful deployment, such as Citrix WinFrame at $300 to $1,000 per seat, or WAN upgrades at approximately $200 per month per site.

I suggest publishing a short (two-to-three-page) paper summarizing the above analysis for each business pattern (and/or planned application), and offering key infrastructure trade-offs from which the business can choose. This report and all other IIA data should be kept on an easily accessible Web site.

IIA Stage 2: Preparing for Impact During more concentrated application design and development work, IIA should identify more detailed infrastructure impact. We must go beyond Stage 1's "who, what and where" to quantify how much, including understanding the criticality of availability, data vulnerability, response time, traffic volume and traffic pattern changes (particularly on a WAN).

To generate a refined (even final) predictive estimate for cost and resources, infrastructure developers must establish a close working relationship with application developers. At this stage, variance from the seven basic infrastructure patterns must be well-understood, enabling a more careful gap-analysis to be performed. Specifically, actual applications should be tested in a lab environment against existing infrastructure component capabilities, allowing application developers to see--not just be told about--application performance over real, enterprise-specific network environments. This process, when done well, can improve relationships between infrastructure and application professionals.

For example, a customer-support application's infrastructure requirements must be defined and proven in a test environment over a variety of WAN environments, with detailed and firm supplier pricing for upgrades for each WAN link (to the extent that their configuration varies, say, to larger or smaller offices).

Output from this stage should include detailed estimates of resource requirements generated from actual application testing, augmented by vendor performance testing information if available, along with initial SLAs (service-level agreements) IT will offer to the business, summarized with reference to earlier IIA work.

IIA Stage 3: Capturing Impact Post implementation, IIA and ongoing network and systems management operations should measure production application impact on production infrastructure (establish baselines) while verifying and refining SLAs. Troubleshooting application and infrastructure problems based on knowledge gained in earlier IIA stages is more efficient and effective. Infrastructure developers must be ever vigilant for application upgrades and new modules that can alter infrastructure requirements. IIA also must detect new and existing applications that have bypassed earlier stages of analysis, enabling IT to identify further infrastructure requirements and levy appropriate "taxes" if new requirements are significant. A final budget analysis can confirm earlier IIA estimates, using variances as feedback to improve accuracy of future estimates. Output from this stage includes an IIA budget variance report, an infrastructure reuse score card and SLA performance reports.

Justifying Ongoing Upgrades Infrastructure upgrades will be necessary over time to improve application performance, to lay the groundwork for future application requirements and to increase infrastructure adaptability. Application Impact Assessment (AIA) can be used prior to production implementation to evaluate the impact of such infrastructure component upgrades on applications. As new technologies and services become available, even IIA Stage 1 estimates can be recalculated, while the business is informed of new opportunities available with advancing technology and changing prices. Output from AIA includes documents similar to Stage 2.

With consistent use, this IIA approach will yield infrastructure resource savings and increase the success of application- and business-process implementations.

Good luck. We'll all need it.

Bruce Robertson is a program director with the META Group's Global Networking Strategies service.Send your comments on this column to him at Bruce.Robertson@metagroup.com.


Print This Page


e-mail E-mail this URL

Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers