What if you had one dashboard from which to view and configure all business systems? And what if some of those configuration changes happened automatically, without intervention?
‍
That’s what Salto’s up to, and for a peek into that future, it’s worth reviewing the past. Because something exactly like this has happened in another industry, and it turned out great.
‍
This is the story of how a technology transformed cloud infrastructure, how the idea behind it inspired Salto, and why that insight has begun to revolutionize business applications. It's a useful history for anyone interested in the present business system mess.

‍

First, Terraform changed everything

In 2011, Terraform co-creator Mitchell Hashimoto dreamt up the idea that would become Terraform, then promptly gave it away. It was an exciting time. Amazon had just released CloudFormation, the AWS service that allows you to automate the management of some AWS infrastructure. The cloud was in ascendance, and infrastructure people were realizing that by virtualizing what used to be physical servers, you could run everything as code. So, for example, instead of fixing fans on server blades or untangling Cat-5 cables, you just, well, didn’t have to.
‍
That was a pretty big shift. But virtualized infrastructure quickly became its own mess. Every time you wanted to change something, you had to go into the software interface—sometimes 10-15 clicks deep—to make a change. And every interface was a bit different, so you couldn’t apply patterns across them. This became pejoratively known as “ClickOps.”
‍
This was more than an annoyance. It was:

• Prone to errors—which could create a compliance or security risk
• Easy for orgs to become silos
• Causing delivery cycles to drag on
• Causing quality to suffer
  

Hashimoto’s idea, which he wrote about in a blog post and “gave away”, was developing a universal language for making changes across different cloud infrastructure. It wouldn’t matter if you were building on AWS or GCP or Microsoft Azure—it’d still work.
‍
Fast forward a decade and Terraform is now the default paradigm. Perhaps its greatest advantage was that by abstracting all that infrastructure into code, developers could apply the tools they used for writing low-effort, safe releases for software. They got to apply Agile, DevOps, Git tools, and more.
‍
Terraform allowed for:

• Faster releases and continuous delivery
• Visibility and collaboration
• Shorter delivery sessions
• Increased quality
  

Enter the Salto team. Our founders wanted to apply as-code methodologies to business systems, where many of the same cross-app management issues existed. But for all Terraform’s benefits, the team ran into insurmountable issues:

#1. Business applications can be modified: The assumption of infrastructure immutability cannot hold true with complex and no/low-code platforms such as Salesforce and Netsuite. The definitions of such applications can be updated by configuration changes that are done in the applications themselves. In fact, more often than not the teams in charge of these applications may prefer to make those changes in the application UI.  

#2. It was difficult to enforce its type system: There was nothing stopping people from misspelling fields or names and so creating lots of little errors that, overall, made things no longer searchable or interoperable.

#3. It didn’t allow for multi-environment workspaces: Or, it did, through directories, but then the main configuration and the state needed to be manually configured, which also wasn’t scalable. Later on, Terraform released the workspaces feature, but it’s not a full featured environments management solution.

So, the idea of infrastructure as code gave birth to a parallel, business applications-specific methodologies. This is implemented with a language that is based on Hashicorp’s HCL and differs in some semantics and operations that we’ve implemented in Salto’s core engine.
‍

Next, Salto united business systems

First, I’ll point out that Salto uses Terraform to manage our own infrastructure. We are ongoing fans. But we also use Salto to manage our business applications, and offer that as a SaaS service to customers, because we’ve taken those innovations further and created an entirely new universal language for business systems called NaCl, or “not another configuration language.”

Based on HCL, NaCl addresses the chief issues business systems managers face:

#1. Universal configuration language with Dual Works Mode: Rather than build from scratch (or templates) in each system, Salto provides one language that works across all supported business applications. That is, you start with the pre-built infrastructure for Salesforce, NetSuite, Jira, etc. And second, Salto’s Dual Works Mode means you can work in the application’s interface or in Salto, and it’ll keep both up-to-date. If someone modifies something in Salesforce, it’ll update the NaCl files.

#2. Strong, extensible type system: Leveraging NaCl, Salto offers a unique capability that allows users to define custom types with built-in validations. This enables the safe representation of any configuration in NaCl. For example, if your company’s products are represented in Salesforce, and each product has its own category, then Salto will use your company’s definition of a product to alert in the event a specific product is missing a category. This supports powerful tools such as auto-complete and pre-deploy validations, that help avoid an otherwise long and cumbersome configuration process.

#3. Simple multi-environment management: In Salto, we allow you to host multiple environments of your business application (what we call “a service”) within one workspace. You can create environments for dev, staging, UAT, production, etc., and manage your complete application lifecycle in one place.

What all this means is business systems managers now have access to the power of software development, and everything Terraform allows for infrastructure, via Salto.

‍

Where it goes from here

Salto is at the early stages of revolutionizing business applications management—doing things like reducing the effort required to implement Salesforce by 75%. We’re making application management as easy as Terraform has made infrastructure management.

And who knows. Maybe someone will apply the idea behind Salto’s universal language to another area next.