The subject: Bimodal (or trimodal, or agile, or high-speed) IT. The challenge: Culture. Culture is a challenge to IT agility. It’s a challenge if you buy into the bimodal model, where systems of engagement need to change and adapt at lightspeed while systems of record need accuracy and stability above all else. It’s just as big a challenge if you embrace the trimodal model described here last week.

Culture is a challenge because it means “how we do things around here.” It’s the set of shared assumptions that let people work together efficiently. Think of culture as an organization’s cognitive infrastructure — a foundation everyone builds their thinking on, confident that if they do, everyone else is likely to agree with their conclusions.

Start with the six dimensions of optimization: Fixed cost, incremental cost, cycle time, throughput, quality, and excellence.

With bimodal IT, systems-of-record employees assume quality, throughput, and incremental cost are what matter most, while systems-of-engagement employees are equally sure cycle time, excellence, and fixed cost are what deserve the most attention.

It’s a recipe for conflict. Now add this: Systems of record are part of the business infrastructure. They’re necessary but not strategic. Businesses invest in them to preserve the value they’ve been delivering for quite a long time.

Systems of engagement are strategic. Businesses invest in them to get new value. One way or another, directly or indirectly, systems of engagement are part of how businesses get the cash register to go ching!

Which means fast-mode IT projects get better and easier funding, and the IT professionals who staff then get more … and more career-enhancing … attention.

The trimodal analysis is a bit different. Understanding its built-in conflicts starts with another property of culture — it’s a big part of how employees define identity, affinity, and, as a natural byproduct, ownership.

The trimodal model isn’t built around the systems of engagement vs systems of record model. It’s built around a progression, from prototype to production-grade, and then from production-grade to part of the core architecture.

In Simon Wardley’s version, described here last week, the progression is managed through a process of theft — “settlers” steal “pioneers'” prototypes to make them production grade; “town planners” steal settler’s production-grade systems to make them suitable for inclusion in the core architecture.

Think pioneers are going to thank the settlers who take over control of their creations and impose strict new rules for their evolution? Think the settlers, who have carefully adapted their systems to support their part of the business, will be delighted when town planners take them over and generalize them so they support the whole enterprise better by imposing one-size-fits-nobody design compromises?

Think again. No matter how what system of governance IT and the rest of the business impose to regulate this process, it’s still going to feel like kleptocracy to those on the receiving end of it.

You’re the CIO. One way or another you need to keep the lid on conflicts within IT. So you instituted DevOps, not only to help speed things up but also to reduce the usual and natural conflicts between Development and Operations. But DevOps exacerbates conflicts between the high-speed culture that uses it and the low-speed one that avoids it.

You’ve already instituted some form of Agile Enterprise Technical Architecture Management (ETAM). (Haven’t you?) With some trepidation you incorporate the kleptocratic town-planner function into it. But you recognize the resentment it will create, and want to minimize it.

What’s the plan?

There are no best practices for this. Not that there ever are, but some fields at least have proven, tested practices. Here, the best we can do is apply what we know to what we don’t know. Three suggestions:

• Avoid false dichotomies. System of record vs system of engagement is one. These aren’t opposites. They’re the poles of a continuum. System-level governance should establish the proper trade-offs between system-of-record-ness and system-of-engagement-ness for every system IT manages.

• Rotate staff. No, don’t have them spin in circles. With some exceptions — your deep system mavens who like being deep system mavens — move applications staff from one system to another, and in and out of your ETAM function. Move operations staff from one DevOps team to another, and through ETAM as well. Resenting them is harder when they become we unpredictably and often.

• Promote “Form Follows Function.” As the first rule of design it’s already at the heart of your architecture (isn’t it?). Those who embrace it are more likely to assume those who do things differently are dealing with different circumstances.

Making it part of how we do things around here will reduce cultural conflict.

And happily enough, it will also improve design.