I'd like to leave you with a prescription for application success. Last October, I wrote about some best practices ("Preventing Application Nightmares: Best Practices," www.networkcomputing.com/818/ 818colrobertson.html). My discussions with clients about this topic during the past two years have reinforced my belief that formal procedures that inculcate or even institutionalize these best practices will pay off in application success. Consequently, the META Group has formalized this collected wisdom into a multistage process called Infrastructure Impact Assessment (IIA).

Why Bother With IIA? Application success is what matters, rather than just middleware choices--which are, after all, merely a single component of an overall application instantiation. If the application is successful, no one cares if the middleware was efficient, object-oriented or just plain cool. Nor does anyone care if the network required ATM, frame relay or LAN attachments, or if the application called for the latest in server technology or worked on old Pentium servers. Only the business users who requested the application can measure the application's success. Did they view IT's solution in a positive way? Does IT have a real set of service levels and metrics to measure application success in business terms?

Enterprises are increasingly trying to formalize the process by which applications are brought into production and measured for success. The enterprise (and IT) also strives for the leanest application budget possible. While functionality is clearly a determinant of customer happiness, so is appropriate application performance. Therefore, as application packages are selected and customized, their networking and other infrastructure implications must be assessed to ensure optimal performance and minimize adverse effects on other applications, while fitting most efficiently with existing infrastructure resources to avoid significant additional expense.

Unfortunately, our experience indicates that most organizations weather several disasters before they bother with this crucial process. Skipping the IIA could lead to suboptimal application performance and performance degradation of other applications sharing the infrastructure.

Assessing network impact is a crucial component of IIA. Networks usually are shared by multiple applications (servers, conversely, are often dedicated to a single application) and are both expensive to upgrade and subject to the ultimate constraint of latency. Furthermore, network resources take time to implement (you first might need to get budget approval and ascertain carrier availability, for example) with commensurate cost increases when sledgehammer approaches like throwing bandwidth at the problem are used as a last resort.

IIA Stage 1: Planning for Impact Ideally, infrastructure developers would work with business and application professionals very early in an application's selection/design. Early on, they could identify infrastructure impact and match identified business patterns, specifically understanding the "who, what and where" of infrastructure pattern matching (see "Infrastructure Pattern Matching," www.networkcomputing.com/902/902colgall.html).