All Posts in Shadow IT

|In: Industry Commentary|Last Updated:

Sometimes, the world changes quickly.

Six or so months ago, in a conversation with some fellow travelers in IT organizational effectiveness consulting circles, someone (ahem) raised the question of shadow IT and how best to support it. “I can’t imagine any circumstances in which we should even consider allowing it,” someone said, receiving near-unanimous support from the assembled multitude, yours truly being the reason it was only “near-.”

Last week I attended MIT’s CIO Executive Forum. In a table discussion at lunch, and also among many of the panel discussions, it was unanimous: Support for shadow IT is an increasingly important IT responsibility.

Which, as I’ve been advocating for shadow IT in some form or another since 1996, is gratifying. For you, it means advocating this no longer makes you a heretic.

If you’re a skeptic, consider the Transportation Security Administration (TSA).

Not its use, disuse, abuse, or quashing of shadow IT, about which I know nothing. What I do have is extensive experience waiting in TSA queues, and how it relates to process cycle time improvement.

Cycle time is the time needed for one item to move through a process from start to finish. When you’re waiting in the TSA line at the airport, total cycle time is measured in psychological months and chronological minutes.

Cycle time has two components: intrinsic cycle time and queue time. In TSA terms, queue time is how long you have to wait until you have to undress, empty your computer bag, and put your toothpaste and other non-solid toiletries on display.

Intrinsic cycle time is what elapses from the moment your first piece of luggage hits the conveyor until you get everything back on the other side of the machines subjecting you and your belongings to various indignities.

With TSA, intrinsic cycle time is actually quite short — no more than two minutes. Almost all of the wait we’ve all grown to detest has nothing at all to do with how long it takes TSA to determine who among us is or might be a threat. It’s queue time that tries our patience.

And interestingly enough, intrinsic cycle time isn’t the only factor driving queue time.

Capacity drives it too. If there’s just one inspection line open and the queue gets too long, TSA can and does fix the problem without any process improvement. It simply opens up a second inspection line and queue time is instantly cut in half, even though it hasn’t even nudged the dial on intrinsic cycle time.

What does this have to do with shadow IT and why you want it? Everything. Because the most important business benefit to be had by embracing, encouraging, and extending shadow IT is its impact on queue time, where its impact is little different from TSA opening the second inspection line.

Only in the case of shadow IT, the business is multiplying its application implementation capacity by maybe 1,000 percent, so long as IT doesn’t do its best to slow it down to industrial-strength IT speeds.

See, shadow IT has two natural advantages over industrial-strength IT. The first is that the trusted cadre known as we is responsible for all of the design decisions, where with industrial-strength IT, we in IT fall into the nasty group of untrustworthy ne’er-do-wells known as them. This is particularly true of the various trade-offs that are unavoidable in any design, but no more desirable because of their unavoidability.

The second advantage is that with shadow IT, most of the analysis and design work takes place inside a single person’s head.

Here’s why this is relevant. A lot of the reason we need methodologies when developing business software is because we have to coordinate the work of multiple specialists, each of whom understands a part of the problem; none of whom has the complete picture. Shadow IT doesn’t usually suffer from the need for all of this overhead. It’s pretty much one person’s show, front to back.

Meanwhile the single biggest argument against allowing shadow IT projects has pretty much fallen apart. That’s the contention that shadow IT frequently ignores the principles and practices required to implement properly secured systems.

This argument fell apart when Target, and Home Depot, and Humana all experienced major data breaches, all of which penetrated their properly secured systems … systems designed, built, tested, and implemented by IT professionals.

Conclusion: We’re over the hump with respect to IT recognizing the need to support shadow IT.

All that’s missing is a clear picture of what that support should look like.

Comments

|In: Architecture|Last Updated:

Old, old, theological IT joke:

Question: If God could create the entire universe in just six days, why does IT take so long to implement a new system?

Answer: God didn’t have an installed base.

What’s this have to do with keeping the joint running? At the risk of pointing out the obvious, in modern business, speed matters. If your company doesn’t continually improve its products, services, and practices as fast or faster than your competitors, pretty soon your customers won’t be your customers anymore because why would they?

The more sophisticated version starts with Colonel John Boyd’s OODA loop (observe, orient, decide, act). Very short explanation: If your OODA cycles are shorter than your opponents’, every time you Act you re-set them to Observe, effectively paralyzing them.

In business, speed matters. And in the 21st century, no matter what a business decides to do, it will need new or changed information technology to do it.

And yet, for the past few decades not only have a lot of business and IT executives actively slowed down IT, but many of their slow-down practices have been enshrined as “best practice,” while much of what’s required to speed things up is deemed too troublesome and expensive.

Three examples among many:

  • IT Governance: Governance is about is making decisions. But when the term “governance” enters the conversation, the subject is really preventing bad decisions and the preferred mechanism is a committee.

But preventing bad decisions means requiring everyone to ask permission before, for example, sneezing. And even the most efficient committee mostly makes decisions when it meets, not when someone asks for a decision. Committees can’t avoid causing delays.

Instead …

A faster and more-effective form of governance is educating everyone about the organization’s goals and priorities and making sure they’ve bought into them; keeping managers and supervisors in the loop; establishing a “culture of discipline”; and then entrusting most decisions to those closest to the action.

More effective? Yes. Most committees consist of people who represent constituencies, legitimizing constituency interests as a factor in making decisions (read “the silos win”). Decisions are political compromises — not a bad thing, but decisions and actions rooted in shared purpose and goals are usually better.

  • System integration: So many IT shops interconnect applications and databases with a spiderweb of custom-programmed batch point-to-point interfaces.

In one extreme case I worked with, IT Operations had more than a thousand interface jobs that had to run in strict sequence each night. Another client estimated that 80% of the total effort in most of its applications projects was invested in not breaking the interfaces.

No argument, uttering the words “federated architecture” makes it sound easy when it’s anything but easy. But in the long run the alternative to implementing some form of planned and engineered integration isn’t saving money. It’s wading through molasses.

Federate your architecture, or else achieve equivalent integration through some other means (two alternatives: use an ERP system as the architectural hub and primary access point; or build and rely on an operational data store for the same purpose).

  • Shadow IT: Who can get more done — 10 teams, or 100 teams?

This isn’t, for a change of pace, a trick question. The answer is inescapable, and yet most IT organizations, instead of being grateful for the help, do their best to stamp out shadow IT.

In case you’re unfamiliar with the term and the phrase isn’t self-explanatory, shadow IT is information technology implemented without the IT organization’s involvement or permission. You’ll find the case for encouraging it in “Stop stomping out shadow IT” (KJR, 9/4/2012); no point making the exact same points again here.

Let’s connect the dots.

Dot #1: In addition to adding to IT’s bandwidth, shadow IT adds speed for another reason: It’s beyond the reach of IT governance.

Keep it that way.

Dot #2: One disadvantage of shadow IT is that it produces “islands of automation” — un-integrated systems that usually make someone somewhere re-key data from the shadow IT system into existing systems and vice versa. Re-keying is error-prone and expensive.

Dot #3: As part of IT’s efforts to support shadow IT, it should change its role, and name. Maybe “Integration Systems” (IS)? IS can and should take its now-well-engineered system integration to the next level: Its new job is to provide APIs to shadow IT groups throughout the enterprise.

Far from adding risk, the impact is the exact opposite: By pushing all access through well-defined APIs, integration won’t just be easier.

You can make it as safe as you want.

Comments