When faced with a problem that is difficult to solve, any good engineer will ask, “Who has solved this before?” Can I copy it? This is happening more and more in business application teams. They look to the world of software development and DevOps principles like version management, continuous integration, and automated testing, and see a strange similarity and many time-saving practices.
What works for one can work for the other, with one small problem: today almost all business systems reside on their own schematic island. And they don’t want to talk.
For each application, a unique snowflake
The problem with business systems, and the reason the complexity of managing them has skyrocketed, is that everyone sees themselves as the center of the universe. For an ERP like NetSuite, this is the source of the truth and all other systems just revolve around it. Ditto with the CRM, the marketing system, the human capital management system, etc. And it would be nice if each of their structures were comparable, but they are not.
Their architectures differ, their objects differ, their rules differ, and their APIs differ. This means that a device that allows you to identify field dependencies in the CRM does not do so for every system. This means that for each “island” of system, you need your own processes and often specific teams to manage them.
So how can enterprise systems teams deliver on the promise of adopting DevOps for BizOps? Here I offer four ideas.
1. Summary of the configurations of each business application in the code
Translating your business application configurations into code does several things. First, it makes these configurations comparable. Second, it brings down all the walls of the app GUI and gives you a single source of truth about the setup.
The advantages to this are numerous. When you can view all the configurations, you can practice version control and audit everything that has happened. You can also answer simple, but so far difficult to answer questions, such as “What else is this domain in our applications?” Or “Is this data definition consistent across systems?” “
In short, it creates a common configuration language.
Now the question that sometimes arises is: do we have to code everything? And luckily you don’t. There are systems (Salto being one of them) that can extract your existing configurations in code. Such systems automate this exchange and make it easier to audit and document changes, search for text in applications, and analyze the impact of subsequent changes. You can debug, go back, and understand in a way that is only possible when everything is on one screen, as code.
2. Manage your setup code from a source control system
The next tip is to check the versions of this code. The code is easily editable, mistakes are possible, and things get complicated when you have no way to go back. A source control system (SCM) like Git is the version of business systems where you hit “cancel” in a word processor.
And besides, it also logs all past states, so even if you get a lot of changes down the line and realize something is wrong, you can always go back to a specific point. He saves everything, which makes the change much less risky.
The benefits of using an SCM include:
A continuous archive of all code changes over time, allowing you to compare changes and identify the source of problems
New team members access full project history and get up to speed quickly
All changes are tied to who made them, which helps reduce confusion when different people touch the same code at different times
Another important benefit of using an SCM is that it allows branching in a project. Branching is necessary when working on features, for example, that would affect someone else’s simultaneous work. With an SCM, each person can work on their features independently to ensure that they are working properly on their own before merging with the work of other team members. Team members can perform code reviews and test focused on the feature branch without delaying anyone if something goes wrong.
With branching, you can keep a clear history of code authors that only includes atomic changes, i.e. grouping individual changes together so that they are easier to understand when checking out. later. Atomic commits help keep the system in a consistent state.
With each “code commission” individuals can leave messages. These validation messages are vital information about what has changed and why. Always provide enough context to help guide anyone who comes in later who doesn’t have as much context as you do. Explain why the change was made, its effects and the limitations it might have.
3. Use different sandboxes for different stages of the development lifecycle
Making changes to the code can lead to a number of results, for better or for worse. It is important to have different environments in which to make and test 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 without causing damage.
Many developers maintain four environments, the first three being sandboxes:
Development sandbox: here you can attempt drastic changes without affecting the real system
Integration sandbox: allows all team members to validate their changes so that work on the whole project can be combined and validated
Intermediate sandbox: an exact replica of the production environment (or as much as possible) so that changes can be tested to see how they would work in real life
Production environment: Once all changes have been incorporated, tested and finalized, they are deployed to the production environment
Traditionally, with line of business applications it is not easy to use multiple environments (especially when there are cross dependencies between line of business applications). Vendors also often charge for very expensive sandboxes. But that brings us back to the abstraction of all your configurations in code: when it comes to just code, you can use software development tools and enjoy all the benefits of sandboxes.
4. Deploy the same process to manage all your business applications
In order to tailor the way you work with your business application configurations, it helps to have a clear process that spans multiple systems. With the “as code” approach, this is in fact possible. So while today you can follow change management process X in Salesforce, Y in NetSuite, and no process in Jira, when it comes to code only, you can apply process X to everyone. This makes what was previously non-scalable scalable and eliminates the potential for human error.
High level process:
- Make the configuration change
- Examine its dependencies between applications
- In your version control system, create a branch
- Test modified systems
- Review the changes and merge them into the main branch
- Deploy the changes to the following environment from the main branch
Letâs sum up. I started this series by explaining how software development tools and practices can be used to simplify and streamline change management in business applications. Then, in this article, I have outlined several fundamental principles that are essential for the success of a project. In the next and final installment, I’ll tie it all together to show how dozens of companies have used this methodology to drive business-wide results.
Gil Hoffer, co-founder, CTO, somersault