Professionalizing Business Engineering – Gil Hoffer – Keenan Vision Podcast Episode 4, February 4, 2022
Join the Keenan Vision Podcast for a fascinating and fun interview of Gil Hoffer, co-founder and CTO of Salto, by Vernon Keenan. Learn about Gil’s perspective on Business Engineering, his love of code, and some cool stories from his past.
Listen On Anchor
Watch on YouTube
Subscribe With Your Favorite App
Be sure to subscribe to get all the upcoming episodes downloaded automatically to your podcasting app.
- Gil’s experience as a company builder
- How as an operator he figured out the complexity of configuring all the applications
- Vern describes how revolutionary products like HashiCorp Terraform was to devops and notes that Salto is kind doing the same thing with “infrastructure as code”.
- Gil describes how they invented Salto’s NaCl syntax to be a universal language for describing how to configure SaaS systems
- Gil describes how organizations may depend on a SaaS system like Zendesk, and sometimes that critical system is being managed manually, and how Salto can help businesses more formally engineer the solutions.
- Gil tells the story about how he got started with computers at the age of six, and that was his first experience with English as an Israeli child.
- Vern asks Gil about his experience in the Israeli Defense Forces, but any response would have gotten both of them killed.
- Gil shares more details on his motivation where he looks at processes and wants them to go faster!
- The occupation of “business engineer” is discussed. How it is now a profession, and how Salto supports being more rigorous leveraging the wisdom of the ages.
- Vern and Gil discuss the low-code features of the Salto UI.
- Vern describes why he likes Salto’s architecture, and Gil describes more how it works by ingesting data from a variety of sources.
- Gil explains why Salto is open source and available on GitHub.
- The free version of Salto is available at Salto.io.
- Gil discusses some of his customers. There are a variety of use cases! Some visionary, some practical.
- The Salto customer success team’s process is described.
- Vern describes more about why he likes Salto
- Gil and Vern discuss Salto’s investors
- Gil gives a pep talk about professional business engineering
Welcome, everybody. This is Vern from Salesforce Devops.net with this Keenan Vision podcast interview series. And this week I’ve got Gil Hoffer from Salto. And hey, Gil. Welcome. How are you doing?
Hey, Vernon. Great to be here. Happy Friday. Happy Friday.
Yeah. We picked a good time to record because I’m not drunk yet, so it’s good. I was looking at your website and you got a lot of nice, very interesting technical articles in there. And I think what’s kind of cool would be to maybe hear this story about how you thought about as you’ve been in businesses building businesses, running businesses, building software. Then you came to this idea that, oh, I kind of need this meta way to describe everything. So that seems to be kind of what Salto is all about. Am I right about that, or why don’t you give us the pitch?
Yeah, sure, I can give the pitch and the back. One story. I’ll start with the background story. Actually, I think it’s interesting. As you mentioned, Salto isn’t our first company, right? We’re three founders. We have a company which is called Ravello Systems. A very different domain was a virtual cloud provider, basically using all the usual business applications to run the business.
They were using, obviously, Salesforce for the bulk of the things, but also Marketo and Zendesk and Jira and you name it. The thing is that that company, we ran it from 2011 to 2016, and we noticed as we ran it that the way that we manage our business application, it was like the weakest link in the company.
We’re really good with developing software and marketing, et cetera. But the way that we actually do Salesforce implementation, et cetera, it was like a hot potato that we kept on bouncing between different departments, and we realized that it was because it didn’t feel like a natural part of the profession of any of the different departments.
And then we got acquired by Oracle, and then we saw basically the same, but to the extreme right. One of the first things that I had to do there was to integrate Ravello into the big Oracle machinery to enable the Oracle sales people to sell us. And the complexity just basically introducing like a Skew, a product number for Rovello was so big. Just realizing what’s implemented, what you need to do, how you actually manage that, change all of those.
It made us realize the way that people today manage business applications. It’s backflow. Now, Interestingly enough, while we’re doing that, we’re dealing a lot with Infrastructure’s code and the way that organizations manage their infrastructure on AWS, GCP or VMware even before.
And the thing there is that the type of problems that I described were actually quite similar before folks adopted best practices from software development, hence DevOps, infrastructure, code, et cetera.
Let me jump in there. You got as an operator of your own company where you had to acquire the services to run it, like marketing, ERP, sales and marketing. You realize that the slowest part of that was you had to take time out to configure the darn things all the time. And there was a lot of clicky stuff involved in that. And it seemed inexact and kind of like wasted effort sometimes.
Yeah. First of all, it was very labor intensive, and on top of it, it was actually scary because it’s like very [unintelligible]. Then you have a version of your code in your self control. You can test it in a testing environment, you can roll back.
And here we wanted to do some changes in our modeling in Salesforce, and it’s really scary what will happen if we make a mistake here. Now we got tons of data corrupted and different processes are not going to run correctly. So we realized that it can’t really work like that. And because the industry already solved some very similar problems in the domain of it.
We wanted to basically enable the business applications, business operations around Salesforce, and that’s it. And that consumes all of the different business applications to walk more similar to the way that they do it there. So that’s a backstory for Sato.
Let me put in our favorite analogy here, because I think you mentioned this kind of leap that maybe DevOps had at one point where they were able to put the idea of how you configure like a virtual machine or a cluster or some sort of like physical what used to be thought of as a physical part of your architecture. You could do that now in code, like how Hashicorp TerraForm works, where you can specify all these things and then put it into a Git repository and other things like that. Are you a little obsessed with this idea of taking that idea and applying it to the configuration management problem?
Sounds like it, yeah. Because first of all, the analogy to TerraForm is very accurate. It’s correct, because what we basically did, we created a language which we call NaCl, which is an auto configuration language. It just happens to be the chemical sign of salt.
And we enable that. We connect different business applications, we extract the configuration and do co generation into NaCl. And now you can version control it, you can change, deploy it back, you can branch out, you can review, etcetera. And one of the hobbies that I have is to keep on testing this concept on some additional business applications, like we can connect to whatever.
I think that this approach is really powerful because then you can have exactly the same processes when you manage your Salesforce instance and [other SaaS systems].
And we believe that because organizations today use so many different critical business applications, they need to be able to unify the processes of understanding what’s implemented, doing changes to the configuration, collaborating on those, monitoring those.Right. So, yeah, you can say I’m obsessed with it.
Well, I think it’s fascinating because you’re existing at this level that I call SaaS DevOps, and a little bit more so than some of the other people in the Salesforce DevOps world, where you are thinking about all the different SaaS applications kind of like as a whole for the business.
And I think that’s a natural evolution. And I think some people may discount the idea of SaaS DevOps a little bit just because they say, oh, well, my SAP doesn’t have to talk to my Salesforce or this, that or the other thing. And I think you touched on an interesting aspect of that. It’s more that people want to do governance on all these systems better, and that a tool like Salto can help you do that.
Yeah. So it’s around governance, but also let’s pick a system, let’s say Zendesk. So it’s a critical system. Right. It is the way that many modern large enterprises manage their customer support. If something is wrong there, then, well, the customers are going to notice it. And it is being managed mostly in a very manual way, which is very error prone.
And [we have] customers who have tens of different Zendesk instances, [that were] being managed completely manually.
And I think that if we look at the Salesforce ecosystem and the software way of thinking, it is actually leading the herd, because if we look at the way the things are going today with Salesforce, then people are aware of the role, people are aware of the need to do change intelligence or to walk in the right way. I think there are many gaps also in the Salesforce ecosystem. We can talk about that as well.
But if we look at the other business applications, then it’s missing. And there’s no sense in building, like, tens of different solutions for those because the core problems are exactly the same around visibility, change, governance, compliance.
Let’s switch topics here a little bit. I think I’m interested when I was looking at your bio, and I couldn’t help but notice that as a child, you had a certain fascination with a certain platform. Tell us how you got started with tech as a kid.
Yeah, sure. So I grew up in Israel, and I actually started at the age of six because my father was in electronics. And one day he brought a Commodore 64 home. And I was a curious kid and had an older brother, and I was sitting on his shoulder, and then I realized this machine is really interesting. And because they were like games, I don’t know the color 64, if you’re familiar with it, you basically had to program in basic in order to use it. I didn’t even know English. So funny enough, my first words in English were …
SET and PRINT?
So at the age of six, I learned some BASIC on the commodore 64. And then I progressed to Pascal, whatever, as a kid.
And the next step was when I joined the Israeli Army, like many others in Israel, enjoying a really great technological unit. And that I met incredible people, very small folks all around you. And that was like an accelerator for everything technical in my capabilities.
So I’m intrigued to ask many journalistic questions about unit 8200. But I think they’d have to kill me. And then that kind of passion it seems to be carrying through. Is there like this love with code? It sounds like it started early on, yes.
So it’s this love with code and this love with solving problems, I would say, right. I’ll give you a nice example from when I was a teenager. So my girlfriend actually, she’s my wife now. She volunteered with some other privileged kids who needed help, et cetera.
And one of the things she said all day playing all kinds of memory games, and she said, well, can you do something to help them? So I created all kinds of games for them, like with their pictures and their day to day, et cetera.
So it was always around trying to find real problems that someone cares about and see how I use tax in order to solve them.
Well, that was in the army. Then later on in Ravello. And obviously we started because we’re seeing some huge gaps in the market that we can help real people with real problems to basically also fast forward their careers.
Because if we look at the administrators and developers in Salesforce and the other business applications, one of the realizations that we had is they’re basically all of them are developers.
Some of them are no code developers or low code developers, but the practices that they use in their day to day are exactly the ones with developers. And we need to enable them to utilize the right methodologies, for example, versioning, and to be able to review each other’s work and to be able to understand the impact of the changes.
And we really do think that eventually all of these and we use the term business engineers in many cases, they’re basically engineers with the skill sets of an engineer that we need to enable them to do that. And that would be great for their careers as well as for the companies that they work for as well as for the entire ecosystem because it’s not true.
So we’re talking about these business engineers. Are they somebody who always is going to work in knuckle or work in code. We definitely have to have a place for the low code developers or business people as well because that’s what’s been driving Salesforce.
And that’s one of the things that one of the design goals that we had on the start of Salto was to let them walk where they are the most productive. So all I’m thinking is you develop your solution using no code tools, still work natively in Salesforce. You build a flow or layout or add some custom objects, et cetera.
When you’re done developing, you basically call it fetch. You fetch the configuration into software, then you basically see, that was the development part. But that’s just the first part of the SDLC, right. The software development lifecycle. Now you need to test it to version, to collaborate, to release, et cetera.
Those are battle tested methodologies that the software industry created in like 50 years. Of how you actually do that with Get, CI, CD, et cetera. Those you do with NaCl. But the actual development is still being done natively in Salesforce or in UI. Whatever business application you’re using, it’s also done in Salto.
The way that your application works, as I recall, is that you have your own user interface and the way that you manage the application and so forth. So even though there’s this underlying foundational code aspect, which is fantastic, as a software engineer, I love that idea. But I think you’re striving to make it compatible with the whole Salesforce low code.
Yeah, exactly. So once you fetch those changes into Salto, you’ve got your code view, but you can also look at it more semantically and for example, compare different environments and then clone a change from your search to your target environment. Can think of it as a change set on steroids. Basically, what you understand all the different dependencies because, let’s be honest, no one really likes changesets, right?
If we look at some of the problems with that is that you’re missing a lot of required information. When we create a changeset like what was changed when, by whom? What kind of dependencies between parts, et cetera.
And all of these are basically traits of the code and changes that we just had. So we’re having a very nice user experience to actually allow users to do that also in Salto and understand that the impact of the changes integrate with Git. Everything is very native in Salto.
That’s right. And I think one of the reasons why I appreciated what you guys were doing was because I realized that you’re doing this ingestion thing that you mentioned a few times where you read in the metadata of a salesforce org.
And I think that kind of thing goes underappreciated, I think then what does the vendor do with all of that data once they have it? And what you’ve done with it is you’ve put it into an intelligent database that works online. And now I can have this wonderful ability to kind of dump it out as code as well. The same database.
I believe the way your architecture works is you have these adapters, then that then work with different SAS systems, and then that lets you kind of ingest and spread out the code the same way for all those different systems.
Yeah, exactly. We call these adapters, which connect us to different agents and they utilize the APIs for Salesforce, for example. Then we transform everything into NaCl or on a presentation.
And one of the cool things here is that first of all, the core technology, the actual engine and the language definition and different adopters released all of these to open source. And many people ask us, why did you do that?
And the main reason is that we’re basically striving to create a standard for the way business application teams are walking and are going to walk going forward. And we believe, I think that the entire industry also believes that standards today, in order for them to get accepted in those areas, they have to be
gone are the days of IBM and then an Oracle sitting in a room and deciding on a standard. They’re way in the past. And that’s the main reason that we’ve basically released all of these two open source. And also, as you mentioned, the number of business applications out there which are relevant to this is huge. And it will take a community effort eventually to build all of these adapters. And we’re already seeing some vendors who are actually starting to build their own adapters in order to plug into this one.
Again, very similar to what we saw happen with TerraForm and HashiCorp. Right.
I’d encourage everybody listening to go visit the Salto GitHub repo to get more information about it and to actually believe you can download and try it and run it.
Right. Yeah, of course. Fully functional.
There is a free version that people can use, can sign up to use the SaaS hosted product, but they’re still like free forever with some limitations.
Yeah. So it’s a free forever version of our commercial product, which is mostly around impact analysis, meaning being able to understand different dependencies in the configuration. So it’s like a read only version of your configuration for a single environment per business application. That’s basically it.
Well, let you get going and get you some functionality. I’d like to hear a little bit about the customers. What are the customers who are picking this product? You don’t have to name names or you could. But also why did they pick you?
Yeah, of course. So we’re seeing all kinds of different use cases and motivations. And I’ll touch on a few of those.
The first one is where we’re talking with customers who are visionary and we’re seeing those in small and large companies. For example, when you’ve got a visionary CIO says, Well, I completely get it. I want to have the TerraForm experience when managing my business applications. And then they get an all in decision. That’s the way that we’re going to manage our main business applications.
And they usually start, for example, with a simple use case, like making sure that they put governance in place for the way that they change their nest with configuration. And after they see that, well, it works well for them, they also start managing all changes in Salto like that. Then they see that it works well for them. They start managing their Salesforce CPQ configuration with that, and then it goes on and on.
So that’s when we’re seeing a visionary CIO or VP of business application which makes such a decision. We’re also seeing companies where they have some very specific use cases that they have in mind and they get to us, for example, around managing their change management processes for Salesforce or for CPQ with Salesforce using Sauto doing the same for Zendesk or for Jira.
We have some customers who are actually using us. I can mention them by name. It’s a public reference Monday.com, for example. They’re using us in order to create visibility within their teams to everything that changes in the configuration in areas that they care about. We have a nice feature where you can get alerted on Slack whenever something changes in an area that you care about. So that’s the way for them. They’re an amazing company.
They’re all about their visibility and transparency in this company as part of their culture. And they’re using us in order to basically create such visibility and transparency and teamwork for their Salesforce administration team.
So it really changes, but we’re mostly seeing its usage with visionary companies who they get it. And it’s not very surprising because we’re still at a relatively early stage.
But the traction that we’re seeing and the direction this is going, we think that it’s very promising and the level of discussion that we have today with our customers and prospects, we’re seeing some major adoption and also some other companies.
So if somebody decides to pull the trigger and they’re onboarding with you, is there an extensive onboarding process with customer care or do they need to hire consultants?
So we have a really good customer success team that helps them with some of the customers. They’re very technical and capable and they figure out things on their own. With some of them, we help more.
For example, one of the things that in some cases people forget about is that when you adopt a DevOps state of mind for managing your changes, it’s also a methodology. Change and methodologies in many cases need to be worked together with the customer to fit the culture, to feed the organization. So we’re also doing that. We’re helping them with that. It’s included as part of our service because, for example, a large company, a very large public infrastructure company, uses us for their network change management flow, for example, they had some very specific requirements which might not fit the usual methodologies that around your usual gift flows, for example.
So we worked with them to make sure that it does fit. I think that’s something that we sometimes overlook in the Salesforce DevOps methodologies, that it’s not a cookie cutter one methodology that fits.
Yeah, I think more diversity is needed. That’s another reason why I was excited by the tool. It’s so influenced by cloud native philosophy. And also you have this requirement to kind of like to make it work with all these other systems. I think that there’s other considerations that go into it that can benefit. If you figured out how to do one thing and service now it’s going to help somebody help you regularize some other problem you might find later on in another system.
Yeah, definitely. Our approach, as you mentioned, is that we’re part of a larger ecosystem. We need to be at the bright building block that connects to the main gift providers, to the main ticketing providers. We’re not here to replace any of those.
Okay. So we’re getting close to the end. But I wanted to ask something else here. You told the story, you were at Oracle, and then I think we didn’t quite hear the story from them from there on. And I should mention that Salto is a company based in the US and Tel Aviv and has got some nice investors who have put money into the company.
And I’m sure you’ve watched the TV series Silicon Valley just like everybody else. You got to have a story for me, some crazy thing that happened along the way.
Life is so much more boring than how it looks on TV. We are some great investors. We have really the top two VCs in Salto, like Bessamer. They’re also an investor in Rovello, but also Accel LightSpeed or Salesforce ventures.
Well, just so people know, Bessemer is like the granddaddy of all cloud investors. In fact, they created an index called the Bessemer Cloud Index, and they kind of invented the idea of investing in the cloud. So the pedigrees are fantastic on all that.
And all of them are great partners. Really. It’s none of those Silicon Valley scenes. It’s not like that in reality. Really, people who want to do good business and want to advance the industry, that’s boring. That’s boring.
Well, it’s been a favorable funding environment as well. I think that’s coming to play. But to have such a great stable of investors, to have taken you out of Oracle, to help you build this business, it’s very impressive.
So, Gill, that’s the end of the podcast here. I want you to leave us with a Pep talk on why you should care about code and why you should configure your businesses this way.
So I don’t know if you should care about code, but I think that you should care about being a professional within business engineering, which means that the type of activities that you do, they have a lot in common with those that a developer does.
Meaning yeah, you develop a solution using no code or no code, that’s fine. But then you need to be able to work on an existing solution and understand what’s being implemented and what’s going to be the impact of changes that you’re going to make. You need to walk in a team. You need to be able to release reliably from your sandbox you’re in UAT into your production. You need to be able to monitor changes to all these activities.
Well, guess what, people have been doing them for 60 years when they’re developing software. So we need to learn from those best practices and we need to be really professional business engineers and be proud about that and be proud about your profession.
By the way, if we go to the backstory about your profession, I guess that’s the number one thing that I learned in that unit. 8-100. The thing that I would have to kill you if we talk about yes.
Wonderful words. Okay. So we got Gil Hopper, Co founder and Chief Technical Officer of Salto thanks again for being a wonderful guest and thank you everybody for listening to the Keenan Vision podcast. We’ll talk to you again soon.