December 17, 2004, 2:28 PM — "Prediction", Yogi Berra tells us, "is hard. Especially about the future."[1]
Enterprise IT budgets the world over stand up on a daily basis and pay homage to this linguistic Yogism. We all have an entry in our IT budgets for the Yogi factor. We call it 'maintenance'. What is maintenance? After all, IT applications are not like cars or lawnmowers. They do not require oil changes or spark plug replacements. Maintenance in this business is a euphemism for 'change'. Our needs change and consequently, our applications need to be, um, 'maintained', in order to meet our changed needs.
Maintenance is an expensive business. It can be argued that the expense is a fact of life. Business changes so rapidly these days. Technology moves on so rapidly these days. Isn't it just a fact of life that application maintenance is so expensive?
In many respects, yes. The volatility of business and the technology that supports it is not something any of us can control. However, there are some areas where I believe we are in control of our destinies. Areas where, with a little effort today, we can significantly impact the costs we will face tomorrow.
Take the area of compatibility between applications and data for example. Every programmer worth her salt worries about so called 'backward compatibility' - the ability to read yesterday's data with today's application. Backward compatibility is a very good thing as it can ensure that older applications can cohabitate with newer applications.
However, backward compatibility is only half of the story when it comes to predicting the future of change in our applications. The other half is the significantly less well-known concept of 'forward compatibility' - the ability to read today's data with yesterday's applications.
An example will help illustrate. Let us imagine you have an application that produces files on disk. Bill and Bob both have version 2 of that application installed. Bill and Bob create and share V2 files with each other.
Now, one bright spring morning, the future comes gambolling over the mountain top in the form of a sprightly new version 3 of the application. Bill installs the V3 application. Bob sticks with V2. All of Bill's 'old' V2 files load into the V3 application just fine. This is backward compatibility in action.
To illustrate forward compatibility, let's bring Bob back into the equation. Bob receives some new files from Bill. Do the V3 files from Bill open in Bob's V2 application? If they do, we have forward compatibility. If they do not, we do not have forward compatibility.
Today, applications that have provide backward compatibility are significantly more plentiful than applications that provide forward compatibility.
As per usual, a number of factors have conspired to get us into this situation. On one hand we have the technical issues. Adding support for forward compatibility is not easy. On the other hand, we have the commercial issues. Vendors have a keen interest in ensuring that customers can upgrade to the latest and greatest application. Moreover, if the Bobs of this world with their retro-application suites are incentivized to upgrade by an inability to work with new data files ... maybe that is good for business.
The technical issues around forward compatibility get rather technical but they are not insurmountable[2]. Awareness of the issues is much greater now than it used to be. There is no technical reason why developers cannot factor forward compatibility into their designs so that the Bobs and Bills of this world can continue to work together without keeping their application versions in lock-step.
The bigger issue is one of market forces. If enough customers insist on forward compatibility, it will find its way into the offerings of software vendors.
In the words of Peter Druker, "the best way to predict the future, is to create it"[3]. In this issue at least, our destiny is in our own hands.
[1] http://www.capnasty.org/taf/issue5/yogibera.htm
[2] http://www.xml.com/pub/a/2004/10/27/extend.html
[3] http://www.brainyquote.com/quotes/quotes/p/peterfdru131600.html
