Sort by Topics, Resources
Topics
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Salto for
Business Engineering
Guides
How to Transform your Company with Business Engineering
The business applications profession is changing, and it demands systems thinkers. Read the 'Business Engineers' guide to discover the discipline transforming business operations.
Author
Yoni Argaman
12
min read
SHARE
Let’s say your business is building a bridge that cannot afford to fail. Who do you call? You call an engineer. They’re the people with patterns and a process to build repeatable, enduring systems.
Yet for some reason when it comes to their business applications, that critical infrastructure upon which the company depends, businesses don’t give the builders the tools or the credit they need to get the job done. Enter, the business engineer.
The new profession of business engineering is an opportunity for companies to take this work far more seriously. The more effectively companies launch, build, incorporate, and customize their business applications, the more capital efficient and competitive they are. As their business applications go, so goes the entire business.
What is business engineering?
Business engineering is the practice of employing people who treat your business applications (CRM, ERP, HCM, marketing system, and hundreds more) like one unified product, rather than a series of discrete systems. When people “engineer” these systems, rather than simply manage them, they’re able to design them to better support the overall aims of the business.
The people who do the designing and building are known as business engineers. Just like civil or data engineers, business engineers possess a systematic and repeatable process. They are always asking how they can automate tasks, eliminate drudgery, and build a more efficient and resilient “product” for the business to run on.
What do business engineers do? Business engineers implement versioning software to maintain non-production environments, conduct impact analysis, unify settings across environments and applications, and coordinate across teams. They ensure the CRM, financial systems, HR systems, and more all reflect reality—no small feat—and change those systems to support the business’ growth.
As this guide will explore, if having a team dedicated to engineering business applications sounds obvious, it is rare in practice. And doing it well in a world where the $572 billion enterprise software market and the number of applications are growing at 10% per year requires uncommon discipline.
(You might also like this: The Business Engineer’s Code.)
Why does business engineering exist?
To really understand the need for business engineering, you have to turn the clock back to the early 2010s to find IT teams warring over two conflicting hypotheses. Each proposed a different way to purchase and configure back-office systems.
One camp argued that the smartest thing to do for cost and interoperability was to buy a suite of applications from one big software vendor.
That vendor presented “one throat to choke” if things went wrong, and offered economies of scale. Sometimes, in order to sell one application, that big vendor would throw in more of its applications for free. While those applications weren’t the best in their category, at least they’d all connect. (In theory.)
"Business engineering exists to help companies build business application architectures that won’t collapse."
The opposing camp argued something very different. They said that every business unit should choose their own applications, regardless of vendor. Sales could use Salesforce. Finance could use NetSuite and Zuora. Marketing could use Marketo.
As we all know, the second camp won. It was known as the “best-of-breed” approach, and as unlikely as it seemed to centralized IT teams at the time, federated responsibility produced superior results. A similar evolution occurred with software systems architecture, breaking monoliths into microservices, with the same, efficient outcome.
With a best-of-breed approach:
- Each business unit chose applications with their own schemas and data structure
- Each of them heavily customized their applications
- Many business units, each their own complex applications, had to work together
But in business systems, best-of-breed also introduced a new challenge: a potentially crippling degree of complexity. This is the biggest challenge modern business engineers now grapple with.
The average enterprise uses 874 applications. - MuleSoft, 2021]
Let us be clear. At Salto, we believe the “best-of-breed” approach—the practice of every unit or team selecting their own enterprise applications—is a net positive. It makes every team their most efficient. But it requires careful planning and support for it to work for the entire company. If those systems scale too rapidly in their own silos, they can start to wobble, and the entire “architecture” can collapse.
Business engineering exists to help companies build business application architectures that won’t collapse, or descend into what Salto’s CEO and Co-Founder Rami Tamir has called tech debt paralysis.
What’s the cost of tech debt paralysis?
When your back office systems don’t change to match what’s happening in the business, you get recursive, work-halting errors with real-world costs.
We hear from our customers that CRM changes that should have taken hours drag on for weeks. Weeks turn into quarters, and sales teams start to miss their quarters because they’re spending so much extra time battling aggressive validation rules when logging activities.
We hear that simple errors in the marketing system cause workflows to fail, and leads go unrouted, or misrouted … for months. Or they cause an automated email to trigger for thousands of existing customers and endanger their shakiest renewals.
Discoordination among teams managing business applications is the norm, it appears, and that’s because these enterprise applications weren’t designed to allow many people to collaborate.
It starts like this: A company or team needs to solve a problem and begins using an enterprise application without considering how it fits into the broader context. They customize that application to fit their work, adding custom objects and essentially building “products” within it. Then that system passes through several generations of owners until the people maintaining it no longer know how it was built.
The application instance has evolved into a highly complex environment where it’s difficult for anyone to understand what changes will have what effects, or to coordinate work across teams.
And then, as if that were not enough, companies have to network several of those highly complex systems together to do business.
Take a customer relationship management system (CRM) integrated with an enterprise resource planning system (ERP) integrated with a human capital management system (HCM). Each is its own universe of conditional and dependent workflows and operations. Each has its own constellation of lesser integrated applications. Knit together, the equation is often staggeringly complex.
What effect might retiring a field in Salesforce have on accounting’s reporting in the ERP? What will adding a new field on an object do to forms across the company’s many digital properties? How might a marketing configuration change irreversibly delete customer records downstream?
Ineffective business application architectures drag down revenue. One organization we know of lost $13 million in bookings in the CRM because of a minor update. Another had an email go out to their list that cost them one-third of their subscribers. Many others have lost out on untold millions because it took so long to process leads. Others suffered big regulatory fines or failed to react to market changes. And this isn’t even to mention the billions of lost hours of duplicated work, or people manually completing tasks that should have been automatic.
"The application has accrued so much technical debt that everyone becomes paralyzed and the machinery of business slows to a grind."
When people become responsible for high-complexity business applications, their thinking tends to change. They grow reluctant to make any changes out of fear of what might break. A culture of hesitance develops.
Eventually, the application’s development no longer follows the business’ evolution, and accrues so much technical debt that everyone is reluctant to make any change. The business becomes paralyzed.
In this environment, a sole administrator can hold up the entire revenue organization because they can’t be certain what impact a change might have, and so they sit on a field change request for months.
Business engineers, and the practice of business engineering, exist to combat these issues. And the most effective way to combat tech debt paralysis is to eradicate it before it arises.
How do you address underlying issues to build business applications at scale?
We believe the only thing that can make “best-of-breed” work in today’s world is a team of business engineers. Only one team dedicated to designing how all those enterprise applications work, and planning for how they’ll work in the future, can address the challenges they create.
Here are those top challenges, summarized:
- Each business application has its own schema and speaks its own “language”
- Each business application is highly customized
- Many people are making changes, often, remotely
- There's no system or process for coordinating work across teams or business units
- Builders rarely have time to incorporate end-user feedback
- Many highly complex systems have to work together
- There is no way to retain knowledge (nobody understands the whole architecture)
- There is no way to understand changes to these systems
Developer readers may note that these challenges look eerily similar to the issues people face when building software—and they do. Parallels abound, and some of what works for software also works for managing business applications.
This is why so many business engineers have adopted practices from developer operations or “DevOps” to help them understand the potential impact of changes, de-risk those changes by allowing them to test and revert, and coordinate policies across environments and even systems.
DevOps practices also apply to engineering business applications
- Versioning and managing multiple environments
- Co-editing with branching, merging, and committing
- Impact analysis
- Documentation for complianceIncident response processes
One of the greatest challenges with high-complexity systems is of course not just that the systems are complex, but cross-app connections amplify that complexity.
If each system is unique, you can’t replicate what works within one across another, though that’s what you’d need to do if you wanted it to scale. If your sales engineering team spends a lot of time constructing a “product” within Salesforce built from custom objects, it’s not always straightforward (or possible) to map those objects, fields, rules, or workflows to what’s happening in NetSuite, even though that’s what a quote-to-cash process requires.
But DevOps methodologies can solve for much of this, and especially with the help of a new category of software known as business engineering platforms.
What are Business Engineering Platforms?
Business engineering platforms (such as Salto) make it possible to apply development and DevOps methodologies to business applications. They give business engineers both visibility and control, so you can actually understand how your systems are configured.
Salto in particular works by extracting the configurations and metadata from your business applications and translating it all into one common, declarative language. It provides visibility into how things are set up, but also controls, to make changes from that interface.
In combination with a versioning system like GitHub or GitLab, and a ticketing system like Jira or ServiceNow, Salto allows your team to address the top challenges business engineers face.
Business engineering platforms give business engineers the tools they need to bring their business applications under control. And for that to happen, many companies will need a new leader with the authority to make that happen.
The new role of VP of Business Engineering
To account for this new world of business engineering, we’ve gone ahead and defined a role to manage it all—the VP of Business Engineering.
A VP of Business Engineering’s most profound responsibility is uniting the business in agreement around what should happen within their business applications. Many will begin their job simply gathering internal teams. They’ll draw sales operations, marketing operations, billing operations, and more under one umbrella. And under them, a substructure of business system analysts, business systems engineers, and product engineers.
This has the effect of allowing the people on all those teams to talk. From there, the VP of Business Engineering constructs an organization that knows more about the business’ internal workings than any other team, and uses that ability to interpret requests from the business into a business applications “product” that works for everyone.
When they do their job well, the business systems reflect reality. And as reality changes, so do those systems.
You might think of the VP of Business Engineering’s responsibilities as falling into three categories:
- Design the system architecture
a. Choose the right systems, make them interoperable
b. Allocate responsibilities and define the team and processes
- Develop the solution and manage the applications
a. Define infrastructure and process for development, testing, release, and incident management
b. Ensure visibility, audit-ability, collaboration, reporting
c. Identify and reduce technical debt
d. Ensure biz app adoption
e. Analyze and optimize spend
- Hire, manage, and grow the team
- Gather stakeholders to ensure the business applications reflect, support, and enable what’s happening in the business
a. Act as air traffic controller for requests
b. Secure buy-in from every part of the business
c. Define the flows and diagnostics to be measured
d. Create a paper trail for changes, connect them to requests (especially for compliance)
They serve an entirely new role within the IT function—to re-centralize some of the control meted out to business units, and ensure that while every business unit gets to choose their applications, they all speak.
How do I get started with business engineering?
Business engineering as a field is growing rapidly. According to a 2021 report by MuleSoft, the average enterprise business systems team now supports 874 cloud applications. The enterprise software industry is growing at 10% per year. The number of connections between applications, and the potential for human error is increasing.
As such, business operations and IT teams everywhere are being entrusted with more and more authority. Ninety-five percent of business operations professionals agree or strongly agree that their work is becoming more important to their organization. Sixty-eight percent saw an increase in their budget during 2020, and yet 60% also say their top challenge is they don’t have the tools to get the job done.
The questions for these teams are: How will you manage an increasing number of high-complexity systems networked together, when that complexity will only increase?
How will you document, version, and ensure that bugs don’t make it into production? How will you understand the impact a change will have before you make it? How will you explain to the business how those applications are configured? How will you coordinate the development of tens or hundreds of enterprise applications across thousands of people around the world without falling prey to tech debt paralysis?
There is no one answer to it all. But understanding what it means for your company begins with business engineering.
What’s next?
Knuckles has suggestions
Enterprise App Configuration. Re-Imagined.
© Copyright Salto 2024 | Various trademarks held by their respective owners
