ALM: thread to tie development lifecycle

BANGALORE, INDIA: The major challenges organizations face today are multiple tool sets, heterogeneity and complexity in the IT environment with difficulty in having a single interface to co-relate all problems in business impact terms. Among the challenges, management of IT infrastructure is prominent. According to IDC, in 2006, the overall infrastructure management software market in India stood at US $24 million and is likely to grow at a CAGR of 22.6 percent over the period 2006-2011, with leading players in the market being HP, IBM and Computer Associates.

"IT Services Management, Business Continuity and Disaster Recovery and Consolidation have emerged as the top three focus areas for enterprises across India ", says Praveen Sengar, Manager, Software & Services Research, IDC India.

Organizations have functional, technological, and geographic silos. Best practices and tools should help break down these silos and contribute to even more successful software projects. Application Life Cycle Management (ALM) comes as an effective tool for an IT manager and enables organizations turn ideas into software in a cost-effective and predictable way.

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."

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 ", says K.C.Yee, vice President of Serena software that claims to be leader in ALM for distributed and mainframe systems, " It helps realize business needs in software in a cost-effective, predictable way that brings competitive advantages and cost savings to the organization".

Figure ALM is a set of disciplines

Figure 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", says Keshav Prakash, Country manager, Serena Software, "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."

                                                                                                                            

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. But while software project success rates have doubled-up to 35 percent from 16 percent in 1994-65 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.

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."

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. 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 towards the end of 2007.

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 organizations 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. Poor telecommunications, cultural differences, accents, and varying degrees of language ability can hamper communication and collaboration among distributed teams.

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.

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.

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.