 Welcome back to Boston. We're down in the seaport. This is theCUBE's coverage of Red Hat Summit 2022. I'm Dave Vellante with my co-host, Paul Gillan. Sebastian Moss is here. He's a senior enterprise architect at Bitmark. Sebastian, thanks for coming to theCUBE. Welcome to the United States. Good to have you in Boston. Thank you. Thank you for the invitation. It's good to be on a live summit again after those testing two years. Strange, isn't it? I mean, people kind of don't know what to do. Shake, bump, fist bump. I was like, yeah, but everybody wants to get out of the home, the lockdown, and there's a real pent-up demand. Tell us about Bitmark. Bitmark is a managed service provider for German statutory health insurance companies. We manage about, our software that we develop is for about 85% of the German health insurance companies. We have, not only do we build the software, we also have data centers where we run software for our customers, and it's everything that a health insurance company is mandatory to have to run their business, so to speak. What's the life of an enterprise architect like these days, and how has it evolved, how has it changed? I mean, independent of the pandemic, we'll get to that, but technology changes, organizational objectives have changed, the public policy changes. How was your, the life of an enterprise architect change? Well, we have this big model with J2E application that is running on JVOS, and now we want to, we want to change that into a more modern environment and using OpenShift to do that. And yeah, there's a lot of regulatory things that come up that need to be figured in. There is new demands that our customers have that we need to figure out how to get to market and to be able to deliver software faster and make the turnaround, or have the turnaround be less. So kind of following the technology trends of going from big monolith to microservices and containerization and distributed data, the whole thing. Scalability, and quick turnaround, that is the main focus. So the application that you're here talking about is pace-to-face and application, kind of a new market for you, a new direction. Is this part of that overall shift to a more modular microservices-based structure? Well, we had applications like this before, but this is a new branch of it because there's a strong drive in Germany to for more digitalization and to have a new interacting model with the customer from basic things to more advanced features like medication services, vaccination status, managing your allergies, and that's an added value that we want to give for our customers so their customers can benefit. I don't know what it's like in Germany, but in the United States, you used to call up the doctor and say, hey, can we do this over the phone? No, you got to come into the office. And then, of course, with the pandemic, it was like, you can't come into the office. It was just total flipping, because you could get 80% of what you needed done, and this is what your app enabled, essentially, right? That and some added value as well to give a benefit for using this online interaction for the insured people, the patients. It's actually a digital gateway, including your data. Well, that's the other thing you can't get as a patient. You can't ever get through your data. Right. You can get it, but nobody else can. Sometimes it's hard for you to get it because, again, in the United States, TIPA and the requirements for privacy restrict often access to data. You have to go through hoops to get it, so that experience is what you codified in your application, yes? Yes, we have this unique data set of all health-related information that people have to interact with when they're sick or when they deal with their healthcare company. And yeah, we want to provide that data to the customers whether they're able to look at it. There's also the electronic patient folder, you can say, where there's data like medical exams and stuff in there that they have access to. We provide that as well for our customers, but yeah, it is about the interaction and that I can see when I put something in to my insurance company via email or the doctor puts something in that I have the interaction on my phone and see when it was delivered to them, when it's active, when I get the money, stuff like that. Now, this application is built on OpenShift. It's cloud-native, has all the constructs. How different was that for your development team from building something like, you mentioned the monolithic Jboss application that you already have. How different was building the cloud-native constructs? It's quite different. I mean, it's building software. There's a lot of the same things involved. And we've done agile and scrum before and so on, but we now have a, we're trying to be, or no, we're actually achieved to be faster in bringing this to market, deploying it in different data centers, doing it all automatically, doing automatic tests right as part of the pipeline. There's a lot of huge steps that we can, we're able to take because of the technology and that's why we did go there in the first place. That's why we said, okay, it needs to be cloud-native. You found that Red Hat had the full suite of tools and you needed? Yeah, I mean, there's some open source stuff that we also integrated into the pipeline and everything, but there's a lot of, for example, we're using the ThreeScale, the API management from Red Hat, just to be able to use the functionality that we build, that the customers can use the functionality and other products that they use, that CERT partner people, CERT partner companies are able to use the services as well. Okay, so the dumb question is, but I'll ask it anyway, is you could get this stuff for free, Kubernetes is open source, you could get EKS for free, why don't you just use the freebie? Why? Well, we're on a scale with so many customers and data centers that we have to take that we do need support in a way. And I usually say, so if we take software from whoever, whatever company it is, we're going to break it. The transaction load that we have is quite intense, and the performance that we need, especially in the business-to-business market, is so big that we do need the interaction with a vendor and that they're able to help us with certain escalation services. Germans play rough. So, you know, when a vendor announces an innovation lab, I always go, okay, that's an EBC, like an executive briefing center, it's all going to be used for sales. But my understanding is you actually leveraged the innovation labs, it was actually helpful in building this application, is that true? I actually took part in the open innovation lift that we did with Red Hat, and we knew what we wanted to do, we knew the technology, we knew what we wanted to have done, but they helped us to get there step-by-step with the tools they have, the ways of working and how this is built, it really lends itself to build that step-by-step and worry about some stuff later and just do it, yeah. Peace, ma'am. This is also a new market for you, it's your first real business to consumer-facing application. That implies a very different approach to experience, design, to how you... And performance, yeah. Yeah, exactly. How did your development team adapt to that? Well, there's certain things that you build into the process, like integration testing, automated integration testing, where the application just gets checked right after you check in your software. We built in load testing to, we have an idea of how many transactions per seconds there will be, and so the load testing takes care of that as well. And that is easier if you have a small piece of software instead of the whole monolith that we usually have. And so we were able to build it quicker and get it out quick in hours. How have you accessed customer feedback, you do your net promoter score surveys, what's been the customer reaction to your consumer reaction? I mean, I'm kind of the wrong guy to talk about that. Come on, you architected the thing. Yeah, I did, and the feedback has been very good so far. And we're pretty happy with it. It's running very well. I don't quite know how they got there. Our customer does questionnaires and stuff like that. We have a different department to solicit feedback on that. But from what I hear, it's received very well. One of the cloud native features I understand you use extensively with APIs for integrations. How are you making this application accessible to partners? What are you exposing? How will you use those APIs to enhance the value through an ecosystem of partners? Well, we document them. And so they're out there to use. And as long as there's a security process within EM that we have in front of it, they're open source APIs. So as I said, they have other programs that they wrote themselves so that they bought that are able to use those APIs from an open API document and just interact with that as long as the user is authenticated, they're able to get this data and show it in a different context and use it in a different context. Do you play golf? I used to a little time ago and not anymore. Do you know what a mulligan is? Yes, I did. Okay, if you had a mulligan, you'd do this all over again. What would you do differently? I have an interesting question, I'm not sure. You say you're smarter after you've done that and of course there's certainly things that I didn't expect that would happen, like how really you need to go modular on everything and need your own resource and infrastructure because we came from a very centralized scope. We had a database that is a big DB2 database and now we're going into smaller database and not decentralized a lot and that was something that the extent of it I didn't expect, I wanted to use more smaller things and that was something that we very quickly learned that we really need to separate stuff out. Was that an organizational sort of mindset shift? Are you rethinking or re-architecting your data, your data architecture as part of that or is this more just sort of tactical for this app? No, we definitely need to do this because it really gets, something to handle a big pool of data is really a challenge, it can be a challenge at times. To scale. Just to scale that up, right. And so yeah, we're going to separate that out and double some data, that's going to be a thing. It's going to be more data at the end but since it's scaled out and decentralized, that will help. A lot of organizations would say, well we want to keep it centralized, monolithic which is kind of a negative term but I think it's true because it's more cost effective. We're not going to duplicate things as much. We're going to have roles that are dedicated but it sounds like you're seeing a business advantage of distributing those functions, decentralizing those functions to a certain extent. Right, right because if you have a centralized monolith and I, yeah, it might be negative but it really is, it's a good working software but to have that, it's really hard to release new features and new, you know, even bug fixes. It just takes time, it is a time consuming process and if you have it decentralized in smaller packages, you can just do a fix, run it through the pipeline, have the testing done and just put that out within hours. How important was it to build this application on an open source platform? The open source didn't come so much in our perspective of things or we didn't consider it that much, it was just, this is there, this works, we have a good support behind that. Our code is not open sourced and we're not going to any time soon. We're actually thinking about having parts that might be a kind of open source-ish just in the healthcare community kind of thing but yeah, no, that didn't factor in as much, it was just something that we had experience with. Another architecture question, so you've got the application stack, right? I can use that term, although application development tools used to build the application and then you've got the data that the application needs. How are those architected? Are they sort of separate entities? Are they coming together? We used to have an MDA approach, J2E, so they're very strong connected. That is, there's just in the database, there are models and entities that we use in the Jboss and we're still going to use Hibernate to do the GPA but it's something that needs to be restructured because it just takes a lot of resources to manage data from different parts of the application, bringing them together that will need to change. And what about new data sources? If I came to you and say, Sebastian, I need to inject new data into the app, I need to get this to, how difficult or fast and easy is that? And now, in the world now, can you compare before and now? I mean, it won't have to happen before, we'll be like it. In the time frame, it's hard to say. But if you have a project right now, we're talking months, like a year, to get it done, get it tested and then it even takes up to a month before it's out to every customer. The rollout process takes some time. And we're planning on, or we developed the new software, we developed it in a couple of months and then it is deployed and then it's in production and it's in production for all the customers that wanted to use it for now. I mean, it's not deployed to all customers yet because they need to adapt it in their way but they have it, it's right there, it's deployed. When we fix it, it's in an hour, a couple of days, it's out and it's out in production in different data centers for different customers. We've come full circle, the life of an architect. It sounds like it's much better today. Sebastian, thanks so much for coming to theCUBE. Appreciate your time and your insights. Thank you for watching. Keep it right there. You watch theCUBE's coverage of Red Hat Summit 2022 from Boston, Dave Vellante for Paul Gillin. We'll be right back.