Q. Hi, Sheela. Can you tell us what you do at LongJump?
A. I work on the support team, primarily focused helping customers with new application development. It’s a very interesting position because we learn about a lot of the different challenges business users and IT departments have and how they are trying to solve them on the LongJump platform.

Q. So what kind of applications are customers trying to build on LongJump?
A. Well, the best applications LongJump can support involve information management, passing information from one user to another, or pulling information from a lot of different people and sources to build some analysis or to trigger some actions around that data. It sounds simple, but when you factor in all the IT infrastructure that needs to go into these applications, LongJump’s Platform-as-a-Service solution really removes the IT management issues and gets to the heart of the business problem.

Q. How do these businesses usually handle these issues?
A. Most organizations don’t have time to think about their problems in a structured way. We see many of our customers going right to their Excel spreadsheet, rather than trying to model their situation in a relational way. Databases can be hard to use, especially when you start sharing information or trying to build reports. And with all the IT staff usually taxed with mission critical problems, a lot of the smaller, but still complex issues don’t get the time of day they need.

Q. And that’s the advantage LongJump provides…
A. Yeah. Definitely. Spreadsheets are great because they’re fast. But spreadsheets can become monsterous if you have a lot of related information. What’s nice is that the time it would take you to model the information in LongJump is about as fast as building a spreadsheet but you get the benefits of that relational data. Then you do all of your reporting or create actions on top of the data (like triggering an email or running a JumpScript), and you’re 80 - 90% finished with the application in most cases.

Q. So what’s the first thing someone should think about before they start creating an application on LongJump?
A. You have to start with the data, or even more basic, what’s the business problem you’re trying to solve. We had a business that was trying to essentially do a very specialized form of licensing and contract management. They have third party vendors, contracts, international use rights, and each of their products had different software and different distributors. They were managing the whole thing on a 1,000 column x 1,000 row spreadsheet with multiple worksheets. It was amazing. Completely color coded and everything.

Their problem was that they needed to make sure that their product managers could go into a geographic market and verify that a specific device, loaded with a specific software, sold by a specific distributor in that specific country met the licensing rights they had with their third party vendor contracts. If it didn’t, they were at a compliance risk and would have to either negotiate new contracts or pay a penalty. It would take them a couple of weeks to fully analyze the information when the dreaded compliance questions came up.

Q. How did they break down their monster spreadsheet into LongJump?
A. The first thing we asked them to do was individualize the different “players” in this problem. So a vendor became an object in LongJump, the device became another object, distributors another object and so on, until the all physical aspects of the problem were represented as data objects that could now be related.

Q. How long did that take?
A. Well, given that they didn’t spend their entire workday on it, it probably took them a couple of hours to think about how to break down the information in a relational way. That also included what field information to map out as part of that object.

Once that basic object data model was identified, building it in LongJump took minutes. Then we ran a few test records to it based on some of the data from their spreadsheet, just to make sure that information was completely linked. When we verified that the data pretty much looked like what it needed to, we started importing their data which took less than half-an-hour.

Q. But that’s just modeling and importing the data.
A. Right, but that’s the hardest part for most people — to learn to think relationally. But once the application is modeled and the data is imported, you can sort of let users ride the application on their own by adding reports and putting dashboards on their home tab to monitor information. They also added alerts to information themselves, so if a contract was coming due or someone added a new license, their core team would get an email alerting them using our Data Policies of the details. Plus, their product managers could get their own view into the data, see the products they were responsible for, and track and add their own information as well. That’s all stuff, if you have to create your own application platform from scratch, you’d have to compensate for.

Q. So that’s a basic application anyone can build.
A. Yes, basic, but still very complex. It just took a little forethought as to how information should be treated as relational objects. But once it’s done, you can’t imagine the time savings. They can now react to problems they know they need to act on, they can quickly look at just the information they need, and they can move on to other more important areas of the business instead of spending time combing and analyzing their data. And they have a single point of truth for their entire team to work from.