Clif Notes: Who Cares if MultiValue Survives?
Before we explore this question, let me get one thing out of the way — the obligatory New Year's resolution.
I will not write controversial column titles.
There. Done. And all in keeping with my tradition of starting the new year off with a burst of productivity by simultaneously making and breaking my New Year's resolution.
With that out of the way, let's return to the question. Who cares if MultiValue survives? I don't.
Oh my, I can already hear the scraping of sharpening stones on steel, the squawking of fowl, and smell the odor of tar being heated in the pots. I should hasten to explain myself before it becomes necessary for me to go on Amazon.com and place an order for large quantities of engine degreaser and burn ointment.
I started working with MultiValue around 1974. At that time, I was informed that it was probably not a good career choice to get too deeply involved with this product since it was "obviously" going to be completely obsolete and totally disappear by 1980. Of course, that didn't happen. It's lucky for me that I ignored such advice. MultiValue has not only provided me with a living for about 37 years, but just think of all of those International Spectrum Conferences, exhibits, technical sessions, dinners, parties, and hospitality suites I would have missed out on if I had thrown in with the COBOL programming and CODASYL crowd.
Then of course, there was the relational database and SQL movement. To say that this was phenomenally successful would be an understatement. As you would expect, the predictions of the imminent demise of MultiValue was rampant. If you were not fully relational and supported ANSI SQL as the primary data definition, manipulation, and query language, you were headed for the trash heap. Forget the fact that the Real World does not follow a precise mathematical model. When the only tool you have is a hammer, every problem begins to look suspiciously like a nail. If your application's data did not readily conform to the idea of tables and full normalization, change your application. If the resulting application did not support the unique way you do business, why just change the business. This bass-ackwards way of thinking, of course, led to the success of databases like Oracle and DB2.
It was also responsible for millions of dollars being spent on application redesign and platform conversions that in many cases failed and in some cases destroyed the companies attempting them.
"So how long is two years in your company?"
(For you relative newcomers, this is one of the ongoing jokes in the MultiValue community. Almost every time we hear of one of these attempts, it all started with an edict coming down that, "We are going to be off MultiValue in two years.")
And yet, MultiValue survives.
Of course, some MultiValue companies have gone out of business, some have merged, some have been acquired. You know, the normal evolutionary trends of businesses in a pseudo-free-market environment. And every time we see a change like this, a group of MultiValue munchkins starts marching around the message boards, newsgroups, and other areas on the Internet singing and chanting, "Ding, dong. The database is dead!" (Apologies to Wizard of Oz author L. Frank Baum.)
I'm still waiting.
And now, lo and behold, we have the NoSQL movement moving into prominence. They seem to have made a radical discovery — not all data is flat. Yes, I know, I know. The MultiValue community has been saying that for decades. And there seem to be a lot of people rather upset over that fact. Here is something that we have been preaching for almost 40 years, and along come these upstarts with their degrees and fancy ideas and terminology, restate one of our main points of view, and are starting to take portions of the application space by storm. And they are getting all the credit!
You know something? You can accomplish a lot in this world if you don't care who gets the credit. For those of us who are in the business of running businesses, we would much rather have continuing and larger revenue streams. And because our MultiValue technology is something that we have proven allows us to develop solutions to problems quickly, we should be able to do it at a lower cost. Higher revenues, lower costs… that smells like profit to me.
Of course, that is not going to happen in the current millennium with green-screen, isolated from the web, won't talk to anything else applications. I think MultiValue is well-positioned to allow us to start producing breakthrough applications that integrate well in a heterogeneous environment, talk all of the modern "mainstream" protocols, and deliver data in whatever format and on whatever platform customer demand dictates. But in order to do so, our current crop of MultiValue professionals need to upgrade their skills.
First, we need those skills to start producing these kinds of applications. Otherwise, the MultiValue systems already in place will continue to be viewed as obsolete dinosaurs to be kicked to the curb within two years.
Second, we need seasoned professionals who are fluent in the modern technologies to help train newcomers to MultiValue. You can't expect to attract, educate, and retain new, young, top-notch talent if nobody in the MultiValue group in your shop even knows that the keyboard has a Caps Lock key on it.
And third, who wants to keep doing the same old thing year after year, decade after decade? How boring. Change is one of the things that makes Life interesting.
So this year, how about learning a new programming language and how to use your platform's APIs from that language to access MultiValue data? Learn to use your platform's tools to produce and use web-services. Explore mobile platforms. Come to the International Spectrum Conference this April to find out all of the neat things that other MultiValue professionals are doing with the database and tools.
As for me, I can't see just doing what I've done for the last 37 years for the next 37 years. (No, I am not one of those people who sits around dreaming of retirement.) So one of my goals for 2012 is to continue to dive into these new technologies deeper than I have already. I want to assist companies with MultiValue applications drag them into the 21st century and continue to expand them to support whatever business environment evolves from new, exciting technologies and customer expectations.
So I recommend that the MultiValue community stop worrying about whether or not MultiValue will survive. Jump in, look to the future, and press ahead. If we concentrate on "Thrive," the "Survive" will take care of itself.
That is, unless the doomsday predictions for next December when the Mayan calendar expires turn out to be true. But then, it will be kind of a moot point. I don't put any stock in those predictions. But sometimes in the wee hours of the dark, your brain will randomly whisper, "What if?" What if it is true? What if I am one of the 500,000,000 to unfortunately survive?
Me and 499,999,999 singing munchkins. Now that is a nightmare.
