All Posts in Shadow IT

|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

|In: Architecture|Last Updated:

Guess what’s now “best practice.”

A few years back it meant locking PCs down tight, preventing anyone outside IT from doing anything creative with information technology unless they could get it done with Excel.

“Shadow IT” … business departments implementing information technology without any IT involvement? An information security nightmare!

Nightmare? Look at the number of recent, massive data breaches whose targets have been … what shall we call the opposite of shadow IT … sunlit IT?

The actual evidence seems to show that shadow IT is, at worst, no less secure than sunlit IT.

The exact same cast of characters that advocated tight lockdown just a few years ago are now, without even a trace of contrition, writing favorably about how smart CIOs are supporting and leveraging shadow IT rather than trying to stamp it out.

Research current thinking on this and you’ll find the IT punditocracy has discovered IT has to handle some tasks more quickly than others. McKinsey, for example, calls it the “two-speed IT architecture.”

Welcome to the party, folks. You’re late. Did you at least bring some decent champagne?

To be fair: Just because these folks are latecomers, it doesn’t mean their insights are worthless. The McKinsey piece, while long on what the outcomes should look like and light on how to achieve them, is a fairly decent analysis.

Decent, that is, other than ignoring the significant role shadow IT will and should play in most two-speed IT architectures.

And, decent with this possible exception: “… companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.”

If, by “quicker,” McKinsey’s analysts mean reducing cycle times for fulfilling orders, then fair enough. While the notion that information technology can be helpful in reducing process cycle times is hardly a fresh one, it’s no less valid today than it was when first introduced in the mid-1970s or thereabouts.

But “quicker” might also mean implementing new strategies or responding to marketplace changes. If that’s what McKinsey means by “quicker,” it’s way off, because optimized processes are one of the biggest impediments to rapid change. That’s because optimized processes need supporting infrastructure, and infrastructure encourages stasis, with “infrastructure” including:

  • Business process design. As these things go, this is the easy one. Designing an efficient process just isn’t all that difficult compared to what it takes to implement one. Visio is the most adaptive component of process infrastructure.
  • Design of business process controls. Beyond the process itself are management practices and process metrics. Designing them isn’t all that hard. Designing them so they don’t do more harm by getting in the way than they provide in benefits? Trickier. A lot trickier.
  • Design and build-out of the physical plant needed to support the business process. This could be as trivial as setting up a new cube farm, or as complex and expensive as designing and building a factory. Ignoring all other aspects of this task, whatever gets built will have to last long enough to be relevant until the company has paid off the design and build-out costs.
  • Design (or selection), implementation, and integration of supporting information technology. Presumably, KJR’s audience knows a thing or three about this topic. To make sure it doesn’t get lost: The integration part is, in most situations, the most expensive and difficult technical dimension of the task.
  • Employee training. The need to train employees is obvious. That their education is part of your business infrastructure is less obvious.
  • Investment in continuous improvement cycles until process optimization has reached the point of diminishing returns. No matter what the new process, it’s the organizational equivalent of a skill. Skills take time, and money, and effort to acquire and perfect.

There’s one more factor to take into account to understand why investments in business infrastructure put the brakes on business agility, and that’s the project failure rate.In most companies, more projects fail than succeed. That being the case, once a company has a process and its supporting infrastructure up, running, and optimized, the fear that implementing its replacement will fail isn’t merely very real. It’s realistic.

And when the odds of success are low, it’s perfectly natural for a company’s decision-makers to take what looks like the safer bet — sticking with that has worked, even if, in the long run, the result will be an obsolete company that sells and delivers obsolete products and services.

Especially because, in so many cases, by the time it’s impossible to ignore their obsolescence, it will be someone else’s problem.

* * *

Next week: Shadow IT’s role in a two-speed business (not just IT) architecture.

Comments