data directions: Oh Great, Another Language
You know, there was a time in the not too distant past, when at Common or some other technical get together, we would spend hours fighting, err.. discussing the value points of the various languages we worried about--in this case RPG and Cobol with a little CL thrown in for good measure. The discussions were always intense with the Cobol guys usually losing, because, of course, they were outnumbered. And besides, who really wanted to type all that verbiage, when a simple F spec would do the job? Never mind that most of the business world had never heard of RPG!
Ahh.. for the simpler days. Well, no longer are the discussions about RPG or Cobol. Now they are about RPG and RPG for gosh sakes. Is RPG III or RPG IV better, faster, more productive. Meanwhile the rest of the industry is fighting the C, C++, Cobol (those guys get in the way all the time), Java, or Visual Basic battle. Of course, we all know that most of these discussions are more religious than practical. Yes there are things some languages are better at than others. But for the most part, we can do anything in any of them.
Now, just as I am beginning to reconcile myself to the fact that there are more languages than anyone should practically put on their resume (but they still put all of them, even if they only have a glancing view of the language), along comes UML. Universal Modeling Language.
Say what? You always have to question anything that starts with universal. That's like saying RPG is for Reports--ha! UML is a language designed to document applications, databases, and how they are put together. Many of the CASE and design tools today are using UML as the way to store their definitions. The ideas is that you can port the language definition to a generator tool to create business objects as well as develop the relationships with those objects.
Recently, there has been an effort underway to allow the language to be used to define business processes, even if there is no intention to push it into a generator. To be honest, it is tough to argue with something like this. We need a good language that can be portable across tools, and give us a consistent way to document systems.
The problem is that most shops just can't keep up with all this. I know of very few shops that use any tool at all, let alone one of this sophistication. It may bring huge payoffs in terms of programmer productivity as well as system reliability, but the cost of entry is high.
It seems to me, we are moving into a time where we have two things happening to our shops at the same time. Tools like Access, Excel, and VB are making it easier for the user departments to do things on their own. These tools are simple to use, learn and can do some pretty amazing things in the hands of the right people.
On the other hand, our full sized systems are getting much more complex, having to deal with more data, more differing types of data like images and BLOBs (not my early programs, but useful objects on the system). We also have to deal with data from more places, not just the database we are attached to. All of these are happening to us, while the users think they can run a $50 million company on Excel and Access.
I suspect that the fully home grown package is dying to be replaced with a hybrid of one or more selected packages, and a ton of enhancements to them to make them specific to our businesses. This is the only way we can keep up with the technology being shoved at us from all angles.
Some will keep a tight reign on the changes, but in today's environment, I suspect they will lose that battle and move on in the future. After all, that is where the future is. To those who can adopt, adapt, and be flexible enough to listen to what is happening out there and figure out the hype from the good stuff.
So maybe UML makes sense, although any language that has a class of objects called meta-metamodel, makes you want to step back and think for a while. Conceptually, having a language that helps us define our business is a great idea. The key of course, is taking the time to define our business, or at least starting with a model that is close and then adjusting it. If this sounds like someone buying a package, then modifying it to their needs, it does. But it is usually, cheaper and quicker than building from scratch. And it usually (not always) creates a more robust, product. So maybe, if I am an auto parts distributor, I can select that model, then adjust my business model to my needs. Of course that means hiring a consultant to help me, and then figuring out what to do with it afterward.
New concepts, new languages, I guess it is not bad, but I sure wish sometime the world would slow down and let me catch up. There is an old movie titled, "Stop the World I Want to Get Off". Maybe it's time to see it again.
John Bussert is president of Swift Technologies (Marengo, Ill.), a company specializing in AS/400 and Windows NT software. Jbussert@stecnet.com.