Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Special Report: Application Lifecycle Management

email article
printer friendly

New Approaches to App Lifecycle Management
Most of today's tools don't address ALM well. Eclipse and Visual Studio change that equation.
by Peter Varhol

June 1, 2006

As applications and their execution environments have grown more complex over the last decade, so have the challenges of building, testing, and maintaining them across their lifecycles. Technology is changing, as managed application environments depend less on the tools in the past that identified and diagnosed memory leaks, and instead depend more on application performance and scalability.

ADVERTISEMENT

The problems are more difficult because writing the application becomes easier without memory pointers, but making sure performance and scalability meet requirements is trickier. If an application doesn't perform or scale, or if there is a subtle fault that manifests itself only under certain conditions, you might not find out about it until its end users are actually trying to do work with it.

And if that is the case, fixing those problems is a monumental and possibly hopeless task. If those types of problems could have been found in the development or test environment, they probably would have been. So when performance and scalability problems are sent back to the developers, the conclusion is typically "cannot reproduce." And the cycle continues as users keep experiencing problems, developers can't reproduce them, and system administrators can't collect the detailed level of execution data for developers to diagnose the problem.

This cannot continue. Working software applications are no longer a luxury for enterprises; they are an essential fact of life. Application lifecycle management (ALM) vendors are addressing this new paradigm by trying to bring together disparate people and data. One problem is that individual development, testing, and administration tools were developed in a vacuum as individual, single-purpose tools. Debuggers, error checkers, performance tools, and code coverage analyzers were all built separately, to address a specific developer need. They had different purposes, different user interfaces, and different strengths and limitations. In many cases, they came from different companies, and could not work together in any way. You used one or the other, but not both together.

As a result, developers used these tools only when they got into trouble, and only individually. There was no way to take data from one and make it available to another, or even in many cases to save the data to analyze in different ways. Individual developer and quality tools were troubleshooting instruments, rather than aids to managing the application lifecycle.

Connecting the Lifecycle Dots
ALM vendors are addressing this limitation by defining a common platform for their tools, no matter which stage of the lifecycle they serve. In the case of Microsoft applications, most opt to integrate into Visual Studio using the Visual Studio Industry Partner (VSIP) program. VSIP lets third-party tools appear as Visual Studio features, so that users have the same look and feel as the VS IDE. While Visual Studio is known primarily as a developer's environment, Microsoft is offering a tester's edition with the Team System, extending its reach farther down the application lifecycle. WinFX will include business process modeling tools and graphical design tools, providing a means for involving more IT professionals in creating new applications and services. All are anchored by Visual Studio.

Alternatively, ALM vendors are increasingly using Eclipse as the lifecycle platform of choice. This began with the Software Tools and Performance Project, and is being extended with two new projects being defined this year—the Application Lifecycle Framework (ALF), being led by Serena, and the Tools Services Framework, being led by Compuware. Of course, individual ALM tools have always been able to work with Eclipse as long as they were written as Eclipse plug-ins, but these projects broaden that scope. They are intended to ensure a flow of data and other artifacts across individual ALM tools, and across the application lifecycle. While they are new projects, and have not yet come to fruition, they have the potential to change significantly how software is developed and maintained.

Most of today's ALM tools don't address the entire application lifecycle well, but rather individual pieces of the lifecycle. There are designer tools, developer tools, functional testing tools, performance testing tools, and so on. They frequently have data that could be useful to others across the application lifecycle, yet there is rarely a good way to get that data from one tool to another.

Eclipse, and to a lesser extent Visual Studio, change that equation. By providing a common tools platform for vendor ALM tools, both enable a common look and feel across those tools. They also get access to metadata generated by the platform itself, for a deeper level of analysis than would normally be possible with a standalone tool. Tools can take advantage of data generated by the platform because they can read and understand its metadata.




Back to top













Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home