Application Lifecycle Framework for Eclipse:
An Open Platform for Integration, Interoperability and Innovation in Application Lifecycle Management

By Kevin Parker, Vice President of Market Development, Serena Software

Application Lifecycle Management (ALM) enables business to transform requirements into reality. The ability to control and harness change is crucial in today’s dynamic business environment, where constant innovation is the price of sustainable competitive advantage--if not survival itself. This is not “just” an IT issue: it is a business issue. The flexibility of emerging architectures compels enterprises to unify their IT infrastructure as they compete in the global marketplace with the power and quality of their code.

It’s time to set ALM customers and vendors free

Businesses that purchase ALM products and the vendors that make them have now arrived at an inflection point that challenges the industry’s fundamental value proposition: ALM has become so complex, so expensive and so time-consuming that it threatens to create as many problems as it solves. For the good of its customers, it is time for the ALM vendor community, working together, to create the Application Lifecycle Framework (ALF)--a single, common, standards-based, vendor- and platform-neutral integration and interoperability platform for all ALM tools.

Just as application infrastructure helps to ensure interoperability among applications, ALF’s ALM infrastructure can help to ensure interoperability among the technologies used to create applications.

Based on the Eclipse Foundation’s open framework, the Application Lifecycle Framework will eliminate both the expensive instability now created by various vendors’ point-to-point integrations and the inflexibility of integrated end-to-end, one-vendor suites. For the first time, customers will have an uncompromised choice of ALM approaches. Users can select best-in-breed tools knowing that they will be fully interoperable with other tools, or they can standardize on ALM suites, or, more likely, on a combination of the two.

With its abstracted, single point of integration, ALF will give customers richer ALM benefits. Tools across the entire ALM spectrum will actually work together because they will be fully aware of one another, collaborating in richer, deeper ways to enable increased productivity through joint ownership of business processes, more strategic innovation and shorter time to market, while cutting the delays, costs and complexity now associated with installing, configuring and customizing a diverse set of ALM tools with equally diverse interfaces, standards and administration needs.

Today’s ALM landscape: something’s got to give

ALM functions as guide and protector as companies travel the tortuous path from the light bulb of a bright business idea to the securely functioning applications that make that idea a reality. But what a high price business pays for the benefits! In the absence of a common framework, even a “simple” array of 10 best-in-breed tools across the ALM spectrum requires 45 unique point-to-point integrations. When--pushed by customers seeking a competitive business edge from IT--any one of the 10 vendors comes up with something new, often all the integrations must be changed. This makes innovation far more difficult and expensive than it needs to be, and it certainly does not scale. Fearing this integration nightmare, some customers buy end-to-end ALM suites, which offer superior interoperability but inferior functionality. By unifying deep functionality with true interoperability, the Application Lifecycle Framework will liberate customers from today’s unpleasant choice among unattractive options.

A stable, open platform featuring one point of robust, universal integration will benefit customers by enabling ALM vendors to concentrate on improving their ALM solutions. When vendors improve their tools, customers will bring them online at times of their choosing, without worrying about today’s fragile necklace of interdependent, point-to-point integrations. Because they will manage only one lightweight integration framework, customers will also free up resources now used to handcraft the integration ALM vendors don’t provide.

Here’s the beef--a hypothetical alf use case

Here is an ALF use-case scenario in which an aware ALM network--a framework for tools provided by numerous vendors--automates business rules and processes that today are handled either by error-prone human intervention or by fragile filaments of point-to-point integration:

The IT department of Enterprise X is developing sophisticated applications for its end users. It has mature development processes with well-thought-out checks and balances built in designed to ensure delivery of quality software with predictability and reliability. One of those checks and balances is a business rule that no code can be developed and go into production unless it has an originating change request approved by Enterprise X’s Change Control Review Board. Against that background …

At the end of the lifecycle the Development Manager determines that it is time to kick off the “Production Build” by submitting a request into the Issue Management System (IMS), from vendor A. The IMS, which has an ALF Web Service, generates an event that is received by the ALF event manager.

Other tools have their own Web Services connected to ALF. Within ALF an “Event Service Flow” is defined that specifies how a given user’s ALM tools are to be orchestrated to implement the business rules of the user’s development practices and processes.

One of those tools is the Build and Release Management System (BRMS), from vendor B. In this user’s orchestration the BRMS ALF Web Service is executed next. It extracts some (or all) of the data provided by the IMS in the event payload and hands it the BRMS application. The BRMS needs to collect the components to be built, but they reside in the Software Change Management System (SCMS), from vendor C. The BRMS submits a new event, “Check-out Release,” to the ALF orchestration.

The SCMS Web Service is “listening” for this event and, again, using the payload data in the event, sends that data to the Software Change Management application to gather the components that make up the specified release. As it collects each component it needs to verify that the component changes have been signed off by the testers and the originating change requests are in an “approved” state. This information is held in the Request Management System (RMS). So the SCMS sends “Query Status” events through its ALF Web Service, which, in turn, delivers then to the RMS Web Service as the next tool in the orchestration.

The RMS’s Web Service accepts the event and passes the event on to the RMS application, which will return “Approved” for those components requested if the release is really ready to be released.

The SCMS monitors these returned values and, if all are “approved,” in turn delivers the code to the BRMS. The BRMS executes the build as originally requested.

When successfully completed a Security Scanning Application System (SSAS) runs on the build to detect issues. If this steps passes, the final phase is to run the Automated Test System (ATS). Each of these applications is orchestrated in the same manner and each has its own single integration to ALF as a Web Service.

What previously had been a complex manual task supported by islands of tools now becomes a fully automated, repeatable and traceable process that enforces the business rules the customer has defined in their mature development lifecycle.

Because open innovation is better

The biggest challenge in Application Lifecycle Management today--as in so many areas of business and IT--is integration. A recent Accenture survey of 1,200 global CIOs ranked integration as the No. 1 enterprise concern for 2005. But what is the meaning of “integration”? Some large vendors define “integration” as integrating everything into their products. The spirit of openness that underlies the Eclipse Foundation, however, defines “integration” as integrating things into one other. Customers, not vendors, should own their integration platforms, and control their software. The Eclipse Foundation’s pro-innovation, heterogeneous philosophy is the spirit in which ALF is being proposed.

The open-source, open-innovation nature of Eclipse provides the where, the who and the how of developing an Application Lifecycle Framework. The need for ALF is self-evident, but having one vendor undertake its development--even if one vendor had all the necessary resources, which is doubtful--would negate the benefit. ALF must be envisioned, created, launched, standardized and administered by the entire ALM ecosystem. Working together under the auspices of Eclipse, the best minds in the Application Lifecycle Management community, both vendors and customers, will create the Application Lifecycle Framework required to truly deliver on the industry’s promise.

About the author

Kevin Parker is vice president of Market Development at Serena Software. He has more than 25 years in the industry, nine of them with Serena. He is responsible for driving the Eclipse Application Lifecycle Framework (ALF) Project and for promoting the ecosystem with vendors and customers. In his leadership position he is directly involved in shaping and delivering the Serena vision. He was born and educated in the United Kingdom, where he acquired extensive development, consulting and management expertise. He is a sought-after speaker here and abroad and has been the key speaker at over 25 seminars and conferences this year so far, from Buenos Aires to Boston and from Houston to Helsinki.