An interesting research piece on the 'application modernization' space was published this month by
Phil Murphy at Forrester. He discusses approaches that development organizations can take to in order to slash application maintenance costs. You are likely familiar with statistics that show 70% and more of budgets being devoted to ‘lights-on’ activities. Clearly, savings in the application maintenance world can have a big impact by redirecting resources toward higher-value activities, like application modernization. And also by demonstrating IT’s commitment to cost savings.
This particular piece takes an insightful and inclusive approach, referencing many previous research pieces for APM and application modernization. On that point alone, this is a worthwhile reference paper. But in addition, it has other aspects that are of interest. In particular, the document looks at how dependency mapping can help.
As applications have grown increasingly sophisticated the interrelationships between various artifacts has become more complex. One program may depend on inputs from dozens of other artifacts, and its outputs may have downstream consequences for dozens of other artifacts. So, enhancements or modernizations to one program can have often unintended repercussions on the rest of the application portfolio. This can disrupt business processes and can lengthen the time required to make enhancements as analysts must research their application portfolio in exhausting detail – often without documentation or subject matter expertise.
The paper makes an important suggestion: use dependency mapping technology to uncover interrelationships between artifacts. This allows users to quickly trace all relationships, provide a list of potential impacts, and correct these impacts before they have negative consequences. While the paper recommends run-time mapping, it is important to consider static analysis. Because static analysis relies on tracing all logical paths from a target element, you can be certain that even infrequently used paths are recognized as dependencies. Run-time analysis will only spot less commonly run (but often more important) processes (like quarterly finance roll-ups) as they are run – which may not be often.
Dependency mapping using static analysis also has other benefits, notably from an architectural perspective. First, let’s say we are interested in simplifying our architecture due to the complexity that stems from our globally distributed development organization. We begin by abstracting our software based on how it is managed. So, artifacts that are managed by the same team are grouped together. This abstraction layer provides a summary of the various interdependencies.
We can then immediately see that there are too many dependencies between the software managed by India and Ireland. From a practical perspective, this means that each time India makes a change it may need to contact Ireland to avoid unexpected impacts. This could lead us to rearchitect / modernize our application portfolio or reallocate assets so that we can minimize these cross-geography dependencies.
Labels: analysts, application maintenance
