The Keys to Defining Requirements for Application Modernization Projects

The Ocean Princess lumbers into port. After a one hour delay caused by glitches with the docking system, the passengers finally begin to disembark. At only three quarters' capacity it's another break-even cruise. The competitors have been steadily taking customers as the old liner simply can't keep pace with the new amenities quickly being introduced into the marketplace. Years of small enhancements and upgrades are beginning to take their toll. The ship is being asked to do things never imagined when originally designed.  With each new enhancement a new set of unexpected issues surface, seemingly bigger than the last time. The costs of operating the vessel and of doing these minor improvements to keep pace continue to rise, while at the same time revenues are falling. It seems the harder they try, the worse it gets. There comes a time when the incremental enhancements aren't enough. The liner needs a refit - to be ‘modernized'.

As with the old cruise ship, there are two main forces that drive software applications to be modernized. First is the continuous pressure on the application to change at the pace of the business. The ability for the application to deliver all that the business needs and to deliver it in a timely fashion. In other words, "agility" of the application. Over time due to a number of factors like design degradation due to successive enhancements and fixes, and loss of knowledge and (older) technical expertise due to staff turnover to name a couple, applications become less agile. The second factor is the cost associated with the application delivering its "services". This includes all costs associated with operations, maintenance, and the enhancements made along the way - everything to keep it doing what it does. When the application can no longer keep pace with the business and its service costs become prohibitive, the only sensible option is to modernize.
There are many requirements definition aspects that are unique to application modernization projects. Of all of them, I would focus in on two which I consider absolutely key. If you don't get these right your chances of success are severely limited.

Key #1 - (really, really) understand what you have

Applications are simply a reflection of the business over time. Presumably the only reason features were implemented were to respond to the needs of the business at one time or another. On a feature-by-feature basis IT gets it right about 55% of the time (according to the Standish report, 45% of delivered features are never used). Also you can expect over time that as the business changes that some features are no longer used and become dormant while new ones are introduced through enhancements. Multiplying this by several years or even decades of use and multiplying across all applications in the portfolio means an awful lot of bloated applications with a lot of functionality that's not being used. This can dramatically complicate one of the keys to success - understanding what you have. It essential to take the time needed and leverage every source of information available to gain an understanding of current functionality in use, and to identify those capabilities which are not being used. Of course it's not quite as binary as this - there will be a spectrum of existing functionality usage and hard decisions will need to made regarding what is to move forward, what can be consolidated, and what can be retired. One framework to help make these decisions is the TIME approach (Gartner) which considers Technical Integrity vs. Business Value delivered by the functionality. The point is that to shortcut this work and proceed without really understanding what you have is like - well, Russian roulette comes to mind.

Key #2 - understand what the business needs - then simplify, simplify

So getting on average 45% of the functionality in each application wrong is certainly one reason applications become overly complex. Another major reason is that the business processes the application was built to support tend to be over-complex. Often times for political or social reasons compromises are made with business processes. Where opportunities exist to harmonize and simplify, some groups feel they're different or have special needs and are entitled to a variation of the process. In other examples, some intent on ‘empire-building' expend lots of energy solely to ensure they can do it their way. This can be very costly to the business in many respects, some less visible than others such as business applications. Application modernization initiatives are one of the few chances to get it right. The biggest service you could do to the business is to be tenacious, to be ruthless, when simplifying and harmonizing the business processes as much as possible.

If you've done well on these two aspects you'll have a much better basis for defining requirements for the modernization initiative regardless of what flavor that takes - wrapping the application, porting it, swapping out for a packaged application, or any of the other modernization alternatives.

For more information be sure to download this latest whitepaper from Blueprint entitled "Agile Requirements for Application Modernization".

 

Back to the Future: Reverse Engineering Requirements

Many organizations today have systems that have no or very little documentation. Users and customers have relied on these legacy systems to provide a reliable means to work on vital information. And as the business changes, more of these systems are being asked to be leveraged in ways that were not designed when first implemented. Reverse engineering requirements can dramatically improve an organization's ability to maintain, upgrade, and integrate to its legacy production systems. But the time and cost to do a total system documentation tend to balance the potential benefits. Instead, an incremental reverse engineering approach has the advantages of a quicker return on investment, reduced risk, and more flexibility. Hence, you need to go back to document these systems to move current organizations into the future.

There are two basic approaches to reverse engineering requirements:

Total System Documentation

To fully document the entire system (data files, back-end processes, user interfaces, new platform, etc.) and then validate the requirements can be very expensive and time consuming. And the problem space gets even larger for decentralized systems. But this approach becomes necessary when "the code quality of the original system is so poor that it can't be reused or leveraged", as stated in Blueprint's Application Modernization webinar. Hence, the entire system needs to be documented so that it can be redeveloped. Although an expensive option, redevelopment has the advantage of using modern tools, platforms, languages, and methods. If you need to go down this path, then be aware of a pitfall. Managing requirements of both the existing legacy system and its continual changes is extremely difficult and feasible only if the system is small. Some functional changes cannot wait until the old system has been documented. Thus, modifications to the legacy system must be continually updated in the documentation. This requires significantly more resources (time, money, and personnel). If the legacy system is too large or too dynamic, the organization may not be able to afford the expense of parallel requirements definition.

Incremental Reverse Engineering Requirements

A key decision when planning incremental reverse engineering requirements is how to decompose the legacy system to its components. Most likely, the decomposition decisions will be based on a mixture of the below strategies. There are different ways to decompose a legacy system:

Physical Site
If you have decentralized systems, then this approach works well. For example, all systems at a given site will be documented first. Or documenting a re-hosted system will occur before any other requirements definition activity.

Functional or Business Need
Reverse engineer requirements of software components that are mission-critical to the organization. Once you have those critical components documented, and then identify all the components that contribute to it. And work your way out via a spider web from sub-components to sub-components as time and resources become available.

Interconnectivity
Obviously, stand-alone systems are easier to reverse engineer requirements than systems that are tightly interconnected. A pitfall to this approach is the lure to document noncritical systems and components. If a system is critical and stand-alone, then starting documentation here is a good idea.

Data and Business Rules
An organization's data and how it's manipulated is very important. Reverse engineering data requirements and business rules can help identify redundant data usage. For example, you may discover different business rules are manipulating the same piece of data in different ways.

Finally, reverse engineering requirements wouldn't be complete without a central repository, which will allow you to define, simulate and validate requirements for all your systems. If you need to do total system documentation, then a repository will help you gather the requirements of the system, but also help you maintain any parallel changes to the system that you are documenting. If you choose to do incremental definition, then a repository will help you store and manage the ever evolving requirements to your systems.