This document goes in to the background on some of the packaging changes for the Jive SBS 3.0 release. It's specific to on-premise customers and does not apply to the Jive Enterprise SaaS environment.

Summary

New in the 3.0 release of Jive SBS, we've made a number of changes to the way the software is bundled, distributed, and installed. These changes result in an overall decrease in costs associated with installation, support, upgrades, maintenance, and even evaluation, while laying a foundation for significant future performance improvements. On the application layer, we now distribute a pre-packaged and optimized bundle of a Java runtime, application server, and the application itself available for the Linux and Solaris operating systems. On the database side, we support MySQL, Postgres, Oracle, and MS SQLServer.

For more information, please read the System Requirements page.

Introduction

In every release we look at the best ways to balance new features, improvements and enhancements with the need to make significant improvements in performance, maintainability, and ease of support. The 3.0 release of Jive makes no exception. We've made a number of changes in the way the software is bundled and distributed that make it significantly easier to install, support, maintain and even evaluate the product. We believe there are many benefits to these changes, mostly in the amount of time saved or cost expended to administer the application.

For years, we've worked with hundreds of our customers and partners to tweak and configure the application environment for optimal performance or integration. We also run a very large Enterprise SaaS infrastructure and have learned a number of best practices around application performance, security, and integration. With Jive 3.0 it's now finally possible to pass along those settings and configurations to our customers in an out-of-the-box way. We've removed the need to install and configure both a Java runtime as well as a Java application server - these are now bundled components of the Jive application. For shops with limited server-side Java expertise, this is a huge win. For shops already familiar with our software and its deployment, we've kept the important aspects: openness, configurability, extensibility while making upgrades and things like support patches much easier. On the database side, we're going to start taking advantage of database-specific code that will lay the foundation for significant performance gains.

It's also important to note what this is NOT. We're not distributing a virtual appliance nor are we creating a black box. At a fundamental level, we're packaging up a very common configuration of the application and making that the foundation to build on.

Finally, we've taken a critical look at the documentation for system administrators and as a result we've overhauled it. Alongside other documentation, we now distribute a Runbook which is a guide for system administrators. It covers all aspects of installation, maintenance, troubleshooting, security, starting, stopping, etc. It's basically everything a system administrator needs to know to successfully run the application.

This document looks at each area of change and how it's beneficial.

Areas of Analysis

We'll highlight five major areas:

1. Installation - the time it takes to install the application and who is involved
   
2. Support - the time it takes to diagnose the root cause of an issue
3. Upgrades & Maintenance - how often patches or upgrades are done and amount of time expected over the lifetime of the installation
4. Performance - how much faster the application performs or the number of pages it can process
5. Evaluation - the time it takes to evaluate and even rapidly prototype the application

We'll look at each area in-depth.

Installation

In the past, installation of Jive has involved a number of steps. At a minimum, we've relied on a properly configured operating system, Java runtime, and Java application server. Some enterprises prefer to set up standalone installation or some integrate in to existing shared environments. For standalone environments, it's necessary to download, install, configure and test each of the dependencies. Or, it might be a matter of using a corporate standard and requisitioning a new instance of that environment. We've provided installation documentation for this case and for the most part the installation is doable, but takes time and is error-prone. The time and effort involved with installation for a shared environment is usually greater. There are more people involved and some sort of capacity planning is usually done to understand the impact and needs of the application on the shared environment. There is also the usual amount of installation and testing. In either of these scenarios, it's possible to miss a step or to misapply the configuration options which means the software might not perform as well.

Now, with the changes in 3.0, nearly every configuration and component is packaged in one bundle. It can be installed via the command line or by double-clicking a file. This removes the risk of a misconfiguration and avoids the need to involve a lot of people to do the installation.

Every enterprise is different, but a common attribute of large enterprises is the various functional roles that exist within an IT organization. Third party software typically undergoes analysis from experts that cover things like hardware stacks, software stacks, network topologies, load and performance, security, runtime, database, backup, and interoperability. Because more of the environmental pieces are bundled together for Jive 3.0, the need for some of the functional groups goes away. Specifically, Jive bundles an entire runtime which is optimally configured out of the box. Depending on the size of your team and the number of people involved, these changes can shave days off of any evaluation or installation.

Support

Over the years we've helped hundreds of our customers troubleshoot and fix issues with their installation. Over that time we've seen a number of patterns emerge in support cases. Typically, time is spent diagnosing the root cause of the issue with the customer. Fortunately, the Jive application has a number of log files and other diagnostic tools that give insight into issues. Also, we rely on getting the right kind of information out of the application server, Java runtime, and database. Given that each customer environment is unique it can be hard to find the right information when you need it. In 3.0, we've drastically reduced the time needed to collect this information which means the amount of time needed to diagnose issues is significantly smaller. We included the the runtime environment, which allows us to know exactly where the right data lives. We have also included scripts so customers can quickly and easily collect and package the necessary information to be sent to our support team.

The other areas of support are determining the resolution, and applying the patch. Each bug is different which means each resolution is different. For this area, there isn't really any consistent improvement to make just because the application is packaged differently. However, with applying patches, we've seen improvements in the time and involvement needed for this. There are two sides to the coin - first, it helps to know exactly what version a customer is on. Because we ship the application as a complete package we can easily determine the base version and what, if any, patches or extensions are installed. Second, the packaging technique we use makes it easy to distribute patches and install them. We leverage proven, enterprise-ready techniques which reduces time and takes advantage of the skills your IT team has.

Upgrades & Maintenance

We work hard to fix any issues that come up as quickly as possible and we distribute those fixes in regular maintenance releases. We call those types of releases "minor" because we don't introduce new functionality and only fix bugs. We also do two to three major releases a year where we deliver new features and improvements. These are referred to as "major" releases because they introduce new features and improvements and our customers typically plan these upgrades more deliberately. We've looked at the process of how upgrades and maintenance is done and found some areas to make some improvement. The goal was to reduce the amount of times an upgrade takes.

We've been able to make the biggest gains in minor upgrades. In the 3.0.x series, future upgrades will be distributed in a way that makes it trivial to upgrade - essentially involving just a few commands. We've been able to make these gains because we package together more of the environment. Before, too much of the Java runtime or the application server was unknown to us so we had to rely on our customers to do much of the upgrade work. Fortunately, we've also benefitted from running an enterprise SaaS environment and we've incorporated some of the best practices for upgrades in to the application itself.

Bundling the software as one complete package helps both major and minor upgrades because it makes it easier to test. Further, the barrier to do rapid testing has been lowered because it's easier to copy an environment and easily install upgrades.

Performance

We listen to our customers carefully and the consistent number one priority is performance. Many of our customer run extremely large public communities, or intensive internal collaboration sites. Because of this the system has to scale. We take this challenge seriously and each release we look for ways to deliver more performance gains. For example, in the 2.5 release we were able to increase overall performance significantly and in some places up to 30%. While that's great, we're always looking to make more improvements to account for customer growth and new features.

As we looked for the next set of performance improvements we saw that we had to attack two places - the database and the application layer. For a number of years we haven't taken advantage of specific optimizations in the database layer. By consolidating the number of databases we run on, we're laying a foundation to be able to make those changes for future releases. The second place is the application layer. We have a number of performance optimizations we want to do but we felt they ran the risk of overly complicating installations, upgrades and support. By bundling the application as one stack with an included runtime we can mask a lot of future complexities.

Finally, as mentioned earlier, we've gained a lot of insight in to what it takes to optimally configure the environment for top performance and scalability. We're able to pass along these improvements in a pre-configured software bundle. This also makes future tweaks (distributed as regular maintenance upgrades) possible - the new tweaks or performance techniques can be easily pushed to an application deployment.

Evaluation

One of the overlooked areas of cost is evaluations. Compared to our competition, Jive is exceptionally easy to evaluate. For new customers, we've focused on decreasing the amount of time it takes to start a real evaluation of the software - that is, getting your colleagues or customers up and running and productive with the tools. A number of factors play in to this - installation, configuration, inviting colleagues, training, etc. Finally, the ability to rapidly prototype new features or use cases is an important consideration with community software. Given the changes we've made, the ability to do this has improved dramatically.

Planning for a successful employee or customer community means thinking about how the community will grow - not just in number of users but in functionality or use case. The ability to rapidly evaluate new uses cases is important and with the changes we've made in 3.0, you'll save a lot of time. Jive already has the ability to quickly customize the look and feel, add content, and tweak site templates through the widget framework. Now that the application is easier to install there's little barrier to creating a number of evaluation or test instances, making changes, then applying those back to the production instance. Further, doing any sort of capacity planning on an evaluation or test instance is a better real world simulation because you can be assured the software stack and configuration in evaluation is the same for production.

Summary

Over the years, we've focused on making our application as easy to install and as simple to use as possible. Now with 3.0, we've taken that to another level by focusing on delivering even more significant improvements in these areas.

For more information or if you have questions, please leave a comment on this document or email bill@jivesoftware.com.