Three IT speed-ups

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.