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.

With the election over, the world’s opinionators have switched their opining from comparing candidates’ horse-race strategies and tactics to pointless post mortems on the same subject.

Pointless because the correct analysis is, what was Clinton thinking, setting up her own email server instead of using Gmail like everyone else?

Last week I promised to get back to business. I am. Because if you filter out all the noise, the Clinton Email Fiasco provides plenty of guidance for the world of organizational dynamics.

Start with an excellent long-form piece by Politico’s Garret Graff titled “What the FBI Files Reveal About Hillary Clinton’s Email Server” (9/30/2016). According to Graff, the FBI’s investigation documents “… depict less a sinister and carefully calculated effort to avoid transparency than a busy and uninterested executive who shows little comfort with even the basics of technology, working with a small, harried inner circle of aides inside a bureaucracy where the IT and classification systems haven’t caught up with how business is conducted in the digital age.”

In broad brush if not detail, the story should sound familiar. Start with Clinton’s technical illiteracy. She apparently doesn’t even know how to use a personal computer. For email, she once learned to use a Blackberry and that was the beginning and end of her tech savviness. Even her staff’s attempts to move her to an iPad or iPhone died on the vine.

Couple that with the sheer volume of emails she had to contend with — you’ll recall they numbered in the hundreds of thousands. Next mix in that the State Department’s secure email facilities were clumsy and antiquated. And that in addition to her Blackberry, Clinton managed much of her email traffic by having aides print out messages for her to read and hand-write responses. But outside the State Department’s facilities this couldn’t be done, so her staff forwarded emails to her private server as a workaround so they could be printed.

The punchline: Substitute your own company’s less-than-tech-savvy executives for Hillary Clinton. Substitute inconvenient or hard-to-use information technology for the State Department’s secure email system. Substitute Gmail and Dropbox for a privately managed email server.

And finally, substitute your technology-use policies for the State Department’s technology-use policies, and your insufficient technology refresh budget for the State Department’s insufficient technology refresh budget.

Get the picture?

Outrage is easy when someone in authority violates the policies everyone else is expected to follow. Empathy is harder.

But as any good business analyst will tell you, empathy is the essential ingredient in information technology design. “Documenting requirements” only gets you so far, as anyone knows who has documented the requirements for secure passwords will tell you. Those requirements are precisely what cause employees to write down their passwords on easily-found Post-It notes.

People have work to do. Executives are people too, often with bigger piles of work than anyone else. And character flaws notwithstanding, your typical executive mostly gets it done.

Executives are, if anything, even more impatient than anyone else regarding obstacles that keep them from doing it.

Regrettably, in my experience at least, at a personal level more executives see information technology as obstacle than see it as an assist, so while they might not be so extreme as to not know how to use a PC, there are plenty who won’t take the time to learn (for example) how to track changes in Word; to use SharePoint in its usual IT-friendly/user-unfriendly configuration; or to use the company’s web conferencing system’s whiteboard feature to facilitate mixed in-person/remote participant meetings.

Not to mention … it’s a whiteboard. How many employees at any level have PCs that let them use a stylus to draw on the whiteboard?

Answer: Very few, because of the rarely recognized chicken/egg nature of so many IT requirements: Few people ask for something because they don’t know it exists; IT doesn’t offer it because nobody asks for it.

So … where does the Clinton Email Fiasco take us?

It’s past time for businesses of all kinds to recognize that inconvenient IT, especially when coupled with a lack of technology savviness, constitutes a significant risk to the business.

Even more, it’s long past time to recognize that dealing with most risks by establishing policies are little more than CYA strategies. They’re pretty much worthless when it comes to preventing or mitigating the risks themselves.

While in your case the fiasco will be less obvious and visible, the lesson is nonetheless just as consequential when profits and brand are at stake as for more minor matters like appealing to voters.