Coupling for a decoupling: Best practices for building a composable architecture | Datrycs x Hygraph

in this video we will talk with markers from datrix and Tim that's me from hgraph and we will discuss coupling for decoupling and so Marcus and I will dive into how this all works and why you actually have to couple something to make a decoupled architecture work really well and the main topic here is to actually talk about how you are going from Legacy to a modern infrastructure and how all that stuff with coupling and decoupling actually works and so in our current space there's lots of companies actually moving away from the molet to this decoupled infrastructure so when you look at the space right now and with your customers what do you see um them dealing with when having their monoliths in place at the moment without calling names of course and but you see um if companies are stuck to the Heritage too long and they were capitalizing their it Investments over a long time um mostly they're stucking into to that position that they can't adapt and then a new player maybe is jumping on the market and launching new capabilities um and those folks with the Heritage are not able to adapt the market or the market requirements so they are not adapt or not able to adapt pretty fast on the market uh which means that they're stocking to some extent to the old world yeah uh they're not able to launch something new because they don't have the data in shape for example so if you would like to build up a new app or a new website or whatever I would say crucial thing is to orchestrate data to some extent yeah um and if you are not able to orchestrate the data later later on because you have that Heritage and then you're not able to jump into new opportunities in that case um which LEDs to that point that they are falling behind the market and the new guys were the New Kids on the Block are just jumping in and growing that fast um that the other ones are still dealing with the Legacy meaning if we're calling uh that Heritage yeah and you're dealing propably with that Heritage or Legacy yeah then you would I would say you're doing a good job but you have to manage that proactively and don't think okay I'm just buying the piece of software today and I will use it over the next eight years because uh then we uh made everything right because the market is still moving and changing so companies that have a rich Heritage and have chosen software for future that is actually holding them back a little bit trying to maintain this thing for as long as possible without having to change because it's complicated can you kind of talk about what that cost of doing nothing means yes sure so you have to think on it uh on two axis basically one access is the time the other access is I would call it effort or budget in that case and that means that over the time the running and changing codes from your current infrastructure meaning from that infrastructure which has the Heritage or so-called Legacy architecture is increasing um at the same time also the customer and the user expectations are increasing yeah and assuming that you have a it a given it budget which is not increasing massively your cost over the time by running and changing that infrastructure is eating up the Innovation yeah so that means customer expect expectations are rising your running and changing costs are rising but you're spending basically your money from the it Budget on the wrong angle which means you should basically in um spend the money into Innovation rather keeping the infrastructure up and running basically this is uh the cost of doing nothing which on the long end means you will fall behind the market so everybody in these types of videos and on conferences and on webinars always talking about the market is changing the Tik toks are doing things and actually that's kind of funny right because we never go into what that change actually is and why do you have to change why do you need to have that quick wish list next week like we just talked about um so Marcus can you talk a little bit about what you see what this change actually is and can we predict it you know all those things so maybe um give us your wisdom yeah okay I try to do it U and maybe we're coming from a non technical angle rather from a macroeconomic point of view and I would say if you have a general look on the market there is a term which is called vuka which stands for volatility uncertainty complexity and ambiguity and this is actually describing the whole state of the macroeconomic markets if we are stepping in to the v um which means volatility that means that everything is changing faster faster changing user expectations on the one side on the other side you have volatile uh traffic Peaks on the infrastructure because somebody's launching a Tik Tok campaign on your website or whatever the traffic's just exploding and everything is leading to a kind of unpr predictable future in that case the second term which means uncertainty means that we can't also predict what's happening around us so we see up there Wars on the world going on we have delivery CH change changes uh delivery chains sorry who are just breaking now and we're not able to ship the goods to out our customers which means uh that's totally uncertain if we were getting that Goods if we have to change it how we deal with it etc etc um and if we are looking at the C which stands for complexity in that case everything is getting more complex because we're just adding systems systems and processes together and triy to orchestrate everything towards our users and having great user experience in that case which means everything is getting complex in that case and complexity has to be managed um and the last letter in that case the a for ibiquity means that everything has more than one meaning in a kind of context so just putting that all into a nut meaning everything is getting more volatile or uncertain in that case and um the only thing what we really can predict is that everything will change in the future and that's why markets are changing that's why user requirements are changing so fast compared to a decade before um and we have to be able uh and flexible to act on that but Tim um just being said on this Muka term in that case what do you think in terms of the technical point of view um if the markets are changing on the one side from macroeconomic point of view what does it mean for it infrastructures um in the future so what is your what is your point of view on that well as we just talked about everything is changing constantly and it seems like to me when a little Trend happens and you get a spike in traffic and you need to do a certain thing wouldn't it be awesome as everything was smaller pieces that you can scale up and down without having to scale your whole environment or add a little puzzle piece or remove a little one if you don't need it anymore first of all that's cost effective right but then also you're able to quite quickly adapt and add like some tiny piece like this wish listing we just talked about on it and I'm not saying a wish list is a simple thing to build there's a bunch of things connecting but if you have software that's just wish list that you just Connect into your current you know puzzle pieces it works really well so concluding your infrastructure should be um an enabler rather than a constraint and that's easier said than done because we all tend to just throw at this thing make it composable throw things together and we'll probably talk a bit later about why that is actually pretty complicated because you can really code all these things together in one place or in multiple places or have a system to orchestrate or orchestrate these things and so yeah it's it's not easy but definitely we want this thing to be flexible with small pieces that are really great at what they do as that small piece and then probably integrate it with your legacy that you still have that you haven't changed yet you don't have to do a big bang change you can have both okay got your point fully um and what would be your four takeaways on that funny you should ask that because we actually prepared this so the first one of course is scalability scaling a huge architecture that this one big block is a lot harder than scaling smaller pieces because if you have just that wish list that needs to be scaled it's a lot simpler to just put that on the cloud and add more virtual servers and make that happen and with that comes cost efficiency because you only scale that one piece rather than everything and of course that gives you flexibility and Agility because you can quite easily add blocks or remove blocks and with all of this together you get technological diversity you can even have different teams specializing in different pieces of software with different languages as as long as they are a little you know Island that an API can talk to as long as these apis are solid everything is going to work and imagine using High graph and actually do graphql then every API is completely unified transparent and easy and you don't even have to know how these other systems work so lots of cool things within these four little blocks here so now that we've established that we want to do a composable architecture with smaller pieces of course there are some ways how you can actually connect these pieces to make it one cohesive architecture so Marcus what are your views on how that works the ways to do it or not to do it so basically if you're jumping into that whole composable talk topic you need really a plan how to execute that because what we often see is that teams are starting to decouple or get into to micros or composable architectures but you really have an impact on that and you're getting challenges out of that if you don't plan it probably in that case and that means on the one side if you're just connecting all the systems to each other and you get kind of new spaghetti um microservice architecture in that case you are getting problems on the customer experience because basically if the data is decoupled and um Diversified in several data stores it's pretty hard to orchestrate that unique user experience in the front end and uh grab the right data set for right application at the right time which leads to confusion um and loses the trust of the application in uh from the point of view of your ad customer in that case and most of that is driven by diant data structures so that you're not having the data at full sing because if you decoupling and it's getting pretty hard to sync the data probably in that case um or also having the data schemas line so that it's also nice for the US experience in that case uh so you have those two topics on that angle meaning um the diverse data structure uh which is also affected by some kind of synchronization delays uh which is uh ending up into a bad user experience yeah and so when we talk about this in a slightly more technical way we kind of we know we have to make it a cohesive architecture but not couple everything in such a way that it's almost worse than the monolith because you can go yourself into a web of troubles and so there's a few ways we see in the wild how this works like the easiest way you can do this is in your implementation let's say your front end your website or your app you just connect to all the services and clean the data from all these places into one bit that's your front end um however if you add another Channel you have to do that again and if something changes your code is full of stuff that is way too complicated and super smart for what a front end should need right so that's what we see most but at scale it's just not maintainable you get lot lots of technical debt like how did I Mor this API and that one and put them together that's a piece of code that needs to be unit tested which will likely not be unit tested and all that stuff is complex right and so we kind of need to find a way to couple that decoupled data that actually makes a little bit more sense where your front ends or your implementation sites your phone apps or your websites or your refrigerator apps All That Remains super simple the simpler that is the better it works because you have your data managed somewhere else and that what is what we like to call at high graph content Federation and in Federation you have a ton of different ways but the way we like to do it is to actually have a layer in between that Aggregates all the data from all your specialty services like your whist list like your you know all these like uh beam systems Dam systems they all come into high graph and high graph is a graphql API and we won't go much deeper technically than that but what that means is um HRA can take over that API and make it a schema that your front end can always query the same way either in the hgraph CMS or just as a data source that you need from your front end but that means your code doesn't have to know anything about these specialty services but just about that aggregation layer and the way hgraph does it is that it leaves these sources that you have like your PIN system like your wish list whatever um autonomous so when you scale you can have specialty people that are really specialist at bu building like a search index or a wish list work on that and then the data goes into hgraph and it stays the same way and it just caches it on the CDN and you can change it all the time fast if you want to you can even do a call from a system to say to hgraph this is now new data or it has a 30-second timeout stuff like that but that means is you have autonomous sources and you you have web developers that only have to query one thing it's all the same it's super simple and that's something that we're quite proud of to have that as a CMS because it's a pretty challenging thing to nail down and there are so many ways to roam to get there right and especially when you throw in the scale part of things so now that we've established this technical system with the business system and Marcus how does that make sense to you when we combine these what what is your fishion here so if we're not having that autonomy in the middle then we're just raising the complexity in that case now but on the other side without the unification in that case or standardization um we have a kind of mess up structure and in a moderate St we need both in my opinion and if we are jumping a bit more in detail in that topic I would explain it with that that you should really focus on content objects so you should ask yourself from a business point of view which content object objects do I have in my company there are objects in my uh point of view like a product like a customer like an order which perfectly can be displayed in a CMS in that case uh and can be Federated and it comes to that point that you realize that those content objects are produced and consumed on attribute level from different systems so you have let's stay to that um example like a product yeah you have an attribute like an SKU which is coming from an Erp for example then you have the description which comes from the M system and you might have a I don't know a price which comes from the price engine just based on that uh product object or product content object and combining all those attributes and federating that data is needed to build up the unique user experience and I would say this is really the key for mod infrastructure it's not only for cers so we talked about this content Federation thing as a pure data play you were connecting erps to pins and things like that but is there also another sign significant part of this that influences businesses so from my perspective yes condent Federation is not only a technical project where you're just combining data it should be served from an organizational perspective and that means that you should start a data discussion that means that you have to get all the stakeholders in place and discuss really the data which they need to uh provide a unique us experience and then you are coming from more organizational transformation perspective rather a technical perspective um where you start a project in that case yeah I totally get when your organization sits correctly in this with all the responsibilities in the right place the technical architecture is actually super easy it kind of just flows together and what we were just talking about in the beginning of this discussion is that this process and the Optics thing is a huge win for all the teams having good Optics with your leadership and being flexible makes everybody happier probably gets cheaper and then you can actually get a lot more work done because your whole architecture is more flexible so it's almost like look at this as a organ organizational transformation that helps you to be more flexible and your TCH will just align and maybe that with that bombshell we can almost end this discussion because it feels like we have now figured out how to couple the uncoupled architecture and have a composable approach to your business and the tech and it kind of all fits together pretty easily um however it is pretty hard to connect to things but then you have systems like content Federation to help you with that and so what are your last words here Marcus I would say that you really should focus on building unique uh digital experience for the customers and not focusing really on all the integration stuff and customer mware we learned in that talk that it's super important to have it but what we see is that people on the market are just starting from that layer here and building on top of it and if they are reaching from that there is no it budget left to build that unique digital experience so I would say there are probab venders on the market like hgraph which we can choose to build a unique digital experience by orchestrating all the data um and think from it from organizational perspective um and come from that angle so that's really in my perspective the key on it awesome um thank you for this discussion and enlightening me with your like more business related knowledge um I think we're good to go for this video cheers have a good one everybody cheers