This is the fifth in a series of blog posts that will focus on answering the question “what is the long-term future of Jive?”

 

In today’s post, I’m going to take a break from the focus of the last few in this series.

 

Over the first four posts, I focused on PeopleGraph – the new core technology we’re building that is the future “engine” of Jive. I’ve also talked about two of our four innovation themes - Discovery and Connection - that describe the focus for the things we’re building on top of PeopleGraph. The other two innovation themes, Collaboration and Organizational Insights, will be the focus of the final two posts in this series (yes, I’m intending to actually wrap this up).

 

The Broader Reinvention of Jive

For customers, what we are doing with PeopleGraph is the most visible part of Jive’s reinvention, which is why it has been the exclusive focus of these blog posts. However, of equal importance are some of the fundamental technology choices and changes we are making under the hood – changes that are foundational to making new technologies like PeopleGraph work. In this blog post, I’m going to talk a bit about these changes, and what they mean for customers in both the short-term and longer-term.

 

Perhaps the most important long-term product decision we’ve made involves the different technology deployment mechanisms Jive currently supports – on-premise, hosted, and cloud – and all of the configuration and customization variations associated with each of those. So, as we roll through some of the core technology decisions, I’ll also clarify how those technology decisions are deeply intertwined with our overall strategy and the impacts they create for customers using each of these different deployment models.

 

Freedom from Compromise

One of the significant constraints that Jive had self-imposed was the intention to keep Jive cloud, Jive hosted, and Jive on-premise roughly in synch and at feature parity. They weren’t fully successful with this of course – there are numerous feature variations among the different deployment models – but nevertheless the soft imposition of this constraint created two important product implications:

 

  • Jive would attempt to use the same technologies across cloud, hosted, and on-premise
  • Where possible, Jive would make available cloud services to hosted and on-premise customers

 

On the surface, both of these seem like customer-centric decisions. But there is a mammoth cost to this approach. Each time Jive wanted to advance one of the products – for example, making a significant change to the search service for cloud customers – it had to take into account a vast array of dependencies (in this case, for example, the fact that any change would impact a number of hosted and on-premise customers, each of whom are likely running different versions with different customizations). And these dependencies created two meaningful impacts: first, they materially slowed innovation, as the new code had to be compatible with an endless array of customer scenarios, deployment models, and technology stacks. And second, they compromised the kinds of innovations that could be considered in the first place (the “lowest common denominator” effect of limiting innovations to those compatible with each and every customer case).

 

If we are to move Jive forward at the pace we aspire to, we have to eliminate the kinds of dependencies and compromises that slow things down, create problems with quality, and lead to bad long-term technology decisions. And so, while we build out the new engine of Jive with PeopleGraph – and all the killer related functionality – we have made one other important decision. We are firmly divorcing “cloud” and its technology stack from hosted / on-premise and its technology stack. Let me share a bit more about why we’re doing this, and what it will mean to you.

 

The Power of the Public Cloud Operating System

Most often, when people hear the term “public cloud,” they think of hosting services that are provided at broad scale and priced on a consumption basis, assuming these services are fundamentally similar to a traditional hosting provider like Rackspace. But this reflects a dated understanding of what the public cloud is today and where it’s going … and the tremendous value it can unlock.

 

By all accounts, public cloud providers (and, specifically, AWS) resemble not so much hosting providers as operating systems. They provide a large and growing array of application related services that the software built on them can access, just like an operating system like Windows did as it grew in functionality throughout the 1990s and 2000s.

 

Consider the following graphic that illustrates the AWS services menu growth. It doesn’t take a genius to understand that this is an important technology trend, that the changes we will see in the next five years are likely to dwarf what we’ve seen in the previous five, and that companies that make the decision to go “all in” on this key trend will reap tremendous competitive advantages.

 


 

As a specific example of the kinds of advantages the “cloud operating system” provides, we are currently building a new video service for Jive. Unlike the legacy video service it is replacing, this new service will leverage an array of native AWS video capabilities, including transcription, sentiment analysis, facial recognition, and more. Were we to build all of these capabilities from scratch, or attempt to stitch them together from multiple providers, it would take a significant amount of time and result in a solution of considerable complexity.

 

However, because we are able to leverage a host of native AWS services, we can rapidly develop new features that are remarkably rich but also quite simple. And, those features will continue to advance as both the “cloud operating system” continues on its exponential innovation trajectory and we work to find new ways to leverage it. If we do this right and eliminate blocking dependencies, the pace of innovation will be dizzying.

 

The tradeoff, of course, is that by using native AWS services we are building innovations that won’t work in an on-premise world. And we are at peace with this tradeoff; attempting to harmonize the (literally) thousands of different customer configurations, customizations, and deployment models into a single path forward that still meets the needs of each customer grinds software companies to a halt. If you ever wonder why mature software companies stop innovating – look no further than this phenomenon. It’s not that they have suddenly lost the ability or desire to be innovative. It’s that, unlike startups that have few if any existing customers to worry about, they compromise their future by creating too many dependencies on their past.

 

But it goes far beyond enabling the pace of innovation. It also contributes to simplification, and simplification in turn makes it easier to ensure high quality while innovating. I can provide a very clear example of this by looking at the Jive cloud architecture and where we are taking things.

 

Simplifying A Mess of Complexity

Jive made the decision to migrate to AWS before Aurea bought the company. This was a good decision and one we wholeheartedly endorsed. Unfortunately, what became increasingly clear in the months that followed is that the Jive cloud architecture was both extraordinarily over-engineered and included dozens of unnecessary and complicating compromises to decouple Jive from AWS. The implication of these decisions was that the Jive code base became larger, extraordinarily complex, and inherently fragile (you can get a sense of this complexity in the “marketecture” illustration of the old Jive cloud architecture below). Some of you that endured transition pains during your AWS migration may have experienced first-hand the impact of this complexity. Complexity breeds fragility.

So, in addition to building new capabilities such as revamped search, the new video service described earlier, and all of our PeopleGraph centered innovation on AWS services, we are also rewriting and simplifying large swaths of the Jive cloud codebase to do the same. This won’t necessarily yield increased functionality, but it will result in a substantially simpler, more manageable, and higher quality code base that is vastly more resilient and suited to the pace of innovation we aspire to. We’ve been hard at work on this re-architecture, and we consider it of equal importance to all the work we’re doing with PeopleGraph.

 

We are embracing a future for Jive cloud that will be simultaneously rich in innovation but also remarkably simple under the hood … all made possible by unencumbering it from legacy dependencies.

 

 

 

So, to put a bow around all of this, for cloud customers we have really been focused on three big product initiatives. The first is the overall migration to AWS – a huge effort that has involved multiple releases in order to move and stabilize hundreds of customers as they migrate to the new environment and architecture. Thankfully, this work is nearly complete. This is the jumping off point for everything we are doing, and was a critical, if time-consuming, first step.

 

The second is the re-architecture to native AWS services I’ve talked through in this post, and that effort is well underway and customers will begin to see the benefits once the migration work is finally complete in the months to come. We will roll this out in a step-wise, iterative fashion, changing and simplifying the plane while flying it. These changes are what will enable us to actually take full advantage of the power of AWS to deliver rapid innovation to customers.

 

The third of course is the new PeopleGraph-based innovation that we are building on this new architecture. We have completed much of the work on the core PeopleGraph engine and are now working on the first sets of new application features that will be built on top of it. We’ll be sharing those first sets of innovations in the months ahead and I’ll have more details on the first things we’ll be shipping in a future blog post on our “Insights” innovation theme.

Hold on A Minute Here … I’m On-Premise!

Roughly a third of Jive’s customers are on-premise. And, as I’ve described, all of the innovation pace and potential that our “leverage the native AWS operating system” technology strategy unlocks for cloud is not applicable for on-premise. So, what does this mean for those customers (or our hosted customers, who are typically just on-premise customers using AWS as a “dumb” data center)?

 

Before I describe our strategy let me be clear – we are 100% committed to our on-premise and hosted customers. We have no intention to end-of-life any product, nor any intention to “force” customers to the cloud. And, it’s important to understand, this position is unusual. According to a January 2019 Gartner research report entitled On-Premise Collaboration Options Are Dwindling, “By 2023, less than 20% of businesses will be substantially provisioned with on-premise collaboration and communication capabilities.” In the broader world, on-premise collaboration solutions are an endangered species. Not with Jive.

 

That said, we intend to make changes designed to create at least some of the same kinds of simplifications and legacy dependency eliminations as we’re doing for Jive cloud. To that end, here are a set of things specific to on-premise and hosted customers we’re working on right now:

 

  • Today, we have customers running 22 different versions of Jive HOP that include over a thousand plug-ins and customizations. We want to get as many customers as possible onto a single version so that our product development effort is singularly focused and not enervated through division.
  • To do this, we are building multiple, automated upgrade scripts that will enable a simple, low cost, and low risk upgrade paths from each of the 22 different versions deployed in the field so that customers running mostly stock versions of the software can easily upgrade to the latest version.
  • For customers using one or more plug-ins and customizations, we are also determining which of these have sufficiently broad utility such that they can be productized as add-ons to the latest version (and in cloud). The goal here is to ensure that for the most common customizations, customers can move from custom code to supported product code, and from on-premise to cloud.

 

The end result of all of this work is to get as many customers as possible to the latest version so that we are in a highly supportable, stable state and are then ready for forward movement.

 

So once we have all HOP customers on the most stable jumping-off point, then what?

 

The number one and preferred option for customers looking for the fastest pace of innovation and the most exciting roadmap and direction – all of the things we’ve been talking about in this blog series – will be to consider an eventual migration to the cloud version. While this won’t be the right answer for all customers, we believe over the long-run it will be the answer for most.

 

There are generally three reasons why Jive customers remain on-premise or in a hosted environment:

  • Unique security, compliance, or other corporate policies that formally preclude consideration of public cloud related applications. In our experience, this is becoming an increasingly small minority of customers. It is rare to find a Global 2000 company that has not embraced cloud technology somewhere in their business. Nevertheless, it does still exist, particularly in government and certain highly regulated industries.
  • Highly customized deployments that make migration to a standard cloud instance expensive or involves significant functional tradeoffs. This is real. Many customers have heavily customized Jive – themselves, with partners, and with Jive professional services. Our research into this issue suggests that there are thousands of Jive plug-ins and customizations, some of which are intrusive and amount to hacks of the source code.
  • Good old-fashioned inertia. Or, to be more diplomatic, a cloud value proposition that is not sufficiently compelling to warrant the cost – financial, political, technical – of change.

 

Let’s talk about these in inverse order.

 

For customers in the last two situations for which there is really no policy barrier to cloud adoption, we believe it just comes down to us creating enough compelling value in the Jive cloud product to warrant the pain of change. And that is a good way to think about our intention. We are going to create so much innovation over the next three years in the newly re-architected cloud version of Jive based on PeopleGraph that we believe you will race to adopt it. This is not “forcing” customers, it’s enticing them. It’s on us to deliver a product that is so awesome it overcomes the forces of inertia.

 

For the small subset of very large customers that have customized Jive to such an extent that it has nearly become a different solution - supporting unique use cases that will not be replicated in our cloud offering - there are two possible options.

 

The first option is that the value proposition of the cloud offering ultimately becomes so compelling that it overwhelms the utility and value being delivered by the customized on-premise deployment (this is our hope)! This may take 6 months or two years, but as we continue to innovate the cloud version will get better and better, enticing more and more hosted and on-premise customers to adopt it.

 

The second option, appropriate for a small subset of highly customized hosted or on-premise customers – may be to begin treating the Jive deployment as what it is – a bespoke, home grown solution with Jive at its core. For these customers, the right solution may be to call a spade a spade and work with the customers to support it as such – certifying the customizations and building a unique, tailored roadmap that is focused on the customer’s core use case and business value thesis. And certifying the customizations is important – this basically turns unsupported, bespoke code into testable code that we “certify” and support through the upgrade process. It provides highly customized and configured installations with the same level of quality assurance we aspire to deliver for stock software. Note this path is really only appropriate for large customers with the resources to support what amounts to a single customer product, but our Gold Concierge Program is this scenario, and for a small group of customers who have effectively turned Jive into something else it may be the appropriate approach.

 

This leaves the last group – those with unique security or compliance policies that preclude a public cloud deployment. For these customers, our intention is to create a new product (we are provisionally referring to as Jive HOP Enterprise Edition) that will focus on and cater to the unique business requirements of this niche market. We have, in fact, already branched the code base to begin initial planning work, but we don’t intend to ship a first version of this product until 2020. Like the cloud product, the technology decisions will be unencumbered by the past (thus the branching of the code), and the product will have unique features (such as a completely revamped content archiving and features related to risk analysis and compliance among their employees) that are hyper relevant to this market segment and will not be available in the cloud version (primarily because they are features that are not valued by the vast majority of customers). We’re very early in the planning for this product, as most of our focus through the remainder of 2019 will anchor on the cloud product. That said, Jive HOP Enterprise is coming. It will be the first completely new on-premise collaboration product in nearly a decade.

 

Bringing It All Together

I’ve thrown a lot of things out in this blog post, so let me summarize what I believe to be the most important take-aways for customers:

 

  1. We believe the public cloud operating system is the single most important technology trend of the last decade (vastly more important than “big data”, “blockchain”, or a host of other tactical technologies that get infinitely more coverage in the technology media).
  2. We are building the future architecture of Jive on native AWS technology – breaking with the constraints of the past and opening a future of high quality, stability, and rapid, meaningful innovation.
  3. We remain 100% committed to our on-premise and hosted customers and have no intention to end-of-life hosted or on-premise versions for the foreseeable future. We will be taking steps in get all of these customers to the latest version to increase stability and quality and maximize functionality.
  4. We intend to launch, likely in 2020, a new Jive HOP Enterprise Edition that will focus on the business requirements of customers with unique security and compliance considerations (governments and highly regulated industries).

 

We expect over the next three years to bring a pace of innovation that, as Jive customers, you haven’t seen in five years or more. We are keenly aware that you’ve been thirsty for innovation for several years. We also recognize that taking the “two steps back” decisions since acquisition have exacerbated that. But all these decisions have been taken in the interest of creating forward momentum. While it was simply not possible to do so where Jive was, we will be uniquely positioned to do so based on where we are going today.

 

We are beyond excited about the future, we look forward to rewarding your patience and we are grateful for your continued confidence.