All Posts in Technology

|In: Career Management|Last Updated:

Consider the case of Ikea and the hexagonal socket-head screw.

In this case, the case is designing the database — the database containing the case of furniture held together by a particular hexagonal socket-head screw, and the case of all the socket-head screws used by a particular piece of furniture.

This calls for a “many-to-many relationship.” It’s something hierarchical DBMSs like IBM’s old IMS product can’t easily handle.

That’s one reason … and by the way, the least-interesting reason … I called IMS obsolete in last week’s KJR.

I shouldn’t have made reference to “batch mainframe COBOL systems,” when I did, though, because except in historical contexts, mainframe has no meaning. I should have left it at “batch systems.” Batch describes architecture. Mainframe COBOL merely describes lineage.

In any event, its inability to easily handle routine data design requirements does make IMS obsolete, although in an uninteresting way. As last week’s column emphasized, the lack of interest the best IT talent has in working on IMS systems is, the most important reason.

Most important, but not the most interesting (to your loyal author, at least).

What is most interesting is that it’s on the wrong side of an ongoing trend — the replacement of static relationships with dynamic ones.

This played out in DBMS-land when relational technology began to compete with CODASYL network-model DBMSs. Unlike hierarchical DBMSs, CODASYL DBMSs could handle all of the data design situations relational technology could handle.

But CODASYL DBMSs handled them with fixed relationships implemented through DBMS-managed pointer chains. Relational DBMSs handle them dynamically through SQL JOIN statements.

The next stage of DMBS evolution — the rise of NoSQL — continues the trend. Most of what you read about the subject would lead you to believe NoSQL’s ability to handle “big data” is what makes it interesting. Most of what you read is … what’s the word I’m looking for? … oh yes, “wrong.”

NoSQL is interesting because it replaces static relationships with dynamic ones too. In this case it replaces traditional data warehouses’ fixed OLAP schemas with “schema on demand.” That’s what makes Hadoop implementations so much quicker than traditional data warehouse projects.

And that makes Hadoop implementations much more like Agile methodologies, when contrasted with traditional data warehouse projects, which resemble traditional (and obsolete in parallel ways) waterfall methodologies, as data design (specifications) has to be completed before storing any data in the warehouse.

And by the way, the rise of Agile is another example of dynamicism supplanting fixed relationships, in this case replacing waterfall’s fixed-at-the-start specifications with Agile’s dynamically discovered just-in-time ones.

Abandoning fixed relationships in favor of dynamically defined ones applies to application development tools, too.

Back in the days of batch mainframes, the notion of coding logic into callable subroutines was something renegade FORTRAN monks preached into the deaf ears of the COBOL priesthood. When several different COBOL programs needed the same business logic, this was accomplished through the use of (I’m not making this up!) the COPY verb, which literally copied source code from a library into the target program.

Any change to business logic meant recompiling all programs that used the copy code — compile-time binding, unlike FORTRAN and more modern object-oriented technologies that bind logic contained in callable subroutines or objects during the linking process … link-time binding.

More modern, that is, but not modern, because modern computer languages dispense with all of that. Binding, such as it is, happens dynamically at run time.

Add Wifi to the list. It replaces fixed location-based relationships (cables run to offices and cubicles) with dynamic ones (wherever the computer happens to be within a facility). Add VPN or Cloud and things become even more dynamic — “anywhere” replaces “within a facility.”

And then … here’s the punch line. It isn’t about technology at all. It’s about the relationship between companies and their workforces.

Following World War II, the relationship between employees and their employers was mostly fixed, from the day they entered the workforce until retirement.

This relationship became temporary a long time ago, and we’re rapidly entering an age in which it’s becoming purely dynamic — independent workers engaged on a contractual basis.

Not only is this basic relationship becoming dynamic, but increasingly, even team memberships come and go, as who reports to whom gives way to who does what best.

The driving force is the same as with the technological trend, too: increased flexibility.

Is this good or bad? It doesn’t really matter. Lamenting the passing of fixed employee/employer relationships is about as productive as lamenting the passing of the hierarchical DBMS. You can argue the virtues of either one all you like.

It won’t change a thing.

Comments

|In: Architecture|Last Updated:

While waiting in some line or other I noticed the young lady in front of me was reading a book about Watergate. She told me she was reading it for her history class. Her history is my current events. Ouch!

“Current” means different things to different people, which brings us to last week’s topic, the value of keeping your technology current.

Take IMS as an example. For those of you who also think Watergate is a historical subject (no, not “an” historical subject) IMS is an IBM product — a hierarchical DBMS, an technology that became obsolete with the advent of codacyl DBMSs, which in their turn became obsolete when relational DBMSs became available.

What’s good about IMS is that IBM still supports it. What’s better is that if you’re a DBA who knows IMS there are probably more jobs to be had than there is competition for them.

Here’s what’s bad: It’s hopelessly obsolete. Worse is that the only IT professionals willing to take those open jobs are either well on their way to geeze-land (like me) or don’t have enough on the ball to go after positions that will let them work on hot technologies like NoSQL, let alone mainstream SQL-oriented positions.

Worst news of all: If you’re the CIO or CTO of an organization that relies on IMS, you will never be able to make a financial case for converting to something modern.

Because there is no financial case for it. By now, your company’s investment in IMS is somewhere between formidable and incalculable. The cost of recreating the same functionality in a modern DBMS would be enormous.

After which the company would run exactly as it did before the conversion, only with that much less money available for other purposes.

The dots you’ll have to connect to associate the conversion with more revenue or less operating cost … the definition of “financial case” in most companies … are numerous enough that few business executives would sit still through your explanation, let alone buy it.

The problem is that most companies big enough and old enough to rely on IMS consider “business case” and “financial case” to be synonyms.

Most companies big and old enough to rely on IMS focus on financial engineering, not competitive advantage. If the CEO and board’s goal isn’t to sell more products and services to more customers, they won’t understand the business case for jettisoning obsolete technology.

Many IT professionals don’t either, because “obsolete” is an imprecise term at best.

In business terms, obsolescence is risk. That there will come a time when you’ll find yourself luring codgers out of retirement, or else have to settle for third-rate employees who can’t find any other employment … that’s a risk. A big risk.

There are others. Plenty of businesses still haven’t migrated from Windows XP, because it does everything the business needs, so what’s the problem? Again it’s risk:

  • Their anti-malware vendor will, at some point, drop support for XP. They’ll still need malware protection when that happens, and self-paced conversions are better than fire drills.
  • Computers wear out. Will Windows XP run on new hardware? At some point, no, and mixed environments are more expensive than homogeneous ones.
  • Printers wear out too. Will new ones have XP drivers? Many don’t right now.

But perhaps the biggest risk is the Stockholm Syndrome — the tendency of hostages to end up sympathizing with their captors. In the context of IT, it takes the form of accepting as normal the limitations obsolete technology imposes on business processes and practices.

You’re now a retailer, relying on batch mainframe COBOL systems. They are, everyone agrees, superior because they’re awesomely reliable and eat transactions just as fast as you can pump them in.

Nobody notices that while transactions are masticated and ingested in real time, they aren’t digested until 1 am, when the batch processes that post them are launched.

Because of the Stockholm Syndrome, it seems perfectly normal your company can’t ship orders until the next day. The delay is minor. Customers won’t care.

And when it turns out you have less in stock than you have orders, well that’s why IT developed a subsystem to inform soon-to-be-former customers their orders are now backorders, but don’t worry — backorders take precedence over new orders for the same item, whenever the shipment happens to show up.

Even if someone does realize batch COBOL’s limitations will kill the company, it doesn’t matter. There’s no money to fund a conversion to a more modern system. The board spent it all buying back stock to improve earnings per share. That’s much more important than winning and retaining customers.

Isn’t it?

Comments