Imagine a world without DevOps. Everything that could be automated isn’t. Any job you dream up isn’t possible and, instead, you have to dig 10 to 15 clicks deep into a friendly but oppressive software interface to make every single change. Oh, and there’s no way to run searches.

Picture that and you have a good sense for what managing most business systems (CRM, ERP, HCM, MAP and other three-letter acronyms) are like today. They’ve been designed to make things easy on users, not efficient for administrators and it forces admins to work out of a schematic island—the interface—where no-code conventions rule.

Yes, there are developer modes, but they aren’t the cure-all you’d imagine. Your business likely has 800+ business applications and whatever you build in one you have to rebuild in all. Not all have dev modes, and no two dev modes use the same language.

This is all to say that, unless business systems get a universal language that works across all of them, businesses will be in deep trouble. I talk to lots of companies about this and many already are.

The Cost of Chaos

If you think about all your business systems together, they constitute a sort of “product” upon which the entire business runs. When that product is built out of 800+ services that can only be governed individually, you have a lot of problems.

As examples, companies I talk to have experienced the following horrors: A minor change caused sales leads to go unrouted for six months. Those leads grew stale, and the company wasted both the money spent acquiring them and lost millions in potential business. Another found that changes in their CRM created an error in the ERP and invoices didn’t go out until after the quarter’s end. (You should have seen the investors’ reactions). Another had a minor error trigger a dormant email campaign that blanketed their database with out-of-date offers. 

This list could go on and on, and the effects are real. From managers who lost out on rockstar candidates because the HR system was undergoing maintenance and they couldn’t send an offer to arcane DOS-based internal systems that have become so enmeshed they are irreplaceable—business systems are vital, and most of them are a mess.

In fact, business applications teams face all the same challenges that software developers do, but benefit from none of their tools. They can’t search through one formal representation of all their applications’ code. (To say nothing of searching across applications.) They can’t easily back up, save versions, collaborate or evaluate PRs except within each system’s frustratingly isolated dev mode.

As a result, they often can’t: 

• Simply see a blueprint of how things are set up today (especially across applications)
• Analyze impact across systems (there are tools, but they’re always app-specific)
• Save versions and revert to a prior state
• Run “find and replace” searches for settings buried 10 to 15 clicks deep
• Figure out who did what, where and why (a real problem for SOX compliance)

This would be all well and good if business systems were due for a sudden and rapid consolidation, but they’re not. They’re so not. The SaaS market is still growing at 19% year-over-year and some sub-markets are growing faster, like MarTech, at 25% year-over-year. It’s given rise to tragicomic diagrams like this one by Chiefmartec’s Scott Brinker. Companies are buying and relying on epic levels of SaaS. 

Moreover, today’s business systems accumulate in vertical stacks. The financial applications team owns the ERP and other financial applications like Stripe and Zuora. The Salesforce team owns Salesforce. But business happens horizontally. Leads go from marketing to sales to finance to customer success. All those siloed applications aren’t really built to allow administrators to create a reliably error-free “product” out of all that. Unless, of course, we get a universal language.

A Plea: It’s Time for Standards

I find it pretty unlikely that any one SaaS vendor is going to lead the charge for universal conventions for managing and configuring business applications. Each SaaS company views itself as the center of its own universe, with all other apps revolving around it. Their app stores reinforce that viewpoint. 

It’s going to take an open source third party to build such a system, but here’s what having a universal language for managing your business systems can mean: You get DevOps across all your business applications. 

To the Salesforce developer who couldn’t care less about NetSuite, that’s fair. But what if I told you that with this standardized language, everything you know about managing Salesforce could be applied to NetSuite if you were pulled into that project? Or vice versa? It’s a lot like suddenly being able to speak an entirely new language. 

For the heads of departments whose purview spans applications and those who are already rearranging their teams to figure out how to be more agile and support the business, this is (potentially) for you. It doesn’t connect your applications (you’ll still need a Workato or a Boomi, for example), but it’ll give you and your team one view into how multiple applications are configured, and the ability to make changes and push them into production without going 10 to 15 clicks deep into the interface. 

It allows you, in essence, to apply all of those DevOps practices you’ve been growing accustomed to in each dev mode across multiple systems. You can run searches, use a Git versioning tool, practice CI/CD, automate documentation, conduct impact analysis and scale your efforts. 

Imagine a business systems world with DevOps. That’s possible, and I’d love for you to check it out and give us feedback.