FTP Online
 
 

An Application Lifecycle in 8 Phases
Use a complete application lifecycle to improve IT effectiveness.
by Danielle Ruest and Nelson Ruest

Posted October 15, 2003

Most application lifecycles tend to focus on the various phases of the development process. Microsoft, Sun, IBM, and many other manufacturers that focus primarily on development have often made this mistake in their own methodologies—methodologies designed primarily to support developers during the development process.

Yet as more and more of us are beginning to realize, application lifecycles are not limited to development just as they are not limited to deployment. Recent examples abound. A good one is the MSBlaster virus, which made it evident that Windows products are never quite finished.

But Windows isn't the only operating system suffering from incompleteness. Linux and Unix also have incomplete code when they are released—that is, code that requires regular updates and fixes to run properly. And the same often applies to in-house development. When it comes to application lifecycles, one truism stands out: Even when applications are released as "final," their development is rarely complete.

Organizations must focus on a complete lifecycle, one that will include all aspects of an application's life and all the players involved. This model should also describe the different interactions each level of personnel must undertake to conduct a complete dialog during the application lifecycle. This process should help you gain better control over the applications in the network because it identifies who has the authority to work on which part of the cycle and when they should interact with others.

A complete lifecycle must follow the path of an application from its conception to its retirement from production. So the lifecycle should comprise two major aspects: the development aspect and the operational aspect. One aspect is driven by developers, while the other is driven by IT personnel. To fully profit from this lifecycle, you must ensure that a dialog is initiated between these two groups from the beginning of the project. This responsibility falls to the business decision makers who will approve and authorize the project.

From Vision to Development
As can be expected, the corporate application lifecycle (see Figure 1) begins with a vision, a vision that responds to a perceived business need (also see "Life Begins at Requirements"). At this stage, the application can take the form of either a commercial software product or new code developed in house. Despite the obvious differences in process for each product type, both will nevertheless need to go through each stage of the cycle.

The vision is crucial to the project. An improper vision can be disastrous if it doesn't properly represent both needs and expectations. This is why the business decision makers should drive this stage of the lifecycle. Discussions should also involve all the players in the cycle from the onset of the project. This way, each player can express his or her own concerns and preoccupations—preoccupations that can be integrated into the vision—ensuring a more complete understanding of the project's scope and objectives.

The second stage focuses on planning. This involves two major players: the project manager and the designer or architect for the solution. The project manager is responsible for the planning and preparation of the project itself. The architect is responsible for the design of the solution. In both cases, the plans should take into account every aspect of the lifecycle, not only the development and testing aspects. Don't make the traditional mistake of focusing only on the initial phases of the project to the detriment of the latter phases. Make sure you take into account the stages that affect the life of an application within your production environment.

Also make sure you cover these items in this phase: cost of the application throughout the entire cycle; benefits of the change; required resources and resource availability; risks for the project and for the business; and impact of the change on existing infrastructures and resource levels.

The third phase comprises development. In the case of an in-house application, this means actual coding. Here, the architectural elements designed in the previous phase can be brought to bear to mitigate development risks. This means making use of the advanced features of integrated development environments such as Microsoft Visual Studio .NET or IBM WebSphere Studio to design development templates that include both project architectural orientations and best practices (see Resources). Capturing expert knowledge and integrating it into a template that controls how junior developers will create the program is one of the best ways to mitigate risk during the development phase.

In the case of a commercial software product that is to be introduced into the corporate network, development activities will focus on discovery of the product features and installation requirements as well as custom configuration. The installation should be packaged to meet corporate standards and should properly coexist with other applications within the network. Products used to support this phase for commercial software include software-packaging tools such as Wise Package Studio or InstallShield AdminStudio (see Resources).

Testing and Quality Assurance
The fourth and fifth phases involve application testing and quality assurance (also see the FTPOnline Special Report on Testing and Performance). These phases apply to both in-house development projects and commercial software products. The initial testing phase focuses on the initial developer or software packager. As developers begin to program new code, they first work on their own local system. As they progress through the development cycle, they migrate the code from their system to servers where it can be shared and integrated with other components created by their teammates.

Most organizations today use this testing and stabilization process, which includes five steps; two occur locally on the developer's workstation, and three take place on centralized servers:

  • Unit Testing: Developing and testing single components on the local machine by individual developers. Developing and testing initial software packages locally by individual packagers.
  • Functional Testing: Ensuring that the new components perform the functions they are designed for or ensuring that the custom configuration will offer all the required functionality. Once again, this is usually on a local system. This completes the testing phase of the lifecycle.
  • Integrated Testing: The new components are moved to a central server to integrate them with components created by other programmers. This test checks whether all the components can work together as expected. In an ideal situation, these components are also integrated with every other component found in the production network.
  • Acceptance Testing: Users or clients are brought in to review the operation of the new program. They will accept the program if it performs the functions they requested in the first place.
  • Pre-Production Testing: The code or package is moved to a final environment to test its performance in a production-like system. If it passes this final test, it will be deployed to the production environment. This completes the stabilizing phase.

During both of these phases, it is critical to focus on product quality and complete documentation. As you can see, developers and packagers begin by working on their own local machine, and move to central environments as the program/package evolves. This is the scope of the traditional application lifecycle.

Deployment, Support, and Retirement
Once a program is complete, it must be deployed. This sixth phase should always include a pilot project of some sort, followed by a revision of the deployment strategy if required, then the actual deployment. In some cases, there might even be a step before the pilot project: a proof-of-concept step that provides a link between acceptance and pre-production testing and the operation of the application within the production environment.

In all cases, it is important to put in place special deployment support teams to provide the ability to react quickly in the event of deployment-related problems. It is also important to have a rollback strategy in case of major disasters. Finally, the deployment phase is where knowledge transfer from the development team to the operational team occurs. One output from this knowledge transfer is the initial service-level agreements for the application.

Once a program is deployed, part of the programming or packaging team will move to ongoing support—the seventh phase of the lifecycle. This might involve minor maintenance-related modifications to the application and fixes or service packs. The support phase also involves performance tuning and stability improvements. Part of the objectives for this phase is the support of the service-level agreements that were designed in the deployment stage. In many cases, this is the longest part of the application lifecycle and may very well last for several years if the other aspects of the lifecycle were managed properly.

The eighth and final stage deals with application retirement or replacement. This is often a difficult phase to initiate because people are reluctant to change, especially when the application responds exactly to their needs. A good example is the number of users still running Windows NT even though its replacements have been out for three years. But it is essential for organizations to identify and treat application obsolescence. Sometimes the cost of running an older application outweighs the cost of making the change. This is also the stage that serves to reinitiate the analysis of business requirements and begin the application lifecycle anew.

About the Authors
Danielle Ruest and Nelson Ruest (MCSE, MCT) just released their third book, Windows Server 2003 Pocket Administrator (Osborne McGraw-Hill, 2003), an everyday administration reference. Their second book, Windows Server 2003, Best Practices for Enterprise Deployments (Osborne McGraw-Hill, 2003), is a step-by-step guide for designing enterprise networks with this new operating system. They are also authors of Preparing for .NET Enterprise Technologies (Addison-Wesley, 2001), a book on mastering change in the enterprise. Both work for Resolutions Enterprises, a small Canadian consulting firm that provides services in the information architecture and change management fields. Both can be reached at infos@reso-net.com.