APPLICATION LIFECYCLE MANAGEMENT (ALM)
INDUSTRY TRENDS IN OPENSOURCE INTEROPERABILITY
Vice President-QA Services
ITFlux Technologies India Pvt.Ltd,
SEMINAR PAPER PRESENTATION AT
NATIONAL CONFERENCE ON FREE SOFTWARE-2008
November 15, 2008
Application Life Cycle Management or ALM signifies the extensive and end-to-end domain in the Information Technology Industry that concerns the
exhaustive spectrum of practices, processes and platforms involved in the making and maintenance of Software products and Production
environments. ALM challenges software service vendors as well as business users with enchantingly multifarious possibilities of methodologies and
products to organize knowledge and artifact flow from Design to Deployment of Software Applications.
ALM practices define a dynamic and complex Expenditure environment for the Industry whereas Software service providers as well as End-users are
directly or indirectly trying to optimize the Technology and Process costs involved in the making and ownership of sturdy and maintainable
applications by persistent exploration of better options.
Quiet obviously, Independent Software Vendors (ISV’s) are essentially competing for this expenditure space by architecting solutions that essentially
propose better time-to-market, better quality and better maintainability (and therefore better business continuity for the end-user) for the target
This paper primarily attempts to showcase the following:
• The tenuously overlapping component landscape suggested by ALM and challenges of establishing optimum ALM frameworks
• Portfolio positioning of some leading ISV vendors in the ALM space
Thereafter, this document tries to justify the proposition of an Interoperable framework for diverse ALM domain products from different creators,
to integrate easily and seamlessly for fast customization and configuration of the most appropriate ALM processes for each Project. For this, the
Eclipse-ALF project launched in 2006 is brought into perspective for the laudable Technology standards and Interoperability vision it established.
Lastly, I attempt to critically explore and invite discussion on the real ground of motives and actual beneficiaries of the Eclipse-ALF initiative; so as
to pose the tentative possibility of the same model being emulated better in line with ‘Open-Source’ ethos for a localized initiative for an open-
ended ALM framework; one that will signify a positive step towards more cost-effective ALM frameworks, that facilitate truly open-source quality
solutions for Mid-Size/Small Industry & E-Governance.
2. The ALM Landscape
Sub-domains or process domains in the ALM sphere may be generally classified as Requirement Modeling & Management, Project & Portfolio
management interfacing with the Developer environment, Quality Assurance, Build & Version/Release management and Post-Deployment
Each sub-domain itself demonstrates varied complexities & constituencies broadly dictated by the Product domain (Singular freezes like Web Portals
OR multiple Product version roll-outs), Technology architecture variances (AJAX, C/s, Conventional Three Tier, SOA) and the choice of
Developmental workflows (AGILE, XTREME Programming, Traditional).
A simplified abstraction of an ALM environment is depicted below:
Project Issue &
Requirements Modeling & Build, Version & Release
Assurance & Performance
Thus, while each ALM sub-domain leverages specific process patterns as well as platforms depending on the project specificities, the ALM
framework is also equally, all about the interdependencies established between different sub-domains.
ALM frameworks also tend to develop iteratively from a base constituency; by accommodating newer elements into each sub-domains depending on
the flux in challenges encountered and also tend to evolve to tighter (& more effective) integrated work-flows between the different sub-domains.
This is demonstrated as persistent efforts or wish lists towards any number of process scenarios like a few classic contexts cited hereafter:
• Tighter Integration and synchronization between Requirement matrix and Test bench (Inter-Domain)
• Better Convergence of Test Automation efforts at Black-Box & White-Box levels (Intra-Domain)
• Better Application Change management by aligning Requirement Change management with Version Control, Release management & Defect
• From disparate Build and Version management to Continuous Build Integration (Inter-domain & Intra-domain?)
Thus ALM evolution independent of a single integrated packaged solution from any single major ISV vendor (which by itself is of a cost that can be
borne only Fortune Enterprises or large Corporate, and rarely CAN they offer the exact & appropriate solution with all required elements of ALM, as
will be seen in the proceeding section) has to persistently address the issue of integrating diverse ALM components from different Open-Source or
The following schematic which resolves our earlier simplified description of Sub-domains into an elaborate array of elemental ALM areas evinces the
quantitative reality of Net Industry time being expended in the Selection, Research and Integration of diverse ALM sub-domains, process elements
3. ISV Positioning in ALM
An extensive discussion of Industry leading ISV’s ALM portfolios and historical evolution of their offerings is outside the scope of this document. Yet,
we will have a short look on two leading ISV’s, Rational-IBM (earlier Rational Software) & HP-Mercury (earlier Mercury Interactive) on their
competitive dispensations in the ALM space with respect to solution paradigms and ALM span covered.
• SDLC spanning solutions from UML based Solution Modeling to Delivery. (No generic Post-Deployment monitoring)
• Sound Integration between Rational rose (Modelling), RequisitePro (Requirement Management), Rational ClearQuest (Change & Issue
Management) and Rational ClearCase (Configuration Management).
• Lesser integration with the Test management and Functional Test automation portfolio components
• Business rule framework to establish the correct appropriate workflow, yet ALM customization will come at a Resource Cost additional to
the tool set.
• The most ‘SDLC-complete’ ALM vendor along with Borland
• NOT an SDLC spanning vendor, yet the Market leader in the ASQ (Automated Software Quality) Market since more than a decade.
• Till 2003, a purely QA solutions vendor with four sub-components with tight integration to each other: Test & Defect Management,
Functional Test Automation, Performance Testing, Post-Deployment monitoring
• Since then ramped up the ALM portfolio with acquisitions Left & Right
• Positions itself as BTO (Business Technology Optimization) vendor which provides comprehensive ALM along with Enterprise wide IT asset
management & Business-Services monitoring to Customers.
• Almost overwhelms the conventional ALM framework boundaries by establishing a strong quadrant of propositions that elevates all four
facets of ALM to unprecedented comprehensive Enterprise Contexts
• Costliest ALM vendor
• No Requirement Modeling or management component. Yet almost convincingly advances a strong product argument equating Test bench
management to Requirement management; especially relevant in recent AGILE TDD environments.
• Test Director is demonstrably the most superlative Test & Defect Management platform in the world, without any serious competitive
claims whatsoever. Again, Cost in the range of 20,000 US $ for 5-User license.
Borland and Compuware Corporation also have offerings which are modeled respectively on Rational and Mercury; i.e., Borland models on an SDLC
spanning paradigm, whereas Compuware attempts to (weakly though) emulate the HP-Mercury route of Enterprise wide Business Service Testing,
Portfolio &change management and Monitoring.
Serena Software, the champion of the Eclipse ALF project that will get under discussion in the next section, is also a major player recently in the
ALM space, but without effectively standardized components for many typical elements of the traditional ALM space like, Automated Test script
development & management. Yet another reason Serena is not being discussed is because, this paper is not, as mentioned before, an exhaustive ISV
vendor analysis in the ALM space. Lastly, but not the least, Serena also caters to the High Cost premium Fortune companies segment and as is the
case of the other mentioned companies, its end-to-end portfolio cannot easily be leveraged by smaller players. But it needs to be mentioned that
Serena’s portfolio of offerings and underlying Technology Architecture along with mode of offerings, has strong implications on the tentative
proposal for discussion, shaping up toward the end of this document.
The preceding discussions are to just explore the dominant Industry habits as established by the premium market consumers including Fortune 500
companies and to demonstrate the following facts:
• ALM solutions from established vendors are for a select few Enterprise consumers
• ALM solutions of even such major vendors are incomplete; the complete ALM solution is still an elusive and moving target.
• The reason is the variability of specific ALM constitution from Project to Project
• Both Software Service providers and Industry require more affordable (yet more extensible and flexible) ALM solutions
4. Inter-operable ALM Component Eco-System
Open Source granaries of diverse tools are to an extent addressing specific limited areas in the ALM requirements space in a vast number of vendor-
customer relationships in the IT biosphere. Software makers catering to small or medium customers rarely take the full plunge to maximize ALM
implementation because of the hectic effort involved in identifying, studying and integrating components to suit their specific ALM requirements.
Hence, being Open in the conservative sense is by itself not accelerating the adoption of these components into effective and advanced ALM
The Eclipse Application Lifecycle Framework (ALF) Project initiated in 2006 by the Eclipse foundation was a historic milestone in this direction
whereas, the vision inaugurated by the project was that, vendors and users could integrate each technology to a central framework according to a
well-defined collaboration model. In line with the earlier terminologies used, each Sub-domain element or component could publish their services
to a central framework according to a standardized WSDL based nomenclature.
Thus each vendor creates an ALF-enabling Web Service for its tool either as an integral part of the tool or, as a wrapper around the tool's existing
API. Each tool registers with ALF and reports the events that it can execute. It also registers the information payload that it will need if one of
these events is triggered and the information payload it will return having executed the event. Thus the very obvious XML/SOAP based exposition of
each of these components to an ideal SOA based framework will ensure that, the ALF can orchestrate event based business logic flows across
diverse Sub-domains to establish the appropriate ALM environment incorporating two or multiple components.
What conserves the Market-charm of the ALF framework is that each participant component can have a controlled exposition of its services, thanks
to a CORONA component model that publishes the services. Thus Eclipse ALF augurs in the vision of Inter-operability while conserving flexible
proprietary control for the respective component makers. But once published the ALF is in total command with respect to orchestrating business
flows between various components. And unexposed Functionalities can continue to pile up within the individual Product shells with a flexibility to
expose them selectively based on strategic Prizing models.
The One definite theme of the Eclipse ALF is the promise of converging diverse ALM product propositions to rapidly configure sleek and streamlined
ALM flows. Irrespective of whether the components are open source or not, tremendous inter-operability is realized and that augurs well for the
making and maintenance of Quality software.
5. A classic ALM scenario with diverse Inter-operable
It would be relevant to describe a classic ALM scenario that would be enacted in an inter-operable environment with the following discrete, but
services-exposed components (Events are shown in brackets and they are triggered by events in the preceding component):
1. Testopia- Test run is created manually with a set of White-Box Test cases against a target build and Execute Button clicked.
2. Junit – Unit Test Case Repository ( Corresponding Test scripts are activated and run against the target build. Specific set of Unit Test scripts
3. Project Issue Tracking System, say, ActiveCollab ( Issue ticketing work-flow is triggered automatically leading to assignment to respective
stakeholders in both Development & QA, based on script or module ownership )
4. Bugzilla Defect Management platform ( Defect Issues are opened, pointing to target build as a default and await escalation by respective
5. Developer attempts Debugging.
6. Re-runs Unit Test case
7. Test Passes
8. SVN (Fix Code is checked in manually by Project Manager after review).
9. Bugzilla (Defect is automatically closed and commented with Debugging notes captured from SVN)
10. Active Collab (Issue ticket is automatically closed)
The Scenario Diagram overleaf, depicts each of the events by the same numbering as mentioned above:
TESTOPIA JUNIT ACTIVECOLLAB
Test Management Test Script Harness Issue/Track Management
Test Run Creation, Execution Issue Opened to stakeholder/s
Run Result has failed scripts
And Result Reporting
6 Scripts provide
Test Run Re-Execution expected results Issue Closed
Code Review & 9
Commit by Project Manager Defect Closed with
Debugging by Developer Defect Opened Automatedly
Build/Version Management Defect Management
Figure Depicts the Event Flow and automated relationships discussed in the sample scenario
6. CRITICAL APPRAISAL OF THE ECLIPSE ALF PROJECT MODEL
The following facets of the Eclipse model needs to be accorded due attention and the overall model debated with respect to its nature of alignment
to the Free Software movement:
• The ECLIPSE ALF project is fundamentally an inter-operability between leading Industry vendors
• The beneficiaries are the Fortune Companies and Premier Corporates round the world who stand to save on their IT investments by
exploiting the extended flexibility of choice offered by Open systems.
• As far as the established ALM vendors are concerned, Inter-Operability only changes the necessary maneuvers of competition.
• It creates a ‘more Level Playing field’ for new ISV vendors, but still at an inaccessible height from the Budgetary limits of the Midsize and
• The ALF framework is not likely to nurture the creation of a ‘Poor Man’s ALM’ Ecosystem because of the very milieu it is steeped in; that of
Corporate valuation of products. In essence it is only like to enlarge a Vendor Cloud addressing the Heavy IT spenders of the world and earn
consequent valuations themselves from the Venture Capital market.
7. AGENDA FOR A TRULY OPEN SOURCE ALM FRAMEWORK
I propose certain points for further discussion over and above the technical and collaborative dimensions for ALM inter-operability attempted to be
elaborated in the paper.
• Open Source abundance of ALM tools in the Internet need to examined for the possibility of an alternative ALM framework modeled on the
• Localized Open Source Communitisation needs to be encouraged to pursue the build up a Framework based ALM Ecosystem with a dedicated
community of professionals, start-up companies, semi-governmental bodies, students and Technical talent in Kerala.
• The ALM framework as well as individual Sub-domain products should follow an incremental Build-Expose- Test- Freeze model that may be
governed by a loosely constituted body involving organizations like C-DIT and C-DAC
• The Project should be monetarily supported and sustained for a specific time period till the Eco-system itself pays back revenue to the
● My colleague Krishnanath V for sharing his rigorously honed developmental perspective of XML, Web Services & Continuous Build Integration
● To Anil and friends in OSS, Kochi, who facilitated this audience.
● 'Turning the Fragile into the Agile'-Kevin Parker's, (VP-Serena Software) Description Of the Eclipse ALF Project
● Artifacts of Serena Software with respect to ALF & CORONA
● Rational-IBM's Web Resources on RUP Implementation
The Author can be contacted at email@example.com