Bridging the business-IT divide

Application Lifecycle Management (ALM) helps invert the traditional view of IT as a cost centre and change it to a value generator. A new report by Butler Group, leading European independent IT research and advisory organisation, highlights the need for business to adopt an ALM approach to effectively monitor and control projects and to ensure business needs are met.

Senior research analyst Michael Azoff, who led the research for Butler Group''s report titled Application Lifecycle Management, explains in this article prepared exclusively for domain-b, how ALM tools can help deliver faster-to-market, high quality software products.

A cultural divide exists between business and IT, with business handing over requirements to IT with the next contact between the two being made only when delivery is expected. There is no involvement of the business with software development and no visibility into its activity — effectively a black box to business managers. Also, with no accepted body of knowledge in managing people developing software, managers often end up learning what works best the hard way. Used intelligently ALM tools and better people management can lead to that elusive project success.

Business Issues
There are two key process methodologies that help address the problems of low project success rates. The Software Engineering Institute''s (SEI) CMMI for Software provides a best practice characterisation of software development management processes, and also within the context of wider organisational management processes.

The earlier SEI standard, Software Capability Maturity Model (CMM-SW), now being phased out, was purely focused on managing software development but was also too document-centric — CMMI is leaner and also more specific about implementation. However, while CMMI can define the backbone activity processes for senior management, it is mainly descriptive rather than prescriptive — in-depth detail of how needs to be added. Agile software development (ASD) is a prescriptive methodology for developing software.

At the outset it should be clear that contrary to the historical origination of the Agile movement and its initial reaction against CMM, the two are compatible: Agile activity can be performed within a CMM environment. Higher levels of CMM achieve greater repeatability and predictability of projects, and also adaptability to changes in the business.

Change is the occurrence that best links the two: the Agile way thrives on a high rate of change in requirements and uncertainty in the project. These attributes are conditions that exist in the real world; the point of Agile is that it is good at meeting these challenges. A traditional ''waterfall'' software development methodology, where each stage is tightly controlled and in a linear progression, is more likely to fail under uncertainty than an Agile approach.

Technical Issues
The ''integrated development environment'' (IDE) is evolving, tool vendors are increasingly integrating their products to deliver suites. IDEs are giving way to tools that reach outside of pure coding and into the architectural, deployment, and management phases of an application''s lifecycle: ''application lifecycle management''(ALM). The hallmark of these suites is a common user interface, meta model, and process engine that also enable ALM team members to communicate using standards-based architectures and technologies such as ''unified modelling languages'' (UML).

The management of an application lifecycle as opposed to its development concerns much broader issues than that of project process and methodology. This is where the concept of ALM is so important.

Applications exist in the organisation in multiple cases: through custom development and enhancement projects, through purchased COTS products, subscription applications from service providers, modules or whole applications provided through outsourcing, and legacy applications. These are valuable IT assets, and ALM helps to manage them all, delivering business value.

ALM is being used as a means of inverting the traditional view of IT as a cost centre and changing it to one of value generator. The chief tools now available in ALM that can provide business intelligence on application delivery include ''project portfolio management'' (PPM), ''requirements management'' (RM), and ''application performance management'' (APM). The addition of these three activities to traditional lifecycle development provides a necessary and hitherto missing business perspective. Three key ALM disciplines are described next.

PPM plays a number of crucial roles in helping to manage application development and application usage as a business activity. Examples include the following:

• Rationalising the number of applications within an organisation, especially important where mergers and acquisitions have taken place, and providing a global view of application usage;
  
• Aligning IT with business needs and ensuring that projects in the pipeline meet business needs, ensuring that business cases are made for new applications to meet business needs, and prioritising projects in the pipeline that are urgent for business needs;
  
• Managing manpower resources to fit business needs;
  
• Running ''quality assurance'' (QA) software metrics on applications, and making cost benefit decisions on maintenance and support;
  
• Manage application delivery; and
  
• Provide ''business intelligence'' (BI) on application development through dashboards and analytics.

This list of capabilities makes PPM play a powerful overseeing role in ALM, and providing the key intermediate layer between business delivery and application management.

RM is another activity that is now firmly part of ALM. For too long requirements has been a paper-based exercise, and/or an activity that starts and ends at the beginning of a project. The fault in this approach is all too evident when people dig deeper to better understand application development and how to improve it. In RM the first step is to build a business case for a proposed application and gather the requirements. This process must identify all the stakeholders in the application; all too often an application is built and only then is it discovered that a class of user has been overlooked.

Modern RM tools keep the requirements traced to code development — this ensures that the correct application is being built. A key advantage of these tools is to keep requirements in a central repository, so that any change in requirements is instantly propagated to all the project team: crucially, developers and testers. Managing change is often where projects fall down: project schedules seldom cater for change, whereas in practice change is the norm not the exception.

Once the application is released the user experience needs to be fed back and RM provides that feedback mechanism. New releases therefore carry the changed requirements from the production environment, as advised by all the stakeholders. Finally, the increasing use of offshore development, with distributed teams separated by time zones, pose new challenges that Web-based requirements tools can meet, as well as assisting collaboration.

APM, together with ''software asset management'' (SAM), is perhaps the least recognised of ALM activities, but ones that can unlock huge value from IT assets. Application development may typically take six to 12 months, but for a mission-critical application its lifetime in deployment may last over a decade. Managing the application during that period is where APM and SAM step in. non-optimal performance in production seriously hampers business effectiveness and gives rise to a multitude of hidden costs.

The complexity of today''s IT environment means that monitoring and managing the hardware and network alone is no longer sufficient to facilitate the effective delivery of IT services. As a result, more and more organisations are utilising APM to drive application optimisation, more effectively align IT delivery to the strategic and tactical needs of the business, and increase cost efficiencies. In essence, APM gathers detailed information from inside applications and uses it to:

• Predict potential failures before these impact on users or the business.
  
• Provide rapid alerts when failures occur and isolate the root cause of these failures.
  
• Improve planning for system requirements.
  
• Speed-up the implementation and launch of new applications.

APM can also be used in the development and pilot testing stage to detect application defects related to performance and system load early in the application lifecycle, and prevent introduction of those defects into the production environment.

SAM is another hidden secret in ensuring value from applications. Monitoring which applications are actually used in the enterprise provides valuable information to better manage budgets. Managing licensing compliance, including renewal alerts and document storage, is important for contract legality and corporate regulatory reasons.

In addition to this broadening of ALM, the core development tools are also improving. Modelling has made significant strides forward with the establishment of the Model Driven Architecture (MDA) standard, which nearly all players in the market have adopted.

The exception is Microsoft, but it has embraced model driven development (MDD) through its ''software factory'' concept, and its equivalent to MDA''s ''unified modelling language'' (UML), the ''domain specific language''. The chief advantages of modelling are: improved communication, collaboration and knowledge transfer; improved productivity and reliability through automation; and improved development through separation of concerns.

Unlike historical modelling, MDA''s advanced technology allows real-time synchronisation between models and code, so that models do not become shelf-ware after initial construction, but are an ongoing source of information and roadmap for the project.

Role-based core development tools enhance the efficiency of developers, whether analysts, architects, programmers, testers, or managers. These tools make available the options necessary for the role and prevent the overload of menu options that plague functionally top-heavy tools. Additionally, top-end ALM suites provide workflow graphical tools that enhance information access and knowledge transfer.

Conclusion
Used correctly, ALM tools can help deliver faster-to-market, high quality software products. However, tools should not be used as a defence mechanism against dealing with difficult software development issues, otherwise the developers will bypass the tools and the same old problems will re-surface.

Rather, there needs to be a better understanding by business of the nature of software development and its practitioners, and vice versa, software developers need to understand the impact their solutions have on the business.

This comes down to communication as the key to bridging the cultural divide between IT and business. Used intelligently ALM tools and better people management can lead to that elusive project success.