Application Lifecycle Management (ALM) is the set of activities required to support application development from initial inception through deployment, support and system optimization. In most cases organizations support ALM through a heterogeneous set of tools, myriad distinct processes and one-off integrations used to pull together the tools and processes across the organization.

The goal of the ALF project is to solve this integration problem in a way that is vendor neutral and platform independent using recognized industry standards supporting loosely-coupled interactions between ALM tools.

ALF does this by introducing a services-oriented event manager to coordinate interactions between applications.  The event manager decouples ALM tools so organizations don’t need individual integrations between these tools. Instead, development organizations need only integrate the tools to the event management system, provide or use web services exposed by the tools, and use BPEL orchestrations to define integrations using loosely-coupled techniques.

Depending on your usage scenario, ALF can benefit you in several ways.

If you develop ALM tools…

You likely have customers or end-users requiring integrations between the software you publish and other tools within the ALM tool-scape. If you are an ISV, often these integrations are required just to be in a deal. Developing these integrations can be a huge resource sink, and keeping them up-to-day nearly impossible. Additionally, off-the-shelf integrations rarely meet customers’ or end-users’ needs, requiring yet more resources to customize these integrations. In the end you likely will have a slightly different integration for each customer, resulting in a support nightmare. Worse, when a problem occurs with the integration, you may find yourself in a finger-pointing face-ff with other vendors with your customers or end-users in the middle.

ALF can help.

Instead of building custom integrations between your software and other tools, integrate your tools with ALF. Then your customers or end-users can use ALF, together with a BPEL designer and engine available either through open source or from a software vendor, to define their integrations according to their own practices. You no longer will need to develop or maintain your own point-to-point integrations. Instead, you expose web services and raise events, enabling your customers do the rest.

Because ALF is based on recognized industry standards such as WSDL, SOAP and BPEL, when you integrate to ALF, you also integrate with other integration platforms available for a fee from middleware vendors. Additionally, if you develop your web services to conform to ALF vocabulary examples, you need not spend your own resources to define interoperability usage scenarios and interface formats. The ALF vocabularies will define them for you. All you need to do is expose the services, raise the events and point your customers or end-users at the ALF site for example BPEL orchestrations they can use to get started.

If you need to integrate your application lifecycle tools...

I’d guess that your organization has a jumble of ALM tools from different vendors running across many platforms. I’d also guess that you have either manual processes in place to transfer data between these tools, or you have a number of fragile, expensive and hard-to-maintain point-to-point integrations that implement automated copy-paste operations. I’d bet that you have end-users asking for more. They want integrations that don’t simply copy data from one tool to another. They want integrations that automate best practices and free staff from costly overhead of routing approvals, establishing traceability or otherwise managing minutiae that could and should be handled by process-based integrations. Finally, I’d bet that you simply don’t have the budget to build nor to maintain these integrations.

ALF can help.

Rather than building fragile and costly point-to-point integrations using vendor proprietary APIs that must be constantly updated, ALF provides you with a toolkit based on industry standards. The event manager allows you to define important events such as a requirement being modified, a source code stream being updated or a defect being closed. You can define a BPEL service flow to start when one of these events occurs, and using the richness of BPEL and web services provided by your tool vendors, you can define integrations that are easy to maintain, customized to your use cases and independent of the vagaries of your tool vendors’ release schedules.

If you are already familiar with the Eclipse Framework...

You probably already use Eclipse integrations in a number of ways. When you access source code control systems within the IDE, that is an integration. When you have a bugzilla view within the IDE, that is an integration. In fact, Eclipse plug-ins are all integrations in one form or another, communicating with the framework GUIs and metadata through defined interfaces. These integrations all have one thing in common: they require you to be running the Eclipse IDE.

However, not all integrations within ALM should or can be driven from the IDE. For example, you may want a check-in to result in a background task that performs continuous integration tasks. You may want a successful nightly build to kick off a series of automated tests that themselves automatically submit or close defects. You may want a new task created and routed to a developer when a requirement gets approved in a Requirements Management system. These integrations are best handled not through IDE integrations, but rather through server-side process-oriented integrations using events and orchestration engines to build integrations that encapsulate your organizations’ best practices.

That is ALF.

ALF isn’t an Eclipse plug-in, although there are features of ALF, such as the event management GUI, that are exposed through a plug-in. Instead, ALF is primarily a server-side event management system that associates important events within ALM (successful build, failed test, new requirement) with BPEL processes to automate and orchestrate tools within ALM. ALF complements the Eclipse plug-in framework by enabling server-side asynchronous and automated integrations. ALF is vendor-neutral, platform-independent and language unaware, depending on industry standards such as SOAP, WSDL and BPEL.

Like the Eclipse IDE, ALF is an extensible framework. The ALF project will define an example implementation for ALM integrations, to include the event management system and domain-specific vocabularies. The ALF community is free to extend ALF through a series of Service Provider Interfaces (SPIs) through which additional capabilities can be added to AFL. Additionally, the example vocabularies defined by ALF can be extended as necessary to meet the needs of ALM tool vendors or ALF users themselves.

So when you install ALF, don’t be surprised when asked to point to a SOAP server, a BPEL engine and an application server. Instead be pleased that you now have an open source integration framework developed with all the rigor, community input and respect for quality that comes with Eclipse sponsorship.