Agile Requirements for Application Modernization: Part 1

Application software is the foundation of the modern enterprise. As business models adapt to new market opportunities, respond to competitive threats, and move to leverage distributed global resource pools, IT systems are continually stretched and re-tooled to support the business. Since application software embodies business logic, software systems must be modernized to support the business as it evolves. The evolution of business takes many forms including the introduction of new products and services, the on-ramping of global supply chain partners, the management of new government and risk compliance, and/or having to support other significant operational initiatives. In short, the logic of business software -- often referred to as "business processes" -- must continuously align as the business evolves.



The pressure to support this evolution in business is only one driver for application modernization projects. In today's economic environment, the efficiency of IT systems has become increasingly scrutinized. System obsolescence is a constant pressure point that initiates application modernization projects. Many IT systems continue to rely on legacy mainframe back-ends that absorb intense amounts of financial and human resources. New technologies and initiatives (such as service oriented architectures (SoA), virtualization and server consolidation) are pressuring IT to re-think application deployments in terms how they impact the bottom line.

IT system vendors have embraced this market opportunity with the introduction of application technology built to specifically assist with the modernization of business software, allowing them to leverage existing investments as they move to update and modernize systems that support the business. With new technologies for custom applications and next generation packaged software systems (from vendors such as SAP and Oracle,) IT teams are beginning to embrace new approaches to more fully leverage their existing capital investment.

Understanding Application Software Assets is the Beginning

Even with new technologies, the complexity of understanding the needs of the business, the upgrade options, and the implementation requirements for a new system demands a level of application-centric domain knowledge and business subject-matter-expertise beyond what has been required in the past.

As a control point, the clarity of project requirements for an application modernization initiative directly correlates to the cost and success of the project in general. To support the goal of implementing an efficient modernization-project that fully supports the needs of the end users, IT organizations are increasingly leveraging dedicated Business Analyst teams to assist in understanding what currently exists in legacy systems (from a business process level, a system level, and a functionality level) as well as the business demands of a modernized application. Business Analyst teams are tasked with the challenge of aligning stakeholders (which are often globally distributed) and documenting precise implementation requirements for IT resources. This requirements definition effort impacts many critical roles in the application lifecycle, including UI/UX design, quality assurance and user-acceptance testing, training and documentation, as well as project management.

Organizations Embrace SOA and Agile

Service Oriented Architecture (or SOA) allows the capabilities of large monolithic application software to be delivered as sets of services that can be modernized individually over time (and thereby simplified), and leveraged by a business process layer that insulates users from underlying changes in technology.

It's not only the software itself that needs to be simplified, but also the process by which it is created. Given the degree of change associated with application modernization projects and the uncertainties that surround most legacy applications, they tend to carry more risk than traditional projects. For this reason, traditional waterfall development lifecycles are not well suited for application modernization initiatives.

By contrast, the highly iterative nature of agile approaches tend to expose risk early allowing it to be addressed, possibly by making dramatic changes to plans, while minimizing the negative impacts. Modern agile development approaches are far more successful than they were just a decade ago, and now scale to larger and more complex projects. All of this makes agile approaches much more appropriate for modernization initiatives to reduce risk and improve time-to-market.

Business Analysis For Application Modernization

Nearly 70 percent of corporate business systems are legacy systems and represent an estimated $2 trillion worth of assets that are relatively inflexible to change. Existing platforms are the product of 40+ years of application development, use, re-use, and change. Through the churn of IT and business professionals over four decades, the understanding of the inner and inter-workings of these systems is muddled and disorganized. As part of the application modernization charter, organizations must create new value by moving away from what has been referred to as a "spaghetti" of multiple legacy applications and disjointed data processing systems. With a modernization project's ultimate goal of upgrading, enhancing, and streamlining existing systems and processes, business intelligence is a significant contributor to achieve this.

Part of gaining business intelligence is understanding the existing business processes embodied in legacy systems. This requires both technical analysis of the current application portfolio (i.e. including data, process flows, and interconnection points) and the understanding of complex interactions by the end users of the application. By overlaying business context on existing systems and users, business analyst teams gain an understanding of how legacy systems are structured from a business-process perspective.

At the highest level of abstraction, these context-rich business process definitions define the alignment of application functionality with the business strategies and goals of the organization.

Editor's note: Part two will be published on Thursday, August 20th.

About the Author

Matt is an experienced Marketing and Product Management executive with a strong background in corporate marketing, product marketing,, product management, and strategic alliances, with an international focus. Over a ten year period at Mercury Interactive (acquired by HP Software), he was responsible for product marketing for a $740MM product category including Mercury’s Quality Management and Performance Management products. In his early days at Mercury, Matt built and managed one of Mercury’s first pre-sales organizations in the Southeast United States. Prior to Mercury, Matt managed an IT development team at MCI Telecommunications, and started his career as a software engineer at Minolta QMS.

More by Matt Morgan