Imagine you work at a midsize company where sometimes, things in the CRM break. This week, it was the configure, price, quote (CPQ) tool. For five harrowing days, nobody could send a sales contract. Your inbox exploded with requests. It was not fun.
And let’s say there was no way to fix the CPQ system but to uninstall and reinstall it, which erased templates, data, and contracts right at the end of the quarter. And nobody knows why the reset worked. How confident would you feel being the CRM’s owner as this company enters hypergrowth?
Enter DevOps. It’s a methodology. It’s a vocation. It’s the fusion of the words “development” and “operations.” It’s a fix for the story above because it’s a process for testing and releasing configuration changes iteratively and frequently, to work faster and reduce errors.
In this guide, we explain DevOps in business systems and share some great places to apply it. We also provide a list of tools you’ll need and offer a mild warning—you will run into limitations trying to apply it in your business systems, but we’ve also got clever workarounds you can try.
The practices that became “DevOps” solidified in the early 2000s among a group of software developers who were exasperated about how disconnected their processes were—particularly between “dev” and “ops” people. These teams had different practices and tools, and for all intents and purposes, spoke different languages.
Developers would build applications and features, but launching them in one big monolithic release was so much work—and there were so many uncontrollable variables—they’d struggle to coordinate with operations people and those releases often failed. Right up until the last moment before a big software release, operations people would be reporting bugs that developers would have to scramble to fix. The two groups had such different methods, expectations, and processes, it was difficult to work together.
They were constantly "throwing things over the wall" to one another and the result was growing hostility and competition.
Just some of the challenges this created:
This exacted a heavy toll on the customer experience. Software built this way tended to have many bugs and it took a long time to get new features to customers. It also made for an aggravating developer experience, and developers often sparred with operations people. In an attempt to fix it all, a few developers ran an experiment to merge development and operations into a single practice, built upon Agile.
The core idea was to systematize all the steps in a release, and where possible, automate them. It also involved saving snapshots of the code base so anyone could “undo” their changes.
Within four years, what started as a small talk about “DevOps” at a coding conference grew into a global movement. Now, a decade and a half on, it’s also standard practice in business systems. Everyone wants to merge development and operations.
At its very simplest, DevOps is the idea that you should be continually improving your process to reduce effort, speed up work, and eliminate errors. The DevOps practices, methodologies, and tools you hear so much about are all attempts to apply that logic to software development and business systems.
DevOps is ever-evolving. It isn’t something some company has trademarked. You can’t buy it. There is no singular, authoritative guide. It’s a mindset and a culture.
And if DevOps advocates truly had their way, DevOps will eventually make itself obsolete. Carried to its logical conclusion, you'd reduce effort so far, and make deploying configuration changes so close to automatic, DevOps would cease to exist. You wouldn’t need a word for it. It’d just be called “doing work.” To some extent, this is already happening. Engineers hired to migrate servers to the cloud tend to make their own job obsolete, and move into other roles. And companies like Netflix are increasingly hiring developers to be “full-cycle,” meaning they operate what they build.
At its very simplest, DevOps is the idea that you should be continually improving your process to reduce effort, speed up work, and eliminate errors.
Perhaps it’s already obvious, but there are a lot of similarities between building software and configuring business systems. Whether you’re writing code or using a no-code interface, you’re still manipulating software. You’re still reconfiguring it. The same potential for human error applies, as do all the issues that arise when someone builds something that someone else has to figure out and maintain.
Plus, as business systems start to offer command-line interfaces that let you write code to update configurations, the two fields are really starting to blur.
All this creates challenges for business systems managers:
Just as DevOps systematized code releases in software development, it can systematize configuration changes and feature releases in business systems. Around 2016, business systems administrators began borrowing DevOps practices, and that brings us up to the present.
There’s no one authoritative list of all DevOps practices, and to claim to create one might come across as dishonest. But for the sake of clarity, we’ve gone ahead and gathered some common examples, and just know that every situation is different.
Practicing DevOps in business systems usually means:
To do this, you’ll of course need tools, many of which do things the underlying business systems can’t do for themselves. In some cases, these tools provide functionality that native frameworks like Salesforce Developer Experience (SFDX) or NetSuite’s SuiteCloud Development Framework (SDF) weren’t built to do. For example, SFDX doesn’t currently allow you to test and promote changes to its configure, price, quote (CPQ) tool. But configuration management tools like Salto, which plug into SFDX and expand upon its capabilities, can.
In other cases, “DevOps for business systems” tools are limited by the underlying business application’s architecture. For example, because most business systems don’t have a clear “undo configuration change” function, there’s simply no way to roll back newly deployed configurations, with or without a DevOps tool.
Thus, practicing DevOps in business systems begins with understanding your business systems and their limitations, and assembling the tools you need to accomplish most of the “practicing DevOps” list above.
Tools you’ll need
There are lots of great tools today that didn’t exist three years ago. With just Salesforce alone, the funding marketing for Salesforce DevOps solutions was $39 million in 2020 and it sextupled to $276 million in 2021. (And that’s just Salesforce, which is just one of many CRMs.)
Today’s DevOps tools include:
1. A “developer mode” feature to turn your configuration into code
Most business systems have a developer mode (SFDX, SDF, etc.) that allows you to view your configuration in XML, which is, admittedly, not pretty. (A tool like Salto turns that into human-readable code that anyone can understand without training.)
2. A source control tool to store and manipulate that code
If you can export (or better yet, sync) your configuration code to a source control system, it unlocks most of the powers of DevOps. Think of this tool as a time machine for text files. It lets you search all your configurations across the entire code base like “CTRL+F” In a Word doc. You can find and replace things. You can see metadata that you cannot otherwise see in the interface. You can plug things into your source control system to automate pieces of your job, and see who changed what. And you can collaborate on changes with others.
A source control tool:
3. A business engineering platform (like Salto) to reintegrate changes
A source control system can’t “push” changes back to your business system, nor keep everything synced. A tool like Salto provides an integration layer to allow for what’s known as “dual works mode”—if you make a configuration change in the source control system, it shows up in the business system interface, and vice versa.
A business engineering tool like Salto:
4. Sandboxes to run tests
Most business systems offer sandboxes as a paid feature. You’ll need them to run what’s known as an application lifecycle—a series of progressively more realistic sandboxes in which to test configuration changes and features. Your business systems management tool can keep these synced to your source control system.
Here’s how to manage sandboxes in Salesforce, NetSuite, and Zendesk.
5. A ticketing tool
Such as ServiceNow, Jira, and similar. This helps you manage changes across a global team, and also serves as a record of the decisions behind changes, in case anyone ever wants to audit it. Your business systems management tool can link changes in the business system to tickets, so there’s a paper trail that can be useful for different things including compliance.
A ticketing tool:
6. A continuous integration and deployment (CI/CD) tool
Advanced teams may already use, or want to use, a CI/CD tool, which is essentially a workflow system. It allows you to define an ideal process or “pipeline” for releasing configuration changes, and then it automates much of it. For example, when someone promotes a configuration change, it’ll automatically run that change through a battery of tests, promote it to the next sandbox, and alert the next person that it’s their turn to review.
With your tools and application lifecycle setup, you can:
And that unlocks a whole lot of benefits, which we’ll delve into in the next section.
When you don’t have to click around in the CRM interface, you can make configuration changes much faster—even with a testing release cycle.
Fewer release errors
When you can search your entire configuration, it’s easier to spot errors and catch bugs. And when you use sandboxes, a release cycle, and collaborative reviews, you’re much less likely to allow bugs into production.
A DevOps process and tools may allow you to do some things in your business systems that you simply couldn’t do before. Like sync Zendesk sandboxes with the production environment, or understand the full “who, what, where, when” provenance of changes within NetSuite.
DevOps gives you previously unattainable visibility into what’s happening within your business systems. That allows you to leave a paper trail, audit people’s past work, and understand what change caused an error. (Remember our CPQ example from the beginning of this guide?)
With a well-defined DevOps process, audit history, and release pipelines, it’s a lot easier for junior people to learn how things are done, and become productive faster.
The great thing about DevOps is you don’t have to apply it all at once. If you buy into the idea that you should be constantly working to reduce effort, eliminate errors, and speed up configuration releases, there are lots of small ways you can start. Even without working with code or a source control system. (Though those help a lot.)
And if you only begin with one use case, let it be this: Start managing configuration changes in an application lifecycle. Setting a requirement to test things progressively before they’re released can change the culture of how people think through and communicate configuration changes.
And hopefully, if you find yourself managing a CRM through hypergrowth, it’ll help you avoid common errors. You’ll know who changed things, what impact it had, and why that CPQ reset fixed things, so you can prevent it next time.
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.