What is DevOps?—business systems edition
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.
Where did the idea for DevOps come from?
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:
Developers were measured on speed, and would leave bugs
Operations people were measured on accuracy, and slowed things down
There wasn’t a good process for finding bugs—before or after launch
Fixing bugs took developers away from other work
It was difficult to know who built what, and why they built it that way
There was lots of manual work, testing, and rework
Big issues would sometimes go unresolved
The divide tended to grow worse with time
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.
Search interest in “DevOps"
DevOps is about reducing waste—and even reducing DevOps
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.
DevOps also works for business systems configuration
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:
No good way to catch issues before they reach production
Difficult to collaborate—especially when configurers aren’t maintainers
Administrators make changes without consulting others
There’s no overall blueprint of the configuration
It’s difficult to know what’s already set up
There’s often no record of who made changes
It’s difficult to understand why things were configured the way they were
There’s no saved “past version” to revert to in the event of bugs
Difficult to audit and limited visibility
Issues, bugs, and a poor user experience
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.
How to practice DevOps with business systems
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:
Shipping and deploying small changes frequently
Using a source control system to maintain versions of your configuration
Collaborating on changes using forks, commits, and pull requests
Testing configuration changes or features in lower environments before “promoting” them to production
Rolling back changes to a prior “version” if you discovered a bug
Being able to view and search your entire configuration in one place
Keeping an immutable record of who changed what, and when
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.)
An example of a human readable code (Salto’s NaCl)
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:
Stores configuration versions
Makes your entire configuration searchable and editable
Allows for collaboration—copy, edit, review, and merge changes
A platform for doing even more in the future
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:
Allows dual works mode
Syncs and promotes changes
Sets alerts for when people make changes to important configuration
Manages multiple environments for the same service with the same configuration
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
, 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.
Top business systems DevOps use cases
With your tools and application lifecycle setup, you can:
Revert or “undo” faulty changes quickly
Set alerts for errors
Set alerts for when people make changes to an important configuration
Enforce a release pipeline for configuration changes (meaning, no more changes directly in production)
Link changes in the business system to tickets, so there’s an audit trail
Establish consistent cross-application policies
And that unlocks a whole lot of benefits, which we’ll delve into in the next section.
Benefits of DevOps in business systems
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.
DevOps is in your future
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.