Regaining Control of Your Applications

Introduction

Your development team is under more pressure than ever.  You have fewer resources available to execute needed changes to your application portfolio.  Yet, the requests from business users are arriving at an accelerated rate.  As a result, your development queue continues to grow.  It is no longer a surprise that analysts estimate that 80% of IT budgets are dedicated to ‘lights-on’ activities and not on new development initiatives.

A major cause of this situation is the sheer complexity of the applications that you maintain.  They have been modified over the course of years or even decades.  They stretch across multiple languages and environments.  The original developers have generally moved on to other roles and the documentation that the team depends on is seldom current. 

As a result, it can be difficult for developers to know where changes must be made to their applications.  As well, they may struggle to ensure that their planned modifications do not destabilize the application portfolio.  This paper will summarize several options for overcoming the complexity of your applications and help you to rededicate resources to new and innovative projects.

Confronting Complexity through Insight

Complexity threatens to overwhelm analysts and developers, as they cannot fully understand their massive applications.  An effective approach is to document the systems.  However, documentation is rarely complete and is typically outdated by the time it is completed.  There are automated documentation tools that are commercially available.  The most comprehensive of these solutions provide solid tooling that addresses this complexity.

Detailed Technical Visualizations

Developers can understand their applications faster when have current, complete, and accurate documentation.  They are even more effective when they can navigate through the documentation to focus on just elements that are important to the task at hand – and abstract the complexity of the rest of the portfolio. 

This can mean visualizations that illustrate artifacts and their various interrelationships.  For instance, how data flows through a system.  Or, documentation may be useful to view from multiple perspectives.  This could be synchronized views of code, a tree view, diagrams, and other views that place the documentation into its proper context.  It could also be to allow you to navigate through documentation to locate which artifacts that must be changed for a given request.

Viewing applications from multiple perspectives provides more complete understanding for development team members.

Inventory Reports and Querying

A major challenge for confronting complexity is simply to know what you have in your portfolio.  After all, as these systems have been built and added to over many years, new elements are added and often untracked.  Analysis tools often will have the ability to list all elements in your portfolio.  More sophisticated tools will also point out orphaned elements that are referred to but not included in the analysis.  This helps to ensure completeness.

Analysis tools will sometimes include querying capabilities – including a library of queries and the ability to construct your own queries.  This helps eliminate complexity by allowing you to quickly locate artifacts that need to be changed.  For instance, this could be by finding all references to a particular variable.
 
 

Libraries of queries should be available to uncover elements of interest for development teams.

Impact Analysis

Developers must avoid unintended effects, as they can have a severe impact on application up-time.  But tracing how a proposed change will affect the rest of the application portfolio is no simple task.  Some analysis tools provide the ability to trace impacts.  Developers should ensure that this capability permits backward and forward analysis as well as the ability to summarize analysis just to end-points to avoid unnecessary information.

Business Documentation

Technical diagrams are useful for executing technical activities.  But when managers seek to understand how their operations are instantiated in an application, they must be able to view them from a higher level.  Development teams should look for tools that can provide business filters on their applications.  This could be from glossaries that link technical and business terms, or by uncovering and organizing business rules embedded in the applications, or by abstracting views on the application via concepts like business process, geography, etc. – providing a business perspective on technical documentation.

Visualize application code from the perspective of various business viewpoints, like business process, geography, or project.

Application Portfolio Management

A further way in which managers can overcome complexity is by focusing development effort on activities that matter most to the business.  This can be achieved by collecting technical and business metrics that identify where value, cost, and risk reside within the targeted applications.  Managers can then spot where inefficiencies and complexities exist, and they can prioritize development and modernization tasks accordingly.

 
Generate dashboards of business and technical metrics that help managers to monitor where complexities and opportunities for improvement exist.

Confronting Complexity by Renovating Applications

A complementary approach is to attack the root of the problem.  That is, by eliminating complex elements within application code.  In this section we’ll explore several options for doing so specifically by looking at complexities in COBOL code.  We chose COBOL because of its pervasiveness in large, mission-critical systems.

Remove Dead and Obsolete Code

Applications are living entities that are constantly in-flux.  As a result, there will often be large portions of the application portfolio that are no longer necessary.  This may be due to programming changes, for example when a branch of code is supplanted by another that is better suited for the purpose.  Or, it could be for business reasons, such as when a line of business is eliminated then the code that supported that line is now obsolete.  Maintaining this unnecessary code is wasteful.

Some analysis tools can uncover code that is unreferenced by other parts of the portfolio.  Because there are no logical paths to reach the code, it can be safely excised from the application.  Additionally, analysis tools may sometimes be used to assess the business logic of an application.  Through the business documentation described above, managers can quickly spot elements of the application portfolio that are no longer relevant for the business and can be eliminated.  

Consolidate Duplicate Code

A similar issue stems from multiple sets of code that perform the same function.  This could be a simple process, like a day of the week check.  Developers will often cut and paste these functions into their applications to reuse the capability.  Or, it could be a more sophisticated process like employee vacation management. 

Many companies, especially those that have been through mergers, likely have a significant amount of duplicate functionality.  This can be burdensome and complex as teams are forced to maintain multiple instances of the same set of code.  

Componentize Code for Reuse

Within your applications are business processes that have been proven over time.  This logic is often buried deep within existing code and tightly interwoven with other artifacts.  Your team would be more efficient and flexible if it could decouple this logic from the monolithic application.  Essentially this amounts to tracing the flow of a piece of logic through a system and isolating that logic into a standalone component.  Development teams will often do so to increase reuse and to make core functions accessible to external applications in a service-oriented fashion. 

Improve Alignment with Standards

Over time, the adherence of code to accepted internal and industry standards tends to erode.  This often occurs as pressures to respond to business demands mount.  While violations of standards may help a project to be executed faster, it can also lead to poor performing applications.  This can have a direct impact on the consumption of hardware resources, and lead to more complex and less maintainable code.

A simple example of a non-standard piece of COBOL code:

This could be changed to the following simpler construct.

Conclusion

To keep your applications maintainable, efficient, and adaptable you need to confront their inherent complexity.  Through insights into the application portfolio via automated and current documentation, visualizations, libraries of queries you can overcome this complexity and provide the users that need information with the right level of insight. 

You should also use this insight to uncover inefficiencies, non-standard code, and opportunities for reuse that can lead to more nimble architectures that are simpler to adapt.