Thanks for the interview. So distributed process is very timely, obviously everybody's trying to figure out, and this is a very difficult domain, right, so I think people have been I think we've moved over the last five years from things being partially distributed to we're almost like living distributed now, right, and people are dealing with the scale, they're dealing with asynchrony, they're dealing with being parallel, and these are very complex issues, right, managing caches and state at scale. So this talk is going to be describing our real- time data-driven policy control platform, and we're going to describe how, you know, how we, we're in detail, we're going to describe our architecture, and how we solve some of these problems, make it a lot easier for developers to build solutions over the platform without worrying about the implementation details, and that's the whole sort of advantage, you know, of our solution is to actually eliminate some of the worst or most challenging aspects of distributed computing. Yeah, it sounds like some of the tools are coming out, I described earlier as being kind of second-generation tools that are not only more powerful, but a little friendlier to use, and I know you're the CEO or founder of Enterprise Web, and what, what is it about your product that answers that solution, or that need? Yeah, that's a great question, and I think that 's true actually, I think there's two things, I think it's, there's a maturity on the vendor side, and also on the market side, right, I think people have, you know, already scraped their knees a couple times, bruised themselves quite a bit. They know what they, it didn't work. Yeah, they know it doesn't work, they don't believe hype really anymore, right, you know. Yeah, you can't just say the cloud. Yeah, yeah, that didn't work anymore. So, now, now actually what people are looking for is a real solutions that they can test at scale, and that solve real complex problems. So, it's exciting time, because actually, you know, we're talking about problems of computer science, actually, that people have been struggling with for 30 years. These aren't just problems of our moment, they're, we're actually pioneering now how to be fully distributed in real-time, data-driven, right, and, and keep that cohesive, right, because that could easily fly away from you if you don't have it under control.

So, to your question about, you know, how do we make that more friendly, you know, first of all, the system is fully declarative, and we adopt a paradigm that's probably the most friendliest paradigm for all developers, is the system actually acts like a library, right. The system essentially makes all of your endpoints, whether they're the remote objects, micros ervices, APIs, or web services, or in-process objects that actually live inside our system, that might be data models, process models, policy models, and it makes them all look the same. It creates a consistency layer. It creates one loosely coupled, well- understood, you know, layer, and it's horizontally scalable. A lot, think of it as a logical store, but it's not just data, it's data, code, diverse objects, right, and by creating a consistency layer, we make everything look the same, and it's an abstraction, right, it's a data abstraction inside our system. Everything looks the same. If everything looks the same, I can navigate it the same way. I can search it the same way. I can reason over it across the same way. So, I can now be, you know, searching, declarative, right through the UI. I can actually be walking relationships between objects that don't actually live anywhere near each other.

They 're completely diverse, but in the system, it's gonna look like, wow, I'm gonna, I'm gonna look at the mic object, and you're an entity in our system, and I see every application you've ever touched. I click into an application, I could see an instance that you worked on. I can see the data and code behind that instance. I can actually click into the, the models of the remote objects that might have been, I can actually see the version of the policy that applied on the day that you did that transaction, and I do that front to back, and that kind of tracing, dependency mapping, library kind of access is probably the most friendly thing you could do to a developer, because then everything else is gravy. Yeah, because the discoverability is always the challenge. I mean , we want from WSDL and SOAP, which at least you had this manifest that you could look at and say, well, this is what my, my methods, you know, my SOAP calls look like, and this is the interaction I can expect to Rust, which is, well, it's kind of a shape, but people kind of had their own shape of a shape, you know, and didn't always quite conform to kind of the nebulous vision of, I mean, I'm sure, you know, if he got really deep into it, Rust had a very concrete definition, but it wasn't really discoverable. Sounds like this is answering some of those problems of when I sit down and I look at an environment and like, what can I do here? Yeah, absolutely.

Because in 2015, and we still, you know, when these people say continuous integration, right, that's talked about a lot here, continuous delivery, continuous integration. The word they forget to leave out, the silent word between continuous and integration is manual.

You know, look at the API, read the API, wire the API into my process and app.

You know, it's only in the service and API abstraction layer does, oh, look, it's all loosely coupled. It's so nice. And look at that, you know, like I've liberated things from my systems. That actually is great. It is an advance. We've achieved some loose coupling. But when we're doing three-tier vertical integration at the apps and the process layer, we're nowhere. We have you just, we've moved the ball. Yeah, we're still tying things together. The funny part about it is I think 10 years from now, people, you know, people will be like, you did what to what?

So we're actually automating interoperability itself because we do everything declaratively. Once your objects are declared in our system and you can now navigate them, I can now compose them in this one system by point and click by metadata because everything's described in its metadata. And you as a developer, you can pick up any individual object, look at its dependencies, you could fully understand it. You could see everything that's consuming it and et cetera. But at runtime, you don't have to worry about that. You don't, you don't have to wire it into an app. An app just has to point to it and the system agents will go out and figure out all the dependencies or requirements to fulfill that contract and render the value back up to the application process. Sounds like a really hard problem. It was a big problem. We took two years. So we're a lean startup. We've taken new capital. We're profitable on our own. We're customers on four continents. We just signed a deal with one of the world's largest consulting firms. We can't announce a point yet. That's building a practice for differentiated solutions. We took the first two years of our company, no pay. We didn't seek any customers just to work out the abstractions because we knew a lot of people were biting off.

And a lot of people are biting off small chunks of a problem, but distributed computing is a big problem. And if you only bite off a chunk, you're just adding another component to a complex architecture already.

We need an enterprise web.

Middleware should be this thin, horizontal layer between my objects and the behavior I want .

And that's really accessible to developers. It's a different way of thinking, but they know libraries, they understand dependencies, and if they can do all this declaratively and they can focus on new connections and business value, then I think that's a win.