Understanding The Innovation Lifecycle

Information technology is a rapidly moving space, and understanding the innovation lifecycle is critical to making sound business decisions. Whether you are a creator or consumer, knowing how your products, technologies, approach, and methods line up with the evolving marketplace better positions you for successful outcomes. Clearly, not every innovation follows the cycle below. Some companies go bankrupt, some products become vaporware, and some technologies seem to never move past a certain stage (or hover in a stage indefinitely.) However, the vast majority of new and disruptive changes in this space follow this lifecycle and complete their journey through it.




What Is Innovation?

Innovation is a much overused and often cringeworthy buzzword. However, it does have a distinct meaning. While that meaning may vary slightly from person to person, in the context of this article we will use the definition constructed below. To do this we will start with in the dictionary definition, and three important caveats.

According to the Oxford English Dictionary, an innovation is:

“a new method, idea, product, etc.” 

That is certainly short, imprecise, and totally lacking for how we use innovation in our common parlance. Innovation is not just a new idea, method, or product. The same model car from last year with a different paint job is not innovation, because it doesn’t represent a wholly new idea. Neither is a phone which only works when standing on the surface of the Sun, because it has no realistic application. Nor would a commuter train made entirely of slowly melting nacho cheese be innovative, because it doesn’t solve any real problem.

To me, innovation as it applies to business and technology requires at least three distinct clarifications and additions to this definition:

  • It must be something wholly new, even if assembled from pre-existing ideas, methods, and technologies.
  • It must be something which has application. An idea alone, or a new method which cannot be realistically applied, is not an innovation.
  • Innovation must solve a problem. In business this means it must impact “the bottom line.” To do that, it needs to affect one or more of the following: speed to market (agility), reduction of effort (rigor), ability to generate capital (investment), ability to reduce cost (savings).

An innovation is also not “a product” alone. Certainly, we can categorize many new products as innovative, but generally when we use the term “innovation” we should be referring to a entire category of products as opposed to a single product. For instance, one could discuss Docker and how it fits in the lifecycle above. However, that would miss the mark, and one should reference “containers” or “containerization” which would include Docker, Rkt, other Open Container Initiative (OCI) technologies, and any closed source or vendor protected products in that space which fulfill the same role. This is important, because products themselves have distinct lifecycles, and those operate independently of the innovation lifecycle. One product may fail, and its competitor may succeed. So we will remove “product” from the dictionary definition and replace it with “technology” in our accepted definition.

All these points aggregate to the following working definition:

“An innovation is a wholly new idea, technology, or method which can be applied to solve a problem.”  

To be even more specific in the context of business, we could say:

“An innovation is a wholly new idea, technology, or method which can be applied in my company to increase agility, reduce effort, generate capital, or cut costs.”

Components Of The Lifecycle

The first stage in the lifecycle is called inception. It represents the birth of a new idea and lasts from the initial spark of a new approach until the point where this technology or method is generally adopted. This is a rocky time in the innovation lifecycle, and exists as a proving ground for new ideas. Technology in this state can be consumable, but often isn’t easily useable or accessible to laymen. With iterative development being the most common model utilized in modern programming, this first stage may only represent the barest foundations of a final “production ready” technology. Features are missing. Things are broken. It is difficult to support without specially trained IT warlocks who don’t bathe and dream in code. Often at this stage there are few to no competing products or suites of products, because no one has a gauge on whether this innovation will be successful or even find a market. Many new, and occasionally amazing, innovations die on the vine in this phase because they cannot make the leap to actually being readily consumable.

The second stage is adoption. This phase lasts from early adoption of the technology by brave and fast moving companies who are able to take the risks, up to Enterprise recognition and large scale deployments. Technologies at the beginning of this phase are past the “beta releases” seen in the first stage, however they are still testing the waters, adapting to general consumption, and often making large course corrections to become more easily consumable. This is followed by relatively stable development, which is often marked by numerous competing products that seek to deliver the same innovation in a different package. Large outside vendors often begin imitating this technology, or adapting it into their own ecosystem of products. The middle of this stage is a great place to become an adopter. You have a market full of choices, and many big names lending their credence to this new idea. Finally, as this phase comes to a close, it moves into Enterprise adoption. Enterprises, which are often seen as late adopters, begin to test the waters with this new innovation. Although, many choose to keep these technologies in development and non-production areas until later in the innovation lifecycle. Here at the very end we begin to see large scale deployments, and a level of soundness and trust which tells the marketplace that this innovation has made it.

The third stage is disruption. Every new innovation which comes along fully believes it is the disruptor, and can itself never be disrupted. This is a critical mistake. In fact, clever innovators should begin to disrupt themselves as soon as they see their core technology being widely used. This is an eventuality every innovation faces, as technology is always progressing. This phase lasts from the first recognition of a disruptor, until the disrupter moves into its own adoption stage of the lifecycle. However, this isn’t yet a period of decline for the innovation being disrupted. The core technology will adapt and learn from its disruptor. Often it will grow stronger, because it has to change and see the world in new ways that it didn’t anticipate. However, there is no adapting out of being disrupted. Once it happens we know that the disruptor will move along its own innovation lifecycle our technology will be supplanted.

The fourth stage is recession. As the disruptor (or disruptors) of the previous stage begin to move into adoption, companies utilizing this technology will start to see it as “last gen” and begin to focus efforts on the coming “next gen.” Vendors will refocus efforts, fast moving companies will abandon this “ancient tech”, and Enterprises will start hiring folks who have the skills for adapting their processes to embrace the new kid on the block. At this point, there is always some innovation panic. This is the mid-life crisis of the innovation cycle. Quite often products using this technology will resort to bolt-ons to prolong life. Large vendors begin to utilize “Embrace, Extend, Assimilate” thinking to keep their variation of this innovation in play with a mix of the new tech. VMWare is a master of this. They are like some wicked Iron Chef who can cook a beautiful steak and throw in a dash of blobfish and still get a standing ovation from their fans. As their core business of traditional on-premis virtualization suffers an overwhelming onslaught from public and private IaaS, PaaS, and CaaS adoption — they start to offer traditional virtualization that also supports Docker containers (VIC), and things like VMWare on AWS (so vSphere and NSX masters untrained in the ways of the cloud are not left out in the cold.) This is impressive, however nothing anyone does at this stage truly prevents the inevitable. At some point, our brave new idea is going to become just a footnote in the history books. All IT is written in sand. The tide will come in, and what was will disappear.

The final stage is obsolescence. Obsolescence is inevitable, but it can take a very very long time. As a COBOL program on a mainframe once told me:

PROGRAM-ID.  NeverDie.

   DISPLAY "i WiLL NeVeR FRaKKiNG Di3 d00d".


This period can run for years or decades. With Enterprise adoption, if wide enough, it may seem to go on forever. Once something gets into the Enterprise, it rarely leaves entirely. It simply gets its desk moved to the basement where it can play with its stapler in peace. The death of a technology is a sad thing, but often the ghost lives on. It may someday be celebrated in small circles by bearded wizards writing LISP and demoing Amiga games written in Lattice C. It even may be run on a futuristic emulator in a computer history museum, so our descendants can just how archaic things were way back in 2018. The innovation will always hit its EOL, but our memories of it will live on.

There the innovation lifecycle completes its journey. Some may object to the arrow at the end of “obsolescence” pointing back to “inception”, but I believe every death gives way to a new birth. The learnings of this technology, including those missed or misunderstood by the disruptors, will give new light to some future development. Even today, as we walk deeper into a world full of artificial intelligence we are rediscovering the innovations, brilliance, and wisdom of early computer scientists like Joseph Weizenbaum, John McCarthy, and Marvin Minsky. As Newton said, “If I have seen further, it is by standing on the shoulders of Giants.” Let us hope our dead innovations become the giant corpses the future needs to stand on.

About syncomm

Gregory S. Hayes has 20 years of experience in enterprise IT, specializing in OpenStack, Linux, and Open Source. Currently he a Lead Cloud Architect with McGraw-Hill Education, principally working on next-generation enterprise cloud initiatives. Previously he served at Red Hat as a Cloud Infrastructure Solutions Architect working with a number of strategic enterprise accounts to enable cloud transformation, workload migration, and cloud governance. Prior to joining Red Hat, he also served as a Senior Cloud Architect for Hewlett-Packard. Gregory has led the way in these organizations with regard to cloud enablement and infrastructure automation. He has been involved in the OpenSource community since 1995, and considers himself an evangelist for the next generation of cloud technologies based on OpenStack.
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s