In this episode, we discuss challenges related to data acquisition and management in systems with dispersed sources and ultra-low latency requirements. We also explore the uses and limits of low-code systems as companies strive to empower their domain experts to create their own applications. 

Our guest today is Robert Cooke, CTO and founder of 3forge. 3forge empowers developers with a hybrid low-code development platform used to rapidly build enterprise applications that require real-time streaming data.

IoT ONE is an IoT focused research and advisory firm. We provide research to enable you to grow in the digital age. Our services include market research, competitor information, customer research, market entry, partner scouting, and innovation programs. For more information, please visit iotone.com

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE, the consultancy that helps companies create value from data to accelerate growth. And our guest today is Robert Cook, CTO and Founder of 3Forge. 3Forge empowers developers with a hybrid low code development platform used to rapidly build enterprise applications that require real time streaming data. In this talk, we discuss challenges related to data acquisition and management in systems with dispersed data sources and ultralow latency requirements. We also explored the uses and limits of low code systems as companies strive to empower their domain experts to create their own applications.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research strategy or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.

Robert, thank you so much for joining us on the podcast today.

Robert: Yes, good to be here. Thanks for having me.

Erik: Robert, I'm really interested in having this conversation today and understanding the transition of 3Forge because I think as opposed to many of the companies that I speak with, which are coming very much from an industrial background, you're coming from a finance background, which means you have a lot of experience dealing with very large datasets and very high requirements for managing data. Now you're moving into the industrial space. So I'm interested in understanding how your perspective might differ because of that.

I also understand that you're just looking at LinkedIn that you're coming also from a finance background, it sounds like that was maybe 15 years ago or so. But how did you first generate the idea of establishing, 3Forge? What were the motivations or the experiences that you had in finance that led you to realize this was a new?

Robert: I've been programming pretty much my whole life, I started writing software, and it's about eight years old, this would be the early 80s. And I started to focus at an early age what it meant to have humans interact with data. And that's obviously a two way street: data gets sent to humans, humans then send information back into data.

Now, I started off trying to see what it meant to write and build video games, something along those lines and then later on I ended up in finance. The reason I bring that up is because I do look at finances. It's obviously very important use case of computer science technology. But it's just one use case. And I've always been fascinated about how can you look at and try to derive the sorts of challenges that different industries in different disciplines face, step back, take those sorts of ideas, compile them together, and then formulate a more generic way to solve problems. And I think always the best technology has been the generic, more data agnostic solutions.

Now, with that overarching introduction, when I started off in finance, the first thing I was doing was what's called oats reporting. Basically, think of it as you're just generating these reports that gets sent off to regulatory bodies, so they make sure companies are doing what they're supposed to be doing. Some point I moved on to building high frequency trading systems, transaction cost analysis, middle office, tax and rebate systems, etc, etc. And while these individual nouns aren't that important, I tell this story because I'm trying to paint a picture that I really was looking at and trying to get exposure and all the different components or all the different areas within finance.

And what I realized after about a decade of doing this, this is now 2002-2010 that while they were falling under very different management structures and completely different groups, I find this group's using Perl, this group's using Java, this group's using C++, these people are using Python, etc, etc. The problem set is 99% the same. It's all being solved with computers. It's all being solved with data structures. It's all being solved with messaging. It's all being solved with online versus offline computing.

And it was striking to me that we would be solving the same problems over and over again because of a few percent difference in the challenges. And so I always felt that it would make sense to build a platform that focused on the common challenges within technology and then basically provide that platform in almost a consortium style manner, where then people can use the platform, provide feedback we add to that platform, and then they can reap the benefits of that. And so basically, it's been an idea more or less on how can we build a platform to allow people to rapidly build technology or rapidly build solutions on top of our technology.

And so with that said, it is data agnostic, I think finance has some of the most challenging problems. The volumes are incredible. And at the same time, everything has to be “transactionally perfect”, you can't drop records, etc. So that sets us up in a way where we can start to tackle a lot of the problems in IoT and other industries as well. So then, a few years ago, we started shifting towards what it would mean to do fleet management.

So, for example, you have 30,000 cars, you want to be able to monitor and manage those in real time; suddenly, that is a lot more doable once you've spent the last decade thinking about a platform that can basically transmit information at very high speeds across a distributed network. Again, our clients are all global, so the idea of having to move information in batches and having things in different time zones, and having systems go up and down, etc, etc, is commonplace for the sort of things we're doing.

Erik: I think we had a podcast a month or so ago, somebody was head of infrastructure in Asia for WeWork and basically building solutions for WeWork internally, and then also working with Nest and had the experience basically that, yeah, we're repeatedly building this middleware, this infrastructure, that drives a lot of time and drives a lot of cost and ends up being 7%, different from what everybody else is building, why don't we just create a company that works horizontally to solve this problem, allow people to focus on doing more value added work?

When you set up the company, you're coming from a background where I imagine you had a good income, and you're making the jump into setting up a startup were probably initially at least just an entirely different work environment. How did that work for you, was it kind of an abrupt transition? Or was it just in terms of mindset, you were ready to kind of buckle down and just have that change of pace?

Robert: So first of all, WeWork thing, I see the analogy, and by the way, we do have WeWork offices in London and Singapore. So we are taking advantage of the platform he's set up. In any case, with regards to the motivation or catalyst for actually doing this, one of the biggest things is I would move from job to job. And at some point, I was head of infrastructure and architecture at the dark pool liquid net. And yes, the salary would keep going up to solve what I felt was fundamentally the same job.

And I was always pushing to get a budget to basically build out an architecture a generic architecture. Because again, once I was starting to run multiple divisions, I could then sit back and say, okay, now I have a clear opportunity where I can build a platform and take advantage of these across the divisions within my group. The problem is you're now facing the ebb and flow of business cycles and changing management and changing decisions. So I'd always be able to get those budgets. No matter where I was, I wouldn't be able to convince people to get those budgets only to generally have them withdrawn.

And so I realized that when you're sitting inside a finance company, it's very hard to basically get the security you need to get the investment over the period of time required to build the sort of platform I needed. I realized it would take about half a decade to build what it is that I wanted to build. Then I had to really step back and ask myself, does it even make sense for a financial company to build a solution like that? And then you start to have an identity crisis, which is what does it mean to buy a financial company? Are you a technology company? Or are you a company that manages money?

And I made the decision that it didn't actually make sense to even try to convince this to be solved within the financial industry. Now, with that said, I think finance is solving some of the most complicated problems there are so they become an excellent customer for us. So I've kind of realized it didn't even make sense for me to try to push this within the vertical. It made more of made far more sense to basically step outside and solve this once and then go back into the industry and sell it across the board. So that was really what it came down to.

I even looked back to the decision I made to basically step outside of a good paying job and sit there for years and build this platform and take a huge risk that it wouldn't be adopted. Unfortunately, we had some early adopters in the beginning, that basically allowed us to bootstrap this and keep it going and gave us feedback and built the community, etc.

Erik: Well, let's get into the solution a bit here or maybe looking first from a business perspective what problems are you solving. At a high level seems to be two big things, so data virtualization and data visualization, maybe you can help just break down for us what does the data management landscape look like and where do you fit in? Because I think a lot of the folks that are listening to us today, data is very meaningful to them. So it'd be great to give a foundation as a starting point here.

Robert: So I'm going to start off with Steve Jobs. He once said, you take any animal and you look at how fast all the different animals are and humans are kind of in the middle of the scale there. But then once you put a human on a bike, suddenly, we're faster than any animal. And that's absolutely true. And so the idea is, because we invented the bike, we're faster than any other mammal, maybe it's only mammal. And so that was kind of the core point he was making that through technology were faster.

And I agree with that statement. But after thinking about that for a while, I don't actually think it's the bike that makes us faster. Because if you took a bike and you put it in the middle of the woods, I think probably a turtle would be faster than human on a bike in the woods because bikes don't work in the woods, bikes work on roads. And so you have to actually think about it as what makes us so striking is that we actually put together a road system that bikes can work on, that's really the magical part that we've done.

So now let's step back and make the analogy of IoT; as you've got the actual devices, think of those as cars. And then you've got the information as the highway system. Now, once again, I think people get very excited about the cars. I really like to think about the system by which the cars move on. And what do I mean by that? Well, there's a few things that we all know we take for granted.

But I think it's important to highlight. So for example, two cars can communicate with each other. There's certain standards out there that say when you turn left, you have to turn on the left blinker; when you turn right, you have to turn on the right blinker. When you hit the brakes, hopefully, your brake lights aren't out, and the brake lights turn on and you can see the car in front of you slowing down. That's an example of there is actually some sort of protocol for how cars have to communicate with each other. And here in the United States, we have the DMV that makes sure to some degree, and I use those words loosely, that people are following those standards, so there are less accidents.

But I actually think the bigger picture here, the more salient point is around the road system itself. Because at some point, during the new deal, the United States built the highway system. I think it still is considered one of the largest projects in the world, which is the highway system. And what's fascinating is the highway system, if anyone's ever driven on a highway, I'm sure most of your listeners have and now the question is, why do you have highway traffic?

And the obvious answer is because there's too many cars on the road. But why are there too many cars on the road? There's too many cars on the road because every single individual house or community has a local street road that connects to that highway. If you took away the street roads, you wouldn't actually have traffic on the highway. Would you? Because there really wouldn't be the cars you might have semis going down moving industrial goods, stuff, etc, etc.

So the reason I'm very purposely trying to flip the way people take perspective on this, which again, I think the way you naturally want to take perspective is I'm sitting in my car, I've got cars around me, this is annoying. Why is there traffic? If you think about it from a systems perspective which is you have a highway system, and that highway system is connecting lots of smaller system and those smaller systems are connecting even smaller systems and now all of a sudden, inevitably, you start to see issues forming at the highway system at the large volume part of it. And that's what 3Forge is focused on.

So, it's interesting to build all these individual leaf nodes that are responsible for acquiring data. But now it really becomes a challenge of what do you do with that data and how do you move that data in a very streamlined fashion? And we can start to get into things like run data integrity. Again, one of the amazing things about the highway system in the road system is you have everything from these tiny little smart cars that barely fit to people. And you have semis 18 wheelers driving on the same road incompatible. And how do you make a system that can handle such diverse sort of components and be able to move that data efficiently and manage it, etc, minimize accidents, so on and so forth? So that's really what we've focused on.

Erik: So we're looking at building out the infrastructure for moving and managing data. And then just if we follow that analogy, there's a lot of fragmentation here. So you have the highways, and you have the telcos that are moving data in a more homogeneous way, and you have HTML and some standardization of protocols. But then you have a tremendous amount of fragmentation, when you start talking about factory A and retailer B, and logistics provider C, and then at that point the standardization starts to break down.

And so where do you fit? Are you focused on serving at the telco side? Are you focused on the large companies that have maybe hundreds of thousands of assets in the field, and even though they are maybe doing things in a very customized way, they have sufficient volume by themselves to require very heavy infrastructure? Where do you fit into this map?

Robert: I think it’s very funny article, it starts off with there's 15 standards, we need to come up with one standard that will standardize all these 15 into a single uniform standard. And then the next slide is now we have 16 standards. And there's been a few times where it's worked. And I would say, like TCP IP, when you get lower down in the network stack, yes, we've been able to come up with uniform solutions. But once you get up to the application layer becomes very, very difficult. As you alluded to, once you move up the stack, and you're to the point where you're now talking about how does this manufacturer talk to that manufacturer? It's just very, very customed.

So the approach that 3Forge just taken is we have come up with a 3Forge API standard and then we have basically build plugins to everything that we can get our hands on, so all the different types of databases. And by the way, when I say everything we get our hands on, we break data down into three different ways that it moves around. Technically speaking, I would say it's online versus offline. By online, I mean, data moving in real time, so that streaming data offline, data that is static, and we're going to go ask for it on demand. So those are two ways that we interact with data. And then the third way is pushing data. So generally, that's either users or some sort of electronic feedback into a system and we're pushing data in.

So again, to recap, basically, we've broken data communication down into three buckets: real time streaming data, on demand static data, and then pushing data, real time back into systems. And then once we had that construct in place, we basically now started building lots and lots of different adapters to meet them. And basically, those adapters are just conforming our standard API into the APIs that everyone else knows and loves. And so, if we're connecting to a particular SQL database, or no SQL database or we're talking to a flat file system, or we're trying to listen to network capture packets, all of those things are individual protocols that we've then mapped into a uniform way to read that. So that's one of the big parts of the platform itself. It's not the biggest part, but that is an important part that we have to do. And we continue to do.

And by the way, it is it is shocking the explosion of different protocols there are. It seems that a week doesn't go by that I don't hear about a new database. I have to now be familiar with at least 200 different databases, which is shocking when you start to think about there's 200 different types of databases at least that are common. But it just gives you an idea of how big the industry is, in general.

The bigger thing that we've really focused on is how to move messages very quickly in a distributed way and how do you build dashboards. Because now this comes back to my childhood dream of having humans be able to interact with large volumes of data. So it's how do you build dashboards that allow for very large datasets to be accessed and manipulated very quickly? So everything is web based. It was kind of a bet I made in 2010 that everything would go well, now it seems pretty obvious. But at the time there were things like flash and some people thought things were going to go that sort of direction anyway.

So basically, those have been two of the big areas that we focused on. And then there's lots of small outcroppings that fall out of that, like how do you do complex event processing things along those lines? But in terms of the platform itself, or to break it down, how do we move data very quickly? How do we allow people to access data and work with that data on mass and having tons of different adapters to connect to different systems?

Erik: Maybe looking at this from another perspective, who would be the buyer and who would be the user? So is this a CIO? Is this CTO function? And then I guess we have users that are managing infrastructure, users that are building applications and users that are using the applications, or what would that look like from a user perspective?

Robert: There's a few value ads. In my opinion, the best piece of software should be data agnostic which we are. And the best piece of software should be really, really focused on, how do you reduce the time to market? And how do you build a more scalable system? And so those are the things that we focused on.

Now, with such a system, you need buy in at several levels. First off, you need buy in, I'm not going to see at the CXO level, but it is somewhat of a cultural shift, if you will, because I would say traditionally, development is done bottom up: you download the latest JDK, or you get the latest good new compiler for C or whatever language you happen to be using and then you just start grabbing open source products or components and just start whittling that all together and trying to basically build a product. We take a different approach, which is you have this platform and has everything you need. It greatly accelerates your time to market.

So from that end, generally, I would say it's senior management certainly has a say in this, both on the business and IT. And generally, what we've seen, our experience has been that some of the more senior it but hands on developers, there's certain people that have been in a company 15 years, and they still love writing code, so they're the ideal person. They take a look at the platform, they confirm that it has what's necessary to go forward. So it does take buy in at a few levels.

Erik: And then the users, how operational does this go? Does it get to the point where somebody who is not touching code at all, but is like management teams are receiving visualizations of data? Are they building those themselves on the platform? Is somebody building them based on a request from a management team? What does it look like from the end user perspective?

Robert: Well, so there's kind of three different perspectives on this. One, is you've got the data integration part, which is how do you actually take all your different systems and stream them in. And by the way, I think another reason that finance is such a good target for us is because not a single one of our tier one clients hasn't been through mergers and acquisitions of mergers of acquisitions of mergers and acquisitions. So they naturally are sitting on every possible technology possible. And I always say, it's very easy to build a technology platform when it's green field and you get to make all the decisions. But after your first M&A events, all bets are off, you're now going to have two different technology stacks you have to integrate together.

So one part is I would say there's people that are subject matter experts in the different areas of the various systems and working with them on how do you actually integrate the data and get it into our platform. And again, there's a lot of talk around about how that's distributed and things. But fundamentally, that's one component of it.

The second component is the actual building of the dashboards. For that, generally, we're looking for it would be a developer, but not a front end developer, which is a bit of a twist. So, front ends are built using very small amount of code, almost all of its drag and drop and templates. And then you use high impact code and now the industry there seems to be this new industry called low code or no code. So I guess we would fall into the low code category. But really, we look at it as high impact code. So you still are writing some code, but you do it within the platform itself to build those dashboards.

And then the third category are the end users. And I want to focus on the end users because I think we're a little different than a lot of other platforms that might come to mind is our use case are very often mission critical sort of use cases, the sorts of things where seconds matter, where data is being fed in from tons of different systems, you're looking for anomalies, the system's automatically trying to pull out the outliers and look for static and try to pull out the noise etc. But at the end of the day, information when it actually finds or detects an anomaly, that basically is raised to user screens where they can make decisions in a split second.

The analogy I make is it comes back to what you naturally envisioned in a movie, which is, you know, if you've ever watched Star Trek, they have all those screens and when something goes wrong, you see it on the screen instantly. So that's really a big part of the cases we focus on, which is, when interesting things happen you need to see them immediately.

And so I'll go back to the fleet management one, which is there's a handful of cars and all these cars have the sensors on it hooked up to our system, and two of those cars get in an accident, the operator would know within milliseconds that that accident took place, the airbags went off on this car, they did not go off on this car, the driver side seat is still occupied in car A but it's not occupied in car B. So we may have someone who's either paralyzed or stuck in the car, etc, etc. And all that information is instantly available to the operator.

I will go back to the highway analogy, because we can build IoT sensors all around the world. But if we don't have a good highway to move that information quickly, we're only getting half the value out of it. When I say half the value, yes, we can still get that historical derived information about trends, etc, etc. But when it comes to being able to respond to things in real time, that's where we come in.

Erik: And then when you get into real time, you also at least have the opportunity to start getting into real time automation. So not just presenting information to a human to make a decision, but automating systems, in particular, if you're looking at a manufacturing environment or somewhere where seconds or milliseconds can really matter in terms of a process. To what extent is that already a set of mature use cases? Are you exploring real time automation or actuation systems?

Robert: That is a natural progression for sure, which is once you start to see all this information in place. And the thing is what you realize is you get all this information in place. Let's go back to the to the car crash situation. So you've got the accident. And now the thing is over time, you start to realize the operators are sitting there like okay, we've got two cars now responsive airbags are... Okay, can't we automate this and automatically have the system detect that when you see these two pieces of information within a window let's call it a five second window? Now a certain event is taking place that can be then bucketed together and now you can start to look at that higher level information.

And this is the amazing thing about finance, is because it's that exact story, put into a recursive loop, which is you have some information coming in, you take that information, you derive more information from that. And then at some point, someone realized you could take that derived information to get more information from that. So we are headed down that path whether we'd like it or not.

And so the thing is you look at finance, and you say, wow, there's so much information. So to put it in perspective, I think if you look at the Twitter feed, I don't know what it is something like 10,000 messages per second globally, that's what humans are generating which is a drop in the bucket compared to any financial exchange that's reasonable in size. But the point is these exchanges are sitting on all this derived information and basically pushing out way more information because they're building this derive information.

So I'm giving a very long, yes, it's a very long way of saying yes, you're absolutely right. Once you have real time access to this information, you then naturally are going to start to build derived real time information off of that and that ends up being more information than you had in the first place. And then the cycle goes on and on and on. And I think that finance is the canary in the coal mine on this one because this has now been happening for 30 years. And we're sitting on now trillions and trillions of records of information today when that's clearly way more than is actually being inputted into the system.

Erik: I think we have a dynamic here where we have information technology that has improved something like a million fold over the 1980s. And then we have human brains that have maybe gotten a little bit sharper, because we have better diets or something. And we have organizations that hopefully have improved a bit, but also are looking a lot, quite similar to what they look like in the 80s. Previously, we had technology that just didn't work very well, now we have great technology, but we have the same human infrastructure. So what are the typical challenges that you see organizations deal with as they tried to make better use of their data?

Robert: We have technology that's growing way faster than organizational structures, or humans are capable of processing that. And I think we almost need new disciplines in education on how to think of data more from a systems perspective than from individual nodes, and things like that. So I think from an educational aspect, there's improvements we can make there.

But I think in the immediate, what still makes me very excited about where we are, this is a fascinating thing with technology because it's so repeatable. And this is what I think is companies like 3Forge real promise. It's a complicated world. And the challenges are incredible. They're very difficult and they're always growing, and people are always looking for the best thing.

But the beautiful part about it is if you actually solve a unique problem and you do it in a unique way, I feel that there's the substrate and the infrastructure globally to be able to adapt to this stuff in a way that would never be imaginable. If you go way back to like when bridges were made with rope and they move to steel, I'm guessing there was not a quarterly conference where all the bridge makers would go and sit down and say, hey, there's this great new thing, steel, let's just move all our bridges from broke to steel right now. It took a lot of time and a lot of trial and error, and etc, etc.

Now, we live in a world where we do come up with a new way to solve something, there's a huge communication infrastructure. I mean, frankly, this blog is that sort of thing. So we're now when there's new ways of solving a problem, they can get out there very quickly. And frankly, that's why a company like 3Forge 10 years ago we can have an idea, now we can have offices globally around the world, and working with most of the tier one banks. And it's because there's this sort of system in place where I think when there's new technology that really does change something, that can be adopted to very quickly, for better or worse, because obviously, then you end up with this hodgepodge of systems.

Erik: What’s the technical requirements of an organization to make use of your solution? Because I imagine if you're coming from a finance perspective, you've got significant IT budgets, they can afford very, very sharp people. I'm working with a lot of industrial companies and they're really struggling to compete for IT talent with the tech companies or the finance companies because they look and they say, hey, our engineering salaries, $100,000 USD and these guys are asking for 200k, we can't play there. So there's a big challenge in terms of the industrial world acquiring the talent that they need often to run the systems that they'd like to be running. What are the requirements typically look like for a manager of 3Forge?

Robert: So first off, the commercials would be a different a different conversation. We structured quite differently depending on the company and the needs and things like that. Now, in terms of the platform itself, I did take a playbook from Microsoft which is back in the day, they would always make sure their software ran on very old hardware. They don't do that anymore. But that is something I still focus on.

So whenever we have a new release of the software, we make sure it runs on a Raspberry Pi. The idea is it should run on small hardware footprints. But I'm not saying Raspberry Pi is small compared to a lot of the IoT devices and a lot of the solutions that is in IoT. But relative to big iron or big hardware, a Raspberry Pi is a fair compromise. So with that said, yes, it's designed to run on very low profile hardware, especially when you start to get out to the exterior nodes.

After looking at many, many, many different use cases, I think of I've approached an architecture that I think works quite well. And it seems maybe a bit arbitrary at first. But I think it actually lends itself very well to just about any industry. So if you can imagine it's a three tiered architecture.

So the first tier is what we call the Relay Layer, you can think of it as the messaging layer. So that's the layer that's interacting with all of your different systems. So let's say you've got hundreds of thousands of nodes all around the world, let's say you drop a few zeros, so you've got 100,000 nodes out in the world, you might set up 100 relays, and each relay is responsible for thousands nodes or something. And those relays would be geographically dispersed. Those relays are really responsible for managing that spotty communication between the individual devices and the relay itself.

Those relays are then what we call store and forwards, they're taking that data, they're capturing it in case they lose communication with “the mothership”, they're storing that data. So that's the first layer.

The second layer is what we call the Center, that's really the brains of the operation. So the data goes from the Relay Layer to the Center Layer, that's where we're analyzing that data in real time. That's where we might be dropped copying that data. That's where we're persisting that data. That's where the windows that we were talking about where you're looking for interesting anomalies, etc, that's the second layer.

And then the third layer is what we call the web layer, but really, it's the layer that humans can then start to interact with this data. And all of those are distributed. So you have your relays those connects with the back end systems, or in this case, the IoT components, the middle layer which is your brains of the operation, so to speak, and then the web layer, which is where humans actually log in and then can see that data in real time.

So the Relays are designed to run on absolute tiny hardware that is going up and down all the time, no problem. The Center Layer really is going to be down to how much data do you want to transmit? How much data do you want to hold, etc, etc? And the hardware should scale accordingly, just like any database. And then the web layer, again, that's going to scale depending on how many users you have. But the idea there is it elastically scale.

So, maybe you'll get 100 users on a single node and then you realize you need another 100 users, you spin up another server, assuming you're in the cloud. So you just start adding more servers as you get more users and you scale that way. And by the way, the interesting thing, going back to the highway analogy, the web server in my analogy is like the airport. The better your highway system gets, the better your economy gets and the more local people have cars, etc, etc, the busier your airports can get.

So, if you think of it that way, the web server scales. So the idea is as you build a more connected system, you're naturally going to have more people that want to access that system. So it's very, very important that you can scale the number of users that can log in simultaneously to take advantage of that data.

Erik: How close to the edge do you get? Are we talking about regional data centers? Are we talking about smart gateways in a facility? Are we talking about embedded software on basically an embedded device in a vehicle?

Robert: Yeah, I wouldn't go as far as an embedded device on a vehicle yet. So in the case with the fleet management, I actually don't think it was a Raspberry Pi. It was the smaller, cheaper version. So there's a Raspberry Pi inside the car, and then that was communicating over the cars bus as an example. So that's how close it would be.

We also have cases, now if we go into finance, they will put a relay so we call it NY4. That's like the data center where if space is a premium and information is moving, everything's going really, really fast and I think everything they want things done quickly. So, there would be a relay in that same center talking directly to the applications that we're monitoring. So that might be another example. And in other examples, there might be one relay geographically located. So you'd put one in APAC, and that would basically be connected up to all your APAC devices. So it's very flexible in that regards.

But basically, the idea is it's communicating. And this is where those adapters come in. So we have lots of standard adapters out of the box. But a lot of times people will build their own feed handler. So at that point, it can be their TCP IP or multicast or however it is, somehow you've got to get the information. So the goal is what we leave up to the customer is how did it get the information from your device into the relay, that can be through any various communication. You write a little piece of code that lives in the relay that does that; and then once it's inside the relay, you can assume it will safely and in a guaranteed manner, at some point make its way back to the center and then ultimately to the web server where people can see it. So basically, we're managing the whole superhighway.

Okay:  Maybe we can look at one or two more use cases. I think we've looked at the logistics one, obviously, there's banking. Any other more industrial or commercial use cases that you have on the market right now?

Robert: To give you an idea of some of the variety of use cases that we have, and again, might not speak directly to the audience. But we've done things even on with like calculating waterfalls, or buy side firms. So that's like one end of the aspects. That's very data intensive calculations. And then if you go to the other end of the spectrum, again, it would be actually putting the relays into small devices, things like those little carts that you have inside the airlines, which moves the food around things like that so you can sort of track that sort of thing.

Erik: Actually, can we quickly touch on the business model? So not getting so much into the pricing details, but just what is the structure look like? Because I guess you could have a very wide variety of adoption cases here.

Robert: So the structure of the company really is broken down into two parts. We have the platform itself, which is licensed and then we have our support, which is basically us providing either hands on services to build. So when I said it's up to the customer to build that interaction, I mean, they can also consult us and we will do it on their behalf as a consulting capacity. So basically, the organization is broken down into two things: core development of the platform, and then support/custom development for our customers.

Now, one of the most important things about the platform, which I have been steadfast on since day one and I think really sets us apart is that the platform has a single branch of code. And by that, I mean, if a customer asks for a feature to be added to the platform, it gets added to the platform for everyone. And that's why I look at this as a consortium.

And this is one of the things that I think is important to creating an efficient business from a software perspective. It's always easier to I would say, take a shortcut and basically quickly build something very customized that just immediately satisfies a particular demand. But basically always look at it, we say, okay, this is the demand. Let's think about it abstractly. What is it they're trying to solve? How can we build the tools and components, add that to the platform, provide that to them, and then give them tools and tips on how to customize that to get exactly what they need? So that's one of the biggest things.

As time goes on, for our existing customers, any existing customer, this is probably one of the biggest attractors, is over time the platform is getting better and better and better, faster and faster and faster as we get more customers. And for them, they don't see a growing budget. They don't see the costs going way up and up and up because basically, it's being shared across this community. And so really, the way I've always envisioned it is, again, it's a consortium where the customers provide capital to use the software, that capital then drives addition improvements and advancements and expansion to the software and then that gets fed back to the customers.

And honestly, really, at this point, we don't have any competition or anyone trying to compete with this frame of mind. But I can't imagine in a few decades this isn't going to be a standard way of operating. It's just so much more efficient.

Erik: Well, it's very interesting, because I think a lot of companies have the approach of selling the platform cheap and then selling value added applications on top, which there's certainly a logic behind that, right?

Robert: Yeah, exactly. And at a high level, obviously, I can't get into the finances, but we are largely funded by the by the licensing itself. I think exactly, you said you tried to get in with a platform on the cheap and then you just charge a millions of dollars in consulting every year. That's the exact opposite of what we try to do. We try to come in, we have a platform that really solves everything they need and then we provide a lot of consulting on top of it to get the job done. But that's not really our core focus. Our core focus is to have the platform be self-sufficient from the start.

Erik: I guess, your users range significantly in terms of usage of the platform. So what is that based on data processed or number of relays or users, or is it a kind of mix of the above?

Robert: I think, when you get into the IoT space, it would be a conversation. Because really, what the way we look at it is it has to be fair to the consortium at large. And it has to make sense for the customer. So it's not like a one-size-fits-all sort of way of doing it. So I can give you examples of failed approaches, which is we’ll charge per user. The problem is you have some use cases where you have thousands of users in one system and then you have other cases where you have thousands of systems in one user. So then you could go down the path of saying, we’ll charge per system, we’ll charge per user, we’ll charge for this, we’ll charge for that. That's no fun either.

So really, we have tried to skinny it down to make it as simple as possible. And so really, we just look at the use case. And in many use cases, we basically just do a very simple sort of pricing model around that.

Erik: Yeah, like that approach of saying, let's discuss and figure out something that works. So what have we not touched on yet that would be important for folks to understand?

Robert: Well, I think one thing is, you have to at least push for push for our LinkedIn page. We do about two posts a week of the different things we're doing. But the point is, we're always doing different trade shows, things along those lines. So follow us on LinkedIn for 3Forge. And then from that you can find out what's going on.

Erik: And so we'll put the website in the show notes. What's typically the best way for folks to get in touch with your team? Is it just go on the website and find the contact details?

Robert: Yeah, that's right. Yeah, they can just go into 3forge.com and find it from there. And of course, if they follow us on LinkedIn, they can always message us or email us at support@3forge.com.

Erik: Well, Robert, thanks for taking time today.

Robert: Thank you. Take care.

Erik: Thanks for tuning in to another edition of the IoT spotlight podcast. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy, or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.