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.
Interesting column. Actually, I just posted so I could see the feedback others might offer. Looking forward to your next installment.
In the email newsletter there’s a question just above the “Leave a Comment” button: Your opinion for IT: Bimodal? Trimodal? Tricycle? Try, try again?
I think I like the “Try, try again” option. It got me thinking, do these different concepts for how IT does/should function reflect developing technologies?
For example, in The Beginning, there was basically mainframes, for business, correct? Not much opportunity for “shadow IT”. Programming, compilation, and roll-out times and methods meant Big Projects, right? Not much room for quick, incremental modifications.
With the advent of the PC things changed. But there was a still a big difference between local apps individuals might run on their own PC and server-based apps that multiple people could access.
So IT had to make a fairly large project out of converting anything local to something more accessible.
Ditto when the internet came along. Building internet apps was quite challenging at first. Now of course there are all sorts of development platforms to make the process easier.
Shadow IT started in the days of the first business PCs, but it has grown progressively easier for both “shadow IT” to create something, and for IT to then incorporate it into the enterprise architecture.
As technology has enabled various methodologies, so new methodologies have developed. One Big Project –> Waterfall –> Agile. Could you have done Agile in the mainframe days? In the early PC days?
So too do these Unimodal –> Bimodal –> Trimodal cultural models strike me. That is, the cultural model you use for IT is dependent in large measure on the technology that is available.
Is it possible to imagine an IT cultural model that transcends whatever technology is current, that would apply going forward into whatever new possibilities the future opens up? Or will we continue to see new models proposed as new tech comes along? (Right away, from “agile” commentators, and some decade or two later from the large, slow-moving consulting groups :-))
Can’t track down the old column – quite a few years ago I wrote about a business manager who bemoaned the loss of informality with IT. As he explained it in the late 1980s, describing events that took place in the 1970s, he used to sit on the edge of a programmer’s desk, asking, “Can you get the computer to do x?” Yes.
A few weeks later he’d have another idea, and ask, “Can you get the computer to do y?” Yes.
In not all that long he had a working system that did what he needed. Nobody knew to call it Agile, but that’s what it was, way back when all we had were mainframes.
i am still struggling with this modal “stuff”. I think it’s one of those things that are being over sold by Gartner and are highly dependent on context. they become useful only as high level concepts but when it comes to implementation every company has to build on its own knowledge and is kind of alone.
Haven’t we always been treating things differently when it made sense? We use waterfall for some projects and agile for others. Some work gets done without projects. Some work goes through EA some doesn’t. Some changes follow change management some doesn’t. For some customer we do things faster than for others. What has changed?
I give Gartner credit for coining terms, it makes it easier to talk about these subjects but this looks like another term that will fade into obscurity in a year or so to be replaced with the next new insight.
Gartner had a prior tri-modal model they called pace layering. Systems of record, systems of differentiation, and systems of innovation. A bit like bimodal, with a nod to the differentiation ‘tweener, which should be designed and built with more rigor than systems of innovation, but done more quickly than systems of record.
In the end, I find this model useful. And I recognize that really good stuff will need to be reengineered if and when it moves up a tier (or two).