Integrating DataOps and DevOps with Perforce’s Jim Cassens

This is Techron tv. Hey guys, thanks for the throw. We're here with Jim Cassens, who's CEO for Perforce, and we're talking about their recent acquisition of Delphix, which brings data management into their portfolio, and we'll get Jim to explain what all that means.

Hey, Jim, welcome Michelle. Thanks for having me. Really appreciate it.

Glad to be here. You guys are already forcing the land of DevOps. Where does data management kind of fit?

Are these things starting to converge a little bit and um, how do you see this all playing out? Yeah, Great question. You know, I think it goes back at heart to what we're trying to do for our customer base in the DevOps community.

We're really trying to help those customers innovate at speed scale and within compliance of their internal and external regulations. And Delphix is a perfect fit into that strategy as we try to achieve that goal. You take a look at a lot of things, right?

There's the whole concept of shifting left from a testing perspective. Well, Delphix allows organizations to do that and do that. By doing that, that really help is helps that increase that speed, uh, to development.

It, it is even more importantly, if you take a look at some of the really the stringent compliance requirements that are out there and now those compliance requirements are being pressed on pre-production data as well. The whole idea and concept of, uh, Delphix being able to mask that private information in that those test environments is, is super important. Um, and then lastly, when you look at the amount of data stores that that enterprise organizations have today and the complexity around that, think about having to create or manage 2, 3, 4 really large environments that duplicate what you have in production.

While Delphix can do that in by, um, the virtualization technology and do it in small subsets rather than entire, uh, replicating the entire environment that a customer has. So think about being able to save in cost, uh, and that storage cost that's associated with trying to develop those multiple environments as you test data through there. We think we're super, super, uh, excited about this acquisition.

It fits so nicely within our technology and what we're trying to achieve. You know, we have a really strong portfolio already in the testing, um, in our testing capabilities and the assets that we have. Adding this in as an additional flavor for how we help, uh, organizations to achieve what they want at speed and scale is, is a game changer for us and we're really excited about bringing that one in.

It certainly does, um, also fit very nicely with Puppet, right? Our, our probably our last acquisition of size. Um, and being able to really help the compliance and, and speed at which we're delivering, helping customers deliver those applications really important.

Are things converging more, and I'm asking the question 'cause historically we had ITSM teams and then we had DevOps teams and data specialists and storage people are, are, I know those are still separate functions, but are we managing that in a more holistic fashion as we go along here because the amount of data is just getting extremely large? Yeah, I think you hit it right on the head. Trying to bring some of this as a coordinated effort versus two separate pockets will just make people more efficient in what they're trying to achieve and, and bringing data in as early as possible.

And that development just helps the development community as they release these, um, new applications out into their environment. Do you think also organizations are getting a little tired of having to navigate so many different vendors to accomplish their goal? And part of this effort is, um, a wave of consolidation that may not be driven so much by the economy, just by the simple fact that customers want a simpler PO process?

Absolutely. There is a, there is a piece to that, right? Hey, I, I have one phone to call for help.

I have one phone number to call for a sales representative. I'm getting one invoice. And that certainly reduces the administration around dealing with 40 different vendors when it comes to DevOps and certainly customers are doing it today across that large number of vendors, but they're having to stitch together those solutions.

So the more integration we can provide into the various solutions that make sense is where we really are going to drive value for our customers. Simply being a consolidator of potential solutions is great and certainly can reduce some of the overhead burden, but I think, I truly believe that the value we can really add to a customer is when we start to integrate these things and make it much easier for them to use and, um, traverse the different applications that we offer. Has data management become the next big, um, bottleneck?

And I'm asking this question because as we move to build applications faster and faster, it feels like, um, I'm still using somewhat antiquated methods to manage the data. So, um, I wind up with this bottleneck that slows down the whole deployment process. Absolutely.

Absolutely. Um, and again, think about how back in the day and even today, if you're doing that as a manual process, the effort it takes to create a simulated environment to be able to test in, and now you've gotta do that for all of your pre-prod, right? From unit testing, function testing to QA and multiple levels of qa, that becomes very complex and difficult to do in real time too.

And, and the Delphix solution, that's the key, right? I can provide you with a subset of data to allow your developers to test, allow your QA people to test at a much greater speed. But I keep that referential integrity, especially as I'm masking that data, right?

So what you're seeing, um, is what you're gonna be able to follow through the entire life cycle of the, of the testing environment and the testing schemes that you're putting together. Is that gonna result in less of this behavior where, um, people say, well, it worked fine on my machine and then they kick it up in a production environment and nothing works as advertised, so can we, you know, reduce that, um, admiration? Well, that would be the goal.

Um, certainly I think there are aspects of that when you're, when you're looking at these very complex, as I mentioned earlier, complex data stores and the way that these things are threaded together, having that, that knowledge of how these data stores and the information is connected is where you're gonna get the true benefit of being able to test on a simulated, um, a simulated environment versus, you know, trying to just say, Hey, it worked on my my PC or it worked on my workstation. Now it doesn't work when it gets into production. Do you think regulators are gonna come along and ask more pointed questions about this whole process?

Because, uh, very often you hear tales about how somebody launched some sort of testing thing and they just pull data out of production environment and the next thing you know, there's all this, uh, PII data string across the development environment and um, as we all know, regulators, if they find that stuff, they're gonna levy fines, right? Absolutely. And I mean, if you take a look at, at any of the sources out there when it comes to cybersecurity, the number one risk is internal risk.

It's not so much external, especially when it comes to development, right? Because those in development environments don't necessarily have provide access or means for access outside of a specific network. Um, but it doesn't, it doesn't prevent an internal, uh, source from capturing data or getting to data that they shouldn't be seen.

Well, if I'm masking that data, if I'm presented in a different form, but it looks like it's real data, guess what? I'm really protecting and securing to the utmost, um, from a compliance standpoint to make sure that I'm not sharing private data with anyone outside of, um, production. Is this an issue that we long ignored?

I feel like we've been talking about data management forever and a day, but most organizations I know would not get the proverbial good housekeeping seal of approval for the way they manage data. So are we having a, uh, a moment where we're gonna bring in some adult supervision finally? Yeah, I was, um, reading a, a survey among CIOs over the weekend and one of the top 10 items on their list for activities this year is to get their data out in order, right?

So they're even seeing today that I need to be able to protect my data better. I need to be able to understand my data better. Um, and that's certainly where Delphix comes into play in, in order to secure those environments for CIOs.

Will we see more automation and may I dare say AI applied to this process and what will that look like? Yeah, and, and obviously, um, everybody's looking at AI and how we can utilize ai. We have some aspects of AI in our existing testing solutions.

So the ability to be able to spin up an automated test case and run that test case is something we can offer today to customers and certainly would be able to love to be able to provide more of that AI technology in through Delphix and integrate it with some of our other solutions as well, just to be able to provide another layer to our customers, um, speed at which they're developing at, allowing them to take maybe some of the manual work away from a developer or tester and really get them concentrated on, um, providing those, those highly specialized solutions and, and unique solutions to the problems, uh, of the world today. So the dynamics are currently changing, we're shifting more things left, we're trying to get data to become more accessible. We want to test more applications, we want to do this all at scale.

Ultimately we want our cake and eat it too. What's your best advice to folks about, you know, how to get there from where they are today? Are there things you've seen some of your customers do that make you know a lot of sense and you wish other folks would copy?

Yeah, I think the thing that I would suggest is to do it as an iterative pro process versus trying to take the whole, um, enchilada, right? So do it in pieces, find your biggest pain point, address that, then come back to the next one and the next one and the next one. Um, Delphix provided, you know, in, in our diligence in looking at this solution had the right approach.

Let's, let's solve this for one of your applications. Let's do that really well and then move to the next application, the next application, the next application. You don't have to take this off as an entire in its entirety right off the bat.

So that would be my suggestion. Otherwise it becomes a daunting, uh, project that's probably fraught with risk and and failure. So why not just be successful and then continue to grow from there?

That's what we've seen our largest customers, um, where they're the most successful when they take it in iterative bytes instead of, um, one big project. Do you think this kind of shift towards platform engineering will help drive that approach because it does feel like we're trying to centralize the management of management application development through deployment? Yeah, absolutely.

I would agree with you, right? Uh, there has to be a, a balance between speed at which you're developing and, and a little bit of control, right? Being able to make sure you're on top of what's happening within your environment, whether you're releasing apps into an environment u using something like a puppet or whether you're securing data, um, and being able to mass that and protect it as it's going through its testing phases.

It's gotta be some level of control in order to make sure that all of the compliance needs are being met. We, of course, worship at the alter of speed when it comes to application development. Can we continue to develop at the pace we have been or do we need to slow down just a tad to accommodate some of these security and, uh, data management realities?

Yeah, sometimes you have to go slow to go fast, but I think to your point, advent of AI and especially if it can take away some of the low level work that needs to be done, that will only continue to help us speed the delivery of development. So I think it's a combination of both. You certainly have to slow down to make sure you're doing things correctly and adequately and um, you know, within compliance, but at the same time, we're here to try to help those developers move as fastly as they po as fast as they possibly can.

So what's next for Perforce? I know you guys have made a couple acquisitions lately and it feels like something that, um, is a powerhouse is coming together here with all these different components, including Puppet. What else do you need?

Yeah, good question. I think, um, right now, you know, the team, I've got the team laser focused on this integration. How do we, how do we get the employees, the customers, the partners comfortable with the acquisition and comfortable with the new resources that are gonna be applied, um, to the, to the, to the acquisition.

Um, post that, we'll take a look and see what's needed in the, in the portfolio, uh, really coming from voice of customers. So we wanna be able to listen to our customers, what do they need? What do they see in the horizon?

Where are their bottlenecks and how can we help? Where should we be looking for other tools and solutions that could be acquired and put into our portfolio? There's nothing, nothing pending at this point, but certainly we'll continue to keep an eye on opportunities.

All right, folks, you heard it here. The pieces on the chessboard keep moving, but hopefully it all works out for the best, for all concern. Hey, Jim, thanks for being on the show.

Thank you. Appreciate you bringing me on. All right, and back to you guys in the studio.