All Posts in Strategy and Tactics

|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

|In: Architecture|Last Updated:

Guess what’s now “best practice.”

A few years back it meant locking PCs down tight, preventing anyone outside IT from doing anything creative with information technology unless they could get it done with Excel.

“Shadow IT” … business departments implementing information technology without any IT involvement? An information security nightmare!

Nightmare? Look at the number of recent, massive data breaches whose targets have been … what shall we call the opposite of shadow IT … sunlit IT?

The actual evidence seems to show that shadow IT is, at worst, no less secure than sunlit IT.

The exact same cast of characters that advocated tight lockdown just a few years ago are now, without even a trace of contrition, writing favorably about how smart CIOs are supporting and leveraging shadow IT rather than trying to stamp it out.

Research current thinking on this and you’ll find the IT punditocracy has discovered IT has to handle some tasks more quickly than others. McKinsey, for example, calls it the “two-speed IT architecture.”

Welcome to the party, folks. You’re late. Did you at least bring some decent champagne?

To be fair: Just because these folks are latecomers, it doesn’t mean their insights are worthless. The McKinsey piece, while long on what the outcomes should look like and light on how to achieve them, is a fairly decent analysis.

Decent, that is, other than ignoring the significant role shadow IT will and should play in most two-speed IT architectures.

And, decent with this possible exception: “… companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.”

If, by “quicker,” McKinsey’s analysts mean reducing cycle times for fulfilling orders, then fair enough. While the notion that information technology can be helpful in reducing process cycle times is hardly a fresh one, it’s no less valid today than it was when first introduced in the mid-1970s or thereabouts.

But “quicker” might also mean implementing new strategies or responding to marketplace changes. If that’s what McKinsey means by “quicker,” it’s way off, because optimized processes are one of the biggest impediments to rapid change. That’s because optimized processes need supporting infrastructure, and infrastructure encourages stasis, with “infrastructure” including:

  • Business process design. As these things go, this is the easy one. Designing an efficient process just isn’t all that difficult compared to what it takes to implement one. Visio is the most adaptive component of process infrastructure.
  • Design of business process controls. Beyond the process itself are management practices and process metrics. Designing them isn’t all that hard. Designing them so they don’t do more harm by getting in the way than they provide in benefits? Trickier. A lot trickier.
  • Design and build-out of the physical plant needed to support the business process. This could be as trivial as setting up a new cube farm, or as complex and expensive as designing and building a factory. Ignoring all other aspects of this task, whatever gets built will have to last long enough to be relevant until the company has paid off the design and build-out costs.
  • Design (or selection), implementation, and integration of supporting information technology. Presumably, KJR’s audience knows a thing or three about this topic. To make sure it doesn’t get lost: The integration part is, in most situations, the most expensive and difficult technical dimension of the task.
  • Employee training. The need to train employees is obvious. That their education is part of your business infrastructure is less obvious.
  • Investment in continuous improvement cycles until process optimization has reached the point of diminishing returns. No matter what the new process, it’s the organizational equivalent of a skill. Skills take time, and money, and effort to acquire and perfect.

There’s one more factor to take into account to understand why investments in business infrastructure put the brakes on business agility, and that’s the project failure rate.In most companies, more projects fail than succeed. That being the case, once a company has a process and its supporting infrastructure up, running, and optimized, the fear that implementing its replacement will fail isn’t merely very real. It’s realistic.

And when the odds of success are low, it’s perfectly natural for a company’s decision-makers to take what looks like the safer bet — sticking with that has worked, even if, in the long run, the result will be an obsolete company that sells and delivers obsolete products and services.

Especially because, in so many cases, by the time it’s impossible to ignore their obsolescence, it will be someone else’s problem.

* * *

Next week: Shadow IT’s role in a two-speed business (not just IT) architecture.

Comments