When Microsoft released DOS 3.3, they added a much requested feature: background printing. That was the state of the art of cool back then: at the time, DOS was a single-process operating system, and users complained that they couldn't do anything else while waiting for something to print. Thus, Microsoft added the print spooler. But that opened a can of worms, because other software companies (like Borland) reversed engineered what it did and built applications around it. The way it worked was by chaining to a low-level interrupt in the underlying plumbing of the operating system. Borland exploited this to create a massively useful little utility called SideKick. SideKick was awesome. While working in an application, you could hit a hot key and pop up SideKick, make a calendar entry, browse the file system, and lots of other stuff. Then, with a hot key, you were back in your application. This was old-school multi-tasking: incredibly primitive, yes, but oh so useful. This category of tool was categorized as a TSR's (Terminate and Stay Resident) application.
Of course, you can imagine what happened next: everyone and their brother built TSR's. And if you weren't careful with your interrupt chaining, the whole house of cards came crashing down. This became an annoying issue in the dying days of DOS. Windows rescued us because it had an event driven architecture, and you could run multiple applications at the same time. Of course, Windows was really just running on the shaky DOS ground, but it allowed developers to take advantage of the event driven system automatically and stop fighting with other applications over interrupts.
The problem with the TSR approach was the fragile high coupling it required for the limited resource of operating system interrupts. We know now (and then) that highly coupled systems are fragile. Yet we seem to never learn that lesson.
Look at the state of most "enterprise" applications today. You think you have 5 different applications that share the same database. In reality, you have one massive application, partitioned at the application layer but still highly coupled once you get to the database. It's hard to make changes to the shared database without breaking (or at least looking hard) at the existing highly coupled applications. In hindsight, I think we're going to regret the way we've tended to use databases in large corporate environments. Part of the problem is the myth of a single source of knowledge throughout the enterprise. I've talked to a bunch of CIO's who say "I don't care what you do in the applications you build, but my database schemas are precious". This is a short-sighted view of how to build flexible architectures. Much of the work done now in SOA is the attempt to untangle this mess. How did we solve the problem with TSR's? Event driven operating systems. And how are we going to fix enterprise architectures? The same way! Just as Windows (built on the foundation of DOS) gave us a sane way to do multi-tasking, event driven architectures built on the foundation of our ridiculously coupled databases will make "enterprise architecture" more sane. Eventually, we'll make fundamental changes (just like Windows did when it added true premptive multi-tasking) to make things even better.
This is one of several places that Ruby on Rails nailed the right answer dead on. One of the obvious-in-hindsight decisions Rails encouraged/enforced was the "1 application, 1 database" style of application. If you need 2 applications to share knowledge, you do it with
ActiveResource and messaging between applications. Once you assume that style of application, so much gets easier. You can stop worrying about the nasty high coupling between application's data access and start thinking about what individual applications need to do.It's going to take a long time to fix this, though. While TSR's and DOS was a bit of a mess, it was a pretty small scale mess compared to what enterprise architecture looks like now. Given the fetishization of databases and the flawed assumptions that people apply to how to use them, it's going to take the rest of our lives to untangle this mess. There are movements afoot to rethink this within the database community (exemplified by books like Refactoring Databases by Scott Ambler and Pramod Sadalage. Just like with TSR's, we need to rethink Sidekick Oriented Architecture.
3 comments:
"In hindsight, I think we're going to regret the way we've tended to use databases in large corporate environments."
Yes, I think you're right. As a secure safe haven to share data across an enterprise most of the RDBMSs I've seen were utter failures. Their only external benefit was allowing adhoc queries and reports, and that was only if the schema was reasonable.
Data has become a prisoner of the application silo. But it's not little bits of data here and there that we need, it's the mining of grand unifications. Something that, at this current rate, is still hundreds of years away, I think.
Paul.
You are describing how I feel, but have never quite been able to articulate. In my current job, I'm surrounded by database fetishists, and before reading your post, I thought I was all alone. The parallel you draw with TSRs is brilliant. Thanks for the powerful analogy!
Wow, you just re-invigorated a couple neurons long dormant, reminding me that I once wrote TSRs -- several of them. This was about the same time I owned parachute pants. Funny how things seem to make sense at the time, and afterwards are obviously soooo wrong.
Post a Comment