“It is said that if you know your enemies and know yourself, you will not be imperiled in a hundred battles. If you do not know your enemies but do know yourself, you will win one and lose one. If you do not know your enemies nor yourself, you will be imperiled in every single battle.”
- Sun Tzu, The Art of War
“A weapon is simply a tool for the application of force.”
- Daniel Keys Moran, The Last Dancer
When people think of Silicon Valley startups like LogBase, where I’m working now, pre-emptive force-based business strategies are usually not the first thing they think of. Although many of the industries that we serve are highly competitive and essentially zero-sum, the industry of technological innovation itself is wide-open to new areas of exploration that create competitive areas rather than competing within existing ones.
Within technology, we tend to think of what we build as fundamentally being just tools. Thus, at a gross level, an RDBMS for example is little different functionally from a hammer – it has an operator or user whom it’s designed for, it processes inputs and produces an output, and it has specific uses which it’s well-suited for and others which it’s ill-suited.
I believe in taking as little for granted as possible — as my firearms instructor Gordon Gray likes to say, “When we ASSUME, it makes an ASS out of U and ME.”
And so as I delve deeper and deeper into researching how best to market a product in the burgeoning field of log file analysis in big data, one of the key factors that keeps me from heading off into a marginal, obscure tangent is the willingness to constantly question and revise my most basic assumptions. I’ve identified what I believe to be a fascinating set of assumptions and cognitive “framing” of use case scenarios associated with the concept of software as tool.
the “software-as-tool” paradigm
Software, even in highly competitive domains and with patently offensive purposes, is always referred to as “tools” and “platforms” and “software suites” — no one is billing their software to be a “weapon for email list manipulation” or a “cloud-based business optimization weapons platform”. In Silicon Valley, our software products are essentially hammers, wrenches, bridges, networks — tools, in other words.
It’s difficult for me to prove this point without something like a comprehensive Lexis search across all time for press release language (not something I like doing, especially since so much human reading is involved), but a casual limited search reveals that the phrase “software tool” has occurred in English language media worldwide better than 10,000 times. “Software weapon” has been mentioned 128 times. A Lexis search does not certainty make, of course, but it does support the basic premise here: “Software weapon” is not a meaningful term. At best it’s a catachresis or just marketing hyperbole.
The paradigm of software-as-tool has implications on how we interact with software and the expectations we carry of it — as the old saying goes, “When all you have is a hammer, the entire world looks like nails.” When your worldview is shaped by the resources you can bring to bear, your resources essentially become your worldview and the world itself becomes — more or less accurately — more inputs for your tools.
“semi-automatic high-capacity assault email servers”: software as weapon
Now, as the reader, at this point, you might figure that the next step I argue for is some weird kind of militarization of marketing copy for software. Let’s stop right there: I’m not arguing for “militarization of software products”. Heck, I’m not even saying we should be “militarizing” our marketing language — mainly because, well, it’s just silly. (“High-capacity assault server”, anyone?) No, rather, my core argument is that software should not be spoken of as weaponry but rather that sometimes it is best thought of in weapon terms. Or, more concisely and generally:
When we question the assumptions behind software-as-tool, new uses and purposes for software develop and software itself innovates.
Alternatively, as the somewhat melodramatic copywriter in me would put it:
I’m not building a tool for my customers to just conduct business – I’m building a weapon for my customers to dominate their competitors and “win” their sectors.
Or — just one more — as the rifle builder in me would put it:
Sometimes what we build isn’t a hammer. Sometimes it’s a life-saving weapon.
data intelligence as business weapon
The software-as-tool paradigm is most clearly evident in the nascent field of data science — data accessibility, data discovery, data intelligence, pretty much data <any business noun>. Here, even highly defensively oriented software is still essentially discussed with the fundamental assumptions of tools firmly in place.
Accepting for a moment arguendo that the loaded term “weapon” and all its connotations might still be the best word, or at least a thought-provoking candidate word, what separates a software tool from a software weapon, then?
A weapon, in contrast to the more general concept of a tool:
- applies or redirects force;
- is designed for an opponent as well as for an operator (for instance, the contrast in knife blade shapes between “combat” and “hunting” knives)
- may be comprised of multiple tools and weapons (a “weapons platform” like an F-22 Raptor or a M1913-rail equipped small arm with accessories)
- may serve a deterrent purpose without actual use (e.g. nuclear weapons, guns in armed robberies, etc.)
As I’ve worked more and more through the literature, both academic and marketing-oriented, surrounding data intelligence and its related disciplines of performance monitoring, incident analysis, log file analysis, trend identification, anomaly detection and performance optimization, it has become clearer and clearer to me that the product I’m working on is best thought of as a kind of business-strategic weapon rather than a business-operational tool:
- force application: Data intelligence redirects the force of a business’ data expansion into increased certainty of statistical measure of the business’ self (through constantly increasing sample sizes) and increasingly interesting hypotheses (through diversifying data streams).
- opponent-based design: Data intelligence products, particularly in security and incident analysis fields, are designed primarily to provide value based on what they are processing rather than who uses them;
- systems/platform integration: Data intelligence products are usually comprised of a suite of interlocking, interdependent software modules and independent programs working together;
- non-use-based value: Data intelligence is still useful (“deterrent”) even when it is not directly producing value in the form of outputs — for instance, if you know trends are going on and you are monitoring your data to find them, the time spent monitoring is still valuable even during the period when you’re not certain of the underlying trend, because at the very least your monitoring provides a baseline profile to distinguish trends from. It’s the first “O” – Observation – in the Boyd Cooper OODA (observation, orientation, decision, action) loop.
data accessibility: the business end of data intelligence
Data intelligence tools share some features of weapons, but quite plainly not all weapons – it is difficult, for instance, to liken a log-analytic machine data intelligence system to a pistol, and it is probably stupid as well as not that illuminating (“You see, the database in your server is just like the magazine in a pistol…” No, just… It’s not. Stop. Let’s not even go there.)
From the viewpoint of someone just trying to run a business, the most significant aspect of data intelligence is its potential to be presented in a meaningful fashion that can be acted on — “actionable” business intelligence, as we like to say in the copywriting community.
Like most such marketing words, however, “actionable” in this context really means very little. (Honestly, I think we use it so much because it just sounds cool.) After all, any data is “actionable” – it’s just that sometimes it results in an insignificant action, or an action of doing nothing, or for that matter even an action of ignoring further data.
The most meaningful standard by which we judge “good” and “bad” business intelligence isn’t whether it’s “actionable” — it’s whether it’s accessible. Within the terabytes of log data produced by most modern big data business every day, there is valuable, “actionable” intelligence in the millions of records of millisecond-to-millisecond activity generated by computerized business systems, but the vast majority of it is only minimally “actionable” in the sense that it suggests the necessity for some kind of significant human action.
Or, to put it in simple meme terms:
applications in application: software as armor
Too often, log-analytic solutions — indeed, business intelligence products in general — are neglected and ignored until something goes wrong. It’s a story I hear repeated everywhere — friends, colleagues, field literature, even news articles and press releases. Up until the first time that the server crashes, or the app takes a serious performance hit or the database’s security is optimized, decision-makers are often reluctant to invest in seemingly obscure and rarely-useful tools like incident analysis. Once that first business crisis hits, though, suddenly log file analysis and data intelligence in general become incredibly sexy and necessary.
As much as you might think so as a frustrated IT pro reading through gigabytes of log files looking for what made the stupid server crash, this refusal to invest in adequate intelligence systems prior to catastrophe isn’t short-sighted stupidity on the part of the executive team. It’s just human nature.
When things are going well, people are quite naturally risk-prone — it may seem silly, for instance, to worry about setting a crash incident analysis system in place if the server has never crashed yet, or to plan ahead for a security breach when one hasn’t occurred yet. It’s a natural aspect of the paradigm of software as tool — building things is rarely a matter of life-or-death in the same way that, say, deploying a weapon system might be. When things go badly, we get very risk-averse, even if it’s rational to take calculated risks based on how bad the situation is.
Stepping outside the paradigm of software-as-tool yields a different way of looking at the situation that can be more persuasive to risk-prone or -adverse decision-makers. Would you step out into a fight without as much armor as you could scrounge up, buy, or find? So why would you go into a competitive business sector with constant competitive “threats” without basic precautions — even if nothing has happened yet?
If you have gear upon which your life depends isn’t it in your best interest to keep in the best condition possible, even if that exceeds the kind of conditions to which you’d reasonably subject your gear? Similarly, business have a vested interest in keeping well-ordered, digested, comprehended universes of internal data — even if those conditions exceed the kind of stress that you’d expect your business to be subjected to, keeping business data orderly and discoverable has emergent benefits beyond simply responding to exigent conditions.
Living in our somewhat perfect, affluent, gentle, high-IQ My-Little-Pony Silicon Valley world where we all just go into new areas of business rather than compete with each other, it’s easy to lose sight of the somewhat stupid, somewhat vicious, almost always dog-eat-dog competitive world that the rest of us live in. And that’s to our detriment as designers and makers and thinkers. We need to be practical in what we make and for whom. I believe that we are making products for imperfect humans in a competitive, sometimes vicious world where order arises out of ad hoc improvisation and genius comes from unexpected places and things very, very rarely work out with a mutually amicable My Little Pony Friendship Is Magic solution.
It is philosophically naive and a misreading of our customers for us to be locked into the paradigm of always thinking of our products as mere tools. We gain insights into our products and our consumers when we examine them outside of our native environments of assumptions.