Music:
Speaker0: Hello and welcome, everybody. This is Joe from StartupRate.io,
Speaker0: your startup podcast and YouTube blog from Germany.
Speaker0: Today, I would like to welcome Stefan Opitz here, the founder and CEO of the Coderflow GmbH,
Speaker0: which is a German form of LTD, a groundbreaking SaaS platform that is transforming
Speaker0: data architecture management.
Speaker0: With a rich background in IT consultancy and a deep understanding of the challenges
Speaker0: in data integration, Stefan recognized the limitations of traditional top-down
Speaker0: approaches to data modeling.
Speaker0: This insight led to the creation of Codaflow, which adopts a bottom-up data
Speaker0: modeling strategy, emphasizing granular data level design to automatically generate
Speaker0: higher-level architecture views.
Speaker0: And this integrates automated system landscape generation, real-time collaboration,
Speaker0: integrated change management, and design-first approach.
Speaker0: Join us as we delve into Stefan's journey, exploring how Codaflow is enabling
Speaker0: organizations to achieve transparent, collaborative,
Speaker0: and governed data model design, ensuring seamless integration,
Speaker0: and minimizing data risks.
Speaker0: Almost without a mistake, Stefan, welcome from Munich.
Speaker1: Well, thank you for having me. And actually, I guess we are done now because
Speaker1: you said everything. So it's absolutely amazing.
Speaker0: Yeah, we're done. Hey, guys, it was the shortest recording ever. Goodbye.
Speaker1: Exactly. Glad being here.
Speaker0: Most efficient introduction ever. Check. Thank you to just me,
Speaker0: my virtual assistant, who made this possible. Thank you.
Speaker0: That said, let us talk a little bit about who you are and what you did and how
Speaker0: you went from consulting to founding Codaflow.
Speaker0: And then we may already hint to our audience that data architecture,
Speaker0: data architecture management is a pretty boring data, but it gets very important
Speaker0: if you want to train an AI on your own data.
Speaker1: For instance, exactly. Yeah, as you said, actually I'm coming from a consulting
Speaker1: background and I still run like a very specialized consulting company and background.
Speaker1: And fun fact is that we actually were looking for a solution first.
Speaker1: So it's not like that we came up with the, well, let's found Coderflow and let's
Speaker1: do something completely different.
Speaker1: It was rather the other way around. So we were looking for solutions in a data
Speaker1: architecture area because we were facing certain challenges over and over again,
Speaker1: because we're doing a lot of integration and we're chasing after data like all the time.
Speaker1: And yeah, at some point, well, we simply said, okay, if there's nothing out
Speaker1: there which is really satisfying us and everything is usually targeting enterprise level,
Speaker1: we simply said, okay, well, let's then simply try to disrupt the world and let's
Speaker1: make it a better place, at least from the point of the data architecture.
Speaker0: Make the world a better place. Okay, yeah, that's a pretty high goal.
Speaker1: Yeah, I know. Bold claim.
Speaker0: Okay, great. You talked about you want to do that stuff yourself.
Speaker0: Can you give us a little introduction, just a tiny bit on why data architecture
Speaker0: is important for the companies out there?
Speaker0: Not the ones who are very tiny and running on one server, but the ones as soon
Speaker0: as they start growing, especially growing very fast.
Speaker1: I would even go a little bit further than that. Actually, I believe data architecture
Speaker1: is important for everyone, and it will become more important.
Speaker1: But the main challenges we were actually facing is that whenever we came into
Speaker1: a new client and we were asking for their, let's say, how is your setup running right now?
Speaker1: And how is your integration working? From a technology point of view,
Speaker1: they were actually rather, like that was rather a short discussion because then
Speaker1: you just like show a couple of slides and then that's it.
Speaker1: But as soon you wanted to actually deep dive
Speaker1: a little bit into like the details of it like like what
Speaker1: information is being exchanged where is that actually being
Speaker1: forwarded to and all that then it was becoming a completely different discussion
Speaker1: because then people would not be able to answer that and would actually just
Speaker1: send you somewhere like you just like basically well go away and ask someone
Speaker1: who knows and then the next question was like well who knows and well
Speaker1: we don't know but that person might know and then they just like push you like
Speaker1: basically from door to door and that is i believe one of the main main challenge in general that
Speaker1: Our IT world becomes more and more a network of different systems.
Speaker1: I mean, there are studies out there, right, saying like, okay,
Speaker1: well, in average, it's 112 systems.
Speaker1: Others say like it's even 200 or even more.
Speaker1: All of that information is being exchanged.
Speaker1: And apparently, to my,
Speaker1: let's say, experience I have never met
Speaker1: a company who has full control on
Speaker1: all that and I think that is one of
Speaker1: one of the the let's say rather infamous elements of data architecture because
Speaker1: it's always outdated and no one knows and it's even identifying it it feels
Speaker1: like if you're comparing like this foldable maps for streets to Google Maps,
Speaker1: right? So it's a little bit like the same way.
Speaker1: So if you're lucky, you have an outdated plan of the 1970s and you are trying to find your way.
Speaker0: And personal experience is that in the IT of very large organizations,
Speaker0: there are usually a handful of people who do have an idea of the general data flows around,
Speaker0: but it starts to get really tricky if you dive into the details when you want
Speaker0: to put something together, like a data lake or something,
Speaker0: where's this data coming from? From this system? No, it's coming from this system.
Speaker0: No, it's coming from this system. Then it gets real, real tricky.
Speaker0: When we discussed before, you told me there's a bottom-up approach.
Speaker0: So what do you do? Do you give a vote to all the bits out there?
Speaker1: Something like that.
Speaker1: So, well, bottom-up approach is, and I guess we need to put that a little bit into perspective.
Speaker1: Common frameworks, common methodologies usually break things down.
Speaker1: So you start from a very high level, and then you're just breaking it down into smaller pieces.
Speaker1: And that is something which absolutely makes sense in certain areas.
Speaker1: And apparently, it has been, let's say, the typical approach for data architecture as well.
Speaker1: Let's say that is part of the problem from my point of view,
Speaker1: because when we are talking about data, if you actually talk to a person like
Speaker1: these experts you were just mentioning, right?
Speaker1: So if you have such an expert, they usually have deep knowledge on a particular
Speaker1: system, on a particular data structure.
Speaker1: It's very rare you find someone who knows all the systems with all their data elements in there.
Speaker1: It's like I have never met someone, and I don't believe it is humanly possible even to get there.
Speaker0: For everybody who's now out there smiling, you should once, at least once,
Speaker0: try to understand those massive databases who only are out there to grasp data flows.
Speaker0: It turns your head upside down within a few days and after a month,
Speaker0: you have not fully grasped it.
Speaker1: Absolutely.
Speaker1: That's exactly where we are coming from. If you think about this one expert,
Speaker1: the expert knows exactly what the data structure looks like.
Speaker1: Quite honestly, data structure is compared to a business process,
Speaker1: which is important as well, but it's usually designed.
Speaker1: It is something, well, there are BPMN 2.0 models and all that.
Speaker1: When it comes to data, we actually can take the data from the data source.
Speaker1: It's actually available.
Speaker1: It's not a design question at that point. It's actually just like taking the
Speaker1: reality and mapping it into some sort of model.
Speaker1: And if you're doing that, and if everyone would do that, then you are starting at the bottom.
Speaker1: And if you're having now all the details, it's from a technical point of view,
Speaker1: it's rather simple then to aggregate the information,
Speaker1: and let's say you have a system containing 10 objects and each object has 10
Speaker1: attributes, and that information is being shared with a different system and
Speaker1: going to some other objects and attributes,
Speaker1: then you can simply state, well, there is information flowing from system A to system B.
Speaker1: It's something which is technically rather trivial to actually,
Speaker1: well, get as an output. And that's kind of like what we did.
Speaker1: We said, okay, make it simple. And if you start from the lowest level of detail,
Speaker1: then you can aggregate the information to whatever you like, right?
Speaker1: That is the magic behind the bottom-up approach.
Speaker0: So let's go a little bit into implementation and start to understand how this normally looks like.
Speaker0: Because I would assume you need at least one point where you actually connect
Speaker0: to the system and get some access to all the data flows,
Speaker0: and then you do an automated mapping.
Speaker0: Is this something that happens, and how long does your whole process take?
Speaker1: Fair question, and quite honestly, that is one of the most asked questions when
Speaker1: we are talking to customers.
Speaker1: Let's put it this way. We believe that a tool in itself is not worth anything, right?
Speaker1: So you need to have the right methodology behind it. Otherwise,
Speaker1: you are just about the fool with the tool, right?
Speaker1: And to actually get to a proper information.
Speaker1: So everyone has still this idea of, let's say,
Speaker1: I want to automatically fetch information and send it somewhere,
Speaker1: which translates for me into, oh, well, I want to give up the responsibility
Speaker1: for my data quality and push it to some sort of API, to some sort of like automatism.
Speaker1: And that is something which is contradicting to actually managing something.
Speaker1: So, yes, there are possibilities to upload information like the data structure in that sense.
Speaker1: We have focused actually a lot of our development just on that particular part.
Speaker1: Nonetheless, it is part of the methodology to have someone who is actually responsible
Speaker1: for the data architecture for one particular system and even interface.
Speaker1: Everyone should have actually irresponsible person attached to it.
Speaker1: It sounds weird, I know, because it's kind of like, well, you would expect that
Speaker1: to happen, but reality is out there.
Speaker1: Let's say there is a system, oh, we have just another one, okay,
Speaker1: you already have two, now you have three, go, right?
Speaker1: So that's the sort of responsibility we see out there in the market,
Speaker1: because quite honestly, it is nearly impossible for a company of a certain, let's say,
Speaker1: mid-size to have a dedicated person for each individual system.
Speaker1: Nonetheless, we want to make it easy.
Speaker1: And there are different ways on actually getting there. The simple path or the
Speaker1: easy path is you just start with a couple of systems.
Speaker1: You are just taking the information you know of and you are just like putting
Speaker1: it in and you have a responsible person behind it.
Speaker1: So the implementation journey for that company starts essentially with two workshops as easy as that.
Speaker1: First one, we explain how it works.
Speaker1: And the second one is we are discussing how the process, the change process
Speaker1: actually works, because that is the most important part to keep the whole thing
Speaker1: alive. Otherwise, you're just getting a snapshot.
Speaker1: So it needs work. It needs, well, taking responsibilities up on your desk and
Speaker1: actually managing it from that moment forward.
Speaker1: But the gains you're potentially getting out of that are by far outweighed that.
Speaker0: We may add a little bit about the data quality, why this is important,
Speaker0: because you can not have any good decisions without good data quality.
Speaker0: For example, what comes to mind is especially if you don't have like the real
Speaker0: structure and real data properly maintained in your system,
Speaker0: for example, You cannot have any financial derivatives based on that because
Speaker0: there is like a big danger in that.
Speaker0: And that basically works for a lot of other industries, a lot of other tools
Speaker0: there as well, especially concerning
Speaker0: pricing, especially concerning compliance and so on and so forth.
Speaker1: And even pointing out the first point you mentioned in your introduction,
Speaker1: everyone wants to use AI lately, right? That's like the new black, right? And
Speaker1: You cannot use AI if you have proper data, because usually AI is,
Speaker1: well, supposed to train on data.
Speaker1: So if you are not aware on your data quality and you don't know where it's coming
Speaker1: from, well, how do you expect your AI or how can you even trust your AI model
Speaker1: or your data model, which is coming out of that?
Speaker1: For me, there is a huge risk that, well, numbers are sort of like proving that
Speaker1: it works, but do you know how long it will work?
Speaker1: What if something changes?
Speaker1: What if you need to train it on a different parameter? Where's the parameter coming from?
Speaker1: But getting back to the implementation journey, I was just focusing on the easy path.
Speaker1: So let's start simple.
Speaker1: Of course, there's another way that you can actually go in and
Speaker1: use some sort of consulting partner who is then dumping everything into the
Speaker1: Coderflow environment and background to helping you setting up every tiny little bit.
Speaker1: But overall, the whole process is,
Speaker1: or the tools we are providing, it should not take longer than 12 and let's be
Speaker1: generous, like 24 weeks because otherwise the data is outdated again.
Speaker1: That's like what the majority of frameworks are actually suffering from because they are starting.
Speaker1: And actually, we spoke to customers who are starting with like traditional tools
Speaker1: in the data architecture environment.
Speaker1: They start looking at documenting it.
Speaker1: And in the end, it takes like two years.
Speaker1: And then they have a picture, which is two years old. I mean, how useful is that?
Speaker1: It's simply, well, not going to fly. That's very simple.
Speaker1: And we are trying to change that. So that's exactly where we are really putting
Speaker1: a lot of effort in and to make it as easy and pragmatic and simple as possible
Speaker1: to get to a starting point.
Speaker1: And from that starting point, and that is, well, allow me to just point that
Speaker1: out, we are not trying to document anything.
Speaker1: It is not supposed to be a documentation or tool in that sense.
Speaker1: It's supposed to be a design tool.
Speaker1: And I think that is one of the the major changes towards other methodologies,
Speaker1: because we believe that it should start inside of a design process and not ending
Speaker1: in a documentation process to actually gain control of it.
Speaker0: You focus on a certain type called SMEs, or in German, KAMUs.
Speaker0: There are more than three million smaller medium enterprises out there.
Speaker0: I was wondering, how do you cater to the specific needs of this target group? Or why?
Speaker1: Why? In general, data architecture in itself is usually part of something which
Speaker1: is called enterprise architecture.
Speaker1: It's a part of that and that part is, let's say, very complex and it is thought
Speaker1: of, let's say, only for the enterprise companies.
Speaker1: But enterprise companies is, well, maybe 25 percent. I don't know the exact
Speaker1: number of the overall global industry.
Speaker1: But the challenges of having multiple systems, and again, the numbers of 100
Speaker1: plus systems is an average over all industries.
Speaker1: So it's true for the midsize companies as well.
Speaker1: So it is actually a problem which is not reserved for enterprise companies.
Speaker1: Actually, everyone has the problem.
Speaker1: So it was time to actually provide a solution for everyone as well and not only
Speaker1: the enterprise companies.
Speaker1: So for that reason, we were focusing on like, okay, let's do it in a pragmatic way.
Speaker1: Let's really try to, well, tear down the boundary of, well, you need to invest
Speaker1: multiple millions to make it fly and wait for multiple years before you can
Speaker1: actually start using it.
Speaker1: So, for that reason, we really try
Speaker1: to come up with a way of working which is doable or affordable in terms of effort
Speaker1: for everyone and not just like companies who can create a different department
Speaker1: just focusing on that particular element of the design process.
Speaker0: Does that make sense? It does. We've been already talking about change management
Speaker0: because change management is very important,
Speaker0: especially if you do have new systems, because if you ever try to remove one system,
Speaker0: just unplug it and plug the other one in, that may work in a small network.
Speaker0: But if you do have more than 20 employees, it will usually not work,
Speaker0: or at least as well as one would like to have it.
Speaker0: So, we need to do some change management and how does Kotoflow facilitate the
Speaker0: effective change management within the IT systems?
Speaker1: Good, very good question, actually. I think that's like the biggest differentiator
Speaker1: between our solution and, well, let's see, other approaches out there in the market.
Speaker1: So, here as well, pragmatism first.
Speaker1: There is no need of a complex solution for a complex problem, right?
Speaker1: So you need to come up with a simple way of solving something.
Speaker1: And here is something, well, which we did not invent, but simply reused.
Speaker1: Any software development company is so used to actually use code repositories.
Speaker1: Essentially, data and its architecture in that sense is something like a code file.
Speaker1: Like it is a structured way of describing how your data looks like and how it's
Speaker1: actually built up inside of a model.
Speaker1: So you can use that and use versioning behind that, right? So that's number one.
Speaker1: So if you are doing versioning and you can ask anyone who has ever done like
Speaker1: some sort of like, let's say, multiple people trying to contribute to a software project.
Speaker1: You want to have something what is called a pull request. You want to have someone
Speaker1: being the quality gate or the gatekeeper for anything which is going to move
Speaker1: into that code repository.
Speaker1: We simply reuse that.
Speaker1: Whenever you are trying to come up with a new release, and the release for us
Speaker1: means that you have changes inside of your data architecture,
Speaker1: the system is going to follow up and trying to find out, okay,
Speaker1: where is that data being integrated to? Where is it being shared?
Speaker1: So who do we need to ask for approval if you may do that or not?
Speaker1: That's literally what I have not seen in the market so far, because this is
Speaker1: really implying that you are asking upfront before you're doing a change.
Speaker1: And if you're thinking a little bit ahead of you don't need to necessarily do
Speaker1: that at the very end, what usually happens, like after testing,
Speaker1: You can actually start asking that particular question in that tool in the design phase.
Speaker1: So you know actually what is coming up. And you can inform the people who should
Speaker1: actually react upon that, right?
Speaker1: If you're changing your field in a system, that might actually affect an interface.
Speaker1: And that interface might affect another system and so on and so on.
Speaker0: And it might affect the process of how somebody does his or her work.
Speaker1: Correct. Correct. So, and that's like the beauty of it because we would, well,
Speaker1: suggest to start with that instead of waiting for everything to be done and
Speaker1: then starting testing and like, oh, well, it fails. Why?
Speaker1: Yeah, because there is not, well, this field is now not supported anymore in
Speaker1: our interface because there's a field length of 10 and we have now 12.
Speaker1: I don't know, right? Just coming up with something. But that's essentially,
Speaker1: now you can actually say, well, okay, I want to change it to 12.
Speaker1: Who do I need to actually ask? And the system will figure out the path of that
Speaker1: particular element throughout your whole data landscape.
Speaker1: And we'll create a task for everyone. And asking the question,
Speaker1: okay, well, are you feeling okay with that change?
Speaker1: Or do you need to react upon that?
Speaker1: And then we are basically orchestrating that communication between the different system owners.
Speaker1: And sort of like pushing out the change before it actually happened.
Speaker0: That sounds pretty interesting. We will be back with more stories about you
Speaker0: and Codaflow after a short ad break.
Speaker0: Hey, guys. Welcome back to my interview with Stefan Opitz of Codaflow.
Speaker0: We will be now talking a little bit about real-time collaboration.
Speaker0: In what way does Code of Flow enable the real-time collaboration among the stakeholders in the company?
Speaker1: That's actually a very, let's say, critical element of the whole solution.
Speaker1: So, again, coming back to our past, so we have been doing a lot of integration
Speaker1: projects between different systems.
Speaker1: I would say 10 out of 10 start with a sentence, let's open up an Excel spreadsheet
Speaker1: and let's combine forces and mapping fields and objects.
Speaker1: Well, in some cases, it might not be Excel, it might be Google Spreadsheet.
Speaker1: It doesn't matter, right? But in the end, it's just a spreadsheet where everyone
Speaker1: is trying to collaborate on.
Speaker1: Main drawback, you don't have any data model information at that point.
Speaker1: You just see, well, attributes.
Speaker1: It doesn't tell you anything about cardinality or anything.
Speaker1: The other point is, oh, I have seen it.
Speaker1: Oh, let's filter it. Oh, let's resort it. Oh, unfortunately,
Speaker1: I did not have all the different columns in my working area.
Speaker1: And suddenly, the work is gone.
Speaker1: So it has happened to me multiple times.
Speaker1: So we said, okay, let's stop that. Let's actually put some sort of model behind it.
Speaker1: So meaning that we created purposely our solution as a web solution where everyone
Speaker1: can collaborate in, like in a Miro board, for instance. So, whatever you're
Speaker1: doing, the other person sees at that very moment.
Speaker1: And we have a split-screen approach, meaning that you can have,
Speaker1: on one hand, your table with your attributes.
Speaker1: On the other hand, you can actually see the data model or even the integration in itself.
Speaker1: And you just, like, basically connect the dots as, well, working,
Speaker1: talking to the other person who is responsible for the other part.
Speaker1: So it's basically if you're a part of the left side, you're connecting the middle
Speaker1: part and the other part is connecting the middle part to their part.
Speaker1: And this is like how we envisioned how we would like to work when we talk to
Speaker1: someone, because usually we are in like the left part of that system.
Speaker1: We are providing information and we would like to simply say,
Speaker1: OK, well, what do you need? This is what we have.
Speaker1: See here, putting it in and saying, okay, let's now actually talk about how
Speaker1: this is actually being connected.
Speaker1: So that's kind of like our approach.
Speaker1: So we purposely didn't want to create another spreadsheet solution.
Speaker1: We wanted to combine a system model, including the, let's say,
Speaker1: Excel-like experience and background, plus putting some permissions on top of
Speaker1: that, because we felt like that is something which is desperately needed in that regard.
Speaker0: I have a question in terms of understanding. You do this once and the system
Speaker0: then automatically updates itself?
Speaker1: It does not update itself by definition, but remember I said we have the design first approach.
Speaker1: So if we would actually go for the system to update it by itself,
Speaker1: like using some APIs or reading SQL tables and background and all that,
Speaker1: that would actually be really difficult to
Speaker1: handle because we want to actually react
Speaker1: before the change happens so if we
Speaker1: want to react up front then the approach is well
Speaker1: we have the design first meaning that you are planning what
Speaker1: you want to do before it actually happened so for that reason you are starting
Speaker1: at that point and the second part is you have a versioning model behind it so
Speaker1: if you're uploading something well to what version to what release is it already
Speaker1: approved do we merge who is deciding on that right So,
Speaker1: these are all the little elements which are, let's say,
Speaker1: well, the consequence of having a proper change management behind that,
Speaker1: but it allows you to really have an unknown quality of your data model,
Speaker1: which has never been done before, because now you can actually trust the data,
Speaker1: which is different from what we have seen so far.
Speaker1: No one trusts documentation except their own, maybe.
Speaker1: And maybe, really maybe.
Speaker0: It does make sense. We've been talking about AI training. Data transparency is here a big topic.
Speaker0: How do you enhance this data transparency and governance? Because that is really
Speaker0: something you should first have nailed before you even start training in an I.O. and data.
Speaker1: That's excellent. Well, actually, this is a perfect, well, next step because
Speaker1: we we're just talking about it.
Speaker1: If we are talking about data transparency, it means to have a versioning behind it.
Speaker1: It means that you need to have a trust-worthy data source for that as well.
Speaker1: Right now, the majority of companies, at least I have seen, well,
Speaker1: at best they have some sort of like, well, data dump called Confluence or alike.
Speaker1: Well, no pun intended here. It's just that someone is writing that because it
Speaker1: has been the contract that you are providing some sort of technical documentation.
Speaker1: So you're just writing it down, basically, well, dumping it somewhere.
Speaker1: And I would even say the majority of these documents is, well,
Speaker1: read by yourself and potentially one or two other people.
Speaker1: And now you have different systems and you have different contributors and everyone
Speaker1: is writing it in a little bit different way.
Speaker1: In the end, you're getting, well, some sort of documentation or arguing about that.
Speaker1: But if you want to create a big picture out of that, it's rather impossible.
Speaker1: And that's why we are saying, okay, let's bring everything in one spot and have
Speaker1: a proper process behind it, have proper responsibilities behind it.
Speaker1: And then suddenly you have a transparent data model and a data model which you
Speaker1: actually can rely on, which you can trust on, because you have put the proper
Speaker1: processes in place to support that.
Speaker1: But that only works if everyone is contributing, right? Otherwise,
Speaker1: you again will end up in a situation where you don't really trust the data anymore. And that's the part.
Speaker0: Could you talk about training AI? Could you also use your tool to investigate
Speaker0: if something is going completely off the charts with the AI if it's not inherent in the model itself?
Speaker1: Well, we don't touch the data in itself. So we don't know what the data is because
Speaker1: we purposely designed our...
Speaker0: I was referring that some AI models are known to go off the charts.
Speaker0: They are unstable, and some of them are performing good to really good,
Speaker0: but they still can be issues.
Speaker0: And if you could use your tool to investigate if one of the issues may be in
Speaker0: the data that you've had to it.
Speaker1: At least we can, well, if we have that data model inside of our landscape,
Speaker1: basically, at least we have a very clear understanding on where information is coming from, right?
Speaker1: So we can definitely plot the path of all the elements which are going in there.
Speaker1: So if it is being fed by, I don't know, let's say you have customer data and
Speaker1: you have order data and both of them are being combined.
Speaker1: But the customer data is coming from an online shop and the order data is coming from an ERP system,
Speaker1: then there might be an inconsistency between these two because there might be
Speaker1: a mix-up of data sets and not the right data quality. I don't know.
Speaker1: So at least you know where to look at. So we don't know what data is being exchanged,
Speaker1: but we know the data types or the data sets in that in that sense.
Speaker1: So I would say, yes, it is definitely a good starting point for your investigation.
Speaker1: We at least help you to identify the areas where you should look first.
Speaker0: We are always interested in looking a little bit also into your entrepreneur's journey.
Speaker0: I would be interested in what obstacles did you encounter during the development
Speaker0: and the launch of your Coderflow?
Speaker1: Well, I would say, ask me what challenge I did not face. I think that would be a short answer.
Speaker1: I guess everyone has challenges here and there, and that's our daily life.
Speaker1: But if I would really need to mark one or two challenges which are outstanding,
Speaker1: I would say the first one would be UI and UX design.
Speaker1: It is, as mentioned earlier, it is
Speaker1: complex problem and we try to build a solution which is so easy to use that
Speaker1: the complex problem is actually more or less taken care of by the system itself
Speaker1: and you as a user just need to
Speaker1: well focus on like providing the proper information and the system will guide you through the rest
Speaker1: Also, we are acknowledging that, let's say, the majority of data architecture
Speaker1: frameworks are relying on UML,
Speaker1: Unified Modeling Language, which is, let's say, a more software engineer approach
Speaker1: of looking at, well, systems, data, whatsoever.
Speaker1: And we purposely said, okay, well, we want to build something which is,
Speaker1: well, readable for anyone, not just IT people or people with an education in
Speaker1: that particular area, but actually even business users.
Speaker1: So we really, really put a lot of thought into that.
Speaker1: And it sounds easy, but it was really, let's say, it was not just one iteration. It was multiple.
Speaker1: And I would say that was our biggest achievement to finally overcome with that,
Speaker1: not claiming that we will not learn along our path and even readjust it again
Speaker1: because that's how life works, right? You continuously learn.
Speaker0: Well, it should work that way. If you stop learning, there's something wrong.
Speaker0: And when you're done with it, how was the market response to code of flow in
Speaker0: the beginning and since it's launched?
Speaker1: That's a good one. So let's say, well, you mentioned earlier,
Speaker1: data architecture is not the most prominent topic in the world, right?
Speaker1: So right now, people would rather talk about AI.
Speaker0: Nice way to say that.
Speaker1: Well, I'm trying to be nice here, right? And it's kind of like if you're getting
Speaker1: in front of customers, we need to explain the problem first.
Speaker1: And then we need to explain that it is really becoming a problem at some point
Speaker1: if they don't do anything about it. And that is independent if they are using
Speaker1: our system or not. It will just hit them.
Speaker1: And there are studies showing that as well. So data architecture is becoming
Speaker1: one of the, let's say, prerequisites to be successful in the near future.
Speaker1: I would say that was the, let's say, more challenging part when we are getting in front of them.
Speaker1: But, funny enough, I have not had one single person not confirming that the problem,
Speaker1: the symptoms of not managing your data architecture, and there are many of them.
Speaker1: Outdated documentation is just one of them.
Speaker1: But just like trying to answer the question, where is the data set coming from?
Speaker1: I have, let's say, the majority of people cannot really answer that,
Speaker1: at least not without putting effort into that.
Speaker1: And that was the part where everyone was a little bit like, oh,
Speaker1: okay, is there really a solution?
Speaker1: And it's more like they cannot really believe it. And then we start actually
Speaker1: explaining how our approach is. And then you can feel like, well,
Speaker1: if it would be that easy, why hasn't someone done it yet, right?
Speaker1: So, it's really like a weird discussion and you really need to kind of like
Speaker1: juggle like the two sides and not making it too easy.
Speaker1: And on the other hand, like trying to point out like, well, it is really a problem.
Speaker0: I see, I'm talking about the future here,
Speaker0: we already discussed the importance of code of flow on data architecture,
Speaker0: data management, in particular when training AI.
Speaker0: What impact do you foresee will AI have and what's your future plans for growth
Speaker0: and evolution in the next few years?
Speaker1: Yeah, well, AI. Actually, one part of our roadmap is to expose, well,
Speaker1: the model context protocol, which is basically allowing language models to use
Speaker1: our system so that it becomes even easier to use.
Speaker1: And you can actually ask questions about the data model.
Speaker1: So instead of asking an IT person where the data is coming from,
Speaker1: you can simply ask the language model and then it will tell you.
Speaker1: That's one part of our roadmap, which is kind of like answering the AI question as well, right?
Speaker1: Because AI will become more and more part of our world.
Speaker1: Like what I personally tend to say, it
Speaker1: will make good people be twice or three times as efficient as they are if they
Speaker1: are knowing the right questions to ask and if the data quality is right and
Speaker1: well ensuring the data quality is right is exactly what we are targeting to do.
Speaker1: On the other hand well another big milestone which we trying to achieve by the
Speaker1: end of this year is what we would call a so-called deployment project.
Speaker1: So I was just like pointing out that we will ask or we will send out these approval
Speaker1: requests when you are trying to approve a release for a data change or a data set change.
Speaker1: That might actually have implications, right?
Speaker1: So if you're sending it out and you're asking 10 people and suddenly that might
Speaker1: actually appear, well, okay, I might not need to change my direct interface,
Speaker1: but there's like three systems further down the integration stream.
Speaker1: There's actually an interface you need to change as well.
Speaker1: And now you need to manage that further, or you need to actually make sure that
Speaker1: your changes are going online in the production environment with that change as well.
Speaker1: Which essentially is an orchestration challenge
Speaker1: so we put now in place this uh
Speaker1: or we are planning to put in place the the this deployment
Speaker1: project which is going to allow you to keep track on what changes are implied
Speaker1: by your change and who else need to change that and start the design journey
Speaker1: on their end as well and then making sure that everything is like flowing together and well,
Speaker1: kind of like a program management behind that so that you are then making sure
Speaker1: that all the necessary changes are going online in the production environment at the same time.
Speaker1: And that is something I believe no one has ever done before because this is
Speaker1: really meaning that you need to have an understanding between different environments as well,
Speaker1: which we do from a data model point of view and background as well.
Speaker1: So we are differentiating it between between a development system versus a production system.
Speaker1: Majority of development systems are not even integrated anywhere because you
Speaker1: are just developing there, right?
Speaker1: So if you are changing something in there, you do not need to check that against
Speaker1: the development environment.
Speaker1: No, you need to check that against the production environment because that's
Speaker1: kind of like where you are trying to push it into.
Speaker1: And then suddenly you have like the real big picture behind that and you can
Speaker1: start planning, I don't know, ERP upgrades, for instance.
Speaker1: It's usually like, well, let's say a challenge, to say the least.
Speaker1: And now you have a completely different approach on, well,
Speaker1: mitigating that risk of failing in the integration tests, which has usually
Speaker1: come at the very end, because that's usually the part which is to develop the
Speaker1: last. Does that answer the question?
Speaker0: Yes, it does. And it leads me to, so to say, the final question.
Speaker0: What advice for other founders would you offer to them? What key advice before
Speaker0: or during venturing into SaaS space?
Speaker1: Mm-hmm.
Speaker1: Obviously, don't do data architecture. Of course, we are there. No.
Speaker1: Jokes aside, and I guess I said it before, if you're trying to really change the world,
Speaker1: try to find a complex problem, which you can solve in the most easy way you can possibly think of.
Speaker1: It is the time for doing things easily. It's not the time of doing things complex.
Speaker1: And I think that is like where a lot of people are having the,
Speaker1: let's say, they have the right idea, but they are trying to overcomplicate it, overengineer it.
Speaker1: And I think right now is the time to actually make it as simple as possible
Speaker1: so that you are capable of adopting it easily. Because a solution which is not
Speaker1: adopted is not going to help anyone.
Speaker0: Very smart words. Stefan, it was a pleasure talking to you. Thank you very much.
Speaker0: For our audience, I would be interested, looking back, is there anything you
Speaker0: would have done differently in your entrepreneurial journey?
Speaker0: Stefan, thank you very much again. It was a pleasure having you as a guest.
Speaker0: And we will be back for our premium subscribers in the founders world with a
Speaker0: few more in that questions. Thanks, guys.
Music: