This is post two in a three-part series on how enterprises can better manage and configure their business applications. In the previous post, we explored how smart organizations are borrowing heavily from software development.

‍Presented with a tough problem to solve, any good engineer will ask, “Who has already solved this? Can I copy it?” That’s increasingly happening on business applications teams. They’re looking to the world of software development to DevOps principles like versioning, continuous integration, and automated testing, and seeing an uncanny resemblance and a whole lot of time-saving practices they can adopt.

What works for one can work for the other, with one minor hiccup: Today, nearly every business system resides on its own schematic island. And they don’t want to talk.

‍

Each application, a unique snowflake

The trouble with business systems, and the reason the complexity in managing them has skyrocketed, is that each considers itself the center of the universe. To an ERP like NetSuite, it’s the source of truth and all other systems simply revolve around it. Same with the CRM, the marketing system, and human capital management system, and so on. And this would be fine, were each of their structures comparable, but they are not.
‍
Their architectures differ, their objects differ, their rules differ, and their APIs differ. That means a device that allows you to identify field dependencies in the CRM doesn’t do so for every system. That means for each system “island,” you need your own processes, and often, specific teams to manage them.

So how can business systems teams make good the promise of adopting DevOps for BizOps? Here, I provide four ideas.
‍

1. Abstract every business application’s configurations into code

Translating your business application configurations into code does a few things. First, it makes those configurations comparable. Second, it knocks down all the application GUI walls and gives you one single source of configuration truth.

The advantages to this are many. When you can view all configurations, you can practice version control and audit everything that’s happened. You can also answer simple but heretofore difficult to answer questions like, “What else depends on this field, across our applications?” or, “Is this data definition consistent across systems?”

It creates, in sum, a common configuration language.

Now, the question that sometimes arises is, do you have to code it all? And luckily you do not. There are systems (Salto being one of them) that can extract your existing configurations into code. Such systems automate that exchange and make it trivial to audit and document changes, perform text searches across applications, and analyze the impact of further changes. You can debug, revert, and understand in a way that’s only possible when it’s all on one screen, as code.
‍

2. Manage your configuration code from a source-control system

The next bit of advice is to control the versions of that code. Code is easily edited, mistakes are possible, and things get messy when you have no way to revert. A source-control system (SCM) like Git is the business systems version of hitting “undo” in a word processor.

And what’s more, it also saves all past states, so even if you get many changes down the line and realize something is wrong, you can always revert to a specific point. It saves everything, which makes change a lot less risky.

Benefits of using an SCM include:

• An ongoing archive of all code changes over time, which lets you compare changes and identify where problems originated
• New team members access the complete history of the project and get up to speed quickly
• All changes are tied to the person who made them, which helps reduce confusion when different people are touching the same code at different times

Another significant plus to using an SCM is that it allows branching in a project. Branching is necessary when working on features, for instance, that would affect someone else’s concurrent work. With an SCM, each person can work on their features independently to ensure they run correctly by themselves before merging with other team members’ work. Team members can conduct code reviews and targeted testing on the feature branch without holding anyone else up if issues arise.
‍

With branching, you can maintain a clean history of who committed code that features only atomic changes—that is, grouping individual changes so they’re easier to understand when checking later. Atomic commits help keep the system in a consistent state.

Along with each “code commit,” individuals can leave messages. These commit messages are vital information about what changed and why. Always provide enough context to help guide anyone who comes along later and doesn’t have as much context as you do. Explain why the change was made, its effects, and any limitations it might have.
‍

3. Use different sandboxes for different stages of the development life cycle

Making changes to code can result in any number of outcomes, for good or ill. It’s important to have different environments in which to make and test out changes before deploying them to production environments. The sandbox has long been an apt metaphor in software engineering, and it’s no less critical today—in a sandbox, you can play around without causing any damage.

Many developers maintain four environments, the first three of them, sandboxes:

• Development sandbox—here, you can attempt radical changes without affecting the actual system
• Integration sandbox—allows all team members to commit their changes so that work across the entire project can be combined and validated
• Staging sandbox—an exact replica of the production environment (or as much as possible) so changes can be tested to see how they would operate in real life
• Production environment—once all changes have been integrated, tested, and finalized, they are deployed to the production environment

Traditionally, with business applications, it isn’t easy to use multiple environments (especially when there are cross dependencies between business apps). Vendors also often charge heavily for sandboxes. But this takes us back to abstracting all your configurations into code—when it’s all just code, you can use software development tools, and reap all the benefits of sandboxes.

‍

4. Deploy the same process for managing all your business applications

In order to scale the way you work on your business application configurations, it helps to have a clear process that spans multiple systems. With the “as code” approach, that’s actually possible. So whereas today, you may follow change management process X in Salesforce, Y in NetSuite, and no process in Jira, when it’s all code, you can enforce process X across all. This makes what used to be unscalable scalable, and eliminates the potential for human error.
‍
High level process:

• Perform the configuration change
• Examine its dependencies across applications
• In your version control system, create a branch
• Test the changed systems
• Review the changes and merge them back into the main branch
• Deploy the changes to the next environment from the main branch

Let’s recap. I began this series by talking about how software development tools and practices can be used to simplify and streamline change management in business applications. Next, in this post, I highlighted several core tenets that are vital to a successful project. In the next and final instalment, I’ll tie it all together to show how dozens of companies have used this methodology to drive outcomes for the entire business.