Enterprise software companies all promise a better future. The absolute core of their business is Marketing.  They all want to offer you a game changing software solution that , although very expensive, is worth every penny to the customer. (Whether this change is successful or not is up to us. We are the ones to make sure that the software is implemented well, and delivers one ( or more) of the six possible optimizations that delivers meaningful results for the organization. )

These companies must continuously innovate to try to stay ahead of each other. They are reading the trends, and trying to stay ahead of what you may ask for, or what they fear that competitors might tout at a Gartner conference. Good marketing is a vital input into product planning, always trying to anticipate what buyers will want next.

There is a bit of “creative imitation” in this, but most of the time, this works to the buyer’s benefit. Consider native cloud hosting of applications—not that long ago, this concept was pretty foreign to most organizations. Now, I don’t think there are more than a handful of companies left that would host their own email or E-commerce servers.

For Enterprise Software companies, AI is the new Cloud (Or the new NoSQL, or Consumerization, or SaaS, or etc, etc.), still high on the hype cycle promising lower long-term costs and better results. In their marketing efforts, they are trying to convince CIOs and other executives to sell the case to the leadership of why and how a new technology, whether it’s a big upgrade, a platform change, or a new application is going to solve important, existential challenges. As one Tech leader says, his goal is to use Marketing to position his product as “the reflex response for a CIO who is replacing legacy technology for the functional area of the asset.”

Something happened that completely surprised me, however—Salesforce reported a big slowdown in new deals, even with all of the AI hype. In fact, all Enterprise software companies seem to be struggling a bit right now.

In thinking about this, I think that AI has the same Marketing problem that the Cloud had 10 years ago—Security and Privacy.

With AI, the unspoken concerns are worse—because whether we can articulate it or not, we are not just worried about sensitive data, breaches, and so forth, but we are worried about the security and privacy of our insights.

We take the software company’s word ( and legal documents) that they won’t share our customer or product data.  That is step one in a basic agreement, and the infrastructure in a multi tenant architecture has proven safe enough to be trusted.

However, we can see clearly that our data, and more importantly, our questions, prompts and refinements are being used to make the AI smarter and more useful, not just for us, but for competitors, snooping governments, and potential bad actors.

Software companies need to address these concerns head on (again, even if we are not saying this out loud yet).  Organizations need to understand what ideas and insights are being shared between instances of these systems, as well as what is being exposed externally.   The concern that I have is that the Software companies themselves may not know the answers to these questions.

Helping CIOs and their colleagues gain confidence that the intelligent “soul” they are inviting to the organization can keep secrets is the marketing leap needed.  Keep your eyes open for whose Marketing department figures this out first.

Bob’s article is a classic on pilots.  This rerun works well with our previous topics.

I was sitting with Moe, Larry, and Curly at lunch the other day (not their real names but I feel an obligation to protect the guilty) when the conversation turned to information technology.

My colleagues (we’ll call them S3 for short) recently left the military, so their perspective on IT is a bit broader than that of most IS professionals. Moe led off with a mention of genetic algorithms. Here’s how these amazing things work: You feed the computer any old airplane wing design (for example) and a definition of what it means for a wing to be optimal. Let the computer churn for a day or two, and just as an automatic bread-maker magically produces bread, it will pop out an aerodynamically perfect wing design.

The algorithm is called “genetic” because it mimics evolution, randomly mutating the design in small increments and accepting those mutations that improve the design. Very cool stuff. If you support an engineering design group, this technology is in your future.

From there, Curly somehow got to artificial intelligence, and in particular the AI golf caddy. Apparently, these little robots actually exist, following you around the golf course and recommending the perfect club for every shot. Larry pointed out the hazards of combining the AI caddy with Y2K: “Carnage on the course,” he called it.

If you haven’t noticed, people are doing amazing things with computers these days. So why is it that most IS departments, in most projects, can’t seem to design a database, create data-entry and transaction-entry screens for it, design and code a bunch of useful reports, and hook it all to the legacy environment without the project going in the ditch?

When I started in this business, a typical big project needed 25 people for three years and was completed about a year after the deadline — if it got completed at all. Compared with the simple compilers we had when I started programming, our integrated development environments should easily make us 100 times more productive. So why is it that as I write this column, a typical big project needs 25 people for three years and is completed about a year after the deadline — if at all?

Do the math, people. One programmer should complete everything in nine months. What’s the problem?

It isn’t, of course, quite that simple. It also isn’t that complicated. Try this: Start with a small but useful subset of the problem. Then, understand the data and design the database. Create edit programs for each table. Work with end-users to jointly figure out what the update transactions are, and design transaction entry screens for each of them. Design a navigation screen that gets you to the edit and transaction screens. Build a simple batch interface to the legacy environment. Do it as fast as you can. Don’t worry about being sloppy — you’re building Quonset huts, not skyscrapers.

Put it all into production with a pilot group of end-users for a month. Turn your programming team into end-users for that period so they experience their system in action first-hand. At the end of the month, start over and do it all again, this time building the system around how the pilot group wants to work. After a month with the new system they’ll have all kinds of ideas on what a system should do for them.

Build Version 2 more carefully, but not too much more carefully because you’re going to loop through the process one more time before you’re done. In parallel with Version 2, though, start building the infrastructure — real-time legacy interfaces, partitioned business logic and so on — that you’ll need for Version 3, the production application that needs a solid n-tier internal architecture and production-grade code.

Does this process work? It has to — it’s just a manual version of a genetic algorithm. I’ve used it on small-scale projects where it’s been very successful, but haven’t yet found anyone willing to risk it on something bigger. Given the risks of traditional methodologies, though (by most estimates, more than 70 percent of all IS projects fail) it almost has to be an improvement.