Eclipse ALF Automates the Life Cycle -- ADTmag

Eclipse ALF Automates the Life Cycle

ALF is a new concept in vendor cooperation, and any one ALM vendor doesn't have the best solution for all disciplines. See how ALF provides a new level of repeatability and transparency.

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.

Many Scripts
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.

In contrast, Eclipse ALF minimizes the need to develop highly customized ALM scripts. Instead, each ALM vendor creates an integration into ALF, allowing information to be passed easily among tools. For example, a requirements tool could pass requirement numbers to the source code control tool, which in turn passes the information to a build tool. When the build executes, a footprint is created showing which versions of the source code were used in the build along with the requirement numbers. The requirement numbers could also be passed to a testing tool, which could determine the modules needed to be tested based on the build footprint that exposes which modules were impacted by the requirement change. This level of traceability is long overdue in the distributed platform.

Through ALF, best of breed tools can be leveraged to create a process with rich functionality meeting the needs of the development teams and upper management, who are looking for a completely transparent and traceable process (see Figure 2).

Open Plug and Play
Without the framework provided by ALF, it is easy to see the potential cost of developing point-to-point ALM integrations for organizations. For this reason, some ALM vendors will argue that it is best to go with a single vendor ALM platform. In theory, this approach may seem reasonable. However, in actuality the use of a single vendor solution can be difficult to implement because diverse development teams establish their own internal best practices and may not be willing to switch to a new process.

If the tools development teams use meet the corporate standard and also integrate into ALF, the need for standardizing on a single vendor solution would be minimized. In addition, as new solutions for managing the ALM process become available, they can be plugged easily into the corporate-defined application process. With a single vendor solution, the organization is limited to only the tools offered by that particular vendor and no single vendor has a suite of tools that address the entire ALM process. Keeping an open plug-and-play process better supports a changing landscape, providing the ability to take advantage of new and important technologies.

ALF supports this plug-and-play technology through a common communication framework. Application life-cycle tools that support ALF communicate with the ALF framework through a Web service and SOAP transactions. ALF provides a common infrastructure using SOAP Web services, the Business Process Execution Language (BPEL) orchestration engine, and the ALF event manager. ALF vocabularies define the domain events, objects, and attributes. The ALF events deliver detailed application life-cycle information among tools such as why, who, what, where, and when an event occurred at any point in the life-cycle process. In this way, vendors can extend the functionality of their tools by simply querying other tools for information.

ALF transactions are defined based on what are called service flows. Members of the Eclipse Project such as Serena Software (project owner), IBM, Catalyst Systems, Secure Software, and AccuRev are contributing time to define common interactions among ALM tools. ALM specialists from these organizations are working together to define a common ALF vocabulary. This common vocabulary is a critical component of ALF and is used to define the ALF service flows. It is the common vocabularies and defined service flows that create the ability for diverse ALM solutions to interoperate.

In essence, ALF is allowing diverse tools to perform a level of data mapping among events, objects, and attributes. With a common language defined between tools, service flows can then be identified easily and defined clearly. When organizations attempt to write custom point-to-point integrations among ALM tools, it is the vocabulary and mapping of objects and attributes that is the most difficult to manage. The collaboration among ALF member organizations creates a common ground to openly define these vocabularies, based on domains (that is, testing, source code control, and build management), leading to well-thought-out ALF service flows.

To completely understand ALF, it is important to understand the concept of a service flow. An example of a service flow would be, "build to test with impact analysis." The way this service flow would be used is easiest to understand by demonstrating a common ALM question. For example, "based on the impact of the source code changes, what test cases should be flagged as critical for testing?"

In this example, the service flow would orchestrate the vocabulary between the build and testing tools. The build management tool would send a list of the impacted executables to the test tool. The test tool could then determine which test cases must be retested prior to production release based on the list of executables provided by the impact analysis generated through the build management tool. Communication among diverse ALM tools is coordinated through the ALF vocabularies and service flows, offering a highly integrated solution without requiring the end user to customize a single ALM homegrown script.

To Eclipse or Not to Eclipse
Seeing ALF in action will delight anyone who is involved with managing the application life-cycle process. A complete proof of concept can be viewed by visiting the Eclipse Web site (see Resources). The proof of concept demonstrates interoperability among source code control, build management, and security audits. Watching ALF in action shows what can be done when diverse tool vendors work together to create a better solution for their customers.

ALF is in the early stages of development, and there are some basic misunderstandings of ALF that can be clarified easily by reviewing the ALF architecture. The most common question comes from users who don't use the Eclipse IDE as a development platform. It is perceived that because ALF is an Eclipse Project, then it must require the user to be an Eclipse IDE customer. This perception is certainly not true. The Eclipse ALF component is not dependent on the Eclipse IDE, rich-client platform (RCP), or any other Eclipse Project. ALF will support the application life-cycle process regardless of what development tool is used.

The second misconception is that ALF is still years away from being completed. The reality is that the adoption rate of ALF will correlate directly with the demand for ALF. As end users begin to understand how ALF will directly benefit their organizations in terms of process improvement and cost savings, they will drive the ALF progress by requesting ALF-enabled tools.

In terms of overall ALM process management, there is currently a division in the types of tools available. Some vendors are selling the benefits of a single vendor solution, while others are seeing the benefits that an ALF-enabled suite can offer. Vendors selling a single solution are attempting to simply tie together their ALM product suites through scripting and APIs. Other vendors are beginning to enhance their product suite around a single repository, creating a single vendor solution that is similar to ALF.

The fact remains that there isn't a single vendor that can provide all of the software to support a complete application life-cycle process. This factor means that as ALF becomes more accepted by the end-user community, those vendors who are attempting to create a single vendor solution will be confronted by customers asking for new features and functions to add to the life-cycle process. ALF will provide the easiest method for end users to add new life-cycle products to their process, which will in turn drive the demand for an ALF solution.

ALF is a new and different concept in vendor cooperation for the benefit of the end user. It isn't being developed so that an open source solution can replace a commercial solution. Its purpose is to improve the end-user experience when working with diverse ALM solutions. From modeling, design, development, source code management, build management, security management, and deployment, ALF will help in connecting the dots from beginning to end and what may be needed in between. As more organizations adopt a corporate-defined ALM process, they will begin recognizing the need for ALF-enabled solutions.

There are many factors driving the need for organizations to adopt an ALM process including IT compliance and the Sarbanes-Oxley Act. Regardless of IT mandates, most organizations are attempting to standardize the software-development-to-release effort that requires that they demand accountability from their development teams. Many tools claim that they can make an organization's development process become IT or Sarbanes-Oxley compliant.

However, one tool alone cannot perform all the functions needed to meet strict IT compliance requirements such as transparency and separation of duties. A suite of tools is required, and not one ALM vendor has the best of breed solution in all disciplines. ALF will assist organizations who are working hard to best meet these new IT compliance guidelines while allowing developers to work within their own best practices with their chosen best of breed tools. Coordinating the ALF service flows among diverse tools will provide organizations with a new level of repeatability and transparency that has not yet been achieved.

To learn more about ALF visit the Eclipse Foundation's Web site here. Information about the ALF architecture, vocabularies, and service flows are available for review by anyone interested. You don't need to be an Eclipse member or ALF project participant to review the ALF design details.