lesscode.org

Once again, I need to branch out into a new thread, for the benefit of bringing to everyone’s attention the importance of the legacy stuff. Here is what Kevin Smith wrote in response to my post Shared Data And Mobile Data:

Alex, I completely agree with you, but one big obstacle is legacy stuff: Legacy apps which already have data in rdbms’s. Legacy code. Legacy coding patterns. Legacy frameworks. Traditionally, exchanging data has been quite difficult.

True. I read somewhere that the data that was collected from the Moon back in the late sixties is unusuable today, because we lost the hardware that could replay them. Urban legend?

Beyond that, if you expose an rdbms today, people can immediately generate useful and productive reports from it. They can query it. With a custom app that is “willing to” exchange data, there’s a steeper curve for other apps, and unless you have pre-exposed all your data through published api’s, you’ll have to keep extending your code to meet the data exchange needs of other apps. So with today’s technologies and patterns, there are some immediate benefits of the “data is shared” model.

This is also true. However, since legacy systems are preponderantly bureaucratic, they should be viewed as such — they are huge bureucracies. And also, we should treat them as such and approach them as such.

What do we mean by that? Well, same as in real world, bureaucratic systems need to be approached prudently, or elase nothing ever gets done.

If I want to renew my passport, for example, there is presently no other way for me to do it but to approach the bureaucratic system that is called the Government Passport Office. And that system is very finicky (as most of you probably know first hand). So, it is quite clear to me that I need to play by their rules if I were to ever get a valid passport.

Now, in order for me to engage in a dialog with the Passport Office, I need to learn their lingo. In other words, I need to get all those forms, study them, make sure I go to the authorized photographer who will make me a kosher passport photo with a neat little dated stamp at the back. I also need to find me a judge, or a high school principal, or a university professor, etc., someone from those professions who claims to know me for more than 5 years. That person will be my guarantor. And on and on….

Once I’ve completed all my legwork, I submit my passport application to the office.

At no point during this process is the Passport Office going to open up its bowels and let me query its state. I can only engage in a conversation with it through a very tight protocol.

We must approach software legacy systems in the same fashion. Treat them as first class citizens (which they are), and learn their lingo. Not naively expect that we could put our diving suit on and jump in and start querying and interrogating the bowels of a first class citizen.

There is (or should be) a protocol specifying how we can talk to the first class citizens, or bureaucratic systems. If we learn how to compose the complex messages they expect us to give them, we can get exactly what we’re looking for from them.

I don’t see absolutely any need for us to assume that the information we’re looking to get from the bureaucratic systems is stored in an RDBMS. Consequently, SQL should not necessarily be our lingua franca when conversing with legacy systems.

Many developers are so immersed in rdbms’s that they don’t even realize that the concepts of data storage and data exchange are separable. I figure we’re at least a few years away from the point that your “data is mobile” idea is widely accepted in by mainstream (especially corporate) developers.

I’m not sure that I agree. I see a big push towards SOA, which is exactly what I’ve described above. The mainstream businesses have realized that only if they place their legacy systems in a role of being first class citizens do they have a chance to play in the 21st century economy.

Comment RSS - Both comments and pings are currently closed.