 Hey, guys, how's everybody doing? So for those of you who don't know, I'm Mike Vizard, and I'll make a little confession. I'm what's known as a conference rat. Every spring, every fall, I go to IT conferences every week for the last 30 years. And so I would just like to let you know, though, that as I sat here for the last two days, that the divide between business and IT has never been wider. We've been talking about it for 20 years now, and I'm going to argue that this panel is going to be one of the more important panels you're ever going to hear on this subject. And so with that, though, I don't think most people know exactly what we mean by low code. So I'm going to open up with Johan, kind of giving us a little tutorial about what low code is, because it's not what you think it is. It's not a similar, and it's not about a place where my friends are. It's about a different way of thinking. Thanks, Mike. So low codes, I think, is best explained by taking one step back. So why are we all here? That's because we want to win in a software-driven world. And that's why we are interested or in Cloud Foundry or using Cloud Foundry. And if you think about Cloud Foundry and the advantages of Cloud Foundry, basically two key words pop into my mind. Cloud Foundry is all about abstraction and automation. It's about abstracting away from lower-level infrastructure layers and making sure we move from an infrastructure-oriented world to an absentric world. So what Cloud Foundry is doing is applying abstraction and automation to application deployment and operations. And basically, low code is doing the exact same thing, abstraction and automation, but then to application development. And evolution. So low code is all about abstracting away from lower-level programming and making sure you can use visual models to build your applications. And that means that you can use it's faster. So it's up to 10 times faster than traditional programming. But it's also inviting broader audience to developing applications and being part of the application development process. So with that, I was talking about the divide between business and IT. I just want to put a thought in your head for a minute. Business people care about one thing. It's called the number. And the number is the X number of things that have to be sold by Y amount of time at Z profit. And it's all they're ever thinking about. They get up in the morning and they think about that number. They go to bed at night, they think about that number. They just throw spouses and they think about that number. And it's on their mind all the time. So when you guys show up and go, you know, we're going to cut the amount of time that it takes to develop an app from two years to 12, you know, they forgot what you said. I mean, two years to 12 months, they forgot what you said even before you left their room because it has nothing to do with the number in their head. And so they're thinking about the world differently than you think about it. So with that in mind, I want each panelist to kind of introduce themselves and kind of talk about how you came to Mendex and how it kind of changed the culture in your organization. Let's start with Olu. So I'm Olu Brown. I work as a director at MIT. I run an application platforms team. So we've been using Mendex, I would say, for around two and a half years. John Charles, the CIO for MIT came in and wanted to have kind of a more data-driven approach to application development. And Mendex was identified as a platform that we could actually use to prototype applications and to kind of manage to kind of that low-code infrastructure framework and application layer to really figure out, does it work? I think short answer, it has worked. We have about 15 applications that we're running at MIT, but it's changed kind of the paradigm of how we develop these applications because like you said, things can take a year to two years to develop something. We generally turn stuff around in three to four months now. Cool. Jonathan? I'm Jonathan Boshay. I'm a partner with the Solomon Group for the Orla, Louisiana. Produced very large events and sporting events and entertainment events. And the way we came to Mendex is we were, we have some pretty unique processes in our industry that we have to go through. And we were looking for a piece of software to help us manage large-scale events. And we quickly found that there was nothing out there that fit our process. And we didn't want to buy an off-shelf piece of software that made us conform to the process that the software was written for. So we decided we could create our own. And by create our own event, let's go find a software company. So we went down that road for about a year and we realized that the expense and the complication of just explaining our process to someone else who isn't in our business was gonna take away too long, cumbersome and expensive. So we started looking around and said, okay, maybe this is a filemaker thing. What is this? What can we use? And we came across Mendex. And we started by building out the ERP program of speaking about it, which we use in-house and it's been live for about a year and a half now. And basically, the processes we wanted to use in our business, we developed a system for Mendex and not the other way around of trying to buy a piece of software and make our process of that. So that was hugely important to us. And it's been a great return on our investment with Mendex. Since then, we've even gone further and realized that it was Mendex for our clients. So we have about 20 applications running right now, three of them are internal and the rest are for our clients, larger than the events that you've probably been to. Cool. Beth Ann? Hey, great. My name is Beth Ann Berksmark. I'm the Assistant Vice President for Academic Systems and Chief Enterprise Architect at Georgetown University. And I spent a majority of my time really focusing on how can we across the entire campus break down aging legacy IT that's locked in silos, moving into modern platforms in a way that embraces innovation rather than impede innovation. And if you've ever had any connection with academia, you don't always think of academia as, you know, cutting edge or a little bit more of the glacier. But I think that that's changing now with options like Mendex and low code and cloud. We adopted Mendex in a specific, our research and regulatory domain. And we had very traditional IT problem. We had five or six different applications. One was failing at scale. Four didn't really meet the needs of individual campuses because in higher ed, not only do we have very specific processes that are unique, each campus will define that process independently. So it's almost an exponential increase in the number of legacy applications that can exist at 91 point in time. And traditionally, our solution path would be, look for a software package, which is not going to meet half the needs. And then that will spur more shadow IT. Or I could hire a consultant that would build me a very expensive custom application that I would never be able to change. So it would be out of date within 12 hours of launch. We could build it ourselves, but that would take two years. And at that point, half the developers would have gone, graduated and gone someplace else and no one would know their code. So Mendex really offered us several options. One, speed to launch and to accelerate, follow the cloud first principle. But most importantly is what we found in the low code environment was the ability for reuse and repeatability. And we use this as an opportunity not to replace five disparate apps, but to build one app so we could combine where the campuses has already agreed on similar business processes, but then build in the variation for other areas. And the benefit that that brought to our business was not only solving the problem, driving down some of the costs, speed to launch, but we improved the experience for our researchers who in the past, you might be one researcher, you've got to go to all of these different places. I mean, at one point, we even had seven websites to tell you which way to go. And the instructions were not the same every time. So giving them one simple intuitive experience that we can also innovate and change over time has been phenomenal. And we really see this as an excellent tool for dealing with, you know, I think we've got like 800 of these apps out there. So down the road. So have you guys kind of changed the, I don't like the word, but paradigm in terms of what a developer is. And I asked the question because everybody's thinking about, you know, there's a developer shortage and I can't do this and I can't do that. And then we wind up prioritizing stuff. So, you know, in your shops, have you seen more developers or people who aren't really traditional developers? They might even be business people or whatever, actually starting to write applications. I don't, maybe not code per se, but they're building apps. Yeah, I mean, are you guys seeing that? Yeah, I mean, I think at MIT, our menics development team, none of them were traditional software developers. We had QA engineers, a technical project manager, and a senior business analyst who took up Mendix. I think the biggest part that Mendix brings is, if you have analytical and logical kind of structure, you can build the applications without having to dig down, you know, into the kind of low application program in area. Yeah, I think we found a similar thing in our business. You know, the nature of our business with producing large events, there's a lot of technical aspects to that, sound lighting, video, and all those types of things. So we were able to take some of those folks who were technically savvy and understood structure and electronics and some of those things that kind of crossover into the code world and let them loose on Mendix and they were able to quickly, none of these people had ever made an app before. They touched on the next application. So they were able to quickly kind of figure it out. Now we're a year plus into it and I would say that if I teach a class on Mendix, that those are the only things. We've seen similar crossovers. So when we first started using Mendix, we definitely built the team with some traditional Java programmers. But then, you know, some of our best Mendix developers have been from our DBA team and joining in into this agile team environment. I think that where the role for developer is changing and this is true of every area in the IT stack. So the last 10 years, we forced our IT professionals into these very tightly defined areas. So I'm the VM person. I'm the block storage person. I'm the developer of this language. I'm the architect in this area. And the new technologies really require you to not only think across the IT stack, but to understand the business and the user experience. So I think where our developers are starting to shift their mindset is not just thinking that I'm going to code to spec, but I'm actually going to think about the overall customer experiences. And I'll use speed as a good example. Like speed is the unspoken requirement that will tank your application that no stakeholder will ever tell you is important. But as developers are starting to realize that, and I think that's helping to traverse this gap of understanding the dynamic infrastructure in terms of understanding what gets adopted and what doesn't. Yeah, and for us, it seemed like it was far easier for us to find someone who knew what the process should be. Figure out how to do the programming in the other way around. The beauty, of course, is that if you have... I mean, you started this panel by talking about the gap between business and IT. And the best way to solve that is to make sure that the same people are all involved in application development, not only in giving feedback, but also in designing part of the application, the business processes, the UI of that application. So basically, if you lower the barrier of how you build applications, you could say that that is democratizing application development because more people are able to build applications and be part of that whole process. Yeah, I think participation is actually really the key, right? Every one of the projects that we work on, we make sure the business and the development team are together involved working through that whole process. It's no longer, you gave us a spec, we'll go away for eight years and come back and deliver something. And then you're gonna tell me it's wrong. I don't even remember asking you to develop it in the first place. But yeah, in the land of DevOps, there's this notion in the agile thing about two in a box. But the two is always two developers kind of work in hand and glove. But in reality, the two in the box should be one developer and one business person who are kind of building something together. I always like to visualize that. I mean, we talk a lot about DevOps at this conference. So you have the operations, developers, and we should merge these two worlds and make a cross-functional team. I think we should do the same thing if you look at application development and the business and kind of merge these two worlds as well. So have a cross-functional team that includes people from the business or the domain experts that can immediately express their needs into visual models. Business people, by the way, don't distinguish between developers and IT. They pretty much hate you both and they don't really care. Can you, we're at a Cloud Foundry thing. So can you take a minute and describe, you know, what is the connection between Mendex and Cloud Foundry and whether you care and why are you here? Basically, we care about Cloud Foundry a lot, but in two different ways. So first, if you look at Mendex as a platform, it's not just about application development. It's about supporting the entire application lifecycle. So from your first idea to building the application, to deploying it, to gathering feedback, and then so the whole cycle is supported in our platform. So for the deployment part, we have our own public Cloud and that's based on Cloud Foundry. So open source Cloud Foundry running on Amazon. So if you build an application, basically model your application, you can just one click upload that to our Cloud and then it will run on Cloud Foundry. And of course, that's something that's speeding up the whole process of our internal engineering. So instead of building that whole layer ourselves, we pick it back on top of Cloud Foundry. So that's one reason. The other way, the reason why we are really happy with Cloud Foundry is that it's a standardization of our deployment target. So we want to offer our customers flexibility and freedom in where they wanna run their application. So we really have a multi-Cloud strategy. And with Cloud Foundry, we can run everywhere. So we run on our own public Cloud. We can run on any Cloud Foundry vendor that's at this conference. And we can, so you can run your application on-premise, on a Cloud Foundry distribution, or on any public environment that's based on Cloud Foundry. And for us, that's of course a very easy thing to do because it's all the same API and it's the same layer. So that's a great thing. So can you guys describe, I mean, have you had any interaction with the Cloud Foundry part or is it invisible to you? There's a runtime somewhere. So I mean, generally it's invisible, at least to us. We use the Mendex Cloud to deploy our applications. And I think it's taken a lot of the burden off of us from just from a support and operation perspective, right? We can log in through the Mendex platform to kind of see all of the different metrics associated with our applications running in the Cloud, view the logs, do all the kind of normal support and operational stuff without having to kind of go down a level layer, a level lower. So we have 20 applications right now. Yeah, it's pretty invisible to us. I would say also, I mean, I think it's a little bit like when you're buying a pan, I want a non-stick pan. I'm not really checking to see if it's Teflon, but it's the Teflon that makes the pan non-stick. And I think that many of the business procurement environments aren't going to look that deep. I mean, even today, I have proposals cross my desk where, oh, this is Cloud. And I look at this and I was like, well, this is traditional shrink rack proprietary software on a physical server in somebody's garage. This is not really Cloud. I know we don't have to buy a server, but there's some differences here. So I think that translation, what Cloud Foundry gives Mendex and what I expect as a consumer of Mendex is the ability to dynamically scale. Because I have a lot of applications that have the cyclical peak. I'm looking for portability. I'm looking for continuous integration that provides no downtime to me. And I'm fine with multi-tenant environments, but because I'm in higher ed and I know our cycles are all the same, I want to know that that scale is partitioned and I want to know that another customer that does something bad cannot hit my data stream. So I think it gives Mendex and other companies capabilities that the business is looking for, but they're not defining it in terms of I'm looking for Cloud Foundry per se. All right, a lot of times the business doesn't even know what the order of the possible is. So they're kind of, since we're talking about that, I'll bring this up. So the buzzword of the day is digital business transformation, which means nothing. I mean, it's a lovely term, but it means absolutely nothing. But at the end of the day, are you seeing a change in the way that business people think about IT or engage with IT as a result of what you guys are doing? And can you describe a little bit about what you're seeing on that side of the house in terms of how they interact with you or even think about things? Sure, I mean, I think you definitely see a change. I think traditionally, they come to IT with an idea and kind of a specific set of things to do and we deliver it exactly to that spec, which is maybe not exactly what they need. The level of interaction that we have now in kind of using these low-code environments allows everyone to participate in the entire process. And we actually are much more in touch with our clients around the university, right? We talk to them four or five times a week, even though we have maybe one scheduled business meeting during the week. So I think that iteration has been very helpful and allow us to kind of switch gears depending on what they figure out as they use the system, right? Because it's that whole cycle of actually using a system, providing feedback and we make additional changes that has helped, which is not the traditional design process for IT, especially in universities. Yeah, absolutely. And I think in our business, we going back toward Mendex era, where we were like, how are we making this system work for us for this? And I was like, well, we just name where it says client, we just put the project ID and then we just put this over here in this field and then we put a little star in the corner and we're like, no. So now we're able to, and I think it's a double bunch to work with Mendex because I consider how quickly we can iterate the application, sometimes on some of our apps, multiple times a week, releasing a new version, but people start to see, oh wait, we can actually make it do what we need it to do and then it becomes a barrage. Do this, do that, do that, we need this, what about it, those, those, those, and then it's like, oh, slow down now. We gotta actually test this stuff and make sure it's reliable and that there's nothing in the buggy that's gonna take the whole thing down. That's been our experience, I think it's a deluge. Well, I've seen a huge change and this whole transformation in the technology industry is a chance for a do-over with your relationships and the dialogue that you're having with your business stakeholders. I still think that there's a long way to go. I think we see it most in mobile that in business environments, especially in very distributed environments, it's very difficult for people to change what they've done for 20 years and so you may be able to build something, a business process in a mobile, but it doesn't feel like a mobile experience and especially in higher ed where we have students and they're willing to say, why, why does it look this way? Why would I have to do it this way? Being successful really requires completely rethinking how you break down some of those traditional barriers. I mean, the different business units across the areas, how many steps, how can you simplify, how can you streamline? And that also often requires governance decisions, changes, changes in funding allocations, working with your CFO's office to go from CAPEX models to OPEX models so that transformation and change with the business isn't really just about what we're building, it's much more fundamental in terms of how your organization is leveraging technology to meet their needs and the willingness to go through that change process. It's always funny to see if people start to feel that application development can be faster, you see a change in the whole organizational behavior and that's, so basically what we see a lot is that if you build your first application and you do it in 30 days instead of a year, then people start to ask what Jonathan was saying, like, okay, can you do this and this and then it becomes the next challenge, basically. But the beauty is that people change their level of expectation and I think that has two effects. So one is that they start coming with new ideas again because in a lot of organizations, people don't share their ideas anymore because if you share your idea and people say, oh, great idea and then two years later, nothing happened, you stop doing that, you stop sharing your ideas because it doesn't help in any way. If you know that your IT organization or can build applications a lot faster now, then you start coming up with new ideas again. So the whole kind of experimentation and innovation within the company is changing a lot. So that's an important aspect. What's also important I think that is the change that if people understand and believe that you can quickly build an application but not only the first version, but you can keep on changing it, that will lead to smaller applications and we all want that, right? So it's a big monolith, difficult to maintain, difficult to change, but people will request basically a big application because they know if they are now on top of the list to be served by IT in developing the application, the next time you will be on top of the list is two years from now. So you better ask everything you wanna have and have that single application. So you need to change that behavior as well so that you can focus on smaller applications, iterating quickly and things like that. So I think that's also an important aspect of changing that whole behavior and how you work together in the organization. So business people play a lot of golf and so the one term they understand is mulligan, so Mendex is a giant IT mulligan. When you think about the term, you use the smaller things and one of the buzzwords of the day is microservices, nobody's really quite sure what the hell microservices is so I'm just gonna say it's something that's smaller than what was there before. So are we gonna like get to the point though where the thinking of microservices and agile is built into the product itself and it's not something I need to think about it because if I need to think about it it's probably not gonna work. So are we kinda getting to the point where the concepts are baked into the tools? I think in any case, you always need to think for yourself and decide if you build an application or build a service, so what the granularity is. And that doesn't differ for Mendex or Java or whatever language you use to build applications. So but that's the beauty of Cloud Foundry as well. It's a polyglot environment so you can build your microservice or small applications using Mendex. You can extend that using code by the way so it's not just only visual modeling, you can extend with Java or JavaScript so you're never stuck into the environment. You can also, in your whole landscape, deploy 10, 20 Mendex applications but also your Java microservices to extend the capabilities of what you're doing. So it's basically your choice to how you organize that whole landscape. So with that in mind, can you guys maybe describe how it is that the usage of Mendex or the applications you're building, are they more externally facing or are you seeing more integration externally with other entities and is that kinda changing the way you think about your role? I think it definitely integration is one of the top priorities associated with a lot of the applications that we use. In an educational environment, we have a student system, we have our ERP and then we have lots of departmental applications around the institute that we expose in whatever way we can and how do we pull that information into an application? Traditionally, it's always kind of extracting data and pumping it into another database which has its own issues. But I think with a platform like Mendex, we're able to create these kind of microservices that can interact with the data from these different systems. We can leverage existing APIs that we have in systems around campus and pull all of that information into Mendex. So we actually have applications that our students use that connect to the traditional student system to pull data so that they can change their major or drop classes, things like that. And then we also interact internally with departmental applications for patent invention submission, things like that. But Mendex acts as kind of the UI layer and a portion of the integration layer. We have a new instance, a client that's a very large music festival production company and they wanted a single source of truth for our schedule. And so our Mendex application that we developed for them is the single source of truth for what artists is going on what stage when for all of the music festivals that pushes out to their different WordPress sites for the public basing schedule. And it's basically the talent buyer enters that information and it flows through all of the other locations. So it's a single source of truth for that because it's hugely important for their business and to their consumers. It's just one example of really using Mendex and also our internal application, the single source of truth or job codes and how much is labor costing and all these types of different things. Yeah, I'll build on that. I mean, I think the big win for us is really moving away from these applications where shadow data that would never map or align to the data in the core ERPs was being collected in 50 different areas or really being seen as being lost in cracks. So you lose all that downstream ability for personalization, data analysis, actual data. So Mendex has been important in terms of being able to support the variation in the app needs but using our tool of MuleSoft to come back and connect to the data. I also really think that down the road where there's amazing opportunity is that if we can care less about what the app is because centrally we care about the data and if we look at what's going on in the mobile environment where apps are disposable, they work for a function, they're a micro function, they mash up data across the way. When things change, somebody grabs a new app and they're mixing and matching. So if our organizations could deliver secured data and these thin lightweight development platforms we can move to that area where we've got disposable apps. Yohan, can you kind of give us a little history of where we are and I'm gonna ask this question because I admire developers as much as anybody but truth in the matter is they're kind of snobs, right? And basically they're like, I got my programming language and my skills and this is the best thing ever and this is all that is in the world. But so back in the day, we had everything from 4GLs to modeling tools and we're kind of down a similar concept and path but connect the dots a little bit about how Mendex came from that thought process and how you kind of got to where you are now. So basically if you look at the history of programming we always have been focused on, I'll use the words again, abstraction and automation because we always wanted to go to a higher abstraction level make sure we could be more productive from assembler to second and third generation languages and of course the whole idea of low code or whatever you call it, it's not new. We have been trying to speed up development for a long time and so you look at case tools, 4GL tools and maybe you have bad memories with that that could definitely be the case and I think why a lot of these tools have failed in the past like 4GL tools. A main reason there is that they basically missed the paradigm shift in the market. So they were focused on building, for example desktop applications very quickly but then the web game or mobile game. So basically at Mendex from the beginning we have been really, really focused on making sure that we are not speeding up how you built yesterday's applications faster but always focused on how to build tomorrow's applications faster. So making sure that people can actually innovate because that's the part of the organization that has a need for speed. The part of the organization that wants to innovate, introduce new services, new business models, you wanna quickly experiment because innovation is all about experimentation. So you need to try out 10 new app IDs in one month and then throw nine away and maybe that last one is the one that will really change your business. So you need to kind of feel fast and keep iterating and if you look at applications in general, so if you wanna build tomorrow's application, I think the next paradigm shift in applications is what I would call smart applications. And if you look at a smart app, that's for me that has three main characteristics. So a smart application is context aware. So it knows where the user is, what the user is doing, the context of the business process, maybe sensors around the user with the internet of things. So that's one characteristic. The second one is that a smart app is intelligent. So it knows how to process all that data and make decisions using algorithms or machine learning. And if you combine these two things, being context aware and being intelligent, you come to the third characteristic of a smart app which is proactive. So making sure that instead of the user going to the app to trigger an action or to get information that the app comes to the user using interactive push notifications or whatever technologies we can use. And then, so I think we have to focus as application developers, as platform builders or making sure that we enable the next generation of applications so that we actually help our customers to innovate quickly and to really enable them. So it's not just about how you build applications or how you deploy them or how you operate them but also the type of applications that you build. Falling fast is also one of those cute little Silicon Valley terms that business people don't get either. They're like, not something they really wanna do. They like phrases like winning sooner. Can you guys describe what do you know now about implementing Mendex or moving to this model that you wish you knew before you started? Yeah, I mean, so one of the things I think we mentioned before around once you have that paradigm shift and the users realize that their ideas can actually be implemented in a short turnaround time, managing kind of that flow, right? Cause I think the trap that you can get into is that there's a lot of churn as well, right? That you're kind of starting and stopping and re-implementing the same idea, maybe like two or three times during the course of the project which sometimes it's okay, but I do think there's components of traditional software development that still apply and how you think about architecting an application and so how does that translate into kind of a low code environment like Mendex? And again, I think you get to it. I wish we had gotten to it faster. It probably took us maybe six months too long to kind of figure that out. But now that we have, I think we're producing more efficiently and at a faster rate. So that question a little bit differently and I do agree with what you said. From our standpoint, using non-coders to that are actually the developers now, I just wish that they have the experience the last year and a half so that I can work on the first application which is our internal ERP, which is the worst one. It's great, but the user interface and some of the way that the microclosers are written in the background, now that we've done 15, 20 since then, wanna go back and say, okay, let's redo this now that we've learned all this information and learned all these skills inside of Mendex. So that's a little bit of a different answer, but that's what I would say, at least for us, because we're using non-developers. Yeah, I would echo that too. I mean, and one of the things in any environment when you introduce a tool where it can be faster and easier, the first natural reaction that everybody has is put as much energy possibly can. I used to teach photography, same thing, digital. I mean, they had enough things in there where this would never load over time. So learning restraint. And we saw the same process where, oh, this is great, we can add all of these things in. But then as the business users then went through the process, they're like, oh, I'm scrolling through 18 screens. Let's simplify, let's come back. And I think that I wouldn't want to eradicate that. I think the group learning process in and of itself was valuable, but to factor that time in just, especially when a particular team comes together for the first time. So I said earlier, I go to conferences all the time and I talk to people at the shows. And basically, everybody's there for the same reason, right? They wanna steal a good idea from somebody. So what's the best thing that you guys have built in Mendex that you think is the coolest thing you've seen so far? And then what's on your agenda over the horizon? Sure. I don't know. I'd say we have probably two separate applications currently that I would think is a good idea. We have a nanotechnology laboratory on MIT's campus. And so a lot of the tool scheduling and tool management around laboratory equipment is something that's very time consuming and just takes up a lot of cycles. So we have an application that helps us with that, not only to schedule the tools, but actually start up jobs. So we're using Mendex in conjunction with like Bluetooth and other technologies to actually interact with hardware equipment within the laboratory. And that's been a huge boom to the nanotechnology laboratory because they have hundreds of research projects that are using equipment on a weekly basis and that interaction needs to be automated as much as possible. So that's kind of one thing that I think is pretty neat, allowing us to interact with hardware equipment. The other is MIT is a research university, so they submit thousands of patent applications every year. And it was all paper, all paper. So automating that, digitizing all of that information and kind of streamlining that whole process, I think they've been able to process patent applications and half the time that they used to before and they're constantly kind of just building upon that. So our legal group at MIT is very grateful for kind of this iterative cycle for application development. And we've been working with them for a year and a half just constantly either adding new components or adding new applications to that entire environment. So you killed all their scut work and they're happy? Yes, no more paper and lawyers like paper, so. Yeah, we've been doing a lot of Mendex in the area. Events, interaction with the Mendex and events and music festivals, trying to blend the production of the event with the user's experience where we're doing the RFID years spans and we're having RFID years out in the field and in the venue and we've left the user and linked their social accounts to their wristband and linked their credit card for spending money at the various concessions and whatnot. And that's all great money from the money standpoint, but for the experience, when someone walks into the room or have social media visualization between the artists on a huge stage and large screens, we'll actually read their wristbands that are in that area and just use their social content on the screens. Obviously stuff that they would give us approval to use, but really, we did the sporting event where there was, you go into the convention center and you can play the punt pass kick thing and get a prize or something. And well, when they walk up to that and scan their wristband and you look up what their favorite team was and some other information about their favorite number on the screen in front of a mother playing the game is their name on the back of the jersey, their favorite team. So really kind of augmenting the life of that experience. So full disclosure though, you were working on something on your way here, right? So the upside of this thing or the downside, depending on your point of view, is that you can work on it anytime, anywhere. Yeah, actually, I was a lot on the outside. Actually, the internet connection on the plane allowed me to commit it and restart the actual as usual that we were able to so quickly meet their needs. Isn't the internet on the plane great? Yes. Okay, so you usually don't use regulatory compliance and cool in the same sentence. However, I will say that using Mendex in that area that is so close to our core mission in furthering science and for our economic needs, I mean, Grant is one of the revenue streams into our organization. It's been extremely successful, but I'll answer the question a little bit differently in terms of where I think there's additional need and potential for products like Mendex and especially if low-code can get even further down to no-code environments down the road. At Georgetown, we participate in a number of research activities and partnerships with our vendors like Verizon and municipalities, public sector, DC government, looking at smart cities. So how can transport, mobility, wireless, internet of things, sensors and data come together to improve safety, sustainability and your life in general through public private and higher ed partnerships? What's interesting to me is that when you're, if any of you have ever engaged to build applications for smart cities environment, something like over 90% of those implementations are in the coastal cities only. And when we talk about the digital divide, which we've been talking about for 30 years, we're seeing that accelerate with the pace of change and what's happening in the middle of the country, you're having large areas that are not being exposed to this level of innovation and automation because you don't have the IT areas in those areas that's all moving to the coast and the urban environments. But a product like Mendex or Cloud Foundry that can broaden that accessibility or the democratization that you talked about, there are enormous applications in those areas. So I think that that's really something in terms of looking at not only the sectors that are jumping on quickly, but what are the untapped markets that are out there as well? So we have one to-do list item for Johan so far. So what do you guys add? What do you want Mendex to do next for you? Well, so I think he already talked about kind of smart applications, right? So the ability to use smart services within applications to kind of, again, I think the biggest thing is being proactive with users of applications, right? More advanced notification of activities that people need to perform is a huge boom. I think the other is around data accessibility, right? So we talked about data integration between applications, but one of the things that I'm always, you know, keen on is data accessibility. So there's data that a Mendex application can generate. So how do non-Mendex kind of consumers use that information as well? And that's always a big boom. So I want the integration to be more bi-directional. Yeah, I would agree with that. I mean, we do a lot of interesting things. We talk about RFID, there's fans early on in RFID in general, we've done a lot with that, both on the consumer-facing side and in our warehouse, so we just keep all of our equipment, lighting sound, video equipment for live events. But we were able to actually write a widget to inside of Mendex to be able to read RFID with an Android, a regular Android device. And a lot of our competitors and even competing software products that we may have bought prior for inventory tracking, they wanted you to buy this $1,500 RFID reader handheld thing. We're like, okay, well, Mendex plug-in that we created runs on those Android devices that have an NFC reader built-in, so that's $99 for a prepaid device. So they become disposable at that point. So that's huge for it. Nothing comes to mind other than that, but we were able to make it work, even though it wasn't built-in functionality just yet. And more of those kind of things, like you said, how the sensors access to physical data. Well, that's the beauty, of course, of not closing the entire environment but making it open, that you can always extend using JavaScript or Java. So basically, you're never stuck and you can keep on building additional things, although it's not out of the box in the platform. So I just want to check, do you have a date for the deliverables on any of this? Tomorrow. You all need to commit that. It's low code, you should be able to deliver. All right, I want to thank our panelists for sharing their knowledge and their insights. Guys, you guys were great. Thank you all for listening. Have a great show. Thank you. Thank you.