Eclipse ALF Automates the Life Cycle
The Eclipse Application Lifecycle Framework (ALF) simplifies development in lieu of custom, point-to-point integrations among diverse ALM tools.
by Tracy Ragan
October 18, 2006
Life-cycle process control and automation is about to get easier with the Eclipse Application Lifecycle Framework (ALF). One of the largest problems that organizations face when establishing a repeatable life cycle across diverse development teams is the diversity of the application life-cycle tools used by those teams. It is often required for application life-cycle management (ALM) tools to pass critical data to one another along the life cycle; however, it is uncommon for these tools to work together without the end user developing highly customized ALM scripts. ALF addresses this problem directly by providing a common framework for diverse ALM vendors to communicate through a Web service.
What does ALF mean to organizations attempting to establish a standardized application life cycle? It means that they are not required to create point-to-point integrations among ALM tools to implement their unique life-cycle process. With a common ALF framework established, organizations don't have to rely on a single vendor to provide an ALM integrated solution. Organizations can choose their favorite ALF-enabled ALM tools from source code control to software delivery and receive the benefits of interoperability without developing a highly customized solution. ALF will result in a substantial cost savings to organizations and a greatly improved development-to-release process.
The definition of the application life-cycle process is often misunderstood. ALM involves the coordination and orchestration of the entire development-to-release process including modeling, development, source code control, build control, testing, and deployment. Further, ALM involves the management of the artifacts created by each step in the process creating a fully repeatable and auditable development-to-release standard practice. ALM incorporates the entire process of moving developed code from inception to production execution.
To accomplish this ALM process, development teams and production control teams use a wide variety of tools that do not interoperate. Design teams and end users often use a variety of tools to track requirements, enhancements, and bug fixes. Development teams often control the source code and build process, regardless of a corporate-defined tool, creating a large number of scripts to support ad hoc and home grown "check-in and build" events. Quality assurance teams use their favorite testing tools, sending approvals back to developers who often create additional scripts to perform the production release. Production control teams attempt to monitor software assets and restrict production server access using security tools.
When it comes to managing the ALM process a system for connecting the dots from design to release is needed. However, without a common framework for communicating and sharing data, the dots remain unconnected and the underlying picture stays hidden from view. The result becomes an unmanaged, ALM process that cannot be controlled or measured for its success or failures.
To establish an ALM process that can be managed and measured teams must be able to communicate and share information using the tools that support their particular area of expertise. To accomplish this sharing, developers, change management administrators, and production control operators often find themselves creating point-to-point integrations in the form of ad hoc ALM scripts, which results in a process that is dependent on ad hoc scripts that cannot be managed or audited easily. Numerous potential scripts may be necessary to fully develop an application life-cycle process using point-to-point integration with diverse tool sets (see Figure 1).
The cost of developing point-to-point integrations among ALM tools is mostly hidden. In the same way that build scripts using open source languages appear to be free, but instead create additional cost and a reduction in developer productivity because of the time it takes to write, manage, and maintain build scripts, developing custom point-to-point integrations among ALM tools may appear to be a cost-free way to handle the problem but adds to the cost of maintaining the process. The reality is that the point-to-point integration efforts create a substantial hidden cost related to the unplanned development and maintenance of the point-to-point integrations. These integrations are difficult to maintain as vendors release new versions of their product, offering new features. These new versions may break the static custom ALM scripting, causing delays in design, development, build, and release.
Back to top