IT Management

Truth or Consequences

6 Pages


Alternatively, if there is a migration strategy, such as moving from COBOL to Java, restructured code can be translated to Java and well-behaved component services into Java methods of Enterprise JavaBeans (EJB). Alternately, restructured code can be translated to other object-oriented code such as C++. In fact, restructured code eases the move to any other language or platform, and this is what we mean by future-proofing enterprise business logic.

The consequences of not following stages one and two correctly include an increase in the application’s environment complexity, potential increase in business logic redundancy with its corresponding business risks, and a vastly more difficult time understanding the resulting deployment environment. Correcting a coding problem could become a nightmare when logic is redundantly hard-coded in numerous programs. In fact, without having re-engineered legacy code into well-behaved components, it is highly unlikely that an attempt to move to an object-oriented language would even be possible.

Companies that have added APIs to existing applications without modernizing the underlying programming code are beginning to realize that their cleanup and restructuring avoidance are coming back to haunt them. It may be possible to delay taking the plunge and fixing legacy applications, but eventually that avoidance will catch up and surpass the cost of doing it right the first time.


Having followed stages one through three, reaping the maximum rewards for your efforts is achieved by managing your newly modernized, reusable code (see Figure 3). This includes:

  • Managing the life cycle of each reusable service from design through development, test, and production implementation
  • Registering newly modernized and discovered executables
  • Tracking correctly deployed reusable service versions
  • Understanding shared service usage across platforms from distributed servers to mainframes
  • Notifying interested subscribers of critical shared service details
  • Discovering what exists and can be reused.

As distributed applications add the power of Web services to their solution sets, knowing what application is executing what service with global visibility becomes a must. If we thought a client/server environment was complex, the agility of an SOA magnifies that complexity exponentially. The rewards are great, and so is the requirement for following standards and applying the right methods and techniques along with powerful, enabling tools.

The consequence of not putting a software asset management system in place is the loss of control that can lead to reduced reuse and increased maintenance costs. If reusable services cannot be found and easily reused, or their stability, proof of quality, and correct configuration management are not in place, the motivation and capacity to benefit from the legacy application modernization effort will not be realized.


Companies assess their IT software assets in the context of rapidly changing technologies. This requires new ways to manage business logic separately from the technology that provides access to that logic. The reward for restructuring correctly is that continuous modernization is easier. With the speed of technology changes, coupled with the growing requirement for intra-organization software collaboration, this is fast becoming a must for survival.

You can follow the right steps now to become more agile than your competitors and win more business. Additionally, you can future-proof your organization from technology changes. You can even improve your total cost of software ownership with your increased application quality. What you cannot do is achieve these benefits without doing the work the right way. Any other way is just putting Band-Aids on your current legacy applications.

Truth may seem an abstraction. The fact is that serious consequences will occur by ignoring legacy applications modernization. Z

6 Pages