application lifecycle management for the enterprise

Transcription

1 application lifecycle management for the enterprise Serena s Approach to ALM 2.0 April 2007 Kelly A. Shaw, Ph.D.

2 Table of Contents Executive Summary...3 What is ALM?... 4 alm improves software project success rates... 4 Custom applications matter more than ever...5 Problems with ALM...5 Shortcomings of traditional alm tools... 6 attempts to remedy the problems of traditional alm tools...7 ALM 2.0 Addresses the Shortcomings of ALM Functional decomposition... 8 role-focused recomposition... 8 process-centric interoperability... 8 Vendor Approaches to ALM The Eclipse Application Lifecycle Framework Project... 9 Serena Mariner... 9 Serena Dimensions RM...10 Serena Dimensions CM Serena TeamTrack Serena's Approach to ALM

3 Executive Summary Application Lifecycle Management (ALM) is a collection of disciplines used to help organizations turn ideas into software in a cost-effective and predictable way. While ALM has been instrumental in making software development projects more successful over the past twelve years, statistics show there is still room for improvement. Current ALM tools are discipline-centric and have process, data, and role silos, which don t work well in today s application development organizations. Organizations, too, have functional, technological, and geographic silos. Better ALM practices and tools should help break down these silos and contribute to even more successful software projects. These ALM 2.0 tools should be role-focused, with functional components brought together in a process-centric interoperability framework. Serena s ALM products are already delivering on the promise of ALM 2.0, with organizations worldwide deploying and utilizing them successfully. Serena is also leading the efforts to create an open-source ALM interoperability framework through the Eclipse foundation.

4 What is ALM? Application Lifecycle Management (ALM) is neither a product nor a process. Instead, it is a way of doing business within application development. Or, according to Forrester analyst Carey Schwaber, ALM is the thread that ties the development lifecycle together. 1 From a technical point of view, ALM is a set of disciplines brought to bear on the application development process. ALM s goal is to help IT define the business needs and realize them in software in a cost-effective, predictable way that brings competitive advantages and cost savings to the organization. Modeling and Simulation Design Issue and Defect Mgt Construction Build Production Monitoring Change and Configuration Release Mgt Test and Verification PPM RM Reporting Traceability Policies Procedures Processes Collaboration Figure 1. ALM is a set of disciplines Figure 1 shows a subset of the ALM disciplines. Many of these disciplines, such as Build or Construction, are employed at discrete points within the application lifecycle. Others, such as Requirements Management and Project and Portfolio Management (PPM) span the entire lifecycle. Reporting, auditing, and collaboration capabilities support ALM by providing visibility across the lifecycle. ALM is important for two reasons. It has been instrumental in improving software project success rates over the past several years. Also, the custom software development projects that ALM supports are emerging as strategic assets that bring competitive advantage to the enterprise. ALM improves software project success rates The Standish Group recently surveyed development organizations, and what they found is encouraging. In the past 12 years software project success rates have doubled and outright failures have been cut by more than a third. 2 But while software project success rates have doubled up to 35 percent from 16 percent in percent of software development projects still fail to meet some cost, quality, or ROI objectives. And while software project failures are down to 19 percent from 31 percent in 1994, 3 still, a 19 percent failure rate is much too high. 1 Schwaber, Carey, et al. The Changing Face of Application Lifecycle Management Forrester Research, August 18, Rubenstein, David. Study: Less Chaos in Development Shops SD Times, February 12, Citing the 2006 Chaos Report from the Standish Group. 3 Rubenstein.

5 As Michael Azoff, an analyst with Butler Group says about the Standish Group Report, This period has seen a number of major changes in software development: open source software projects; the Agile development movement; and advances in tooling, notably Application Lifecycle Management (ALM) tools. 4 Given ALM s part in improving software project success rates in the past, further improvements to ALM and ALM tooling should continue to help boost success rates and reduce failure rates. Custom Applications matter more than ever Applications matter to businesses, now more than ever before. These days, a customer s first experience of a business is often through a website or other custom application rather than face-to-face or over the phone. Web applications are becoming more interactive, more collaborative, and more engaging, driving business to organizations that have invested in customer-facing applications. 5 To satisfy this demand for innovative applications, IT is increasing its spending. According to Forrester, in 2007, enterprise IT groups expect to spend 25 percent of their entire IT budgets on new software development projects. Overall IT spending on new projects is set to rise from 25 percent in 2006 to 33 percent in This increase in spending is about more than just financials. It says that spending money on custom application development is no longer merely a necessary evil. With custom application development now critically important to the business, development organzations must increase project success rates to well above the current 35 percent and drop failure rates far below 19 percent. ALM stakeholders must be able to work across functional, technical, and organizational silos. They need improved visibility and traceability across all the ALM disciplines, and also need to collaborate easily, regardless of role or geographic location. Unfortunately, most of the ALM tools available today don t meet these requirements. Problems with ALM Just when ALM is becoming a strategic necessity within IT, it is also becoming more difficult. Software development teams have always struggled to overcome communication problems among stakeholders involved in different ALM disciplines. Even when the entire development team worked behind the firewall, team members would misunderstand requirements, bypass processes, and make assumptions. Today, with offshoring and outsourcing so common within application development, the challenge of communicating across geographical, organizational, technical, and functional silos is further complicated by language and cultural silos. 7 Poor telecommunications, cultural differences, accents, and varying degrees of language ability can hamper communication and collaboration among distributed teams. 8 4 Azoff, Michael, Application Lifecycle Management Making a Difference. Enterprise Networks & Servers, Opinion Wire, February Rogowski, Ron, et al. The Business Case for Rich Internet Applications Forrester Research, March 12, Schwaber, Carey, et al. The State of Application Development in Enterprises and SMBs Forrester Research, February 22, Joseph Feiman. Concepts and Tools That Enable Globally Distributed Application Development October 6, Brian Nicholson and Erran Carmel. Offshore Software Sourcing by Small Firms: An Analysis of Risk, Trust and Control IS Perspectives & Challenges in the Context of Globalization, 2003.

6 ALM practices are evolving to make it easier for organizations to manage application development across all these silos. Unfortunately, they haven t fully risen to the challenge, and managing software change across these silos is not easy. Figure 2. Firms deal with software that spans silos but they don t find it easy to do so 9 Shortcomings of traditional ALM tools Most ALM vendor offerings tend to have silos of process within their disciplines. 10 For example, Build Management tools may have embedded processes to manage the build discipline, but most won t work with Test and Validation tools, despite the obvious potential benefits and synergy. Discipline-centric processes need to be choreographed into ALM-wide processes but aren t. Attempts to make the different disciplines work together have resulted in a set of fragile and expensive point-to-point integrations that never quite meet the needs of the practitioners. These integrations often break when one of the tools changes. Because they are difficult and expensive to upgrade, the integrations can t readily keep up with evolving business needs. And, because they are point-to-point, you need to create a lot of them: given n tools, you need on the order of n 2 integrations to tie them all together. With traditional ALM tools, traceability and reporting across disciplines is extremely difficult. For example, to report on the status of a software development project, you would at the very least need information from Project Management, Task Management, Test and Validation, and Requirements Management tools. However, since each tool has its own internal data, you would first need to consolidate and normalize the data, which, while not impossible, is certainly not easy. 9 The Challenges of Software Change Management in Today s Siloed IT Organizations, November 2006, a commissioned study conducted by Forrester Consulting on behalf of Serena Software. 10 Schwaber, Carey, et al. The Changing Face Of Application Lifecycle Management.

7 Furthermore, because current tooling focuses on disciplines rather than roles, any stakeholder whose job touches several disciplines must jump from tool to tool to get work done. For example, a developer working on a design task might need to access her Task Management system to get the task, then pull up a model of the new features from the Application Modeling system. She would also need to access information in the Requirements Management system. After all that, she would use her design tool of choice to create the design, and then drop back into the Task Management system to change the task status. This complex process offers little opportunity for automation or efficiency gains because each role requires different sets of tools and types of interaction. Also, as Schwaber points out, 11 in an attempt to get more market share, vendors often add features to their products that address adjacent disciplines. For example, a Test and Verification vendor might add some Issue and Defect Management features to its Test Management tool. These offerings often address only a small subset of the adjacent discipline to meet the needs of one or two roles. This causes confusion among ALM practitioners when they must decide which tool to use. Additionally, these add-on features often drive more integrations since data must be pulled from the system of record into the adjacent tool. Finally, vendor support for features outside of the vendor s core competency is often sketchy, or at the very least uneven. Attempts to remedy the problems OF traditional ALM tools Vendors have attempted to fix these problems with ALM tools by moving to a single repository or by suggesting practitioners move to a single vendor for all ALM tools. However, these approaches simply don t work. A single repository would provide better traceability and reportability across the lifecycle. However, because organizations develop software on multiple platforms with multiple teams spread across multiple locations on both sides of the firewall, actually achieving a single repository is highly unlikely. Additionally, a single repository would do nothing to address the problem of process choreography between disciplines. Moving to a single vendor isn t a viable solution either. Even if an organization were willing and able to spend the money and undergo the turmoil of ripping and replacing their ALM tooling, this approach wouldn t solve the problem because there is no single vendor who has everything. Furthermore, just because tools come from a single vendor doesn t guarantee the tools will be integrated, either through a repository or through process orchestration or choreography. ALM 2.0 addresses the shortcomings of ALM 1.0 ALM 2.0 products are emerging as a way to address the shortfalls of ALM. Schwaber calls out the guiding principles vendors are adopting to support the move to ALM 2.0: break down tools into functional fragments, allow a la carte re-composition that is role-focused, and bring the fragments together using a process-centric interoperability framework Schwaber, Carey, et al. The Changing Face of Application Lifecycle Management. 12 Schwaber, Carey, et al. The Changing Face of Application Lifecycle Management.

8 Functional decomposition Vendors need to divide up tools into capabilities that align along role boundaries. This will allow stakeholders to use only the capabilities they need. For example, an Issue and Defect Management system may be packaged as functional fragments for tracing, reporting, creating defects, changing defect status, sending notifications, and assigning ownership. It is unlikely that any single stakeholder will need all the capabilities provided by the tool, but the tool will address the needs of the discipline across all roles. Role-focused recomposition ALM 2.0 tools will allow stakeholders to piece together a virtual ALM product from the constituent elements of various ALM tools. For example, a developer may need only reporting from Requirements Management, but might need full traceability from Build Management, ownership from Issue and Defect Management, and the full set of library functions from Version Control. Process-centric interoperability Practitioners will access these virtual ALM tools through a process-centric framework that will provide a personalized, unified interface. In our previous example of the developer working on a design task, with ALM 2.0, she would be able to access her tasks, requirements, models, and design tools directly from her interface of choice, likely through her IDE. Other roles would use other interfaces such as portals or thick client applications. Vendor approaches to ALM 2.0 Figure 3 shows major vendors approaches to ALM 2.0. The first is the single vendor platform, in which vendors define their own ALM interoperability frameworks and expect practitioners and other vendors to build integrations to that platform. These frameworks force practitioners into vendor lock-in since moving to a different framework would require rewriting all integrations and redefining all processes. Vendor-proprietary interoperability frameworks may be good for the ALM vendor, but are not good for the ALM practitioner. Single Vendor Platform Multi Vendor Platform Single Repository Serena X X X Borland X CA Compuware X HP/Mercury IBM X Microsoft X X MKS X X Telelogic X Figure 3. Major vendors approaches to ALM The second approach is for vendors to build a complete set of ALM tools using a single repository to support traceability and cross-discipline reporting. As you can see from Figure 3, Serena is moving towards a single repository as part of its ALM 2.0 strategy. However, while important for traceability and cross-discipline reporting, a single repository doesn t help practitioners create role-focused and process-centric virtual ALM 13 Schwaber, Carey, et al. The Changing Face of Application Lifecycle Management Forrester Research, August 2006.

9 tools. A suite of tools built on a single repository simply doesn t solve the problems of interoperability. The only approach that makes sense for ALM practitioners is an interoperability framework that is open source, standards based, and supported by the ALM community. This is what Schwaber calls a multi-vendor platform because the framework is developed in an open-source community, and practitioners can help drive requirements, influence the direction of the framework and even participate in the development project. Also, because the framework is standards based, organizations aren t locked in to a single vendor. The Eclipse Application Lifecycle Framework Project Serena is leading the Eclipse Application Lifecycle Framework (ALF) Project to solve the challenge of interoperability. The goal of the ALF project is to develop an open and community-supported interoperability framework that is vendor neutral and platform independent. ALF is based on recognized industry standards such as WSDL, SOAP, and BPEL, not on vendor-proprietary standards. ALF is designed to allow processes to support 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 expensive point-to-point integrations. 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. The event manager allows you to define important events such as a requirement change, a source code stream update, or a defect closure. You can set up 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 your tool vendors release schedules. Serena Mariner The point of adopting ALM 2.0 is to improve the success rates of software development projects. That means not only building the software right, but also building the right software to get the highest business value from your application development resources. Do you know what 100 percent of your people doing with 100 percent of their time? Is each individual working on the highest-valued activities? How do you balance and manage all of the competing demands for IT resources? What are your applications costing to develop, enhance, and support? Surprisingly, many IT organizations can t answer these simple questions. As Schwaber points out 14, much of the value of ALM comes from interoperability with Project and Portfolio Management (PPM). With objective, actionable data, executives can maximize the business value of the application portfolio and focus more resources on innovation. 14 Schwaber, Carey, et al. The Changing Face of Application Lifecycle Management.

10 Figure 4. Serena Mariner helps you prioritize and manage the projects in your portfolio Serena Mariner provides insight into demands for IT work and helps executives make decisions about allocating time and money to get the most business value. Mariner also tracks resources, making it easy to know whether you have people with the skills and availability you need to complete your project. Mariner tracks the cost of project and maintenance work, and project schedules, status, and actuals so you know whether your project is on track. Mariner consolidates development process metrics (defects, requirements tested, requirements met) with project priority, schedule, resource, and cost data. With Serena Mariner you can know rather than guess the TCO of applications within your portfolio, and can answer the all-important question of whether projects are delivering the ROI necessary to make them worthwhile. Serena Dimensions RM Serena Dimensions unifies the software change lifecycle across distributed teams and platforms. In addition to allowing you to standardize development practices, its common repository integrates Requirements Management, Change and Configuration Management, Build Management, and Deployment for traceability and reporting across these disciplines. Serena Dimensions RM for Requirements Management allows you to control your requirements management process with flexible and enforceable standard definitions and comprehensive impact analysis. With Dimensions RM you get visibility and traceability throughout the application lifecycle with a simple and familiar browser-based interface. 10

11 Figure 5. Serena Dimensions RM lets you define your Requirements Management process Dimensions RM integrates with Serena Dimensions Composer. The requirements you identify in your model will automatically populate the Dimensions RM repository so you don t have to worry about error-prone and time-wasting copy/paste operations. When you specify requirements in Composer you effectively define them in Dimensions RM as well. Serena Dimensions CM Serena Dimensions CM is a comprehensive software change and configuration management tool. In addition to industry-leading configuration management capabilities, it also offers integrated task management so you can automate repeatability, predictability, and accountability. Dimensions CM incorporates a sophisticated dashboard that provides visibility into your development projects and tasks. The dashboard includes both high-level visibility and drill-down capabilities to show more project-oriented data. Figure 6. Serena Dimensions CM gives you visibility across the application lifecycle 11

12 Solid IDE integrations are vital for developer productivity within the context of ALM 2.0. Dimensions CM supports both version management and task management within VS.NET and the Eclipse IDE. Serena TeamTrack Serena TeamTrack synchronizes execution across platforms, silos, and teams, streamlining collaboration through the industry s most advanced and proven IT process management platform. TeamTrack easily spans the geographic, functional, and technological silos that make effective ALM so challenging. Figure 7. Serena TeamTrack helps you automate and manage your IT processes TeamTrack can be used throughout ALM to route application models through feedback and approval processes, and to provide process automation and visibility. Serena customers use TeamTrack for task management both inside and outside of application development, from QA to IT Operations. Additionally, in order to help customers achieve faster time-to-value, Serena offers pre-configured TeamTrack accelerators for IT Process Management. For example, an out-of-the-box Issue and Defect Management accelerator is available so you can track any problems with your applications. TeamTrack exposes a set of web services that will enable you to start building your ALM 2.0 role-focused and process-centric virtual ALM tools today. Serena s approach to ALM 2.0 ALM has been instrumental in helping application development organizations become more successful. However, it needs to do even more, especially now that custom software has become such a critical part 12

13 of an organization s competitive advantage. ALM 2.0 is evolving to meet the changing needs of application development organizations. Tools embodying the principles of ALM 2.0 provide web services so practitioners can pick and choose features on the basis of roles. These features can be brought together using a processcentric interoperability framework. Some vendors are building proprietary frameworks to facilitate interoperability. Others are moving to a single repository, planning to build out complete ALM feature sets. These approaches won t work. A proprietary framework subjects ALM practitioners to vendor lock-in. A single repository won t solve the problem since no vendor has all the tools, customers won t want to rip and replace, and the strategy doesn t address the role-focused and process-centric requirements of ALM 2.0. Serena Software has a full suite of ALM products that enable ALM 2.0, not just for IT, but for the entire enterprise. Additionally, Serena is leading the Eclipse ALF project to implement an open-source, vendorneutral and standards-based interoperability framework. With Serena and ALF, practitioners will be able to achieve the benefits of ALM 2.0, using the tools they already have in a framework that won t subject them to vendor lock-in. ABOUT SERENA Serena is the leader in Application Lifecycle Management for distributed and mainframe systems. More than 15,000 organizations around the world, including 96 of the Fortune 100, rely on Serena software to automate the application development process and effectively manage their IT portfolios. For more information on Serena software and services, visit: www. CONTACT Learn more about ALM for the enterprise by visiting index.aspx or contacting one of our sales representatives in your area. Serena Worldwide Headquarters Serena Software, Inc. Corporate Offices 2755 Campus Drive Third Floor San Mateo, California United States T F info@ Serena European Headquarters Serena Software Europe Ltd. Abbey View Everard Close St. Albans Hertfordshire AL1 2PS United Kingdom +44 (0) T +44 (0) F ukinfo@ Serena Asia Pacific Headquarters 360 Orchard Road #12-10 International Building Singapore T F apinfo@ Copyright 2007 Serena Software, Inc. All rights reserved. Serena is a registered trademark of Serena Software. All other product or company names are used for identification purposes only, and may be trademarks of their respective owners. Apr07