Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Quality in Configurations

Written by Jim Hickey

Monday, 16 April 2007 09:35

Ask anyone responsible for delivering and supporting business applications about quality requirements and most will reply with a common mantra: ‘Five nines reliability is the expectation of the business.' But while this goal is frequently attained for hardware servers and networks, it's another matter entirely for most business applications. Whether you call them ‘n-tier applications' or ‘composite applications' or ‘wiggly apps' as Gartner's Research VP Ronni Colville calls them (my personal favorite cognomen), that acme of quality and reliability eludes most businesses.

But it's not for lack of effort. Significant resources are applied to the quality challenge across the enterprise. However, the bulk of these resources often go to ensuring quality in the front-end of the application and in various components of the application infrastructure stack. The configuration parameters that are used to configure the application infrastructure receive comparatively less attention.

This is a common bias that occurs not only in IT development and support environments but everywhere. More resources are applied to ensuring quality in the front-end of the application because that's what all of your business customers actually see. But often, the things you can't see cause enormous problems. And these are usually time-consuming and expensive to track down.

Think about this analogy: Who wouldn't rather spend money on dressing up a room with some new and expensive lighting fixtures? Everyone will see them and appreciate the impact they yield. But what about the wiring in the walls that connects to the main service in the basement? Without quality there, your investment in the front-end is ill-advised.

This is certainly the case with configuration parameters or properties in the application infrastructure. For all the effort spent on QA'ing applications, much of this will be wasted unless the application is built upon a reliable foundation (OK, enough home repair metaphors!) in the application stack. Consistency and quality in configuration management for the application stack are essential.

Certainly, the issues are well-known to industry experts. According to leading research analysts at Gartner, Forrester and Enterprise Management Associates, application configuration errors are the leading cause of quality and downtime problems-between 40% and 60% of occurrences. mValent's own research with customers and prospects syncs with these analysts, showing that 73% of companies experience configuration-related downtime.

Fortunately, there are a few simple steps to promote quality in configurations that will yield tremendous benefits to overall application quality and reliability. Here are a few considerations for IT teams:

Build-in configuration consistency and standards across all of your environments (Dev, QA, Staging UAT, Production) and your various applications
Automate the delivery of infrastructure configuration properties
Develop a plan to audit your configuration standards in use to measure so-called ‘configuration drift'
Implement processes to remediate this drift and bring configurations back in line with your standards.

Taking these four simple steps will drive a higher quality level in the applications themselves.

First, configuration consistency delivers your developers that firm foundation upon which they develop and deliver their application code. By agreeing on configuration standards for the application infrastructure, and insuring that these standards are used in all environments, enterprises experience substantial improvements in application quality.

It's always important to eliminate as many variables as possible in the quest for higher quality. Development, QA, UAT, Staging and Production may all use the same code and similar systems. But when the application infrastructure itself is configured identically across these environments, trouble-shooting and remediation are that much easier to accomplish.

Maintaining this configuration data in a common database format is an essential method to promote consistency. Combine this with a ‘model-based' view of your infrastructure and you have a reliable vehicle for insuring quality across various stages in the application life-cycle before applications are delivered.

Second, IT teams can improve quality by ensuring that these configuration standards not only are well-codified in the central database but that they are delivered reliably to all of the target systems. Just think about the scale of a mission critical business application, like your company's CRM system or supply chain management system. Working with large enterprise customers, mValent encounters applications like these running on large sets of servers. When you have to deliver hundreds and thousands of configuration parameters to 40 or 50 systems, it only takes a few errors to cause tremendous downstream problems.

Often, companies use a mix of manual methods and home-grown scripts to distribute configuration. But these are not ‘bullet-proof' processes. A systematic method to distribute the configuration properties and then validate that this has been done exhaustively and correctly will also deliver much improved configuration quality.

Third, a quick and comprehensive audit of your configuration properties that compares what is deployed to your acceptability standards is critical for improving quality. This is a very useful way to avoid problems before they occur.

Again, having codified your configuration standards and storing these in a common database is a key first step. Then, have tools on-hand which traverse your various systems and collect copies of the current configuration parameters. Next, use a sophisticated "Compare" tool to spot differences between your standards and the current state of your world. You will want to track the differences down to the individual configuration parameter level, not at the file level. These files often contain hundreds of parameters and it can only take an error in one or two places to cause systems to perform poorly.

Fourth, having a method to remediate the problems that you highlight through the previous "Compare" process completes the loop for driving higher levels of quality. It's a beautiful thing to be able to find all of the differences in your application infrastructure configuration settings which may be causing application problems. But it's a lot less beautiful if you cannot act on that information in a direct and comprehensive manner. The knowledge itself is an important precursor, but the ability to make corrections is an essential companion to achieving quality in configurations.

For all your best efforts to get things right when you deploy applications, we know that IT people and developers will continue to make changes to systems during the application life-cycle. So, tracking differences and making needed corrections are essential quality tools.

Conclusion
With a few steps like those outlined above, IT teams can instill quality in the configuration management process and deliver better application reliability. More attention paid to those things you don't see, like configuration settings, will provide a consistent foundation for your developers and production users.

Jim Hickey, mValent's Chief Marketing Officer, has more than 20 years of software marketing and sales experience with emerging and growing companies. He is a former strategy consultant with global consulting giant, Booz-Allen & Hamilton and has an MBA degree from the Stanford University Graduate School of Business and a BA degree in Economics from Harvard College.

Set as favorite

Bookmark

Email this