Gill Hoffer, co-founder and CTO at Salto, talks with SE Radio host Kanchan Shringi about a new persona — the Business Engineer — created by the rise of SaaS and adoption of best-of-breed business applications for back office systems. They examine the evolution of tooling for developers and IT and the parallels with tooling needed for the Business Engineer. For organizations to actually use such business applications, they must first configure, customize, or extend them to fit their internal processes. It’s not just something that organizations need to do when they onboard but continuously over time as the processes change. The people managing these business applications must understand exactly what’s going on there and to continue evolving, managing, and administering them; these are the business engineers. Organizations need methodologies and tools to build real functions, very much as we saw with devops just 10-15 years ago.
Show Notes
Related Links
- Salto’s blog: Business Systems Management Essentials Blog | Salto
- Guest’s linkedIn: https://www.linkedin.com/in/gilhoffer/
Transcript
Transcript brought to you by IEEE Software magazine.This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Kanchan Shringi 00:00:16 Hello everyone. Welcome to this episode of Software Engineering Radio. Our guest today is Gil Hoffer. Gil is the co-founder and CTO at Salto. Salto is pioneering the building of tools for the Business Engineer to control visibility into their business applications in a way similar to have DevOps revolutionized IT. In the past, Gil has been a VP Engineering at Oracle and VP R&D at Ravello Systems. Welcome to the show Gil. So happy to have you here. Is there anything you’d like to add to your Bio before we start?
Gil Hoffer 00:00:52 No, thank you Kanchan. Really great to be here. I’m excited to talk with you about the interesting things that we’re doing at Salto.
Kanchan Shringi 00:00:59 So Salto is pioneering the building of tools for the Business Engineer. I know the developer, we all know the IT Engineer and more recently the DevOps Engineer, NSRE. Who is the Business Engineer?
Gil Hoffer 00:01:15 That’s a great question, Kanchan. So as you know today, any modern business uses a very large collection of business applications in order to run their businesses. Applications like Salesforce for the sales processes or NetSuite for Finance or Zendesk for support, in any organization you would see anything between a few 10s to a few 100s of those. Now the thing is that in order for the organizations to actually use these business applications, they need first of all to configure, customize, or extend or develop to those business applications. So they’ll fit their internal processes. It’s something that they do when they onboard, but also continuously over time as the processes change. Now, someone needs to be tasked with actually managing those business applications, understanding exactly what’s going on there and keep on evolving and managing and administrating those. These are the business engineers. They take pride at managing those business applications.
Gil Hoffer 00:02:19 They need methodologies, they need tools, and they are a really an important part of any modern business today. In many cases, they will still go by some other names. You will get your Salesforce Administrators, you will have your NetSuite Developers, you would have your Zendesk Administrators. And one of the things that we’re realizing today in the industry is that we need to create a real home, a real category for these engineers. So they will take pride in what they’re doing. They will have the right tooling and methodologies, and will be able to build a real function very similarly to what we saw with DevOps just 10-15 years ago.
Kanchan Shringi 00:03:02 Because of course Salesforce calls it Salesforce Administrator, but if I’m a Salesforce Administrator, I’m also doing NetSuite administration as well, and perhaps a zillion other things. So I am way more than an a Salesforce Administrator. I am the Business Engineer is your point.
Gil Hoffer 00:03:20 In many cases, you will deal with multiple business applications, but even if you deal just with Salesforce, let’s say you’re Salesforce developer, architect or administrator, your day to day is partially in the domain of managing Salesforce or managing revenue or sales processes. But it also has a lot of more technical bits. How do you make sure that those things that you develop are the same things that you roll from your Sandbox to your production? How do you work as a team and review each other’s work? How do you make sure that you clean up tech debt, which keeps on accumulating in your implementation? All of those concerns, these are actually cross cutting concerns, which are not specific to Salesforce. And they’re part of the practice for proper engineering practice. And this is part of what we’re preaching here today. And the thing is that it is applicable across all different business applications. It doesn’t really matter if you are managing Salesforce or NetSuite or Zendesk or Oracle Fusion. Eventually in your day to day, the types of activities and challenges that you’re dealing with, which are coming also from Morph, an engineering type of challenges. They’re all very similar. They deserve similar tools and methodologies. Again, very similar to the way that things eventually evolved with software development and DevOps.
Kanchan Shringi 00:04:55 And we should talk about that, the evolution of just software developer tools and DevOps, but how did the Business Engineer person come to be? Is this fairly recent?
Gil Hoffer 00:05:07 Yeah, so we’re seeing that in many organizations today, you would see a growing organization in many cases, title the business applications organization. In some cases, some organizations would call it Information Systems. In some cases it would be still distributed across different business units. But what we saw is that as companies onboarded more and more SaaS business applications, as part of them having a best of breed strategy, we saw that those teams kept on growing. And in some organizations we’re seeing teams of 10s and 100s of people who are tasked in their day to day with managing those business applications. As more and more resources go to those areas, both in terms of administrators but also managers and obviously budgets, we’re seeing more and more focus in those organizations on those areas, which in turn leads, focus on being more efficient, having the right methodologies in place when you work.
Gil Hoffer 00:06:19 And these are the fundamentals, which eventually an entire discipline, such as business engineering is starting from. So it is very recent. We’re seeing it in the past few years or so from the organizations which are leading the camp and are much more advanced in the way that they’re managing their business applications, but judging from the past and how things also evolved with DevOps or with test automation or with infrastructure is code. Usually these become much more widespread as time passes because the rest of the industry realizes that it is an efficient and productive way to go to.
Kanchan Shringi 00:07:02 So let’s kick off with the history of the tooling for developers. If we can just work through the evolution, maybe then we can draw some parallels with DevOps and then the Business Engineer.
Gil Hoffer 00:07:16 Sure. I can try. I’ve been around the industry just for the past 20 years, but I think that we need to look much further into the past because people have been trying to program computers from the forties, give or take, right? And we’re seeing that in the late 50’s, early 60’s, I’ve been trying to find better ways to collaborate in teams. And that’s actually, if I remember correctly in 1962, first version of a Source Control System, right? Because development teams wanted to see how can they make sure that they can collaborate multiple human beings together on the same code base? It doesn’t matter that eventually the code based translated into punch cards or into other types of media, but the logical problem was how do we collaborate in a team and how do we keep track of the changes that we do over time? Because they matter.
Gil Hoffer 00:08:19 So starting from the 60’s, we kept on seeing methodologies being built on top of tools. If it was for source control. Later on, we saw bug tracking software. We saw testing started with how do we manage our manual testing? Switch went into automated tests of various set types. And then I think the main change started in the mid 90’s give or take. Back then the title was the software crisis, right? Why can’t we produce high quality software? Why we keep on having projects, which never end on time and we have quality issues, et cetera. And the human nature usually is to try and add more processes, more visibility, the dreadful waterfall processes, right from the 80’s and 90’s. And then at the end of the 90’s with the agile manifest on the entire agile movement, I think that the entire industry realized that there are much better ways to do that by utilizing first of all, common sense, but also much better tooling and processes. Hence born Agile, the reliance on automated testing in many cases. Fast forward a little bit into automating everything around deployment, around configuration management, around testing and monitoring.
Gil Hoffer 00:10:02 I think it’s interesting to see how in that relation to development, also IT evolved over the past 20 years or so, because I think that the piles there are also very, very interesting. If you go back, not that long ago, let’s say 15 years into the past, then many IT persons would start the day, literally holding a box. Doesn’t matter if it was a virtual server or physical server, then going into the data center, putting that box into a rack, opening an installation guide and start typing. And it would take them half a day to a day to install a new server with the latest version of software that they have to install on it? And then it was pretty much a repeat process. And obviously it wasn’t scalable. It wasn’t something that high performing high scale organizations could really deal with. And luckily enough, these were exactly the same days when we started to have APIs in front of everything.
Gil Hoffer 00:11:10 It started with virtualization with VMware and virtualization off compute and later on off networking and storage, and obviously went to the extreme with AWS, with Amazon Web Services in the public Cloud, which put every compute network and storage resource at the tip of our fingers with an API call. And what happened back then is that the real high performing organizations, they realized that they can actually bypass their IT and provision those kinds of resources. And on the way also import all the best practices that they used to know from development into the world of IT and Infrastructure. All of a sudden, if the definition of an instance on EC2 or server in the Cloud became a source file source control that you conversion, that you can take a design pattern from another company, let’s say someone has the best definition of a Redis cluster,
Gil Hoffer 00:12:22 it is encapsulated now in code. So all of a sudden that 50 years of advances in software development was almost overnight applied to infrastructure. And all of those methodologies around how do we make sure that whatever that we just developed in our development environment is the same that we deploy to our production, which was always applied to code. Now become exactly the same for infrastructure. How do we make sure that the team can review changes done to the infrastructure? Exactly the same thing that was done to code, was all of a sudden applied to infrastructure. And then this entire notion of started with configuration management. Let’s say with tools such as Chef Puppet and later on with Ansible, Salt, etc. which obviously went to the extreme with tools such as Terraform or Pulumi. which build themself on infrastructure is code, right? But if we pause for a second at the core of it, is all around importing those 60 years already of best practices and tools from software development into the world of IT and DevOps and making things much more predictable and repeatable and visible. Because think about it for a second, 20 years ago, in order to answer the question of what is it that you have in your inventory, in the data center? You would have to open a database, you would’ve to open some highly curated list or run all kind of discovery tools in order to populate back then, all the rage was around CMDB, creating a database of your configuration.
Gil Hoffer 00:14:15 Well today that infrastructure that you have in your highly virtual data center in the Cloud, it is actually what you have described in your telephone code, which is exact sitting in the exact same, Git repository next to your application code. And everything became more predictable and streamlined. And if we pause for a second to think, then actually the things that we’re seeing with business applications, configuration, which are being managed in a relatively manual Ad Hoc way directly in production, it has a striking similarity to what it just described about IT 15 years ago. The same IT person going into the data center with the box. It’s not that different from your Network Administrators, going into your production instance and clicking a bunch of different buttons in the UI in order to implement whatever configuration, then that’s needed. Same problems around visibility and predictability and scale and being able to work in a team and well, I’m an Engineer. So usually if you see a certain pattern of problems emerging, I would usually opt in for trying and use the same tools or IDs to solve them. And as we started, as we said, it is all about adopting engineering, best practices and tools and methodologies, also in the field of business engineering and business applications.
Kanchan Shringi 00:15:57 Thanks Gil for the history. It was very interesting. So the things that I got can be divide into two or three sections. One is the setup and deployment is more predictable and repeatable. Those are the two words I get. That makes sense. And then you mentioned visible, what exactly do you mean by visible?
Gil Hoffer 00:16:20 Sure. So I answered both around software and infrastructure as well as for business applications. For business applications actually it is a very simple explanation. I can actually share an anecdote from a customer of ours last week, I’ll keep it anonymous. But this is a very large Zendesk customer. And as part of the setup in Zendesk, you define what is called a trigger. A trigger basically, whenever something happens in the system, then it triggers another action. Now that company, which is a very big company, actually has a setup with 3,600 different triggers in the end instance. Now, obviously there is some kind of dependency also between the order of the different triggers, because if something runs, it can actually trigger another trigger by the action that he just did. Now, it is a great example because it’s very similar with in all the other business applications, but in order for them to actually know what is it that they have implemented right now, the only way for them to do that is to log into Zendesk.
Gil Hoffer 00:17:32 They got a huge list of triggers and they need to either click on them one by one, or remember by the name of the trigger, what is it that it is doing? So obviously at this scale, they cannot do that. So they actually maintain a huge spreadsheet on the side, which describes exactly what is each and every trigger. What is it good for? What is it doing? Why did we build it? And they need to maintain that list up to date. Now this is absorbed because all of that information is actually encoded in that system. And the way that we’re thinking about these kind of problems in Salt is, well, we connect to that system to Zendesk in this case. And we extract all of that information into code. Now, what is code basically? Code is a language which human beings can read and also a structure.
Gil Hoffer 00:18:27 So a computer can also read and understand that. So once I extract all of those triggers into code, you can all of a sudden search them for certain strings and traits and even better, because there is structure, it is code. You can actually very easily answer questions. Like what are all the triggers which get triggered by a change in that field? This is something which can be very, very, almost impossibly hard to answer in most of these business applications, because all of the knowledge is really hidden behind endless number of UI screens. And by extracting all of that logic into code, which is searchable and structured, all of a sudden it is like we’re literally lifting a veil and enabling those administrators, all of a sudden to understand what is the test already implemented in theire system? And this is one of the really fun parts of my week is to go on a first meeting with the customer.
Gil Hoffer 00:19:43 They connect their system for the first time, they fetch the data into Salto. And then usually there’s like this huge smile on their faces because all of that information that is hidden and scattered in so many places, become visible. It is similar to, I can remember the first time that I think I was 12 back then. The first time that I searched something online, there was no Google. I think it was Alta Vista or Excite or one of those ones. So the first time that you realized that you have all that information at the tip of your fingers and think about it, that for those administrators, in many cases, they know that it’s implemented, but they have no way to actually know what is it that they have implemented. It is very similar to a developer working on a code base. And I think just bits of that code base in Salt form and the rest in binary form. It’s a really hard thing to do and in many cases, that’s how they’re working to get today. So creating visibility is from our point of view, it’s always the first step. Later on, we can use this visibility in order to create much better teamwork and the proper change management process. For example, when you actually go and change that configuration, but the first step is always, well, you have to be aware of what is that you have implemented, right? Which is surprisingly hard in many of those cases today in those business applications.
Kanchan Shringi 00:21:20 So predictable, repeatable for the changes you’re making, the configurations you are doing visible is what do you get from the framework? What do you get from the configurations themselves? In the framework you’re using. And we’ll talk later a little bit more on how you choose which ones to make visible, et cetera. But the other thing you mentioned also was working in a team. So collaboration tools. So are those the categories setting up off the code deployment, making visible, and then collaboration?
Gil Hoffer 00:21:54 Generally there are I think, that if we go back to engineering, there is some intersection between the different tools. Meaning take a look at Git for example, and the source control tools. They are very important for collaboration because that’s part of your way to think of a poly quest for example, to ask for a code review, and for other team members to review our work. They’re also very important for the vision history and making sure that you actually know what changes over time in your code base. IDs for example, are very important in order for you to develop code. But they’re also great code understanding and visibility tools. If you need to understand what finding references of certain code parts, etc. So the activities that you mentioned are correct. These are all activities which are basically part of the application life cycle management, the SDLC right? Which we all know but hard to say that whenever we develop a new feature product, it starts with a planning phase, which parts of it is requirement, then the designed. And we actually implement and test and we maintain et cetera. The same activities are basically also happening when you work on the configuration of the business applications. Just that unfortunately today you’re lacking tools. That’s what we’re trying to help with.
Kanchan Shringi 00:23:28 So the one category of tools we did not really talk much about was related to observability monitoring. I’m guessing business engineers would rely on the actual applications that they’re using to take care of that piece. Is that fair?
Gil Hoffer 00:23:43 In many cases, yes. What we’re seeing that in many cases, business engineers would also stream a lot of data to a data warehouse. And in those cases they would run reports on top of the data warehouse to make sure that their data is is still correct. Because in most cases, monitoring would tie to data correctness with the business applications. Now, there are some cases where you actually extend the functionality of a business application. Then you might actually break some flow and some users would start getting errors in the UI. The native tools would usually alert on those. If you have got a broken flow on a Salesforce, then you would get an alert if there’s a broken screen. On NetSuite you would usually get an alert, but I agree that there are some gaps there. I think that it is a very interesting area to explore, especially on the relations between the business outcomes, because eventually those business applications, they’re all tied to business processes, right? You’ve got your quote to cache process which is involving multiple different business applications. And I think that monitoring those kind of processes also, which go across different business applications and understand how they perform on the business level, which is really the holy grading observability of what we’re talking here is an area which is not really being served today. And I think that it can be an interesting one in the future.
Kanchan Shringi 00:25:30 So talk now about the evolution of business apps. One of my questions to you earlier was why now, you know, what’s new about the Business Engineer and your response was that a trigger for creation of this role has been because customers have moved to adoption of best of breed, so multiple applications. Has the On-Premise to SaaS more influenced this as well in any fee.
Gil Hoffer 00:26:00 I think you’re right. I think that the On-Premise to SaaS is one of the enablers for the best of breed approach. Because when organizations were mostly On- Premise, the overhead of managing another business application, even just from a pure operational standpoint of installing it on a server and monitoring and keeping track with patches and upgrading and backing the tax that you had to pay for each additional business application that you installed OnPrem was very high. So you really had to choose what are the applications that you’re using. And in many cases you would have to resort to a best of class solution and not a best of breed. Now because of the move to the Cloud, the cost of all of these underlying operational task became almost non-existent. Because these are things that the SaaS providers, the software, the service provider is taken care of. So the actual cost of onboarding and larger solution became much lower. And that’s one of the reasons that we’re seeing so many business applications in modern organizations, which on the other end creates a real problem on how do you actually manage those at scale?
Kanchan Shringi 00:27:29 So the setup has certainly dramatically changed.
Gil Hoffer 00:27:33 Mm-hmm
Kanchan Shringi 00:27:35 How has the customization and administration needs changed with move to SaaS?
Gil Hoffer 00:27:43 So the thing is that because those applications are relatively targeted and narrowed, in some cases in what they’re doing, then they’re also highly customizable. And they allow for features, which in the past in many cases required proper development effort. And what we’re seeing that with the rise of SaaS business applications, which go end in end with no code and low code tooling, they are also highly customizable and they empower the administrators to really implement many, many use cases that in the past really require the development resource. The flip side of this by the way, is that it helps with the actual first development. But as we all know, development is just the first step in a much longer journey of a feature or system which maintenance is a very big part of it. And over time as the maintenance cost becomes much more dominating compared to the original development cost.
Gil Hoffer 00:29:06 And there is maintenance because you need to keep on changing your processes and you have a lot of tech debt already in whatever that you have implemented. Now, it doesn’t matter that you’ve built it with clicks and drag and drops instead of writing code, logically you still have tech debt there, you have all kinds of different fields and processes that God knows what are they doing? And because they relied on no-code or low-code tooling in order to build that, they don’t have proper tooling for the maintenance part compared to code where we have it figured out, right? Because we rely on code so, you know what you have implemented, you can change it, you have versions to it, etc. This is missing on the maintenance part. So on the one hand, those tools are extremely powerful in terms of customizing them, but they’re still lacking in terms of maintenance and the later parts of the software’s life cycle.
Kanchan Shringi 00:30:08 As you were talking, I realized that as a developer, you obviously will write to some extent what you will implement and before you actually implement it. So with low-code or no-code platforms, is that typical, or is the visibility really after you have configured it?
Gil Hoffer 00:30:30 So, we do see that most organizations, at least at a certain scale, they do document at least the business and all the way to a functional spec, more or less. So, for example, you would’ve a JIRA ticket, which would describe the change that you would like to do from functional or from a business point of view. Then you would usually go directly to implementing it. It’s not that some developers for example, originally would start like building a skeleton with some comments and then start replacing those with functions. You don’t really have the tools to do that in many cases in those business applications, whether you would go and implement directly. Now, one of the things that as a software developer always used to love doing is to keep traceability between that change that they just did, to that business requirement for example to that JIRA ticket.
Gil Hoffer 00:31:34 And technically the way that you would usually do that as a developer would be through the source control system, right? You have your committing to Git, you would annotate it correctly so it would get picked up by JIRA. So then you’ve got full traceability. You can look at the business requirements and understand exactly what is it that you’ve changed in the code and vice versa. Unfortunately, with business applications, you don’t really have a way to do that, again because you don’t have code. You have that missing link in between. And I can share that with quite a few of our customers. That’s actually the first use case that they start with because they want to make sure that they have this traceability between a business requirement and actual change in their configuration. So they will be able to go in either way. And one of the things that Salto enables them to do is to basically to have a code representation of their configuration, that then they can tie back into a Git commit, which gets tied back into a JIRA ticket, for example.
Kanchan Shringi 00:32:32 Yeah, that sounds really fundamental. How many SaaS applications are typical for a medium sized company’s back-office systems?
Gil Hoffer 00:32:42 So in recent service, you would see numbers ranging anything from 200-800, those ranges. Now, obviously not all of those Saas applications have the same weight, right? It’s not that you’ve got your, let’s say your main ERP can be an Oracle Fusion or SAP or NetSuite. It doesn’t have the same weight as tooling for sales developer representative. So if we look at the real major tools, then usually you would see anything between 10 to 20 at that ballpark with a few per department, you would have a major and main tool for the Sales Department, for example, Salesforce. And if you go a level deeper for example, the Sales Development or Business Development would’ve their own main tool such as Outreach. You would’ve a main tool for the Marketing Department, such as HubSpot or Marketo and for the Support Department such as a Zendesk, for Finance such as NetSuite. So this accumulate each one of those that I just mentioned, there are really deep tools with a lot of configuration which usually a team or multiple teams manage. JIRA for example, which is a very centralized tool for development organizations in large companies, you will have large teams, which manage it.
Kanchan Shringi 00:34:11 With so many, there’s obviously integration needs as well. Does Salto helps with that?
Gil Hoffer 00:34:19 So Salto, it does and it doesn’t. I’ll explain. Many of the integration needs are actually around, run time, data exchange between these tools. Whenever you change a field in JIRA, you want to automatically update something on Zendesk, because it’s a bug which relates to a customer that we’re communicating with. So we’re not there in runtime, but a big part of the problem is how do you know what are the different fields that you actually need to synchronize? And how do you know that, that field in Zendesk is actually dependent on that other field in JIRA? We do help with that, with being able to understand the data flow more of a design time understanding, but we’re not there at front time. We do help companies in the fact that they have now a single unified streamlined process to manage the configuration of those business applications. We’re helping them with that. If you look at integration, there are really some great modern tools for the business engineers, such as a Workato for example, or Tray.io. And there are a lot of other tools out there which help with the actual runtime data synchronization problems.
Kanchan Shringi 00:35:45 What did people do if they don’t use tools like Salto? What have they done so far?
Gil Hoffer 00:35:52 So obviously companies work and they find their own ways. In some cases they choose not to do certain changes. So it has an impact on the business. I can share a personal story. Salto is not our first company of me and my co-founders. We actually had another company before called Ravello Systems, which was a SaaS company. We’re actually a Cloud provider. And back then in some areas we actually chose not to do certain changes on the business side because we understood that actually implementing them on our business application stack would be too costly. So we actually chose not to do certain changes because we knew that it would be too hard for us to implement them. Companies obviously when things are very important to them, they will do that. It usually translates to more resources. So teams would grow in size, grow in budget, a lot of reliance on consultants and a lot of hard work in some of our customers in some of those business applications, you don’t really have a way to just copy changes from your sandbox to your production accounts.
Gil Hoffer 00:37:16 Extremely basic I know, but in some of those business applications there’s no way to do that. And we’re actually working with a customer where has 20 different production instances. And they have a team which manually logs into 20 different production instances and push the same buttons over and over again, because they don’t have a way to automate it. Obviously the business needs to operate. So they do that. They’re not happy about it. It is slow, it is labor intensive and it is error prone because you might miss a click. But that’s the way that they work today.
Kanchan Shringi 00:37:55 So you had an example where you said, Hey, this is too hard to do. I’m going to fail. I just won’t do it. Is there also a story? You said the business impact is way too high. I need to do this. And then you found a way or really suffer it. Is there anything like that you can share?
Gil Hoffer 00:38:14 Yeah. So in Ravello then we got acquired by Oracle actually. And one of the first things that we had to do was to integrate Ravello’s back office into Oracle. So sounds like a relatively simple task, right? You basically need to introduce, a few skews, a few catalog numbers into the Oracle CPQ is the term, right? It’s the quoting system. Now, obviously we had to do that, right? We had to enable the field to sell Ravello, it was a very, very long and manual and tedious process. Many, many calls with 10s of people to make sure that the exact data is being deployed from dev to integration, to UAT to production, multiple approval cycles and process, which took many months and took us a lot, not just us, also all of our peers at Oracle, but obviously you have to do that. Now, that was one of the realization moments for us that this needs to happen differently, because when we manage software or infrastructure, DevOps, IT, we found ways to make it much more streamlined, repeatable, and almost effortless in those parts of their release cycle. And there is really no reason not to do that for the business applications. And there is no need to really struggle with that because the pain back then, it was hard.
Kanchan Shringi 00:40:03 So it was not repeatable, which is why you had to test at each step along the way. That was the downside, which took time.
Gil Hoffer 00:40:13 Yeah. We had to test on each way on the way also the different environments, they were not identical. So in some cases, by definition, you had to do some changes to what you deploy to integration versus the actual content that you deploy to UAT versus the actual content that you deploy to production. So it’s not just that you don’t have a button which deploys and you need to repeat it, you actually need to do slightly different things at every stage. And because of that, you really do want to have multiple people review those changes, because you do want to minimize the chances of a human error. And making a mistake there can be very costly because the field will sell the wrong products, right? That’s like core business of the company. So it was non repeatable in various aspects, right? Not just the way that you cannot just click a button or run a script and deploy, but also that you need to actually deploy different things to different environments.
Kanchan Shringi 00:41:22 There’s lots of dependencies. So your solution, Salto solution if I read the website and you’ve talked about it, is translate the business applications configuration into text, allowing you to search, compare, deploy, and track changes across the environments. How do you choose which configurations to do this for? Because clearly there is work per type of configuration.
Gil Hoffer 00:41:49 Yeah. So when we connect to a new business application in Salto today, we support seven, main business applications. So when we connect to new business applications, we first of all map the configuration space, to understand what are the relevant or important configuration types. In many cases, we need to differentiate between what is metadata versus what is data or what is configuration versus what is data? And then we focus on configuration only. Now over time, we’ve built infrastructure on our side, which allows us to actually add many more types with a very, very low effort. For example, many modern APIs today would’ve a swagger spec, or I think we’re supposed to call it an open API3 today. So when an API has a spec, then we can just connect to it directly and almost generate the rest of the parts on our side, which can connect to that API.
Gil Hoffer 00:42:55 And in many cases, the question of what would you like to manage as configuration? It is also a logical question for users because you would get cases where certain data elements, for example, are actually configuration from their point of view. Think of an ERP system like NetSuite or Oracle Fusion. So in some cases, the definition of subsidiaries in some organizations, they would actually treat that as configuration, that they would like to go through the different gates and release cycles etc. while this is actually data in those systems. So we also enable our customers to tell us well, in the system also treat that data as configuration, or suppress that configuration; it is irrelevant. So, when we started Salto for the first two or three adapters, we actually did it by hand. We just wrote the code to support all the different metadata types or types that we had to support in those systems. And then we generalized. Then the next four adaptors were using that infrastructure. It just allows us to pick and choose much more easily.
Kanchan Shringi 00:44:13 What about other vendors and solutions in this space?
Gil Hoffer 00:44:17 Great question. So I think it can be interesting to look at two types of other vendors and solutions. I think the first one is vendors who are targeted at the infrastructure domain. And I think the main one to look there is obviously HashiCorp with a terraform. Because the core concepts of terraform, which by the way, we love terraform, we use it ourselves in order to run our own infrastructure. But terraform is basically doing very similar things to infrastructure and platform as a service in some cases. There are some core differences between what we’re doing and what they’re doing, but at the core idea, it is relatively similar. They’re focused on infrastructure, we’re focused on SaaS and business applications. And we think there is more than enough for multiple vendors in those areas. Another type of competition of vendors, which are in the ecosystem are vendors which are targeted at a specific business application and at the specific use case.
Gil Hoffer 00:45:25 For example if we look at a Salesforce for example, so there are multiple vendors who are trying to solve problems with Salesforce DevOps, or change management within DevOps. With vendors such as a Copado or Gearset, about five or six different main players were targeted at that area. Or if you look at NetSuite and compliance, so there are, there’s a vendor their strong point. I think that the difference here is that those vendors, they all came from a specific need in a specific business application and they develop the best solution for that specific need. Our approach is different. We came from an infrastructure point of view that an organization needs an infrastructure to manage reconfiguration of all the different business applications. And then basically, we’re building it top down. When we tackle a specific business application, we add the capabilities. So our solution would be at least as good as those vendors who are specific to that business application. And that specific use case in that specific application. But we also cater and solve for a lot of either use cases within a single business application, but also across all of them. So different approaches to the problem.
Kanchan Shringi 00:46:54 So I listen to this episode, I have a lot of parallels in my job. You know, I feel I’m a business engineer. How do I keep up with this topic?
Gil Hoffer 00:47:03 That’s a great question. And one of the main challenges that we want to take on ourselves looking forward in the next few years, is to start and build a real community around business engineers. Because we’re seeing that they’re lacking in many cases, the ability to go and talk with appeal in another company and understand what are the industry best practices for business engineer. That this is something that we’re going to deal with extensively. Until then my recommendation would be to find your peer group, go to user groups, understand what are the best practices in your field there today? We write about this quite a lot in our blog, by the way. So you can follow it or follow myself or some of my co-founders on LinkedIn and Twitter. We do try and lead some of the thoughts on those areas.
Gil Hoffer 00:48:03 But my number one tip would be to start and consider yourself as an engineer, meaning that engineers, in many cases, they’re very scientific methodological persons take pride in what they do. We cannot continue and manage those business applications. When we’re saying the focus is on the business side and the administration is whatever needs to be done in order for us to do that because it is not sustainable. So take pride in your work, try and understand why things are working the way that they are. When you see and that’s very common for engineers when you see a process, which is not optimal, try and optimize it, ask why are we doing that manually? Keep on optimizing the processes. That’s the first step thought to becoming a great business engineer.
Kanchan Shringi 00:49:02 We’d certainly love to have the link to your blog or any other links in our show notes.
Gil Hoffer 00:49:07 Alright, great.
Kanchan Shringi 00:49:10 Anything we missed that you would like to cover today?
Gil Hoffer 00:49:13 No, I think it was a very interesting discussion, at least for me. I hope also for you Kanchan. Yeah, I think we covered it all.
Kanchan Shringi 00:49:20 Yeah. It’s a really was interesting. Again, I certainly feel this is a topic that is going to grow and certainly interested in, keeping in touch and how can people contact you and be in touch with you?
Gil Hoffer 00:49:34 Definitely. So I’m most active on LinkedIn, so feel free to connect, send messages. I’m also active on Twitter, so that’s also a good venue. And for Salto, one of the interesting thing is that we also have a very active Open-Source project, which basically implements what I just described. So you can download it and just use it free, fully functional and try to become a better business engineer. We also have a free tier of our product, which can be used free for life, no strings attached. It’s not a free trial, it’s a free for life. So that’s also a great way to keep in touch of what is it that we’re doing at Salto.
Kanchan Shringi 00:50:24 Definitely will include some of these links in the show notes. It’s so great to have you here today Gil. I learned a lot, I hope our listeners did too. Thank you so much.
Gil Hoffer 00:50:33 Thank you so much, Kanchan. Bye. [End of Audio] `
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
great podcast, thanks