This is the third and final post in a trilogy about how enterprises can solve the challenge of managing and configuring their increasingly complex business application suites. Read Part 1 and Part 2.

Business applications just became less difficult

We often don’t know how difficult our life is except in retrospect. Consider electricity. Air travel. Computing. Big advances throw the past into stark relief. I think we’re very close to a new period like that now within business applications.
‍
In Part 1 of this series, I discussed how the frameworks pioneered in DevOps and software development apply rather neatly to business applications management. In Part 2, I explored four specific ways to apply it, with one open thread—you need a way to translate your systems into code. In this final installment, I’ll share precisely how companies tie off that thread with Salto.

With it, you may realize that the way you’ve been managing business applications has been, in retrospect, difficult.

‍

How we turned companies into code

Let’s return to that final point I made in Part 2, where I explained the absolute necessity of applying the same process for managing one business application across all. As SaaS grows, there will only be more systems. More complexity is inevitable. You have to simplify with a common framework now, and get all those systems under control.
‍
At Salto, we believe the best way to do that is to turn all your business applications configurations into a sort of code. It’s the only way to make them comparable and interoperable.
‍
And by code, we don’t mean any existing coding language. Salto is built on a human-readable or “semantic” code called NaCl that extracts all your business systems’ configurations and translates them into one common declarative language. We call it “not another configuration language,” or NaCl.
‍

We designed that language with six goals in mind:

1. Create a strong, extensible type system

This is crucial for business applications where you can define custom types, such as custom objects in Salesforce, as well as instances of those types which take part in the configuration of the business application.

‍

2. Keep it human-readable

It would have been quicker and easier to simply create a language. But we chose to minimize syntactic boilerplate code so as many people as possible within the organization could understand it. To do this, we adopted the HCL syntax by HashiCorp to allow it to be text-diff friendly, or able to account for small semantic changes. This in turn allows users to easily use tools like Git. (See point #2 in Part 2).

‍

3. Make it customizable

NaCl is a language. And like all languages, it evolves based on the needs of those who speak it. We know we couldn’t possibly anticipate every possible need, so we made it easy for users to ensure fields adhered to certain constraints, such as text length. (To be specific, we incorporated built-in and customizable validators into the core language semantics.)

‍

4. Make it referenceable

Every configuration element in NaCl has a unique referenceable ID, enabling the language to encode strong dependencies between configuration elements, within a specific business application as well as across those business applications.

‍

5. Make it flexible

We wanted people to be able to make changes within the editing tool as well as within the business application—whichever suits your preference. We call this “dual work” mode, and it’s a big departure from previous tools which forced users to always edit the declarative code. We recognize that business applications have lots of users and it’s crucial that if someone adjusts something in the business application, it reflects within the editor.

‍

6. Make it copyable

Business applications engineers should be able to work on multiple environments at once (dev, test, staging, production). We chose to treat environments as first-class citizens and allow you to clone configuration elements from one environment to another, or to easily compare environments to see what’s changed.
‍
The sum of these goals is a language that achieves precisely what we hoped to set out to do—translate all business systems configurations into a sort of “common language” that makes them all comparable and interoperable.

When your systems are comparable and interoperable, you can bring all the power of DevOps to bear. As I’ll explore next, many companies are doing this—and so can you.

‍

A real-life example of Salto’s open source project

Torq is a no-code automation platform for security teams. The incident responses tasks you used to have to kick off manually—say, isolating a threat, locking users’ devices down, or detonating an attachment—Torq can string those together and run them for you in an automated flow.
‍
With such a pro-automation outlook, Josh Thorngren, VP of Growth there, was similarly interested in automating some of the more laborious aspects of their business application setup. He’s a multi-startup veteran, yet with just him supporting the entire company, he knew it’d be labor-intensive.
‍
“I have helped dozens, if not hundreds of companies with how they got Salesforce up and running,” says Josh. “But if I need to go into Salesforce and make an admin change, I still usually Google an article about how to do something. It's not easy.”
‍
But Josh tried Salto’s open source components and found it cut down that time significantly. “I know it sounds hyperbolic. But in terms of planned hours versus actual execution hours, Salto was a 75% reduction in effort,” says Josh. “I had planned to build out our new Salesforce instance to specification and ready for users over four days. In the end, it took me only one.”
‍
Now, rather than add things to the backlog and watch them pile up, Josh can change things within two hours. Now, everyone on the team can understand the “code” without him having to explain it. Now, he’s so effective that he may not need to hire—at least not yet.
‍
“I recently spoke with a fellow marketing leader and she asked me, ‘How are your systems keeping up with your growth? I’m sure you’re starting to feel the pain.’ And I said ‘Actually, we’re not—and I’m not sure we will feel that pain. Normally at this point, I’d be hiring for systems help, but that’s not even on my radar because of what I’m able to do with Salto.’ Which is to say, with Salto, it’s easy. There's a clear structure and a clear language.”
‍
Granted, Josh is an expert who knows the systems and precisely what he wants to achieve within them. That combination—business applications savvy plus Salto to view and make changes—is particularly effective. But anyone can try what he implemented.
‍
Here’s how to get started with Salto yourself.
‍

The future of business applications is now

This is only the beginning. We haven’t even begun to report on some of the interesting multi-environment operations or cross-business application use cases happening right now.
‍
(Nor does this account for Salto’s commercial application, which is fully hosted.)
I think it’s fair to say the world has transformed over the past 20 years. Businesses are using dozens of core applications and grappling with a never-before-seen degree of complexity and interdependence. When companies address that problem using principles already pioneered in DevOps, and do it with tools like Salto, I think we’re going to look back on any time before it as a time when life was very difficult.
‍
Like electricity, aviation, and computing, I think our lives may soon be unimaginable without it.