Development teams in companies spend considerable amounts of time, resources and effort to design reliability into the applications they build to support business processes. Ask anyone responsible for delivering products or services about building quality and reliability into their offerings and they'll all tell you the same thing: it's a lot less expensive to build quality and reliability into processes upfront versus fixing problems in the field.
Application development projects receive
considerable focus while the supporting infrastructure receives markedly
less. In many cases it is assumed that
the infrastructure software assets (e.g., application servers, web servers, databases,
middleware and the operating systems) and their required configuration settings
will be in place and set to corporate standards.
Consider for a moment how application developers might operate if they were engineers for a NASCAR racing team. The engineers worry about tuning the engine and overall vehicle for maximum performance. They assume that the car will be racing on a smooth, level and dependable track. In this analogy, the software assets and the configuration settings should be like that smooth, level and dependable track. And ideally, an IT team will be responsible for providing the consistent, dependable platform for the application because without a dependable infrastructure, the business will not experience a truly reliable application.
But between vision and reality there is often a very large gap. The gap is caused by the:
- Complex nature of the application infrastructure assets;
- Lack of tools for managing the assets consistently; and
- Internal process challenges owing to the rapid change rate in today's application environments.
Generally, these factors are overlooked while companies instead over-focus on the application development process. We'll examine each of these factors and suggest improvements so that the application infrastructure itself reaches a quality and reliability level equal to the development process.
Application and Infrastructure Complexity
The first issue to tackle is that of the inherent complexity of today's application environments. Those environments are composed of many different moving parts (once again the application servers, web servers, databases, middleware and the operating systems) oftentimes supplied from many different vendors. The beauty of open standards allows customers to take a "best of breed" approach to building the application
Problem. The downside - or "dirty little secret" as we say at mValent - is that the application infrastructure assets require tens and hundreds of thousands of individual
configuration properties to be set, tuned and controlled in order for the applications to run smoothly. Just in case you underestimate the scope or complexity of the configuration management challenge in this area, consider this recent customer experience. In only
one application project, this customer was managing over 40 software assets which included close to 3,000 configuration files and 625,000 configuration properties.
Given that these properties and files are most often managed manually or with home-grown tools, the possibility for errors that disrupt the operation of the application is high. Combine these factors with high change rates and inconsistent change controls and the result is unexpected outages and difficulty in moving applications through pre-production
activities (staging, QA, user acceptance test, and performance test) into full production.
There is a long list of potential suggestions for ameliorating these problems and the ITIL® (IT Infrastructure Library) website is a good resource. Here are a few things to consider:
- Institute a template-based approach to defining standard configuration settings for the various software assets that constitute application infrastructure.
- Identify the configuration properties that should be identical on servers across the application life-cycle as well as those that will vary from system to system (e.g., hostname, IP address, among others).
- Develop a consistent methodology to deploy those settings across your environment.
- Institute a tool for measuring how the configuration of deployed assets compares to your corporate standards.
Lack of Tools for Managing Diversity of Infrastructure Assets
Consider again the customer who has a single application composed of over 40
software assets - consisting of the five aforementioned "moving parts" - and
625,000 configuration properties.
Problem. These diverse software assets are invariably managed and configured through different management consoles by different members of the IT Infrastructure team.
From an overall management perspective, there is no unifying, consistent methodology for viewing the infrastructure. From a staff leverage perspective, there is no ability to easily
cross-train IT staff to perform operational tasks across the various software assets that compose the application infrastructure. The resulting impact is a drag on application reliability owing to inconsistencies in how assets are viewed and managed as well as inefficiencies in trouble-shooting as core staff teams must convene to solve configuration management problems.
Here are two suggestions:
- Investigate various configuration and change management tools that can offer you an integrated, coherent view of the assets and configuration properties in your environment.
- Look for tools that not only allow you to identify configuration items as they change but also give you an ability remediate problems via comprehensive release management or deployment capabilities.
Change Management Process Challenges
Companies today are pressuring their IT teams to not only increase the reliability of their business critical applications but to field and support a growing list of applications. Many of these are the so-called "composite applications" which Gartner Research VP Ronni Colville refers to as "wiggly applications." She imposes this term because these composite applications open the door to continuing change cycles between development and the IT teams-particularly during the pre-production phases of staging, QA, user acceptance test, and performance test.
Problem. The pressure to move applications through these processes into production often forces IT team to act in "fire-fighting" mode where configuration changes are made ad hoc to solve specific problems, outside of an ordered change control process.
The results are only satisfactory in the immediate term: the specific problem is solved, but IT remains mired in an endless loop of fire fights. And the business impact from this is severe:
- Failures from this source comprise greater than 40% of application outages, according to research studies from Gartner, Forrester and Enterprise Management Associates.
- 67% of IT resources are tied to maintaining existing legacy applications, unable to move the business forward, according to Gartner.
Here are a few things to consider:
- Review the ITIL guidelines for change management and develop a plan for instituting an ITIL-based framework in your environment.
- Provide training to IT staff to insure that they comprehend the impact of inconsistent or haphazard change processes and that they understand and adhere to newly-instituted change management processes.
- Investigate change management tools that are consistent with ITIL norms and fit with your internal management processes.
Building reliable applications depends not just on the development process but also on consistency and reliability in the IT infrastructure where those applications run. A strong focus on making incremental improvements among your people, process and products can deliver high reliability in your application infrastructure, thereby improving application availability and quality.
Jim Hickey, mValent's Vice President of Marketing, 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.