Organizational Design – Page 12 – IS Survivor Publishing

Trimodal IT: 50% better than bimodal IT?

In one of the more satisfying bits of recent sociological research, Michael Kasumovic and Jeffrey Kuznekoff discovered a correlation between poor performance and abusive behavior toward women in on-line gaming.

It’s tempting to extrapolate to the workplace. It’s even more tempting to use “Speaking of losers,” as my transition to continuing last week’s look at Gartner’s bimodal IT model.

It’s tempting, but unfair. Just because Gartner showed up 15 years after the party began doesn’t mean it’s missed the boat. After all, for many in our industry there is no boat until Gartner floats one.

Anyway …

To its credit Gartner has (finally) recognized the need for what it calls “bimodal IT.” But it hasn’t explored a challenging, near-inevitable consequence of establishing two radically different working styles — dueling cultures. The fast one will inevitably look like the CIO’s favorite son while those relegated to supporting the company’s systems of record will feel like red-headed stepchildren.

I’m not the only one concerned about the consequences of bimodal IT. In a Comment, long-time correspondent Stephen Bounds pointed to a piece by Simon Wardley (very perceptive writer; recommended) that’s highly critical of the whole bimodal approach.

Wardley’s concern is that two modes aren’t enough. He proposes three: Pioneers (Gartner’s high-speed branch), Town Planners (Gartner’s slow-speed branch), and an intermediate mode he calls “Settlers” that industrializes the work of the Pioneers.

If IT is limited to Pioneers and Town Planners, Wardley argues, you’ll end up accumulating a bunch of functional but poorly constructed junk that, over a span of perhaps five years, will turn into “spaghetti junction.”

The Settler role is reminiscent of a process proposed in this space back in 2002 — the Access Tangle Replacement Methodology (ATRM). ATRM applies an architectural perspective to the collection of point solutions shadow IT and other Pioneering groups put together, using them to define the aggregate requirements for a more broadly-based architecturally sound environment.

But in modern businesses, Settlers aren’t needed to clean up the messily constructed systems created by IT’s fast-mode Pioneers, because IT’s Pioneers don’t build poorly constructed systems. Modern IT’s fast mode uses some form of DevOps and delivers well-constructed software that doesn’t need cleaning up.

Settlers are still needed, but to bring systems built by shadow-IT projects into conformance with IT standards. It’s a vital role, but a different one.

Left to their own devices, Settler-supported shadow IT and fast-mode Agile/DevOps teams create a very different type of mess — an unplanned landscape. Metaphorically, it would be as if a large number of individual real-estate developers built wherever they pleased, with no zoning laws or urban planning to constrain them.

It would, that is, be like medieval London.

The so-called best-practice solution to this challenge (so-called because it’s way too early in the game to enshrine one solution as best) is called “scaled Agile.” Without endorsing or critiquing any specific approach to scaling Agile, my colleagues and I are discovering that many of the organizations attempting to scale Agile find themselves less agile than they were with waterfall.

Trimodal IT offers an alternative.

My old ATRM fixed medieval-London-ish systems through an approach we might call “scaled refactoring.”

Scaled refactoring leaves Agile/DevOps teams to do what they do best, which is to quickly develop small solutions to well-defined business problems. It leaves shadow IT’s pioneers to build rough-and-ready prototypes, which an IT Settler function converts to well-plumbed and wired production-ready applications.

In the aggregate these provide the requirements and specifications for industrial-strength enterprise-scale systems that metaphorically turn medieval London into a modern metropolis.

There’s just one problem with this model: It’s horrible — horrible because it recreates the same giant technology replacement programs that so often suck all the oxygen out of a business. I’ve abandoned ATRM as a bad idea because it relies on the successful execution of a very large, waterfall-style project that looks a lot like a traditional systems conversion.

Ugh.

Wardley provides the sketch of a solution that fits a different, important concept that’s emerging in our industry: Agile enterprise technical architecture management (ETAM).

Wardley describes his approach as progressive theft: Settlers “steal” applications from Pioneers to industrialize them; Town Planners steal them from settlers to incorporate them into the enterprise technical architecture.

Town Planning’s (aka ETAM’s) success, that is, comes from ongoing incremental misdemeanors. This is good. Massive remediation efforts are by definition Big Projects, which means they usually turn into felonious failures.

* * *

We still haven’t addressed the cultural challenge of fast-mode/slow-mode conflict. Instead, we made it worse by adding a third culture to the mix. We’ll get there next week. Unless, of course, something else distracts me.

The hidden pitfall of bimodal IT

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.