This article is based on an interview between Mariia Onyshchenko, the Product Marketing Manager at Exalate and Jorden Van Bogaert, the Atlassian Service Delivery Manager at Brainsquare.
Jorden Van Bogaert is the Atlassian Service Delivery Manager at Brainsquare — an Exalate Partner that designs, develops, and manages complex, critical application landscapes. During our meeting, Jorden shared his thoughts about using integrations and why Exalate is an excellent integration solution.
I started our discussion by asking Jorden why companies choose one particular integration from the sea of available options.
“Teams working in different systems need to align their efforts to bring everyone together into one system.”
Jorden Van Bogaertm Atlassian Service Delivery Manager at Brainsquare
Jorden further elaborated that normally, the requirement is to have one system as the single source of truth, even though teams work on different systems, so all information syncs to a central place where they report.
I then asked him about the main hurdle with choosing a central system, to which he responded with an example. Suppose a partner is trying to convince one team to move from one system (Jira, for example) to a new one (ServiceNow) or vice versa. They need to address the question: “Can we optimize it so we can just work in Jira, and they can do their stuff in ServiceNow?”
In such scenarios, a tool like Exalate can break this impasse by making sure both teams stay on their respective systems but still share data smoothly.
This led us down the path of using REST APIs for integrations. I learned that customers usually encounter issues when building something independently. In Jorden’s opinion:
“They [customers] need to make it work bidirectionally, and with REST API, you can only push things. You also need to get things. But the problem with this option is that it will cost you a lot more even though it is feasible. You are basically rebuilding Exalate.”
While discussing customer experience, I found out that customers often inquire about the usability of Exalate—and their main concern usually revolves around scripting. Some customers don’t want anything to do with code, while others want access to advanced configuration and scripts.
“I needed the possibility to do advanced configuration, [but] the other tools I have tried were either too limited or way too expensive,”
added Jorden to buttress the point.
Still on the issue of advanced configuration and scripting, I was amazed to find out that devs enjoy using Exalate because it allows them to translate one programming language to another. And since most use cases, even the ones that customers consider basic, often end up requiring additional configuration, a tool like Exalate covers most of the custom coding.
“You can script everything. Well, I’m a big fan of scripting. I really like it because it supports almost any use cases.”
Said Jorden, in regards to Exalate’s flexibility being another key selling point for customers.
Taking a breather from all the coding talk, I shifted his attention to the Exalate UI and visual field mapping. Jorden explained to me that these features made it possible for users to know what to map when customizing the script for specific use cases.
“To make it easy, you need to sacrifice a lot. You can make everything clickable in UI, but that means that you’re going to make a product that defines the use cases for you. And I think people want challenges as well.”
We then drifted back to the technical side, discussing Exalate’s distributed architecture.
“That [Exalate’s distributed architecture] is one of the selling points we use, especially when it comes to linking two partner companies–they want to make sure that the other partner does not need access to their environment.”
Unsurprisingly, I learned that companies are particular about Exalate sending their data to partners unless given permission to do so. Essentially, the entities syncing data can independently control what goes over and what comes in.
I followed up with the question about how customers’ appreciation of how the Exalate console gatekeeps the data for all sides involved in the sync. In Jorden’s view, this feature helps maintain transparency by ensuring that both sides of the sync approve any changes to the script.
“If they change something on one side, Exalate will throw an error. It sounds bad that it breaks, but it doesn’t break. It stops until you fix it,” he emphasized.
When I finally broached the pricing subject, Jorden conveyed that prospects react neutrally to Exalate’s pricing. So every time they send a quote, there weren’t really questions. He thinks it was an expected price for what we said we could do with it. He also emphasized on Exalate not being in the high-end price range compared to other premium solutions.
Then I asked if customers were skeptical about involving Exalate partners whenever they needed integration solutions.
“It seems like [Exalate] is not self-explanatory. It is not. Because it is as complex as your use case”, Jorden added, underlining that Exalate could take a lot of time and tweaking to figure out. Alternatively, a partner could get customers started without breaking a sweat.
And with that, we landed on the usefulness of partners. Jorden also buttressed their importance by discussing how to set up triggers and translate the use case to code based on the outlined sync rules.
“The partnership is very useful in terms of understanding how the integration behaves and helping the users with their experience. For instances, understanding why Jira suddenly has a different status than ServiceNow.”
All in all, my conversation with Jorden showed me the importance of partners as intermediaries between Exalate and customers.
Jorden said that sometimes customers might think that something is not synced properly and then they might try to prove that its configuration is very difficult because it seems like Exalate didn’t handle it properly.
Well, that is where partners excel; they help understand what the customers want, which helps in mapping the required fields. And most importantly, the admins of both instances retain control over their spaces.
