Product history

Kinetic Data started as a consulting company, helping large complex organizations create and improve applications on top of the BMC Remedy Platform. After a number of years of doing this consulting work, we recognized patterns. Customers needed to provide web interfaces to their employees that allowed them to participate in processes.

Kinetic Survey

In 2008, Kinetic Data launched its first product, Kinetic Survey which allowed organizations to quickly create surveys that could be sent out to employees when an event happened (a ticket got closed, an order was placed). This product was built on top of the BMC Remedy platform, which didn’t have a flexible surveying capability.

The application allowed administrators to build forms to collect input from end users and then trigger the survey to be sent when something happened in BMC Remedy. Frontend developers could also customize the UI (add a header and style how the forms looked).

Kinetic Survey was a Java web app that stored its data in the BMC Platform.

This was a great tool that filled a gap in the BMC Remedy platform and could easily be sold to any organization that was using this platform internally.

Kinetic Request

As time went on, customers started building some pretty neat things. Not only were they using surveys to collect feedback, but they were also building “surveys” that would kick off a process. Enter Kinetic Request.

The primary use case for Kinetic Request was self-service. Companies wanted to allow users to “do things” without picking up the phone and calling a help desk. They realized they could save a lot of money by allowing people to self-serve.

Kinetic Request was a “sister” application to Kinetic Survey. It shared a very similar architecture but was geared toward creating catalogs of things that people could quickly request. With Kinetic Request, companies could create forms and beautiful UI’s that were like Amazon.com, but for their organization.

Kinetic Calendar and Kinetic Schedule

Kinetic Calendar provided companies with a way of visualizing time-based data within a Calendar. It was a pretty lightweight Java application that had adapters that sourced data (originally just from the BMC Remedy platform) and drew it up in a simple Google Calendar-style format. You could even overlay multiple data sources together, allowing companies to spot anomalies or conflicts.

The use case that started Kinetic Calendar was IT Change Management. Organizations wanted to see all of the changes that were being scheduled for a given date in a calendar view so that they could quickly identify conflicts (you don’t want to be patching the database while installing an application update).

Kinetic Calendar, combined with Kinetic Request, allowed calendars to come to life. You could click on an event and edit it or click on an empty spot to schedule something.

Kinetic Schedule simply was a twist on Kinetic Calendar. It allowed builders to source time-based as well as “resources” and lay it out in a Gantt-style view. It was commonly used for scheduling people, like a doctor's office may schedule nurse coverage.

Kinetic Response

Up to this point, all of our products were focused on well-established or predefined processes. But what about when a company just needs a way to collaborate in an ad-hoc fashion?

Kinetic Response was a great idea that we prototyped but never really took to market. You can think of Kinetic Response as a precursor to Slack. It allowed you to create “issues” and then invite people (both internal and external) to participate and collaborate.

Kinetic Task

Kinetic Survey and Kinetic Request were both built on top of the BMC Remedy platform. When users would fill out a form, that form can only really interact with the BMC Platform.

Customers began asking if Kinetic could be a one-stop shop, not just for interacting with BMC Remedy but also for other systems. We realized we needed a workflow engine — and that’s where Kinetic Task enters the picture.

Kinetic Task was released in 2010? as a framework that allowed administrators to build workflows that would wire together the steps of any process they wanted. Steps were effectively mini ruby programs that would accept inputs and return outputs (we call these “Handlers” — you can think of them like plugins).

Kinetic Task was originally built on top of the BMC Remedy Platform, but by version 4 (released in 2013), it was refactored to be independent of the BMC Platform, starting the trend that the rest of our products soon followed.

Kinetic Bridgehub and Filehub

As our customers evolved, they began having a strong desire to interact with other systems in real time. While Kinetic Task had a very robust integration framework, it was asynchronous, meaning that it wasn’t useful for sourcing information from external systems to create UIs.

To solve for this, we built another integration framework called “Bridging,” which allowed customers to reach out to external systems to do things like populate dropdown lists or build real-time dashboards. The idea here was that customers could define a “simple” data model in Kinetic and then map the model to the data being retrieved outside of Kinetic via a Java “bridge adapter.”

As customers began integrating Kinetic with more and more systems, it became burdensome to manage all of these bridge adapters, so Bridgehub was born as a “harness” to install and manage the adapters in a single application.

Filehub is pretty much the same as Bridgehub, except specifically built to work with files vs. regular “text” data.

Kinetic Core (aka Kinetic Request Core Edition, or Kinetic Request CE)

Kinetic Data realized around 2010 that our dependencies on the BMC Remedy platform would soon begin to hold us back. BMC competitors were popping up in the market, and as their market share began to deteriorate, so did our total addressable market (not many companies would buy and set up the BMC platform just for our products).

We decided to embark on a big project to rethink and rebuild the Kinetic Request product to make it standalone. We would architect it to be completely agnostic of the backend systems we were integrating with. We wanted this version to be able to scale to enormous volumes, be multi-tenanted, and be generic enough that customers could eventually build any type of business application on it (not just self-service portals).

We choose to write Kinetic Request CE as a Java application with a Cassandra backend. Cassandra was chosen primarily for performance, stability, and ease of maintenance.

Kinetic Platform

So, now we’ve got Kinetic Request CE (the front end), Kinetic Task (the back end), Kinetic Bridgehub (the front-end data integration system), Kinetic Filehub (the file integration system), and Kinetic Discussions (a real-time collaboration tool). Each of these apps had different user interfaces and required a lot of training to understand how they all worked together. We effectively created a bunch of microservices that could independently scale (which was great), but we didn’t have a way to easily package them for installation/upgrade or a single management interface.

In 2020 Kinetic Data released the first version of the Kinetic Platform (aka V5), which took all of the existing apps and bundled them using Kubernetes as the underlying orchestration platform and also provided a single admin interface that brought all of the different apps together to form a more consistent user experience.