11.03.09
Aging Software is Good
Corporate IT has some great terms like “legacy systems” to describe applications designed and developed in the “old days” of technology. If we look upon application systems like factory equipment, this idea of old is a strong consideration for “modernization”. How could anyone running a software application written in an older technology not want to bring it up to a modern technology?
Well, is it reasonable to compare application software with factory equipment? Factory equipment wears out and parts need to be replaced. Software does not show any wear and never needs parts replaced. Obviously, this is why it is called software rather than hardware. So, to answer the question, application software never actually wears out.
But, what about maintenance and support? As newer development languages come out isn’t it difficult to get support for the older languages? Although it may be more difficult to get support, it can almost always be found somewhere. But, what about the cost? Doesn’t the cost of maintenance go up for older development languages? Actually, the more expensive development is always with the new languages. With new languages there is usually a smaller pool of available resources.
Maybe the concept of modernization has nothing to do with the way the software was developed. Maybe the software simply does not deliver the functionality that is needed by the business. Well, this does not make any sense at all. The business operates every day just fine with the old software. If it did not provide the needed functionality the business would be out of business.
Alright, it does not wear out, maintenance can be provided, and it meets the business needs. Why modernize? Business management is told by Corporate IT that the older applications must be modernized to bring about agility in a changing business environment. They say there must be a movement away from silo applications where information is not shared and processes cannot be reused. These are lofty platitudes that imply a complete rewrite of the current applications.
Often, Corporate IT uses these lofty goals as a means of justifying major enhancements in the IT infrastructure. Enhancements may include things like message systems, service-oriented architecture control systems, and new development environments. Besides the cost of this new infrastructure, there is the cost associated with the IT staff and the users learning how to effectively use the new environment. And, there is of course, the cost of errors due to conditions not considered in the development of the new software.
Enterprise Architects follow the approach that silo applications are like fine wine. They get better with age. The software has been time-tested. Business conditions that the original developers overlooked have long since been corrected. These applications are good, they work, and they are a major asset of the business.
The Enterprise Architect realizes that all change must be driven by business needs. For example, if the business’s competition is offering faster response to service requests due to better applications, then change may be required to stay competitive. If the Enterprise Architect has organized the current IT artifacts as described in Enterprise Architects: Masters of the Unseen City, then it will be visually obvious where changes are needed. Usually, only parts of an application will need to be changed.
Taking this incremental approach will minimize the risk of change, the cost of change, and time required to implement. Over time, the entire application may get replaced component by component. There may even be a time when the cost of maintaining the older components is not cost-justified. At that time, the remaining components could be scheduled for upgrading.
Enterprise Architects do not use the terms “modernization” and “legacy”. They focus on business needs and the minimization of change to bring true business value.
