All Posts in Shadow IT

|In: Industry Commentary|Last Updated:

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.Map of 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.

Comments

|In: Leadership|Last Updated:

Culture is the new IT governance.

No. It isn’t. Not yet. Culture should be the new IT governance.

The IT Governance Institute’s definition of IT governance is as good as any: “… leadership, organizational structures and processes to ensure that the organization’s information technology sustains and extends the organization’s strategies and objectives.”

Nothing wrong with the concept. IT’s priorities should be driven by business considerations. Setting them through the consensus of its stakeholders seems sensible.

It is sensible. Where IT governance goes sideways is where oversight usually goes sideways: A failure to understand that Homo sapiens has two subspecies: Steven Spielberg and Jeffrey Lyons. Either you helped make the movie or you’re a critic.

In most companies, most of the time, the IT Steering Committee is Jeffrey Lyons. It doesn’t really exist to set IT’s priorities. It exists to review, critique, and for the most part reject suggestions as to what IT’s priorities might be.

The IT Steering Committee, that is, isn’t a strategy-setting team that collaborates to decide how the company can best take advantage of what IT has to offer. Instead it’s become a group of critics, who see their job as ensuring IT doesn’t go off and waste precious company resources on pointless technological extravagances.

In case the problem still isn’t clear, too often, the IT Steering Committee’s mission isn’t to help put good ideas into practice. It’s to prevent bad ideas from becoming bad practice. The result: It makes sure the business never tries anything except the safest ideas.

Which is one reason, and a very important one, that shadow IT is on the rise: Departments commissioning their own information technology don’t have to jump through any of the IT Steering Committee’s flaming hoops.

There’s another, related reason: The company has to be careful how it allocates its “scarce IT resources” so they provide the maximum return.

This sounds convincing, until you ask why IT resources are so scarce. Usually, they’re scarce for one of two reasons, or both.

The first has been pointed out in this space several times before: Companies try to cut costs by trimming the IT budget, not realizing this is like trying to cool a room by blowing cold air at the thermostat. The more cold air you blow, the more everyone swelters.

The second reason is a terrible trend: IT’s resources are scarce because of the fondness boards of directors and top-level business executives have for financial engineering.

Here’s the math: In its most recent year the Fortune 500 will have earned an aggregate $945 billion in earnings. But as reported by Bloomberg last fall, they’ll “invest” 95% of it in stock buy-backs, leaving only $47 billion for all forms of reinvesting to achieve competitive advantage. All new IT spending has to come out of that residue.

If IT resources are scarce, it’s an artificial and deliberate scarcity. Rather than fight for these artificially scarce resources, business managers at all levels are increasingly walking away from the struggle, instead rolling their own IT through a combination of SaaS solutions and cloud-hosted custom systems written by outside developers.

As pointed out last week, this avoidance of formal IT oversight results in three very real risks: Re-keying of data that should automatically flow through IT’s integration mechanisms; exposure of sensitive corporate data to outsiders who have no business seeing it; and failure to adhere to the company’s painstakingly arrived at set of official data definitions, which will, in turn, make both re-keying and automated integration problematic.

Which in turn leaves only three possible solutions. The first is to live with the problems — probably not a good idea, as they are preventable without all that much additional effort.

The second is to apply existing enforcement mechanisms to shadow IT. They’ll work, but they’ll slow down something whose principle virtue is that it speeds things up.

That leaves the best alternative: Culture. Members of cultures enforcement them through social coercion, greatly reducing the need for official sanctions. It’s efficient, because everyone in the company internalizes its culture without any formal training. Employees know the rules.

The downside: Establishing and maintaining the desired culture is hard work — not hard the way nuclear physics is hard, but hard the way laying cinder block is hard.

But it’s worth it. The right culture delivers the right results without the heavy hand of enforcement, letting leaders apply a much lighter touch.

Comments