Technical differentiation
I commonly write about real or apparent technical differentiation, in a broad variety of domains. But actually, computers only do a couple of kinds of things:
- Accept instructions.
- Execute them.
And hence almost all IT product differentiation fits into two buckets:
- Easier instruction-giving, whether that’s in the form of a user interface, a language, or an API.
- Better execution, where “better” usually boils down to “faster”, “more reliable” or “more reliably fast”.
As examples of this reductionism, please consider:
- Application development is of course a matter of giving instructions to a computer.
- Database management systems accept and execute data manipulation instructions.
- Data integration tools accept and execute data integration instructions.
- System management software accepts and executes system management instructions.
- Business intelligence tools accept and execute instructions for data retrieval, navigation, aggregation and display.
Similar stories are true about application software, or about anything that has an API (Application Programming Interface) or SDK (Software Development Kit).
Yes, all my examples are in software. That’s what I focus on. If I wanted to be more balanced in including hardware or data centers, I might phrase the discussion a little differently — but the core points would still remain true.
What I’ve said so far should make more sense if we combine it with the observation that differentiation is usually restricted to particular domains. I mean several different things by that last bit. First, most software only purports to do a limited class of things — manage data, display query results, optimize analytic models, manage a cluster, run a payroll, whatever. Even beyond that, any inherent superiority is usually restricted to a subset of potential use cases. For example:
- Relational DBMS presuppose that data fits well (enough) into tabular structures. Further, most RDBMS differentiation is restricted to a further subset of such cases; there are many applications that don’t require — for example — columnar query selectivity or declarative referential integrity or Oracle’s elite set of security certifications.
- Some BI tools are great for ad-hoc navigation. Some excel at high-volume report displays, perhaps with a particular flair for mobile devices. Some are learning how to query non-tabular data.
- Hadoop, especially in its early days, presupposed data volumes big enough to cluster and application models that fit well with MapReduce.
- A lot of distributed computing aids presuppose particular kinds of topologies.
A third reason for technical superiority to be domain-specific is that advantages are commonly coupled with drawbacks. Common causes of that include:
- Many otherwise-advantageous choices strain hardware budgets. Examples include:
- Robust data protection features (most famously RAID and two-phase commit)
- Various kinds of translation or interpretation overhead.
- Yet other choices are good for some purposes but bad for others. It’s fastest to write data in the exact way it comes in, but then it would be slow to retrieve later on.
- Innovative technical strategies are likely to be found in new products that haven’t had time to become mature yet.
And that brings us to the main message of this post: Your spiffy innovation is important in fewer situations than you would like to believe. Many, many other smart organizations are solving the same kinds of problems as you; their solutions just happen to be effective in somewhat different scenarios than yours. This is especially true when your product and company are young. You may eventually grow to cover a broad variety of use cases, but to get there you’ll have to more or less match the effects of many other innovations that have come along before yours.
When advising vendors, I tend to think in terms of the layered messaging model, and ask the questions:
- Which of your architectural features gives you sustainable advantages in features or performance?
- Which of your sustainable advantages in features or performance provides substantial business value in which use cases?
Closely connected are the questions:
- What lingering disadvantages, if any, does your architecture create?
- What maturity advantages do your competitors have, and when (if ever) will you be able to catch up with them?
- In which use cases are your disadvantages important?
Buyers and analysts should think in such terms as well.
Related links
Daniel Abadi, who is now connected to Teradata via their acquisition of Hadapt, put up a post promoting some interesting new features of theirs. Then he tweeted that this was an example of what I call Bottleneck Whack-A-Mole. He’s right. But since much of his theme was general praise of Teradata’s mature DBMS technology, it would also have been accurate to reference my post about The Cardinal Rules of DBMS Development.
Comments
4 Responses to “Technical differentiation”
Leave a Reply
I’d expand to AI-inspired products where clear instruction/execution goes to the next level.
If a system is very intelligent, than that would likely be manifested by you being able to get away with very concise instructions.
I guess there could be “I’m sorry Dave, I’m afraid I can’t do that” kinds of complications, but those are beyond the scope of this post. 🙂
In my opinion Technical diffierentation matterthe most it covers enterprise data managment and analytic technologies and practice and industry leader in its coverage of data warehouse appliance
[…] a post last year about differentiation, I wrote “Your spiffy innovation is important in fewer situations than you would like to […]