All Posts in Shadow IT

|In: Cloud|Last Updated:

In the beginning there was dBase II.

Yes, II. There was no dBase I, and shortly after dBaseIV there was 0, as superior products eclipsed this, the original end-user app dev tool.

Fast forward thirty years to the present and it appears the entire EUC (end-user computing) category is failing. This makes no sense.

No, it isn’t extinct yet. There is, for example, the venerable Microsoft Access, although anyone who thinks Microsoft is giving it much attention isn’t paying much attention. If Microsoft had any interest in the product, it long ago would have become a highly publicized Azure development environment.

At least it’s economical: $110 buys you a license.

There’s QuickBase. I know little about the product other than that from a features and functionality perspective it looks promising. And it’s cloud-based. But it costs a user-unfriendly $180 per client per year.

Also, an alarm bell: Intuit recently sold QuickBase off to a private equity firm. For the most part private equity firms buy companies, starve the P&L of investments, and flip the company before revenues crash.

Draw your own conclusions.

Apple’s FileMaker Pro is reportedly a strong product, as it should be for $330 per user license. There’s also a cloud version, priced at, as one reseller, amusingly puts it, “from $1.63/day.” Let’s see … carry the 1 … that’s $595 per year, per user. I thought the cloud was supposed to be cheap.

These are three of the more prominent EUC products. Like I say, this makes no sense, given what we’re hearing from the trend-meisters: (1) Everything is moving to the cloud; and (2) IT is going the way of the dodo: Infrastructure is leaving the data center in favor of the cloud, while app dev is leaving the IT organization to become shadow IT, embedded in the business and out of control.

If shadow IT in the cloud is supposed to be a Next Big Thing, why aren’t the big cloud players — in particular Microsoft, Amazon, and Google — fielding products to cash in on the trend?

What’s particularly strange about this situation is that we are, for the first time, in a position to field application development environments that truly could make business managers independent of IT — that could take care of just about every detail of application design.

It’s now technologically possible to create:

  • Wizards that provide a dialog that results in a normalized data design (I’m old-fashioned) — one that makes use of IT’s APIs to provide meaningful integration and avoid the creation of duplicate data fields.
  • Automated form generation for PCs, tablet, and smartphones that flow naturally from the data design.
  • Visual workflow design tools, so systems can let users know there are forms to be opened and work to be done.

IT won’t be irrelevant in this new shadow/cloud universe we’re imagineering. But it probably does need to recognize the need to get out of the app dev business and into the integration business.

So far, this is just me grousing about the sorry state of the world — less an occupational hazard than a chronological one, but a hazard nonetheless.

What’s in it for you as an IT leader?

First and foremost, take integration seriously. It’s mostly a matter of solving a problem once instead of over and over again.

The key: Especially for IT shops that mostly license COTS and SaaS software and integrate it rather than building their own, build an architecture that makes systems of record and sources of truth separate and distinct.

Systems of record are maintained and managed by IT, which keeps track of which system is the central repository of what information and which systems have to be kept synchronized to the central repository.

Sources of truth are SOAP or REST-based APIs. When shadow IT efforts … and for that matter, formal IT efforts … need to retrieve or update information from the company’s official databases, they consult the sources of truth, not the underlying systems of record.

Next: if you want to do everyone a favor and not force them to make Excel perform unnatural acts, settle on a suitable end-user computing tool in spite of the state of the market, connect it to your APIs, and actively promote its use, both inside and outside IT.

You’ll be amazed at just how much more automation your company achieves, and how much more satisfactory it is as well.

Comments

|In: Industry Commentary|Last Updated:

Did we give up too easily?

We used to automate processes. Back in the early days, before we called ourselves Information Technology, Information Systems, or Management Information Systems, that’s what we did.

We didn’t optimize processes, orchestrate them, or develop metrics to assess their performance. We obliterated them, replacing them with computer programs that called on humans only when an input or decision was required the computer couldn’t handle on its own.

To be fair, we didn’t always do this all that well. Some of these automations sped up business processes that contributed little business value beyond keeping some people busy who otherwise might have caused all sorts of mischief.

There were also quite a few cases where the program paved a metaphorical cow path, faithfully reproducing in automated form every process step that had previously been executed by a bored human being, even if these steps had nothing at all in common with what an engineer might construct if given the goal and a blank sheet of paper.

But even with these flaws, IT’s predecessors delivered orders-of-magnitude improvements in business efficiency. And then Something happened, and suddenly, overnight, IT became the biggest bottleneck to business improvement.

My theory is that Something = Methodology, but perhaps I’m being unfair. I’m not, after all, a business historian, so while I lived through some of the mayhem, my personal mayhem experience isn’t a statistically significant random sample.

Based on my personal experience, direct and second-hand through colleagues, here’s the way process automation happened back in the good old days we neocodgers see in the warm glow of imperfect memory:

Someone from the business would drop by EDP (electronic data processing, IT’s ancient forebear), sit on the corner of a programmer’s desk, and ask, “Can you get the computer to do x?”

After a short discussion the answer was either yes or no, and if it was no, a longer discussion usually led to a useful alternative the computer was capable of.

The programmer would go off and program for a week or so and call the business person back to review the results and suggest course corrections. In not all that long the computer had automated whatever it was the business person wanted automated.

Usually, in the interim, other notions occurred to the business person, who, while reviewing how the solution to the initial request was progressing, would ask, “Can you also get the computer to do y?”

Over a span of a few years these solutions to business problems accumulated, turning into the big legacy systems many businesses still rely on.

If we’d only had the wit to call what we were doing a methodology and label it Agile.

Had we done so we might have avoided quite a lot of the discreditation that happened to IT during the years of waterfall wasteland that, starting in the early 1980s, transformed us from the department that automated stuff, generating enormous tangible business benefits, to the Department of Failed Projects.

For that matter, had we continued in our quest to automate the bejeezus out of things in our naively Agile sort of way, disciplines such as Lean and Six Sigma might never have achieved their current level of prominence.

Not that Lean and Six Sigma are terrible ideas. In the right contexts they can lead to solid business improvement.

What they’ve turned into for some businesses, though, are Strategic Programs, and religions for some practitioners. For these devoted adherents they’re the answer to all questions, before actually asking the questions.

What they’ve also turned into is a sort of IT-less shadow IT — a way to improve business processes without any need to involve IT, and, more important, without having to ask the Department of Failed Projects to deliver very much.

Let’s imagine the executive team at some enlightened (or misguided — your call) company reads the above and, convinced, calls to ask how best to return IT to its process automation roots. What would a modern version look like?

Mostly, it would treat each process as a black box that turns inputs into outputs. IT’s job would be to understand what the inputs and outputs are, and to develop, through a combination of inference and listening to the experts, an algorithm that reliably turns the defined inputs into the desired outputs.

That’s it — the entire methodology in one paragraph, understanding that “algorithm” can hide a lot of complexity in its four syllables.

Might this work? Beats me. It’s an idea I’m just starting to play with. Next week I might strenuously disagree with this week’s me.

Don’t hesitate to weigh in.

Comments