It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

I can’t help it.

Gartner has discovered the need for “Bimodal IT.”

What I can’t help: Pointing out that once again, Gartner has discovered something KJR’s subscribers (back then it was InfoWorld’s “IS Survival Guide”) read about a long time ago … in this case, 1996, when I wrote:

You can’t ignore the Web, and so, probably for the first time, you have to start thinking about serving your company’s RPCs (real paying customers). That will change everything.

Remember when you did feasibility studies, requirements analyses, external designs and internal designs before you got around to coding systems a few years later? Forget it. You’re going to start working in marketing time.

What’s marketing time? That’s how long your company takes to get new products, services, and pricing programs into the public awareness to beat your competition. Years? Forget it. You’re going to be working in months. Sometimes weeks. That means a whole different way of designing and building systems.

Well, better very, very late than never at all, and give Gartner credit for publicizing the concept.

So bimodal IT it is, and publishing precedence be damned.

What you care about is making bimodal IT happen. On that subject there’s a point neither Gartner nor I have explored: The challenge of culture.

Culture is loosely defined as “how we do things around here.” It’s a collection of informal, unwritten rules, enforced with iron discipline through the application of peer pressure.

IT started by automating a lot of the drudgery associated with core accounting. It had a batch-oriented culture which was fine: Accounting is a batch-oriented discipline. It had no tolerance for defects, which also was fine: Accounting balances the books to the penny.

Speed? Speed wasn’t all that important compared to making sure systems provided reports everyone could trust. And by the way, with punch-card-driven batch systems that provided accounting reports, there wasn’t a lot of opportunity for ambiguity when the question was whether a system did what it was supposed to do.

For the most part, the mental habits IT acquired in learning to support accounting are still valid … when it comes to supporting accounting and other “systems of record.” Even if the underlying systems rely on overnight batch processing, they’re supporting a discipline that considers the end of the month and end of the year to have mystical properties.

Okay, that was mean. A more charitable view is that unlike most other departments, Accounting cares enough about the accuracy of its numbers to verify them on a regular basis.

And this emphasis on accuracy reinforces the traditional slow-and-steady culture that pervades so many IT organizations.

Enter bimodal IT. Systems of record don’t go away, and continue to rely on this slow and steady way of viewing the world. But now, coexisting with slow and steady is a need for an entirely different IT culture — one obsessed with speed; one that recognizes when systems have reached the exalted state of good enough and whose members are happy to put good-enough into production.

It’s a culture where late is just as serious a defect as a calculation error, and where poor aesthetics (the marketing buzzword is “ugly”) gets as much attention as overall functionality.

Want to make bimodal IT happen? We can talk methodologies and architectures until we’re blue in the face (speaking of aesthetics) and when we’re done we can’t escape the need for two radically different IT cultures coexisting in the same organization.

The question is whether this is feasible or fantasy.

It’s a good question. For guidance, look at differing cultures in the business as a whole. The view isn’t promising: Accountants talk about the bureaucrats in HR, who sneer at the bean-counters in Accounting in return. Marketing complains about the propeller-heads in IT, who make snide comments about the marketing crazies in return.

And so on. In the business at large, different cultures clash.

How about inside IT? Still not so promising. Among sysadmins members of the Unix and Windows subcultures tend to disrespect each other. Elsewhere, IT operations staff have been known to gripe about developer teams trying to push buggy code into production, while the developers in question gripe about the bureaucracy of the change control board (CCB).

Think that’s bad? Just imagine the resentment of slow-and-steady Accounting developers. While they still have to deal with the CCB, the DevOps teams supporting Marketing practice continuous integration and get to bypass the CCB altogether.

That’s your dilemma. You have to foster two very different IT cultures. And you know before you start that they’ll almost inevitability clash.

* * *

What should you do about it? Great question. But it will have to wait until next week. With any luck I’ll come up with something between now and then.

It’s always more complicated than it looks.

Case in point: Houston

Your hypothetical challenge: Bring the city back on line. What does this entail?

Lots and lots of lots and lots, that’s what.

Understand, I know nothing at all about civil engineering, or emergency management, and not all that much about enterprise risk management. What I do know is that nobody else can keep the list of everything that has to come back on line in their head either, let alone the interdependencies that could lead to creating a proper Gantt chart.

Oh, by the way, a half hour of Googling failed to uncover anything resembling a disaster recovery plan for the city of Houston. An emergency management plan yes, a recovery plan no.

Which isn’t necessarily bad management. As with IT’s ancient habit of trying to create comprehensive software designs before beginning to write any code, so disaster recovery plans of metropolitan scale or larger for disasters of inordinate magnitude are probably pointless. If, that is, they do much more than list the organizations that need a recovery plan, specify what one should encompass, and insist they have them.

Even then there are limits. As everyone who’s involved in disaster recovery and business continuity knows, a plan that isn’t tested isn’t a plan.

And along came Harvey.

Case in point: New York City.

I worked with a client there several years ago, enough that a corporate apartment made more sense than staying in hotels. The result, though, was that for a couple of years I qualified as a resident, meaning I owed New York City taxes. These were (1) substantial, and (2) business expenses, not directly deductible from my Minnesota state tax bill.

This sawed me off. Until, that is, I saw a sign in the midtown Whole Foods that explained New York City creates enough garbage every day to fill the Empire State Building.

It occurred to me then that I had not the slightest idea how to go about removing that quantity of garbage every day, and that garbage removal is far from the most complicated challenge in running New York City.

As I had no idea how to run NYC I certainly had no idea how to run it at a lower cost, which meant I should put up and shut up. I benefited from services I didn’t even know were being provided. My New York City tax burden was how I paid for them.

Case in point: Any legacy retirement

Over and over again, companies make this mistake: They decide to retire the ancient mainframe batch COBOL system the whole company has been running on for forty years. And from this decision comes a logistical nightmare, because no matter how you go about it, you can’t shift the entire company from the old system to a replacement at the flip of a switch. It has to be phased and staged.

And no matter how you go about the planning it turns out many business areas will be running in a mixed environment for a year or more.

But unlike New York City or Houston, a lot of this complexity is a self-inflicted wound, the result of looking at exactly the wrong end of the horse.

The problem is the decision to retire the mainframe. Not that the company should stay on it. No the problem is that this focuses everyone’s attention on what they’re migrating from. In addition to the logistical migraines this thought process creates, it results in something even worse than the planning nightmare: When the project is done and the mainframe has been retired, the business runs pretty much the same as it ran before it invested the zillion or so direct dollars, plus sweat and opportunity costs, that were needed to make it all happen.

Much of which would have been avoided had everyone focused on the opposite question: What to migrate to.

Even better, they should be focused on how each business manager at every level wants to run his or her part of the business differently and better, leading to an applications portfolio plan that will mostly let them do so.

Taking this approach, things still aren’t simple. They are, however, simpler — a lot simpler, because (for example) moving Sales to a modern CRM system is, at a minimum, clear in what has to happen.

And moving Sales to a better sales process that’s possible because of the modern CRM system’s features has actual business benefit beyond a modest reduction in the IT operating budget.

Most IT managers started reading in the first grade. So far as I can tell, most stop shortly after they’re hired for their first full-time position.

I’m no longer surprised, but am chronically disappointed in the response when I ask members of IT leadership teams what they read to stay informed about industry developments. The usual response? Embarrassed shrugs, punctuated by acknowledgement that Gartner is their primary … make that sole source of strategic IT insights.

You’re reading this right now, which makes you an exception. On behalf of all of us who write and publish, thank you.

But if you’re in management and especially if you’re in IT management, reading is just the ante. It won’t win you the pot.

As a reader you’re aware that “Digital” has become a noun. As a regular KJR reader you know that, whether noun or adjective, Digital is about turning new technologies into new business capabilities and turning those new business capabilities into competitive advantage.

Presumably you read more than just KJR, familiarizing yourself with specific Digital technologies that seem especially promising for your company. That’s what prepares you for conversations about using them to increase marketshare, walletshare, and mindshare.

As a regular KJR reader you’re an IT leader no matter what your job title or official position on the organizational chart is. If you weren’t, your eyeballs would be elsewhere. And so, a reminder: The most important difference between a leader and an individual contributor is that individual contributors succeed. Leaders build organizations that succeed.

It might be my fault. I named this e-letter Keep the Joint Running to embody the principle that, as put forth in the KJR Manifesto, before you can be strategic you have to be competent.

Keeping the joint running is no small thing. That doesn’t mean it’s enough. It’s necessary, but it isn’t sufficient.

Reading isn’t just for management. Reading is the difference between a data warehousing team actively promoting hyperscale “schema on demand,” data-lake repositories and wondering why IT management brought in outside consultants to make them happen.

It’s the difference between developers embracing microservices architectures and saying, “This is no different from what we used to do with COBOL copylibs,” while IT management brings in outside consultants to develop new applications built on a microservices foundation.

It’s the difference between IT infrastructure management advocating replacing the company’s MPLS-based WAN with an ISP-centric connectivity model, and figuring they’re meeting their SLAs so it’s all good while the CIO brings in an IT services firm to make it happen.

So reading isn’t just important for management. It’s everyone’s tool for staying current and not slowly sliding into irrelevance.

It’s everyone’s tool, and as an IT leader it’s up to you to encourage every member of your organization to use it … to recognize that being knowledgeable matters. Maybe not quite as much as competence, but close.

What does this encouragement look like?

Here’s one possibility: With the rest of the IT leadership team, settle on a handful of promising Digital technologies and parcel out responsibility for turning “promising” into either “important” or “never mind.”

Then, each IT leadership team member involves their staff in the process. For small and medium-size IT organizations this might mean reserving two hours in everyone’s time budget for this purpose — one hour to read and one hour for discussion. The desired outcome: A briefing on the technology, that (1) defines and explains what it is; (2) lists and describes the new or enhanced business capabilities the technology might make possible; (3) assesses the technology’s maturity and market readiness; and (4) sketches an adoption roadmap that takes IT from incubation to integration.

And, by the way, once-and-done isn’t good enough. These briefs will be out of date as soon as they’re published, and new high-potential technologies are popping up all the time. Those who write the briefs are responsible for keeping them current.

Keeping track of Digital possibilities is a vital role for IT because the company’s org chart says it is. It is, that is, unless the CEO gave up on the CIO’s ability to provide this level of leadership and hired a chief digital officer to pick up the slack.

In our upcoming book, There’s No Such Thing as an IT Project, Dave Kaiser and I reserved a chapter to describe IT’s new role as business strategy leader. It’s a role that’s important for IT because a department that doesn’t know What’s Going On Out There is a department that neither receives or deserves respect from the rest of the business. It’s important for the rest of the business because …

Well if it isn’t, what’s all the fuss about Digital about?