What is DevOps?—business systems edition

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.
‍

‍

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.)
‍

‍

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, 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:

• Tracks issue tickets
• Records the rationale for changes

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.