Alm Opensource Seminar
- 1. APPLICATION LIFECYCLE MANAGEMENT (ALM) INDUSTRY TRENDS IN OPENSOURCE INTEROPERABILITY Sarath Chander, Vice President-QA Services ITFlux Technologies India Pvt.Ltd, www.itflux.com SEMINAR PAPER PRESENTATION AT NATIONAL CONFERENCE ON FREE SOFTWARE-2008 CUSAT, KOCHI November 15, 2008 1
- 2. 1. Introduction 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 applications. 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
- 3. 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 monitoring. 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 & Change Management Requirements Modeling & Build, Version & Release ALM WORKFLOWS Management Management Quality Assurance & Performance Monitoring 3
- 4. 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 management (Inter-Domain) • 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 Commercial vendors. 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 and components. 4
- 5. 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. RATIONAL –IBM • 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 HP –Mercury • 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. 5
- 6. 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 6
- 7. 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 engineering. 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. 7
- 8. 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. 8
- 9. 5. A classic ALM scenario with diverse Inter-operable components 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 fail). 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 stakeholders ) 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: 9
- 10. TESTOPIA JUNIT ACTIVECOLLAB Test Management Test Script Harness Issue/Track Management 1 3 2 Test Run Creation, Execution Issue Opened to stakeholder/s Run Result has failed scripts And Result Reporting 7 6 Scripts provide Test Run Re-Execution expected results Issue Closed 10 8 Code Review & 9 Commit by Project Manager Defect Closed with Debugging notes 5 4 Debugging by Developer Defect Opened Automatedly SVN BUGZILLA Build/Version Management Defect Management Figure Depicts the Event Flow and automated relationships discussed in the sample scenario 10
- 11. 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 Small/Tiny Industry. • 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. 11
- 12. 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 Eclipse Project • 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 initiative. 12
- 13. 8. ACKNOWLEDGEMENTS ACKNOWLEDGEMENTS: ● My colleague Krishnanath V for sharing his rigorously honed developmental perspective of XML, Web Services & Continuous Build Integration environments ● 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 sarath@itflux.com 13