tecosystems

Integrated Innovation and the Rise of Complexity

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Fifteen years ago, around the apex of its dominance of the then central operating system market, Microsoft pursued a strategy it called “Integrated Innovation.” The promise for customers was a streamlined experience, one not pockmarked by multiple vendor to vendor integration weakspots. Microsoft’s pitch to customers was a seamlessly pre-integrated – whether the pieces had been developed natively or inorganically acquired – stack from operating system to database to server upon which to build their enterprise applications.

The promise, and opportunity, for Microsoft was an expansion of its addressable footprint beyond the boundaries of the operating system entrypoint, the revenue that tends to accrue to those types of enterprise platforms, and even tighter control over its customers.

While the strategy worked to some extent, it never achieved the dominance some anticipated or in other cases feared. Enterprises the world over turned in huge numbers to alternative, multi-vendor Java based platforms – the legacy of which is still visible in the thousands upon thousands of J2EE (and its descendants) applications currently facing uncertain futures in the cloud era. As an approach to market then, the proverbial ‘one-throat-to-choke’ Integrated Innovation approach largely gave way to an alternative ‘best of breed’ Java stack.

The Java stack was in most cases harder to assemble, but had the virtue of being offered by more than one vendor. Many an enterprise passed on Integrated Innovation for fear of being beholden to a single vendor for its enterprise stack the way they were for their operating systems and office suite. The enterprise Java stack may have been harder to wire together, but as anyone who sat through vendor dog and pony shows at the time, you could at least attempt to play vendors off against each other.

With some notable exceptions, from AWS to one time champion of Integrated Innovation, Microsoft, this best of breed, DIY-centric approach has persisted to this day. The question is whether it should.

The defining characteristic of today’s enterprise infrastructure market is its fragmentation. At every level of the stack, categories have fractured and become more fractally complex and difficult to comprehend over time. For enterprise buyers, particularly long tenured ones, this is a problem. Gone are the halcyon days when an enterprise architecture was assumed to be three tier, and the only decisions to be made were which app server and database – relational, of course – to select.

Instead, today’s technology leadership looks out onto an endless labyrinth of technology decisions to make, the outcomes of which are less clear by the day as current technology evolves and new tech arrives at accelerating rates.

One logical response to this complexity, of course, is a pre-integrated and packaged offering. What if customers had to worry less about which choices to make and not at all about the integrations between the offerings? What if offerings like Microsoft’s original Integrated Innovation stack returned, in other words?

Some would argue that they already have. Heroku, for example, followed in the footsteps of the original Platform-as-a-Service (PaaS) platforms like Force.com and Google App Engine with a pre-integrated fabric. The operating system? Invisible. Database? Managed. Compute? Push your code and don’t worry about it.

But while this was enough to earn Heroku a $212M valuation in their 2010 acquisition by the owners of Force.com, PaaS always took a backseat role to the DIY-ish Infrastructure-as-a-Service (IaaS) market. For many, particularly those in investment communities who privately buried the idea of PaaS-style offerings, the takeaway here was that DIY-style approaches were and would always be the preferred approach at scale.

Which is certainly still possible.

It is worth noting that since the aforementioned acquisition of Heroku in 2010 – let alone the apex of the Java application server market, however, that the market has only become more complex. Every layer of the technical stack from development to production has become more complicated, involving more moving parts. What’s unclear is how sustainable this trend is. It was one thing to integrate three tiers two decades ago; the sheer number of tiers requiring integration at this point is, even in best case scenarios, an intimidating prospect.

All of which may help explain the interest in pre-integrated platforms such as Dark, Netlify and Zeit or the potential for platform feature departures/expansions such as GitHub/Actions or MongoDB/Stitch. For decades the infrastructure landscape has presumed a high comfort level with integrations on the part of customers – but what if that begins to wane? At what point do customers, frustrated with the multiplying number of choices to be made and integrations performed force a pendulum shift back towards more and better integrated platforms?

That is one interesting question. A second is whether more vendors will see integration as a means of competing with and differentiating from AWS. Much as companies once competed with Microsoft not by trying to outperform the company in its core markets but by routing around them, it is possible that we’ll see similar efforts with Amazon. The cloud giant has many strengths, among them its ability to sustain an unprecedented pace of innovation at an expanding scale. But this velocity is driven in part by its organizational structure, which is composed of highly autonomous and independent teams each producing standalone products and services.

AWS is, as the company’s employees are only too happy to tell you, customer driven. Their steadfast refusal to provide integrated Paas-like offerings, then, can be read as a lack of demand for such things. But it is worth considering whether, if the market did ramp up demand for it, AWS would be able to deliver on such offerings. We know AWS is capable of producing independent services, quickly and at scale. Conway’s Law suggests that it might struggle – comparatively speaking, at least – to produce offerings that combined multiple services in one complete package.

To date, that hasn’t mattered particularly. Whether it might, ultimately, is something to watch.

Disclosure: AWS, GitHub(Actions), MongoDB(Stitch) and Salesforce(Heroku) are RedMonk customers. Dark, Netlify and Zeit are not currently RedMonk customers.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *