Don’t let trendy terms overrule crucial business decisions
We’ve all seen tech marketers use a trendy phrase to push their offerings. Some of these phrases get muddled in the push to promote and they begin to lose a bit of their impact. Likely the most pervasive example is the word disruptive.
“Disruptive SaaS,” “disruptive technology,” and even “disruptive APIs” are boundless. But what does it actually mean to be disruptive, now in 2018?
To answer that question we’re going to dive into the implications, both positive and negative, the term carries. We’ll look at the history of disruption through historical business use cases, and place its usage in the tech business dialogue.
While a lot of this boils down to opinion and marketing preferences, it’s an interesting question to consider: Is being disruptive even a good strategy in the first place?
Disruptive has become jargon, with many new solutions, regardless of how novel, unique, or genuinely innovative they may be, employing the term. Due to this, disruption itself has become watered down.
Disruptive: Innovative or groundbreaking
In an attempt to rectify this, as well as some additional misunderstandings as to what disruptive means for the API space specifically, we need to set some linguistic and historical standards for what the term even means.
To Sustain or Disrupt?
The concept of a technology being disruptive came from a Harvard Business professor by the name of Clayton M. Christensen. In his book, The Innovator’s Dilemma, he set the framework for technology within two general categories – sustaining and disruptive.
Sustaining technology is when a product, solution, or implementation is incrementally improved upon, sometimes even in innovative form. This can continue the function of said item within a new situation of challenge or requirement. For example, if a provider finds their market share dwindling as more users opt for a mobile experience, shifting toward a more responsive, mobile design would be considered a sustaining technology.
Disruptive technology, however, is a radical departure from the current solution, often to the point of being a new solution altogether. This comes with significant marketplace benefits. However, since the solution is often novel and untested, it also often comes with a range of performance issues, a somewhat limited audience appeal, and a lack of trust in long-term longevity.
Why This Matters
It might seem nitpicky to care about the definition of these terms, but understanding what disruptive tech actually is could arguably be instrumental to the development of new, greater technologies within a secure and performance-centric framework.
It’s been a recent trend for large organizations and traditional media to release interesting solutions to existing problems, and then brand these solutions as “disruptive.” In reality, these solutions are often sustaining technologies. Mislabeling technology not only overstates its importance and design ethos, but has the effect of understating legitimate concerns for other truly disruptive technology.
To bring it home to the API economy, releasing a new API version that does what the old one did in a novel way is not being disruptive. It makes the solution novel, sure, and it might even be revolutionary, but it is not in itself disruptive. In cases like these, the term is used largely for marketing purposes.
Push It To the Cloud
The disruption doesn’t end there. Cloud is another conflated term that’s had a similar history of wide use.
As an example, a wireless hard drive is often marketed as a personal cloud, but if it can only be accessed over local wireless, that designation is not true. In that instance, it is simply a network attached storage device, albeit one that is wireless. While it might support a gateway to the data for external access, it’s not truly a cloud implementation, because the physical resources still relate to the cloud presence on a one to one ratio, with no use of virtual machines and no separation from the logical, physical topology to the virtualized environment. This causes lack of understanding and confusion.
In some cases, terms like these are used honestly. Some new solutions occupy a strange zone between the traditional and the unproven, and as such, a liberal interpretation of the term “disruptive” could arguably be seen as acceptable, especially when used to describe sustainable technologies in large corporations.
Can Enterprises Truly Be Disruptive?
That’s not to say of course that large organizations can’t be disruptive. In many cases, pivoting from a traditional offering to a novel one requires disruptive technology. The movement from SOAP APIs to RESTful microservice architectures with added value through novel hypermedia integrations is probably the best example of enterprise-level disruption.
A great example of traditional media pivoting to disruptive solutions can be seen with Netflix. The idea of offering video rental through brick and mortar is about as old as one can get with media on-demand, and the shift to offering DVDs through mail was novel, but not disruptive – many had thought of it before, and Netflix just happened to be the most effective at their distribution method.
The truly disruptive innovation, however, was the pivoting to digital on-demand content streaming on an internal API backbone. When technology allowed for streaming within the Netflix framework, the company shifted wholesale towards it, adopting new, powerful APIs and distributed media storage to deliver high-quality, on-demand media over traditional infrastructure cable and satellite. The pivot was so disruptive that, in many people’s minds, it was responsible for most of the business shift that ultimately put Blockbuster out of business, and paved the way for other streaming competitors to join in fundamentally changing the way we consume our media.
Netflix continues to innovate through self-innovation and content creation, of course, but has now become a standard. In the same way, an API can be truly disruptive, and become a de facto standard for an industry claim as seen in the movement from SOAP/RPC to RESTful architecture.
Disruption – Is it Good or Bad?
There seems to be the idea that disruptive is “good”, and thus any novel, new implementation from a traditional company is often branded as “disruptive” for market value. This is a shame, as the reality of disruptive APIs is relatively easy to state – while the benefits of disruptive technology can be far reaching and hugely positive, negative possibilities exist too that can result in serious security concerns and market share loss.
As a specific example, we can see the original push for digitization of books in the late 90s. The idea of providing both the hardware and the software to deliver content in a semi-on-demand method required several significant disruptive innovations, not the least of which was the underlying APIs that drove the online eCommerce and payment methodologies. Unfortunately, this was the main issue at hand.
While the concept was novel, the APIs were hampered by both the technical limitations of the hardware and the legal demands of publishers and authors. Implementing a digital rights protection system meant that the API had to have significant security considerations and high network utilization for rights affirmation. The e-Readers were often limited to a small amount of storage, and the APIs had to also deal with the storefront rate limiting for popular titles that were difficult to handle on bulk from a centralized server to many distributed devices.
All said, the tech was simply not there yet, and the APIs as well as the user experience suffered because of it – no matter how disruptive and novel, the ecosystem was too limited to see success. In fact, it would take another decade before the tech and the network to support it would be developed to the point that readers would see high success and adoption.
Is disruptive tech is good or bad? Well, neither. A disruptive technology fits into a specific criteria, and the effect of its implementation is determined by how well — or how poorly — it’s integrated into a given solution.
In other words, a disruptive API with great security and awesome functionality that fails in capturing market value is well-designed, but bad for the organization. On the other hand, an API has has limited functionality but is revolutionary might be defined as poorly designed, and still be successful if the solution itself is better than the traditional approach. Simply put, it all comes down to how the implementation of the disruptive API is actually handled.
The reality of disruptive APIs, and disruptive technology in general, suggests that we should be wary of considering “disruptive” as a good thing by default. There’s really two realms that exist for this term – there’s the realm of marketing, and the realm of the technical.
When it comes to the realm of marketing, disruptive is often a code word for novel or unique. As such, truly disruptive technologies should be considered a possible solution that be must be tested, secured, and resolved, regardless of the marketing material.
When it comes to the realm of the technical, we should be aware that disruptive tech has both extreme possible benefits and extreme possible drawbacks. In certain situations, a traditional approach is required. If it’s possible to integrate a disruptive solution into an experimental branch without compromising function or security, it should be considered.
As an aside, our industry requires clarity and understanding. We should all endeavor to properly use technological terminology and concepts in their proper way, not because of any semblance of formality or the need to correct, but out of understanding. As such, understanding what disruptive is, and what it is not, will go a long way towards fixing the otherwise somewhat broken use in marketing it currently suffers.