This week we interviewed Tim Wagner, CEO of Vendia. Vendia is a real-time data infrastructure provider that enables companies to securely share data across organizations, applications, and data lakes. 

In this talk, we discussed the use of next-generation blockchain and server list infrastructure to solve data sharing problems related to security, privacy, and data management. We also explored the three body problem - how conventional IT, private ledgers, and public blockchains will work together to usher in the Web 3.0 era. 

Key Questions: 

• What are the characteristics of a suitable use case for blockchain architecture? 
• How to distinguish between private and public ledgers? 
• How do data ownership and sharing mechanisms work for private blockchains? 
• What is the functionality and business logic of next generation blockchains?

Erik: Tim, thank you so much for joining us on the podcast today. 

Tim: My pleasure. Thank you so much for the invitation. 

Erik: Tim, I've got to tell you. On this topic of blockchain, you could define me as maybe a skeptical optimist. 

Tim: You're in good company there. 

Erik: There's something really interesting here. Obviously, there's people like you that—based on your background, you've got a PhD from Berkeley. You've got in computer science, BSE from Princeton in Computer Science. You've worked with a slew of market leaders in different areas and technical positions. You could be spending your time doing anything that you wanted, more or less, and you've chosen this. So, I think it's also interesting that a lot of really smart, talented people have chosen to devote themselves to this. That also gives me optimism that there's really something tangible here. But of course, there's also a lot of speculation in that, that creates a lot of noise around quick money and so forth. Maybe just as a starter, I'd be really interested in understanding what is it, high level, about the vision for what this technology can provide that has convinced you to devote some significant number of years of your life to this domain? 

Tim: It's a great question and maybe a natural segway, too, into why I'm interested in this, why the company, why do I start up in this space, and so forth—when, obviously, so many other things are happening out there. I'll give you just a little bit of the origin story here. I spent about six years at AWS. I started what's now known as the serverless division there. Of course, we didn't have that fancy work back in the day. What we did realize and what I went through to do in a sense was help democratize using the cloud. If you think about building an application from scratch using the lowest level infrastructure in the cloud, it's a heavy lift. Not everybody who knows how to code or who has an IT team is necessarily up for the challenge of figuring out scalability and fault tolerance in multi-region deployments, and on and on and on. Part of building what became eventually AWS Lambda and API Gateway and these other services was this idea of making them so you didn't have to know all those details. You could get value out of the cloud, and build some of those technical capabilities and applications and outcomes without necessarily having to deploy your own and manage your own servers there. I was very interested in that. I left AWS to go down to Coinbase, which was to continue the theme there, democratizing access to crypto. You're making it so anybody can buy, sell, trade in cryptocurrencies. One of the interesting things about working there was, I got this fantastic ringside seat to this really interesting technology of distributed ledgers in the form of cryptocurrencies. As you mentioned, they work well for speculation. You can log into Coinbase with Binance, or pick your favorite brokerage out there. Go buy yourself some bitcoin, buy Etherium. They work as these stock markets for this particular form of currencies. What they don't work so well at—and here's where we get to the interesting blending of these two pieces of the background. What they don't work so well at is functioning as an enterprise piece of infrastructure. By that, I mean, trying to use, for example, Etherium as if it were a database that two or more people could use to share business data. When I say it doesn't work well, I mean that in both of a qualitative way and also in a quantitative way. Etherium can do about 14 transactions a second. Your typical bank or insurance company, whatever, is doing tens of thousands, maybe hundreds of thousands of transactions a second in their various mission-critical applications. That's a lot of zeros that are missing there. It's not just the performance piece—it's the ability to hook up to the cloud, to be highly available and fault tolerant, all these things that you think of as enterprise-grade or enterprise-ready. 

I got really interested in this idea—not of blockchains as crypto, but blockchains as a piece of enterprise infrastructure. If we could reimagine them the way that the cloud would have built them. Think if AWS had invented a blockchain, how would it have done it? It would have made it highly distributed, highly reliable. It would run in the cloud, obviously, and be really easy to use. That was the goal. It was reimagined blockchains with this very cloud-forwarding, cloud-native capability, and then let that technology go out there and start to solve some of those really interesting, challenging data sharing problems that we can chat about here. 

Erik: Got you. Okay. Very interesting. Thanks for the perspective. Maybe another thing that we can cover at a high level, before we get into the details here, are just defining some of the key terms here. I'm just going to throw a few terms at you, and if you can just give me a nice common sense or definition of how you think about them. The first term—blockchain and next-gen blockchain. What is a next-gen blockchain? Second would be serverless infrastructure and serverless ledger. Then the third would be Web3, which is a big, semi-amorphous term. Can you just give us a quick summary so we're all on the same page with these terms? 

Tim: Sure. Let's start with blockchains. Blockchains are—for folks who haven't worked with this before, they are in a way a form of law. People would be generally familiar with — on the technical side, you're really usually familiar with application and system logs, these ordered lists of things that happened in some order on some system. If you're a business type, you're used to the concept of financial or accounting ledgers. You QuickBooks online, right? You made a bunch of transactions that occurred in a specific order. You can figure out, if you run from top to bottom, what your current balance is. Really, at the end of the day—the implementation tech aside—that's what a blockchain is. It's an ordered list of some transactions or activities that happened. Then usually, at the same time, you're keeping or running into a running tool as it were, a copy of whatever that current state is. Lots of details about how you make that happen, what the tamper proofing and everything else that's required in there, and how you make that cryptographically secure. But at the end of the day, it's really just a list of things, just like a list of accounts, account changes you would get in your bank statement at the end of the month. That's a blockchain. 

Now, often, when people talk about blockchains, they mean something a little bit more. They usually mean not just maybe a blockchain but a distributed blockchain. So, that starts to get a little more interesting. Because now you're talking about the amount of this ledger, the statement log, the statement of accounts that is somehow kept consistent and the same for multiple people, for different people, so that you and your bank, for example, know the same information. You agree that the same set of things happened in the same order, leading to the same account balance at the end of the month. You can see how that will be really important. You don't want to be in a disagreement with your bank about whether a transaction happened or not. Distributed ledgers are a really exciting idea, because they let two different companies—with maybe completely different IT infrastructure, completely different teams, completely different compliance regimes, maybe in completely different parts of the world—have an absolute guarantee that they know and believe the same set of data. That's why distributed ledgers are such an interesting and potentially disruptive technology. 

Now, most of the world knows distributed ledgers in the form of crypto, right? Because what they get used for is to store the balance of your cryptocurrency. You go and buy some bitcoin, for example. All the Bitcoin servers, everywhere in the world, agree that you bought that bitcoin, that you now own that. You, here, is really an asymmetric public, private keys. It's a little more complicated than your identity when you go to the bank. But for the sake of our discussion here, let's assume that that's essentially how that works. 

But cryptocurrencies aren't the only place where distributed ledgers are useful. We'll talk a little bit about use cases. You can imagine anything from supply chain. You go to the store, and you buy a bottle of ketchup. The bottle of ketchup maybe got moved by three or four different—it had to be produced somewhere. You needed a glass bottle. You needed tomatoes. It had to be packed into a crate. The crate had to be driven somewhere. It had to eventually be loaded onto a storage shelf. Everybody needed to know where that ketchup was, what was happening, was there enough—that kind of shared information could be stored on a blockchain just like a Bitcoin balance could be. That's where some of these interesting business use cases come from. So, that's going from blockchain to distributed ledgers. I was thinking about serverless ledgers. 

One of the things that Vendia has done, which is very different from the way blockchains and distributed ledgers are normally built, is we designed it to work in the cloud. This is where things get a little bit technical here. Most blockchains are built using a single machine, right? You can deploy Etherium, for example, to your laptop. That's useful from a testing perspective. It's also really, really bad in a lot of ways. Because it means that when you hit the limits of what one machine can do—you run out of memory, you run out of CPU power, you run out of networking capacity—you, therefore, hit the limits of what Etherium can do. It was designed in such a way that it can't ever do better than what one machine can accomplish. That's really dangerous. No cloud service is ever built that way. 

When we build these things at AWS, like Lambda and API Gateway, they used millions of machines. So, they have access to a huge amount of raw computing capacity. That's what's different about a serverless blockchain or a serverless distributed ledger from maybe a conventional one like Hyper Ledger Fabric or Quorum. It's that they have access to the power of the cloud, to all the many, many machines in the cloud. They can spin those machines up, and then tear them back down again. That ability to recruit—as we say, recruit Silicon—in the space of milliseconds and then let it go again gives this amazing scalability, but also really, really tight cost enveloping. So, it's a double win. Cost enveloping is important to the people who have to buy it, obviously. Also, for the planet, because lower cost also means lower carbon footprint, which means fewer emissions for a given amount of computation in the underlying technology there. That actually gets interesting for lots of reasons to try to minimize that. 

Erik: Got you. Well, thanks, first of all. It helps me a lot actually to understand the foundation here. The last would be then Web3. How do you view that? That seems like a few technologies grouped together. 

Tim: Yeah, it does. I'm going to save this one for last. Because Web3 is a broad mix of concerns. One take on Web3 is that, it's an attempt to actually make some of the information and the data that's out there less centralized in nature. You often hear this term bandied around 'decentralized,' when associated with blockchains and especially with distributed ledgers or cryptocurrency. The idea behind 'decentralized' is, think of it in opposition to these classic centralized systems. Today look behind the scenes. Take your favorite company like Airbnb. They got a bunch of machines with a bunch of data running a bunch of applications. You create an account there. You rent a place to stay. They've got a database. They store your information. They have all your private information—all the information about your orders, where you've stayed and everything else—sitting in one of their databases. 

In a decentralized system, two things can happen. One is, of course, different people can share the data. Think cryptocurrencies. Everyone shares that information about who owns which bitcoin. But the other thing you could do with decentralization—here's where the Web3 concept gets really interesting—is remove the sense of one person being in control, like no one person controls Bitcoin. Nobody gets to step in and say, well, I'm going to take your bitcoin back, or I'm going to move it around to another account. The owner of that is in control of it. Part of the idea behind Web3 was, what if you took that idea of control—not just of say a Bitcoin account balance but of things like your personal information, your employment history, your reviews from former employers, who you've given permission to advertise to you—and place that control not in the hands of these large, massive companies, maybe like Facebook or Google but instead, push it back into the hands of the people who are using the internet. Through this decentralized technology, create a more egalitarian and democratized way of controlling, and delivering, and using information. That's the Web3 goal. I would say that the world has obviously not realized that outcome yet. But it's an interesting one to hope for, right? When you get down to brass tacks in technologies, Web3 becomes a lot of discussion around how would we get there. What technologies would be needed? How would they actually work? What would be necessary to deploy them? That's where things are still very chaotic. Imagine the early days of the Internet before all the functionality the internet was built out. People were still trying to figure out what's a browser. What does the network do? What are the data exchange formats? That's, frankly, where Web3 is today. It's still very early in that journey to a more open and decentralized and, frankly, egalitarian notion of internet and data ownership. 

Erik: Great. I want to get into use cases, but just maybe one more angle on Web3 I'm personally curious about. We have big, very large investments from Facebook, from Microsoft. I'm a happy Microsoft customer. I'm not a happy Facebook customer. But anyways, these are fine companies, right? So, I have nothing in particular against these companies. But I would say that they don't strike me as caring very much about creating an open infrastructure or this vision. It strikes me that they're trying to maximize stakeholder, shareholder value. Closed systems have traditionally suited them very well. So, I'm a little bit skeptical that these investments that they make are made with the intention of the ideals that you've just shared with me around Web3. Of course, there's a lot of other people that do have those ideals and are trying to build solutions around them. If I look forward 20 years, I could say, could there be a Web3 that is dominated by Facebook and Microsoft? Would that still be Web3, or would that just be them using certain technologies to create new platforms? How do you look at the different possibilities since this Web3 have to have this sharing dynamics or control to the individual dynamics? Could there be a Web3 that emerges that has some of the marketing potential and, I guess, the digital twin aspects of people living in these platforms, but still being more or less as controlled as Facebook is today, by a single company? 

Tim: It's actually a fantastic question. We talked a little bit about this idealized state here. The reality, of course, is going to be a blend as it always is, just like not every piece of data out there is owned by one single, large, centralized entity today. 20 years from now, it's not going to be the case that all of your data is somehow fully decentralized and fully under your control either. It will always be an advantage to companies to keep information about their customers. I don't think any of us should expect anything other than that companies will fight tooth and nail to have that information removed from their control and their access. 

I'll give you two interesting trend lines here, though. One of them is the open-source movement. You roll the clock back. I started at Microsoft, probably back in 2006. Open-source was a dirty term. It was something the company was actively fighting against. There were a lot of rules about how to not use it, or not allow it, or how to prevent it internally. But today, Microsoft is one of the biggest proponents, advocates for users of and contributors to open-source software. It's a complete 180 that the company has done. I think what's happened to code there, probably, eventually, to some degree, happens to data and data ownership. But it's going to take a slightly different path, and it's a much, much broader and longer road to hoe. Because a relatively small percentage of the worldwide population work on code—either producing or consuming it—whereas all of us have personal information. I think you can see an analogy there in the code. But I think it's a much, much longer pathway to democratize that personal data. 

The other interesting trend line there, though, which has been driven by nation-state laws and regulations, is around these compliance and assurance programs—things like GDPR in Europe. There's one called CCPA in California, which was followed up by Prop 24, very GDPR-like in flavor. They're starting to force companies to be more transparent and responsive to the information that they keep. That doesn't speak to the technology or where that data lives necessarily. But it starts to force things in the direction of swinging the pendulum of control a little bit back to the people, about whom that data it was representing rather than the people who are collecting that data. So, I think you're going to continue to see a bit of a constantly escalating war there or a constant battle of companies who want to keep that information, and people who want to preserve their privacy and have more democratized access. I think those two trend lines are going to be interesting ones to follow over time. 

Erik: Great. Thanks. That's a great perspective. Let's then look at the use cases. You've already given us a couple examples. But before we get into specific examples, I'm really interested in how you think through what characteristics define a use case that would be suitable for blockchain rather than for traditional architecture? Is it the number of stakeholders, or the requirements that specific stakeholders or a high variety of stakeholders can control data access, or is it how flexibility in terms of financial flows between stakeholders? What would define for you the characteristics of a suitable use case for a blockchain architecture? 

Tim: Let's first make a really quick distinction between, what generally gets called, public and private chains here. What would you use something like Etherium for versus what would you use something like Vendia or others in that space like Hyper Ledger Fabric or Quorum for public ledgers? I've written this thing called the three-body problem about how centralized public and private blockchains can actually all work together. I think that's actually a wonderful way to think about it. The world is not going to throw away 50 years of IT progress and replace them all with blockchain, any more than any individual technology replaces everything that came before. Similarly, public chains have some really interesting advantages, but they also have some really interesting and challenging scale and cost challenges, that make them not suitable for everything. 

Public chain is generally great for two things—ordering and non-repudiation. Generally, that information has to be placed on them in an infrequent and often digest-based form. Think like you're a bank, for example. You put your end-of-the-day balance on Etherium. What you can't do is record a million transactions a second, because Etherium is 14 transactions a second. It isn't going to be able to handle that. You're sharing that 14 TPS with everybody else on the planet. So, the cost per transaction is high. The latency of the transaction is high. The system can't go any faster than it can go. What you typically want to do there is put a coarse-grained updates that become useful for public dissemination. Think something like the public records. I have place in King County, up in Seattle. By law, the information about who owns which property has to be made a matter of public record. Obviously, if you sell a house, it's important to know who sold it to whom, what came, and what order. Great stuff to put in a public chain. Of course, anything where you want to be able to trade stuff. Cryptocurrencies are a good example, where people around the planet want to have this very open market of things that they can trade with this record of who owns what and who gave what to whom, or sold what to whom, and what order. That's the public one. 

On the private side, we should talk about three characteristics that make for a really great use case: the data changes—that is the data is real time, the data sensitive—that means you're not just trying to give everything to everyone. Otherwise, maybe some other technology like a CDN would be a better choice. Then the third and probably the most interesting one is, the data has to cross some interesting divide. That can be two different companies. It might be two divisions within the same company. It might be two different clouds, two different regions, two different accounts. But the data has to get from one place to another, where there's some challenges associated with that. 

When all three of those things are true and you can think supply chains, shared workflows, financial ledgers, loyalty programs for an airline ticketing system, any of these places where that collaboration exists, where that collaboration is real-time and where there's also some sensitivity to it—you don't want to just tell everyone in the world that Tim Wagner just bought an airline ticket to go see a customer. When those three things are true, that becomes a really interesting use case for a distributed ledger, especially a private blockchain, if you will. Because it has all the characteristics. As a software, a piece of software infrastructure for a business application system that looks like a database, has a bunch of rows and columns inside it, and yet has to be shared and kept consistent what we call a single source of truth with a bunch of business partners. 

Erik: Okay. In those circumstances—because this is obviously very important to corporates—what does the ownership structure or the control mechanism look like for blockchain? Is there one entity that fundamentally defines the structure but then sets very transparent rules that other entities participate in the blockchain adhere to? How does that ownership and control mechanism work for a private blockchain? 

Tim: Let's talk about two different pieces of that—ownership of the individual pieces of data, the rows and columns in the database, if you will, and then the ownership and control over the data model or the schema for that data. Now, this is where some of this will differ, obviously, based on different products, different technologies. I'll tell you how Vendia does this in a little bit, about why. 

We track ownership in a very fine-grained way. Think, for example, every row in a conventional SQL database or NoSQL database where every object is owned by one of the participants. That maps really well on to most real-world use cases. Let's say, you're taking a flight on an air flight. You need a couple of carriers. You're going to fly on Delta. You're going to fly on American. You've got a ticket and some information with each one of those airlines. It's really important that each of those airlines knows what you're flying. It's important that they'll be able to know that your baggage has to get exchanged. But they don't necessarily want to share all of the details. That row representing your ticket has to be known to those two airlines, and to no one else, which is equally important. Then some columns will be shared, and some columns will be visible just to one or the other there. That's a model, a very fine-grained model of ownership for individual data items. 

What we've set up here, and it's one of the nice things about decentralization, no single entity owns all the data. This is what really distinguishes blockchains and distributed ledgers from a classic or conventional database. Vendia doesn't own the data. In this case, United doesn't own all the data. American doesn't own all the data. The airlines own the charts of the data that was created or was supposed to be visible to them, and nothing else. Then everyone has an equal view into the system and an equal share and right to participate into the system. But no one entity necessarily controls any of the other entities. 

Now, things do get a little different when you talk about the data model of the data schema. Usually, if only for logistics purposes and nothing else, somebody is setting this chain, this network, this set of people up in the first place. There's usually a natural first party who does that. Often, they will work with others and collaborate around what that data model should look like. One of the things we've tried really hard to do at Vendia is to make that data model very explicit and also very evolvable so that you can change it over time. You'll add fields, for example, as business needs change and grow. 

There are things you can do on chain, as the blockchain folks like to say. For example, vote to make those changes amongst the various parties and so forth. But usually, again, just as a practical matter, somebody has thought out that data model at the beginning of time before things were set up in the first place. Because otherwise, it could be chaos with different people representing things in very different ways. Then that model also makes a nice place in a nice way for the participants to be able to decide who should see which rows and which columns, what parts of the data you want to share, what parts of that data are perhaps private or restricted to a smaller group of people. That data model becomes important, also, as a way to express these data access controls and create that response to data sensitivity needs. 

Erik: Okay. Great. That makes sense. I suppose you can imagine some friction there, where stakeholders are going to want to—customer says I want to make a change to the model and so forth. I guess that's not fundamentally any different from companies negotiating over a business model and saying we want to restructure how our contract is, or our financial flows, and so forth. 

Tim: Exactly. It's a really good metaphor. Sometimes someone is truly in control. Stripe—amazing company in the payment technology space. We're a small company; they're a large company. Stripe decides what their APIs are going to look like. It doesn't really matter if I like that or not. My choice is to either use those APIs or not, to use their data model or to not use their data model. Other times, you've got, let's say, credit card companies, airlines—these folks work in large, complex networks. You can go see these industry standard messaging protocol formats that have been developed over the course of many decades to make the exchange of data easy, safe, and secure. That analogy of producing those protocols—whether it's airline ticketing protocols, or credit card, PCI styled exchange protocols, swift, ACH, and so forth—those things then become embodied either as literal standards or, in some case, just de facto standards. It's not unlike developing a data model for blockchain. 

Erik: Great. Well, thanks for giving us this background. I think this really helps to understand the business logic around where these can be used. Let's get into what you're doing at Vendia now. I'm just looking at your website. I'm imagining it's a middleware platform where companies can build the infrastructure and then apps on top of that. Maybe also you provide services. I assume most corporates don't have a lot yet of competence insight for developing these. How do you help companies to build next-gen blockchain platforms? 

Tim: Sure. I'll give you an example here of a use case that we can talk a little bit about some of the details of deployment and implementation and so forth. A little bit of background of this. This is the BMW use case customer but also an investor, for full-disclosure, in Vendia. As you can imagine, building an automobile requires a lot of component parts, I think around 35,000 components in there. Each one of those components composed of even more fine-grained parts. Very complex supply chains, very complex logistic chains. Part of what they need, part of what has to happen there is those parts need to get to where they're going—those components. Then as things get produced, for example, the chassis produced in Munich might need to get to the United Kingdom to ultimately be turned into a Rolls Royce—which involves going through various logistics providers. 

One of the things that can happen in any supply chain or logistics chain, of course, is that—in the happy path, everything gets there. It's in perfect shape. It gets there on time. In the not so happy path, sometimes they get there. They're damaged, or lost, or what have you. When that happens, being able to track where the part was and where something went wrong in order to be able to do attribution at the end of the day. Let's say, you've got a chassis that's an expensive piece. Something gets damaged in transit. You need to know when was it damaged, by whom it was damaged, and that will ultimately inform who's responsible for that damage. It's a matter of responsibility. 

If you think about mobile apps and photo booths, you're able to take pictures of these components, of these parts, tracking them across time. But because they're being produced, carried, and consumed by many different companies along the way, no one of these companies has either a full view of data or trust necessarily of all of the other parties. You and I, for example. If we got into a traffic accident, I might think it's your fault. You might think it's my fault. But if we had a video, probably, an objective third-party would be able to figure out what actually went on there. This is somewhat similar, where different parties can produce video and other kinds of information that serves as evidence. That evidence is both immutable—because it's a blockchain, it can't be changed by anybody—and it's also shared with all the different parties that allows this easy attribution. Instead of getting a bunch of lawyers and accountants and others into a room, you can simply go back and say, "Well, that part was in good shape before it was picked up. It was damaged after it was picked up. Therefore, it's this particular logistic provider who's at fault. They're the ones who are going to pay the insurance claim on it." 

The other thing that's nice about turning that manual process into an automated and mutually trustworthy one is that then you can also start to do interesting analysis on the data. It's not just figure out who's going to pay the bill in the event something goes wrong. But over time, do you get more errors with one particular provider versus another? Does a particular supplier result in vehicles that have a higher or lower error rate over time, or more or fewer warranty repairs? Is there a particular step of the process that's creating downstream errors or problems that could be remediated in a more efficacious way? Once you have that data on chain, you have this ability to start doing important analysis that can drive this great cost saving feedback loops back into the business. This was a great, interesting example. Because it's got a little bit of the supply chain flavor but also involves getting data from IoT devices. In this case, everything from a mobile tablet camera to a phone booth that can automate a vehicle, or partially constructed vehicle being driven through. Then turn that into what is effectively a digital twin representation of the current state of play, the location, conditions, and other important meta information about that particular piece—component chassis or finished vehicle, what have you. One that we were really excited about in terms of turning that into a blockchain based solution. 

Erik: If we tear that tech stack down, I guess you're going to have a lot of different components. You're going to have the fundamental architecture for moving and storing data. You're going have digital twins, maybe some analytics engine for looking at camera data and understanding what's happening here. You're going to have the applications or front-end interfaces for people to view information and make decisions. What is your role in this stack? Where are you? I guess, you're partnering with other tech companies. You might be working with existing systems. How do you interface? 

Tim: Great question. Vendia's role in this is data storage, data replication, including across clouds and accounts and parties in this case. Then what you would call, what a blockchain person would call consensus, what a database person might call transaction monitoring or transaction processing, the process of making sure that that information in all the different places is properly secured—shared or not shared—based on the series of controls, and that it is kept consistent and accurate. This phrase that we say all the time, that you hear a single source of truth, that everybody has a guarantee, a cryptographically tamper-proof, secure guarantee that their data is exactly the same as the data that one of their business partners can see, and both parties know that that's the case at all times. 

One thing we do that's different than other blockchain technologies is, we also automatically generate APIs. For the tech crowd out there, think GraphQL automatically generate it, compiled GraphQL APIs, driven off the data model, that make it really easy to use the system and to connect it up to the other pieces. As you said, in this case, the tablets, the dedicated photo booths. In this case, front-end administrative and web portals, for example. Those actually existed from prior incarnations, but they were built on top of centralized databases. We replaced the database not just for BMW, but obviously for the partners here as well. We took over that part of the stack and provided an easy API for that, that gets generated automatically from that data model. Then, of course, you can have people in different clouds here. Under the covers, another thing that's happening is this high-speed data replication not just within a cloud, potentially, across regions, but also across clouds. As we'd like to say, you can pick your partners. You can pick your cloud. But you can't pick your partner's cloud. Multi-cloud—it becomes a necessary prerequisite as a piece of the technology stack here. 

Erik: Interesting. Let's look at it, also, then from a stakeholder perspective. I guess, we don't have to use exactly this use case. But let's say, internally, to BMW, we have a CIO office. We have maybe the Chief Digital Officer, or an innovation office that might play a role here because it's a new technology. Then we have the functions, quality assurance, supply chain. Then outside the organization, I guess, there's going to be some relatively large companies involved in logistics, who might also want to have a say in the structure. Maybe also, a third-party system integrator who might be helping to do the integration with different systems. What does this typically look like in terms of who has taken the leading role? Who's helping to hands-on define? Then who are the system users once the system closes its operation? 

Tim: You laid out some of the basics there. Maybe it's worth pointing out one of the most salient pieces of that, too, to your listeners, which is—this is a little unlike a conventional IT sale or deployment in that it does generally involve partners as well. Often, when you're thinking about an application like this—be it a supply chain in the auto industry, or loyalty programs in the travel sector, or financial settlements for FinServ—they usually do have multiple parties who are working on this at once. It's a win, but it also can make the process a little longer at the beginning, in part, as we talked about earlier. Because there's generally a step of that or a phase where people are also agreeing on a data model. Now, sometimes that's already been sorted out by the industry or some standard exists, which, obviously, can simplify that piece a little bit. 

Then as you mentioned, we're often talking to—one of those offices you just discussed and depending on the size of the company, often there's somebody on the innovation side who has both a business outcome objective or role, and another foot in the technology side who is concerned with either the cost of shaping some of these outcomes today—the high cost of standing up databases and doing custom point to point API integration solutions, and then doing that over and over and over again as applications need to get built within the company. In addition, sometimes, they've got a top line focus, where they're trying to enable some new aspect of the business. Like dynamic pricing, for example, where you need real-time, up-to-date information—including sometimes partner information, if you're going to actually provide a great customer experience on a website or a board through a mobile app. It often can be a combination of those. Some brownfields retrofit of an existing system, which often involves a line of business owner. As we said, delivery for those is not uncommon for there to be an SI, a system integrator partner involved. Usually, someone who is familiar with those, that part of the system. Or if there's a large IT staff internally, then whoever's owning and managing that will become part of the delivery process. 

Typically, it goes from there's some natural leader or nexus. Maybe that's BMW working upstream and downstream on their supply chain, or an airline, for example, maybe working upstream and downstream with loyalty partners in their alliance. Within that, usually, a technology leader who's championing this as a cloud architecture-based way of doing it. Typically, either that person has a business responsibility, or there's a closely associated line of business owner for whom this is an economic outcome. They're looking at it from a very business results perspective. That's a typical deployment. We have a solution architecture team here, so we're certainly not—primarily, we're a product company, not primarily a professional services shop. But we do provide some solution architecture as well, since we often have a lot of experience relative to our customers and thinking through the production and deployment of these multi-party solutions. 

Erik: Got you. Then just one last point. I know that the answer here is going to be it depends. Where is the budget usually coming from? Is it usually coming from the CIO office or from the operating function? 

Tim: In our case, it's about 50/50. As you get closer to supply chain, discrete manufacturing, and sectors in and around that, it's more frequent that it's coming from a line of business. As you would look more at the airline and financial services, where there's often an institutionalized notion of data sharing. In fact, sometimes these whole companies have been basically spun up as human blockchains to share various kinds of information in some of those industries and sectors. There tends to be a little more of a top-down driven process that's coming either from the C level, or it could be CIO or CEO, or from an innovation office which has been charged with coming up with a better or more forward-looking architecture, especially around some of these mission critical projects that require large, real-time data sharing between a company and its partner. Think things like mortgage servicing, for instance. 

Erik: Maybe we don't need to get into the details. But pricing—how does that work, actually? I guess you have a lot of flexibility in terms of how you can actually build a pricing structure. I assume it's somehow scalable. What are the different options that will be most common? 

Tim: We have a free tier, as well as a pro tier design for individual developers. That also allows companies to come and experiment with the technology. One of the challenges, especially if you're trying to do something that's category creating, is that you need to also make sure that people have that opportunity to get past whatever initial skepticism and confusion analysis they want to perform. So, that's one way that we make that an easy trialing experience. 

Then for enterprise pricing, normally, we do consumption-based pricing as the backbone of what we do. Think of a transaction like reading or writing a piece of information. Since we build this in the cloud, we have a really nice, low margin cost structure to be able to store, transfer, and replicate that data on the back end—which makes it possible for us to do a fine-grained pricing structure. But that said, a lot of our enterprise contracts will do an initial all-you-can-eat. Again, it's a way to—especially for a business owner—feel like they won't necessarily have to do this upfront analysis of the consumption while they're still trying to figure out what their architecture and business pattern is going to look at. It's not unusual for us to have that initial honeymoon period, where we allow folks within some large upper limit to basically do all they can eat across a multiple set of use cases and consumption patterns, as they start to learn and figure out what that is ultimately going to look like. I told you, just historically, when we did AWS Lambda that we had in AWS, it was a very similar challenge for customers. If you've never used that serverless pattern before with consumption pricing, that you'd only ever rented servers, it was really hard for people to figure out how much they'd spent and whether that would be tractable or not. At Vendia, we decided we need to have some structural mechanisms there that make it easy for people to try before they buy and make that up, an easy exploration part of the journey for the customer. 

Erik: I know this budget clarity is useful for companies. There's no way that we have to secure $500,000 per year for the first two years, whatever that might be. What are the orders of magnitude? I guess this could scale up to a very large scale. But if somebody is starting and they're looking at, "Okay, we need to budget for the first three years to consider something like this," what are the ranges? 

Tim: Look, we do sales that are as small as $25k annually, where somebody is maybe sharing a modest amount of information. Think of marketing contact databases, for example. You've got two companies wanting to share a subset of their CRM information to do some co-branding, co-marketing, co-selling activity, all the way up to contracts that run into the millions where companies are building mission critical applications with tens of thousands of transactions per second, processing and restoring potentially large amounts of data—both real time transactions, as well as files. There's quite a spectrum there in terms of what customers can and do use the platform for. 

Erik: Okay. Great. Well, last question from my side. You raised Series B $30 million in just end of May. At least I'm reading around the press release, end of May this year. Congratulations, first of all, for that. I'm curious. How are you going to be spending the money? Are there specific verticals that you're planning to grow into? Are there specific technologies or extensions that are on your roadmap, whatever you're comfortable sharing about the future outlook for the company? 

Tim: Absolutely. Both of those. All of that. Part of it is definitely to grow into new sectors we haven't done. We know there are a lot of great data sharing use cases and challenges out there in healthcare, for life sciences, for example. We haven't really been in that sector, partly because it's got some specialized sales motions, but also because you need to have the right HIPAA compliance, fire protocol support, and so forth. Building out both the go-to market machinery and the backend infrastructure for that is important to do in order to enable that to really be a successful entree into the sector. 

Definitely, one of the things we'll be doing is looking at new and additional sectors that we can go build out there. We're also continuing to expand just our platform footprint. A little sneak peek here. We're going very shortly to be announcing the beta of our Azure file support. Continuing to push on our part, multi-cloud experience, supporting more clouds, more features and capabilities with different clouds. There are some things that are evergreen. Customers always want lower latency, higher throughput, more connectors that come out of the box, ready to go—so being able to expand those kinds of capabilities to meet customers where they are. For example, we support APIs today, an easy data ingress/egress through events. But we have a number of customers who really like doing data queries, and they'd love sequel support. Finding ways to give people conventional data access mechanisms through query languages, exporting their real-time operational data into Snowflake and other data analytic systems—all of that on our near to medium term roadmap here. It will be a great use for the additional capital that we just raised. 

Erik: Great. Awesome. Tim, I really appreciate your taking the time and giving us a very lucid explanation for this domain. Anything else that you wanted to touch on? 

Tim: I appreciate the time. I hope your listeners had fun hearing a little bit of my thoughts on blockchain and ledgers here. One thing I'll just close with is, there's a bit of a hype cycle. Blockchains, we're going to save the world. Then they became sort of useless, and now they're coming back again. It's like any other technology, right? It'll find a home long-term within the IT stack. 

For us, blockchains are just one of several interesting technologies that we use in order to create this amazing data sharing experience for customers. Our goal is really to make that kind of data sharing for all sorts of businesses—as easy and low cost as possible. Really, for me, the continuation of this journey is trying to democratize the cloud, and now with democratization of data as well. It's a journey we're really excited about. We have a wonderful, passionate set of people here at the company. Listeners who are interested in learning more can go visit vendia.net. We've also got a lot of technical articles on our blog, which if you're on the tech side of things, you can learn more about, for example, how we're making blockchains behave like databases. It's a bunch, a wealth of technical information out there as well. 

Erik: Great. Tim, it looks like you're building a great company here. I would love to have you back maybe in 12 months and see where you are then. Thanks for taking the time. 

Tim: Thank you so much, Eric. Real pleasure being here today.