How Codoflow Reinvents Data Architecture for AI-Ready Startups

With a rich background in IT consultancy and a deep understanding of the challenges in data integration, Stefan recognized the limitations of traditional top-down approaches to data modeling. This insight led to the creation of Codaflow, which adopts a bottom-up data modeling strategy, emphasizing granular data level design to automatically generate higher-level architecture views.

And this integrates automated system landscape generation, real-time collaboration, integrated change management, and design-first approach. Join us as we delve into Stefan's journey, exploring how Codaflow is enabling organizations to achieve transparent, collaborative, and governed data model design, ensuring seamless integration, and minimizing data risks. Almost without a mistake, Stefan, welcome from Munich.

It was rather the other way around. So we were looking for solutions in a data architecture area because we were facing certain challenges over and over again, because we're doing a lot of integration and we're chasing after data like all the time. And yeah, at some point, well, we simply said, okay, if there's nothing out there which is really satisfying us and everything is usually targeting enterprise level,

we simply said, okay, well, let's then simply try to disrupt the world and let's make it a better place, at least from the point of the data architecture.

And how is your integration working? From a technology point of view, they were actually rather, like that was rather a short discussion because then you just like show a couple of slides and then that's it.

But as soon you wanted to actually deep dive a little bit into like the details of it like like what information is being exchanged where is that actually being forwarded to and all that then it was becoming a completely different discussion because then people would not be able to answer that and would actually just send you somewhere like you just like basically well go away and ask someone who knows and then the next question was like well who knows and well

we don't know but that person might know and then they just like push you like basically from door to door and that is i believe one of the main main challenge in general that Our IT world becomes more and more a network of different systems. I mean, there are studies out there, right, saying like, okay, well, in average, it's 112 systems. Others say like it's even 200 or even more. All of that information is being exchanged.

And apparently, to my, let's say, experience I have never met a company who has full control on all that and I think that is one of one of the the let's say rather infamous elements of data architecture because it's always outdated and no one knows and it's even identifying it it feels like if you're comparing like this foldable maps for streets to Google Maps, right? So it's a little bit like the same way.

So if you're lucky, you have an outdated plan of the 1970s and you are trying to find your way.

When we discussed before, you told me there's a bottom-up approach. So what do you do? Do you give a vote to all the bits out there?

Let's say that is part of the problem from my point of view, because when we are talking about data, if you actually talk to a person like these experts you were just mentioning, right? So if you have such an expert, they usually have deep knowledge on a particular system, on a particular data structure. It's very rare you find someone who knows all the systems with all their data elements in there. It's like I have never met someone, and I don't believe it is humanly possible even to get there.

It is something, well, there are BPMN 2.0 models and all that. When it comes to data, we actually can take the data from the data source. It's actually available. It's not a design question at that point. It's actually just like taking the reality and mapping it into some sort of model. And if you're doing that, and if everyone would do that, then you are starting at the bottom.

And if you're having now all the details, it's from a technical point of view, it's rather simple then to aggregate the information, and let's say you have a system containing 10 objects and each object has 10 attributes, and that information is being shared with a different system and going to some other objects and attributes, then you can simply state, well, there is information flowing from system A to system B. It's something which is technically rather trivial to actually,

well, get as an output. And that's kind of like what we did. We said, okay, make it simple. And if you start from the lowest level of detail, then you can aggregate the information to whatever you like, right? That is the magic behind the bottom-up approach.

So everyone has still this idea of, let's say, I want to automatically fetch information and send it somewhere, which translates for me into, oh, well, I want to give up the responsibility for my data quality and push it to some sort of API, to some sort of like automatism. And that is something which is contradicting to actually managing something. So, yes, there are possibilities to upload information like the data structure in that sense.

We have focused actually a lot of our development just on that particular part. Nonetheless, it is part of the methodology to have someone who is actually responsible for the data architecture for one particular system and even interface. Everyone should have actually irresponsible person attached to it. It sounds weird, I know, because it's kind of like, well, you would expect that to happen, but reality is out there.

Let's say there is a system, oh, we have just another one, okay, you already have two, now you have three, go, right? So that's the sort of responsibility we see out there in the market, because quite honestly, it is nearly impossible for a company of a certain, let's say, mid-size to have a dedicated person for each individual system. Nonetheless, we want to make it easy.

And there are different ways on actually getting there. The simple path or the easy path is you just start with a couple of systems. You are just taking the information you know of and you are just like putting it in and you have a responsible person behind it. So the implementation journey for that company starts essentially with two workshops as easy as that. First one, we explain how it works.

And the second one is we are discussing how the process, the change process actually works, because that is the most important part to keep the whole thing alive. Otherwise, you're just getting a snapshot. So it needs work. It needs, well, taking responsibilities up on your desk and actually managing it from that moment forward. But the gains you're potentially getting out of that are by far outweighed that.

And that basically works for a lot of other industries, a lot of other tools there as well, especially concerning pricing, especially concerning compliance and so on and so forth.

You cannot use AI if you have proper data, because usually AI is, well, supposed to train on data. So if you are not aware on your data quality and you don't know where it's coming from, well, how do you expect your AI or how can you even trust your AI model or your data model, which is coming out of that? For me, there is a huge risk that, well, numbers are sort of like proving that it works, but do you know how long it will work? What if something changes?

What if you need to train it on a different parameter? Where's the parameter coming from? But getting back to the implementation journey, I was just focusing on the easy path. So let's start simple. Of course, there's another way that you can actually go in and use some sort of consulting partner who is then dumping everything into the Coderflow environment and background to helping you setting up every tiny little bit.

But overall, the whole process is, or the tools we are providing, it should not take longer than 12 and let's be generous, like 24 weeks because otherwise the data is outdated again. That's like what the majority of frameworks are actually suffering from because they are starting. And actually, we spoke to customers who are starting with like traditional tools in the data architecture environment. They start looking at documenting it. And in the end, it takes like two years.

And then they have a picture, which is two years old. I mean, how useful is that? It's simply, well, not going to fly. That's very simple. And we are trying to change that. So that's exactly where we are really putting a lot of effort in and to make it as easy and pragmatic and simple as possible to get to a starting point. And from that starting point, and that is, well, allow me to just point that out, we are not trying to document anything.

It is not supposed to be a documentation or tool in that sense. It's supposed to be a design tool. And I think that is one of the the major changes towards other methodologies, because we believe that it should start inside of a design process and not ending in a documentation process to actually gain control of it.

So it's true for the midsize companies as well. So it is actually a problem which is not reserved for enterprise companies. Actually, everyone has the problem. So it was time to actually provide a solution for everyone as well and not only the enterprise companies. So for that reason, we were focusing on like, okay, let's do it in a pragmatic way.

Let's really try to, well, tear down the boundary of, well, you need to invest multiple millions to make it fly and wait for multiple years before you can actually start using it. So, for that reason, we really try to come up with a way of working which is doable or affordable in terms of effort for everyone and not just like companies who can create a different department just focusing on that particular element of the design process.

So, we need to do some change management and how does Kotoflow facilitate the effective change management within the IT systems?

Essentially, data and its architecture in that sense is something like a code file. Like it is a structured way of describing how your data looks like and how it's actually built up inside of a model. So you can use that and use versioning behind that, right? So that's number one. So if you are doing versioning and you can ask anyone who has ever done like some sort of like, let's say, multiple people trying to contribute to a software project.

You want to have something what is called a pull request. You want to have someone being the quality gate or the gatekeeper for anything which is going to move into that code repository. We simply reuse that. Whenever you are trying to come up with a new release, and the release for us means that you have changes inside of your data architecture, the system is going to follow up and trying to find out, okay, where is that data being integrated to? Where is it being shared?

So who do we need to ask for approval if you may do that or not? That's literally what I have not seen in the market so far, because this is really implying that you are asking upfront before you're doing a change. And if you're thinking a little bit ahead of you don't need to necessarily do that at the very end, what usually happens, like after testing, You can actually start asking that particular question in that tool in the design phase.

So you know actually what is coming up. And you can inform the people who should actually react upon that, right? If you're changing your field in a system, that might actually affect an interface. And that interface might affect another system and so on and so on.

Who do I need to actually ask? And the system will figure out the path of that particular element throughout your whole data landscape. And we'll create a task for everyone. And asking the question, okay, well, are you feeling okay with that change? Or do you need to react upon that? And then we are basically orchestrating that communication between the different system owners. And sort of like pushing out the change before it actually happened.

It doesn't matter, right? But in the end, it's just a spreadsheet where everyone is trying to collaborate on. Main drawback, you don't have any data model information at that point. You just see, well, attributes. It doesn't tell you anything about cardinality or anything. The other point is, oh, I have seen it. Oh, let's filter it. Oh, let's resort it. Oh, unfortunately, I did not have all the different columns in my working area. And suddenly, the work is gone.

So it has happened to me multiple times. So we said, okay, let's stop that. Let's actually put some sort of model behind it. So meaning that we created purposely our solution as a web solution where everyone can collaborate in, like in a Miro board, for instance. So, whatever you're doing, the other person sees at that very moment. And we have a split-screen approach, meaning that you can have, on one hand, your table with your attributes.

On the other hand, you can actually see the data model or even the integration in itself. And you just, like, basically connect the dots as, well, working, talking to the other person who is responsible for the other part. So it's basically if you're a part of the left side, you're connecting the middle part and the other part is connecting the middle part to their part.

And this is like how we envisioned how we would like to work when we talk to someone, because usually we are in like the left part of that system. We are providing information and we would like to simply say, OK, well, what do you need? This is what we have. See here, putting it in and saying, okay, let's now actually talk about how this is actually being connected. So that's kind of like our approach. So we purposely didn't want to create another spreadsheet solution.

We wanted to combine a system model, including the, let's say, Excel-like experience and background, plus putting some permissions on top of that, because we felt like that is something which is desperately needed in that regard.

So if we would actually go for the system to update it by itself, like using some APIs or reading SQL tables and background and all that, that would actually be really difficult to handle because we want to actually react before the change happens so if we want to react up front then the approach is well we have the design first meaning that you are planning what you want to do before it actually happened so for that reason you are starting

at that point and the second part is you have a versioning model behind it so if you're uploading something well to what version to what release is it already approved do we merge who is deciding on that right So, these are all the little elements which are, let's say, well, the consequence of having a proper change management behind that, but it allows you to really have an unknown quality of your data model, which has never been done before, because now you can actually trust the data,

which is different from what we have seen so far. No one trusts documentation except their own, maybe. And maybe, really maybe.

Well, no pun intended here. It's just that someone is writing that because it has been the contract that you are providing some sort of technical documentation. So you're just writing it down, basically, well, dumping it somewhere. And I would even say the majority of these documents is, well, read by yourself and potentially one or two other people. And now you have different systems and you have different contributors and everyone is writing it in a little bit different way.

In the end, you're getting, well, some sort of documentation or arguing about that. But if you want to create a big picture out of that, it's rather impossible. And that's why we are saying, okay, let's bring everything in one spot and have a proper process behind it, have proper responsibilities behind it.

And then suddenly you have a transparent data model and a data model which you actually can rely on, which you can trust on, because you have put the proper processes in place to support that. But that only works if everyone is contributing, right? Otherwise, you again will end up in a situation where you don't really trust the data anymore. And that's the part.

But the customer data is coming from an online shop and the order data is coming from an ERP system, then there might be an inconsistency between these two because there might be a mix-up of data sets and not the right data quality. I don't know. So at least you know where to look at. So we don't know what data is being exchanged,

but we know the data types or the data sets in that in that sense. So I would say, yes, it is definitely a good starting point for your investigation. We at least help you to identify the areas where you should look first.

It is, as mentioned earlier, it is complex problem and we try to build a solution which is so easy to use that the complex problem is actually more or less taken care of by the system itself and you as a user just need to well focus on like providing the proper information and the system will guide you through the rest Also, we are acknowledging that, let's say, the majority of data architecture frameworks are relying on UML,

Unified Modeling Language, which is, let's say, a more software engineer approach of looking at, well, systems, data, whatsoever. And we purposely said, okay, well, we want to build something which is, well, readable for anyone, not just IT people or people with an education in that particular area, but actually even business users. So we really, really put a lot of thought into that. And it sounds easy, but it was really, let's say, it was not just one iteration. It was multiple.

And I would say that was our biggest achievement to finally overcome with that, not claiming that we will not learn along our path and even readjust it again because that's how life works, right? You continuously learn.

I would say that was the, let's say, more challenging part when we are getting in front of them. But, funny enough, I have not had one single person not confirming that the problem, the symptoms of not managing your data architecture, and there are many of them. Outdated documentation is just one of them. But just like trying to answer the question, where is the data set coming from?

I have, let's say, the majority of people cannot really answer that, at least not without putting effort into that. And that was the part where everyone was a little bit like, oh, okay, is there really a solution? And it's more like they cannot really believe it. And then we start actually explaining how our approach is. And then you can feel like, well, if it would be that easy, why hasn't someone done it yet, right?

So, it's really like a weird discussion and you really need to kind of like juggle like the two sides and not making it too easy. And on the other hand, like trying to point out like, well, it is really a problem.

Because AI will become more and more part of our world. Like what I personally tend to say, it will make good people be twice or three times as efficient as they are if they are knowing the right questions to ask and if the data quality is right and well ensuring the data quality is right is exactly what we are targeting to do. On the other hand well another big milestone which we trying to achieve by the end of this year is what we would call a so-called deployment project.

So I was just like pointing out that we will ask or we will send out these approval requests when you are trying to approve a release for a data change or a data set change. That might actually have implications, right? So if you're sending it out and you're asking 10 people and suddenly that might actually appear, well, okay, I might not need to change my direct interface, but there's like three systems further down the integration stream.

There's actually an interface you need to change as well. And now you need to manage that further, or you need to actually make sure that your changes are going online in the production environment with that change as well.

Which essentially is an orchestration challenge so we put now in place this uh or we are planning to put in place the the this deployment project which is going to allow you to keep track on what changes are implied by your change and who else need to change that and start the design journey on their end as well and then making sure that everything is like flowing together and well, kind of like a program management behind that so that you are then making sure

that all the necessary changes are going online in the production environment at the same time. And that is something I believe no one has ever done before because this is really meaning that you need to have an understanding between different environments as well, which we do from a data model point of view and background as well. So we are differentiating it between between a development system versus a production system.

Majority of development systems are not even integrated anywhere because you are just developing there, right? So if you are changing something in there, you do not need to check that against the development environment.

No, you need to check that against the production environment because that's kind of like where you are trying to push it into. And then suddenly you have like the real big picture behind that and you can start planning, I don't know, ERP upgrades, for instance. It's usually like, well, let's say a challenge, to say the least.

And now you have a completely different approach on, well, mitigating that risk of failing in the integration tests, which has usually come at the very end, because that's usually the part which is to develop the last. Does that answer the question?

And I think that is like where a lot of people are having the, let's say, they have the right idea, but they are trying to overcomplicate it, overengineer it. And I think right now is the time to actually make it as simple as possible so that you are capable of adopting it easily. Because a solution which is not adopted is not going to help anyone.