Three threads, one conclusion:

Thread #1: In a recent advertorial (“Stop Using Excel, Finance Chiefs Tell Staffs,” Tatyana Shumsky, 3/31/2018), The Wall Street Journal proved once again that, as someone once said, if you ignore the lessons of history you’re doomed to repeat the 7th grade.

Dan Bricklin first invented the electronic spreadsheet back in 1979. It was immediately and wildly popular, for some very simple reasons: It was incredibly versatile; you could use it to think something through by literally visualizing it; and, when IT responded as it usually does to requests for small solutions — not a good enough business case — users could ignore IT and solve their own problems, right now.

The Wall Street Journal’s story tells the usual tales of spreadsheets gone wild, with their high error rates and difficulties in consolidating information. What were those fools thinking, using Excel for <insert Excel-nightmare-case here>!?!

I was nowhere near the place and I can tell you exactly what they were thinking. They were thinking they had a job to do and the alternatives were (1) Excel, and (2) … uh, Excel.

The business case for the solutions extolled in The Wall Street Journal story was that the Excel-based solutions caused problems. Had users not solved their problems with Excel first, they’d still have no business case.

When Excel is the problem you can be sure the pre-Excel problem was much bigger.

Thread #2: One of my current consulting areas is application portfolio rationalization. It’s usually about enterprise applications that number in the hundreds, but sometimes clients want to consolidate desktop applications that, in large enterprises, easily number in the thousands, not including all of the applications masquerading as Excel spreadsheets.

It’s a shocking statistic, and a support nightmare!

Only it isn’t a shocking statistic at all. A typical Fortune 500 corporation might have 50,000 or more employees. With 50,000 employees, what are the odds there aren’t at least a couple of thousand different processes that might be improved through automation IT will never get around to?

It isn’t a support nightmare either. For the most part the applications in question are used by a dozen or fewer employees who are almost entirely self-supporting.

Support isn’t the problem. Lack of control is the problem. And, in highly regulated industries, lack of control is a real problem corporate compliance needs to solve. It needs to document not only that a given business function’s outputs are correct, but that its processes and supporting tools ensure they’re correct.

On top of which, information security needs to ensure applications with gaping holes are kept off the network, and that applications stay properly patched so that as new vulnerabilities are detected, new vulnerabilities are addressed.

All of this is certainly harder when each business function solves its own problems, but it’s hardly impossible.

And it’s much easier when IT is an active partner that helps business functions solve their own problems.

Thread #3: Once upon a time I was part of a team that redesigned our company’s CapEx governance process. We hit upon a novel idea: that our job wasn’t to prevent bad ideas from leaking through. It was to recognize good ideas and help them succeed.

It turned out we were on target. What we found was that bad ideas that needed screening out were few and far between. Good ideas explained badly? We saw plenty of those.

Tying the threads together: Large enterprises have lots of moving parts, which means small problems are real, worth solving, and too numerous for IT to handle on its own. Users engage in “rogue IT” to make their part of the business more effective, because they can and they should. IT ought to find a way to help their good ideas succeed instead of assuming they’re all pursuing bad ideas that have to be stopped.

The KJR solution: create a Certified Power User program (CPU — catchy, isn’t it?). Certified Power Users will understand the basics of normalized design so they can use MS Access instead of spreadsheets when they have a database problem to solve. They’ll know how to evaluate solutions professionally, so they don’t buy whatever looked flashy at a trade show. They’ll also know how to keep solutions patched, to minimize vulnerabilities.

And, they’ll keep an inventory of the small solutions they create and share it with IT.

In exchange, they’ll have administrative privileges for their PCs, and those of the users they support.

When you’re trying to persuade, “Let us help” is a more powerful message than “No you can’t.”

I took a long weekend, so this was my first chance to post even a re-run.

It’s a bit dated, (it ran in 2002) what with its references to web services, but substitute SOA for web services and it holds up pretty well.

At least, I think it does. But you’ll have to be the judge.

– Bob

# # #

Long before ManagementSpeak graced these pages, Mad Magazine had mastered the art of translation. My favorite:

What they say: It isn’t the money. It’s the principle of the thing.

What they mean: It’s the money.

To run IT, you need both money and principles, of course. Among the core principles for running a typical IT organization:

> Buy when you can, build when you have to.

> Minimize data redundancy.

> Maximize software re-use.

> Pick two.

If you buy when you can and build when you have to, you’ll use applications from more than one software vendor, your databases will be tied to your applications, and you’ll have redundant data. On the other hand, most vendors now write to an n-tier software architecture, which means you can get at the underlying logic, so you achieve software re-use.

Want to minimize data redundancy or maximize software re-use? Build everything yourself, or at least everything you can’t get from your primary ERP vendor. You’ll have full control over your code, too which gives you a fighting chance at re-use. Too bad you can’t afford either the budget or time to choose this option.

Web services promises to eliminate these trade-offs. The use of components instead of full-blown objects means logic is easily accessible while data is still defined separately, and the use of HTTP and XML means vendors can write general-purpose components and make money by renting them out. That means (blare of trumpets!) you’ll easily assemble enterprise applications out of commercially available components from all over the world.

It won’t happen — not because of technological obstacles, but because an enterprise application is more than a collection of general-purpose utility routines.

Software is an opinion about how a business should run. It’s expressed in code rather than English, but its an opinion nonetheless, so when you buy software from multiple vendors you’re buying differing opinions. Interfaces are where they clash. To state the obvious: Technology can’t resolve a difference of opinion.

Imagine you’re a retailer. Web services can solve some irritating problems for you, like managing the sales tax logic in multiple states, so as CTO you decide to adopt the architecture to run your whole business.

That’s when you discover: The different vendors from whom you’re going to rent components disagree on some very fundamental issues, such as how to define “customer.” One considers “customer” to be an individual. For a second it’s a household. A third, oriented toward hardware stores, perhaps, remembers that building contractors buy a lot of stuff and use a definition that includes companies and everyone in the company authorized to make a purchase.

Think you’ll just ship customer data into and out of components from all three vendors with impunity?

Think again.

The grand vision of Web services is that easy integration of independently engineered components will happen by just connecting them together like Tinkertoys. The reality: Integration is hard, even when designed into an application.

It won’t happen by accident, grand visions notwithstanding.