The client that was confused about security
The competition for April Fool’s Day humor is brisk, as I documented in 2010 with two lists of excellent pranks. So I went against the grain that year, offering a collection of strange-but-true stories — such as how I came to have heartthrob James Marsters autograph a shirtless picture of himself, why I regretted that graduating athletic powerhouse Ohio State University at age 16 cost me my NCAA eligibility, and the sore butt I got from spending an afternoon with Bill Gates’ girlfriend, herself a well-known industry figure.
That post seemed to go over well, even if I’m a little disappointed at how few people joined in with stories of their own. So I’m opting for strange-but-true this year also, just more aligned with the usual subjects of my blogging. And thus, without further ado, here’s the story of
The client that was confused about security
It’s a consulting rule of thumb that what a client thinks they’re hiring you to help with often isn’t their biggest issue. I’ve been hired to help decide which columnar DBMS should replace Oracle Standard Edition in a CRM SaaS application, only to discover that the real issue was handling 50,000 updates/minute (a couple of years ago, before there were good NoSQL alternatives). I’ve been hired to help decide whether Exadata or a columnar DBMS should replace Oracle Standard Edition in a CRM SaaS application, only to discover that the real issue was each web page request spawned 400 short-running queries — if not 1600 — in a loop.
Yeah, our user clients are often software sellers, SaaS or otherwise.
Based on those examples and many more, the description of our services for users will evolve to increasingly stress consulting, listening, discovering what the real problem is, uncovering surprises, getting colleagues to talk to each other, and all that touchy-feely stuff. I think we do that better than anybody else, in part because of consulting style and skills, but also because I have the breadth of knowledge needed to have a chance at pulling it off.
Hey — if you think you understand all your potential future scenarios perfectly, and just want a quick sanity check to see if you missed something on your vendor short list, we’re up for that too. Just don’t be flabbergasted if what you choose and implement isn’t meeting your needs two years down the road.
But on with the story. My best example of all may be one from late in the previous century. (1996, if I recall correctly.) Along with database technology, I was then an expert on application development tools, and so I got a gig helping a large Swiss bank* decide among several different fourth-generation languages. Lots of variability in tech savvy there; when they took me down Mahogany Row to meet execs, the EVP of sales crawled out from under a desk where he’d been doing PC support for his secretary. Anyhow, it was six days of work at $10K/day. Sweet deal.
*Not a software-seller client! Whoops, never mind — a big part of why I was there was to help decide whether to spin their internal software out into a separate line of business.
There was the usual religious conflict about competing programming languages, but that was all manageable. The really big debate was that some people had gotten the idea that, for security reasons, the application shouldn’t be client/server at all; rather, it should rely on X terminals (X terminals were like what might be called a thin client today, but too dumb to be useful). For security. At great cost in application functionality. One thing I wasn’t much of an expert on in those days was security, but that struck me as pretty wrong-headed even so.
Ironically, I’d been brought into the project by Charles Wang of Computer Associates, which in those days passed as a leader in security technology. The bank in question had let CA a couple billion dollars, and its CEO had asked him for the favor of some advice as to who to hire as a consultant.
When I pressed the issue, it turned out that the group I was working with thought the X terminal idea was silly too, but the security guys were insisting on it. I suggested that they might have misunderstood, and we should maybe ask the security folks to make sure. They got a security guy on a conference call accordingly; he had no idea why anybody would be opposed to PCs on a security basis; and poof — the problem was solved.
So the best thing I did in the whole engagement was get different people at the client to talk with and listen to each other. Not a shock. As a second-generation consultant, I learned that trick from my parents.
My principal contact let on that this outcome wasn’t really surprising. After all, he opined, any security system could be defeated just by spending however much money was required to suborn a clerk. You could wonder why one crooked clerk sufficed, but otherwise he surely had a point in those pre-web-hacking days. Anyhow, the security problem was put to bed, I threw cold water on the idea of spinning out the banking application software they hadn’t even decided how to build yet, a reasonable course was set for picking application development tools, and everybody was happy.
Some months later, I noticed a small article about the bank in the newspaper — one still read from dead trees in those days — and guess what? That EVP of sales I’d seen crawling out from under a desk had been convicted of embezzling from the bank.
Obviously, the choice between PCs and X-terminals had been the least of their security problems.
Comments
One Response to “The client that was confused about security”
Leave a Reply
[…] In particular, there’s a break point when companies — often SaaS vendors — outgrow Oracle Standard Edition. […]