The Cost of Doing Nothing

Hi,
I did think of something else to write about, after all.
It’s about my recent guest editorial in SD Times.
Reading this over, I wish it read a bit more clearly. The point is the huge expense IT departments face if the enterprise software industry doesn’t standardize.
The big irony of standardization efforts for enterprise software is that vendors tend to promote their involvement on behalf of the user, although the economic interests of vendors and users are not perfectly aligned.
Do we get enough out of the standardization process to meet the vendors’ interests? Is that enough to meet the users’ interests?
The major economic factor of course is software procurement, and enterprise buyers are showing signs they are getting ready to enforce change in buying behavior.
The acceptance of open source is a good indicator of the perceived shift in value for software, from something new and uniquely able to solve a problem toward commodity that can be multiple-sourced.

Even If it Kills Me

I’m going to get the new book to the publisher by Monday, I swear it!
I’m sorry I haven’t been keeping up very well with the blog recently. Or anything else for that matter. Getting through the final push on any big project can really take a lot out of you. My wife is ready to kill me — and probably will unless the book does it first.
Those of you who’ve done it know what a pain in the ass it is to write a book. It’s a little like having a baby — well, not really like having a baby — more like how you forget after the baby is born how hard it was. After the book is published and you see the first copy, you kind of forget how hard it was to write it.
(Publishers count on that, you know. They send you a copy of the cover so you can put it on the wall and keep thinking how great it looks.)
Anyway, there’s a lot to catch up on, including the Intel Software Strategy Summit and the dinner speech by Frank Abagnale, and responding to the recent comments. And I will get to it all soon, I promise.
Meanwhile, Rebecca Bergersen pointed out this article on UML from ACM Queue, and I thought I’d pass it along. I guess that’s really one of the big problems I have with UML, is that people think it’s good for everything.
Actually I think what the industry really needs is a code generator for PowerPoint. (I’m sure I’m not the first one to say that.)
Anyway, enough for now. Back to the book.

SQL is Dead

Last week while talking with Frank Martinez during the BEA show (and this is really one of the great things about my job, that I get a chance to meet and talk with interesting people like Frank), I started on a version of my mini-rant about SQL and GUIs being labor-draining anachronisms. Frank basically agreed, and that’s about all the encouragement I need to try to write it all down here ;-).
The point is that it just takes too much time and effort to design, develop, and adminster a database and associated GUI. Who can really afford to take on all the data modeling, normalization, and structuring work necessary to define a sensible database and usable GUI?
The benefits seem very small given the huge amount of effort. After all, most database applications just extract the variable data items from the static fields, figure out how to store them in the database, and then retrieve them so they can “rehydrate” them back into the GUIs from which they were extracted.
This all started when storage space was tight in the early days of business computing, when every byte counted and we (all) did things like store “82” instead of “1982” and measured program load sectors in 16K chunks (for example). Processing power was non-existent on the desktop, and even the servers were constrained. Data and its presentation needed to be managed carefully to maximize hardware and software capacity.
Today storage space is essentially free, and there’s an abundance of cheap and available processing power from the desktop to the mid tier to the back end. Why not just store the data along with its formatting information in an XML file and just render it when it needs to be displayed or interacted with? Just store everything — variable and static — in the XML documents and XML Forms and eliminate all that unnecessary database and GUI design and development labor.
Of course, SQL is really no more dead than CORBA, Java, or the mainframe — at least not yet.
But there is no longer any good reason to assume that structured data is the right solution for every data management problem. A large number of applications manipulate data intended for use by one person at a time. A database and GUI application is really overkill for that.
On the other hand, applications like airline reservations and buying concert tickets will probably always need structured data, since they rely upon the ability to accurately manage shared access to a single data item instance (i.e. the airplane or concert hall seat) so that it is sold only once and on a first come first served basis.
Applications like purchase order approval, medical records distribution, expense report filing, engineering and repair drawing distribution, safety inspections, and so on, really do not derive any benefit from the significant effort required to structure their data.
These are also the applications that are increasingly important to “mobilize,” and structured data is not the right approach, not just because of the excessive labor involved, but also because the database replication and synchronization problem is basically unsolvable over a WAN.
This isn’t to say that structured data isn’t important, but it is more important for field workers to have the ability to orchestrate the distribution of unstructured, personal content to the right individual at the right time, and SQL just can’t do the job.