Transcription
Thank you so much. Uh, hello everyone. I'm so happy to be here and so happy for you to be here. I'm Pavl Sodat. Uh, I'm originally from here, Accenture Slovakia, but uh, I guess 10 years ago, I moved to the States. I've been there ever since. Still running, still running Open Slava. And um, it's just, it's just a pleasure to have you all here today.
I want to talk about many of the topics that we heard in the keynote and I felt so validated by many of these like points that Max and Adam made because that's exactly what's also the content of my presentation with a specific topic of domain-driven enterprise. We are living in this agentic shift and um, you know, you could quote a number of people and you could quote actually yourself because you're seeing it yourself, but I'll quote just two. I'll quote uh, Satia, uh, who is the CEO of uh Microsoft, saying that SAS is dead. And then I, I'll quote technology vision, which you should go check out for this uh year, uh, which says that we are in this binary big bang.
What it really means is that we have, I have a specific story for you to visualize this, what I'm about to tell you in a minute, and it's about hearing music and slash listening to music. Previously, we had music. Um, if you remember, we had CDs and we had cassettes, and that's an example of data connected to the medium. And you had a CD and you put it into a CD recorder, and that was your endpoint for listening to the music. So, but again, you had that medium connected to the data on that particular CD.
What happened with streaming is that we decoupled the data from the medium. The medium became ephemeral. Uh, basically, there is a data model somewhere in, probably in the cloud or some other storage, and you can stream that data, um, no matter where you are, in your car, on your phone, or your laptop, you know, in a, in a cafe. And, um, what has changed is the user experience. It is more, uh, seamless, end-to-end, omni-channel. If you want to use business speak, you can possibly have an experience of going from place to place and if you still control the endpoint, you would have the same continuous song playing.
But what has not changed, even though the data is decoupled from the medium, is the data model behind it. There's still, uh, a lot of data, um, uh, details that are happening in whatever displays it is, and there are a lot of details that we know about this data and the data, uh, structure. It's, uh, all of the metadata, the bit rate, what song you're playing or track, all of that. Uh, but however, we are not running around with, um, you know, CDs in our pockets anymore. We're running around with the endpoint in our pockets.
And we see this in business applications as well. We are entering an applica, a shift, an architectural shift from app-centric to data-centric. Similarly, how you had the CD-centric to a streaming-centric where you really are operating the endpoint. And, you know, previously, we had classical applications where you log in and it's on your, in that one place, and the data is owned by that application, and that application is both the endpoint, the user experience, the business rules, and the data itself.
Then we moved into this microservice space. I was talking to my friend Lucash here, who, uh, I told him about microservices just a few moments ago. He was very surprised. And, um, uh, the, the, we are in this era of microservices where it's basically, um, small and, as Adam said, stateless, uh, pieces of code that execute functions and do a, do some type of workflow and operate on a smaller instances of data. However, you still have the user experience or the endpoint connected to that logic.
And in the future, we are seeing going away from that. We're seeing the disappearance of apps because why would, for me, um, we, why would I have to go and login into this one SAS application to know about an applicant, and this other application to know about status of some order, and the third application to know about some type of, uh, business process or anything like that? I want my life simplified. And this is what we see everywhere. Do the work for me is the mantra. And the "do the work for me" will be done by these endpoints, by agents, um, you know, AI agents.
And for this to be effective, uh, exactly how Adam said in his, uh, simple example of rebooking a flight, you need to connect a lot of data together and you need to organize the data, uh, into something we call knowledge. So, a simple run-through again, what's the evolution of the application layer? And we had the apps that were very platform-centric. Then we introduced agents that are connecting some, some applications with the platform, uh, but it's very unstructured. And, you know, it's a little bit of replacing the, the traditional APIs. And over time, we go into data at the heart.
And so, what does it mean, uh, to have data done at the heart? Uh, we will discuss. But before that, let me tell you another story. There are two kinds of many things that we see now, and I divide the world into these two kinds, completely unrelated. I divide the world into friends and future friends. So, future friends, welcome to Open Slava. But I also divide AI use cases into something that's a little more of automation that can do things a little better. And those are useful because they will drive some type of a savings, but they're not the true, true AI use cases. The true ones are the ones that can do things so fast that no matter how many humans we put together, how many automation, the traditional one, we put together, it, we will never be as fast.
There's one example from my current client, which is our insurance company. Um, they have a very complicated set of rules for all of this, their insurance products, which is business-to-business-to-customer, and all of these combinations is unique, or almost unique. They have more than three, three trillion combinations possible in their contracts, in their insurance contracts. And, um, what they've had to do before is, uh, they couldn't allow self-service because you would have to create three trillion web pages to go through. However, they have found a way how to navigate the knowledge graph of these contracts, which is stored in a GraphQL. And as they are navigating the nodes, they are auto-generating the front end as they are doing it. So, as you are navigating the intricacies of your own contract, as you're clicking yes, no, it auto-generates the next question to get to, uh, the endpoint. And the endpoint is all of your allowed activities on that contract.
Another one is, uh, another insurance company that created a domain-specific language to describe their contracts and scanned all of their physical copies from hundreds of years back, 100 years back, of, of their insurance contracts, and used that domain-specific language on to describe all of these, you know, screenshots, so to speak, these scans, and then transcribed that into something, uh, an AI agent can, uh, understand through this domain-specific language and ask one question. And that question was, out of all of my contracts, where am I in the risk of overpaying? And it spit out 5,000 contracts that they could go and then physically with humans review. But to start with a million contracts and review by hands, you would never do this with humans. But now you could focus your workforce on the thing that matters.
So, there is also, we spoke about two kinds of another thing. AI use cases that are probabilistic, AI use cases that are deterministic, which, you know, we probably don't want to use AI. Um, but all of this just says to me that there are two key elements to make it happen. And those two key elements are your use cases. The best use cases you have are cross-line-of-business, cross-silos, and then they are real-time. They are happening now. It's not your data swamp. It's not your data lake somewhere where you can do a query later on and figure out that we should have captured this customer the moment they walked into the store or the moment they they bought something. It's that in that very moment.
So, remember two kinds. First, use case has to be cross-line-of-business. Second, it has to be real-time. And to demonstrate, we will have two kinds of stories here. One is about the cross-line-of-business, one is about real-time.
So, to create that, um, uh, that real-timeness and the cross-line-of-business, we are thinking about an agentic data backbone. And interestingly, everything we know about building software still applies. You know what applies? Conway's Law applies. Conway's Law roughly, um, says that the organization building software will pass on the, the communication structures from that organization onto the software. So, essentially, the software will resemble the organization architecturally speaking, um, usually siloed. And what that brings us, if this happens, and this is a real-world scenario for many of our clients, is a big ball of spaghetti. We have layer upon layer of middleware. We have siloed applications, siloed funding for all of those in various stages of, of being done or being updated. We have dependencies across the teams that slow us down, and we have continuous, uh, cascading synchronous failures if we have, uh, if we have dependent communications. So, Conway's Law manifests in all of this.
And, uh, partners like Confluent with their product, or, or similar products, help us decouple these systems. And, uh, they help us with the, with the function of, of moving data around. And, you know, being able to connect and, you know, essentially help us to get to this agentic architecture where you have the seamless music streaming, ing experience on top. You have the event stream, all of the things that are happening at the point they're happening. Remember, an important part of any good use case is real-timeness. And then you have this decoupled target modern state architecture with some parts generated, some parts legacy, some parts decoupled, some parts your pure data around, potentially decoupled core.
And, um, to get here, we have ideated how we go from what you would know as 12 factors of cloud-native into nine princ, nine principles of agentic enterprise. And those nine principles are that you start with a hybrid, you are composable by design, you have semantic interoperability, you have traceability, observability embedded. You are real-time. We spoke about that. You can govern this. You are dual mode, meaning human and machine. You are self-describing, meaning you connect to that semantic layer and describe what you're doing. And then you have a lot of testing, a lot of, uh, self-reinforcement in how you do this. The blue ones are the data concerns. You could argue for a little bit more, or there could be a shading between the two colors, but realistically, we're talking about, uh, knowledge, and we're talking about knowledge in the context of, uh, semantic interoperability, real-time, and self-describing.
So, what I've seen so far when I go out to the internet is all of the companies, you know, all of the, all of the hyperscalers are trying to attack this one surface and capture it. Capture it in a sense that they want to be able to orchestrate agents. They want to provide the endpoint agents. They want to provide, um, models for for learning. And, but they also want to help with, uh, the core systems and the infrastructure. And that's exactly how Accenture thinks about, uh, the agentic enterprise reference architecture. It looks something like this. On the top and across, you have your lines of businesses. Here, I, I modeled private equity, but basically, we have roughly five layers, um, horizontally, and two on the side. On the top, you have where the business value happens. Remember that business value that is cross-line-of-business and real-time, and that's where your actor platform is. Underneath, you have platform orchestration. Underneath, you have your core enterprise or your SAP systems and others. And underneath that, you have this data backbone that again has the data foundation and moving the data around, two pieces. And underneath that, you have your omni infrastructure, as well as supported by this, like how we build stuff and how we know about things about, uh, the stuff we build, right? So, plus machine operating model and the observability of that model. But really focus on that blue part, which is the data backbone that enables these use cases I talk about.
This is how it could look like, um, for one of my clients, uh, where, you know, it's a, it's, it's a logos galore, but they have all of these in place, and you can use and you can use, uh, rationalizing these, you know, uh, systems or this, this, uh, logos applications, platforms, um, based on, based on the reference architecture. But each one of you probably could create something like this in your, in your space.
So, how do we decide? If we go back, how do we know how to create that data, uh, or that real-time event backbone? We know it. You just go and and listen to Confluent having their their speech, or how AWS does it. But today, let's talk about that data foundation and the data products, and how you can reason about the whole enterprise. And you reason about it by talking about agentic data readiness and the knowledge ontology, like a taxonomy, things in some type of a structure and some order. And why is this important? Understand your own data. I'll use a, a new law I made up yesterday. Uh, the new law is, uh, called after my friend Gavin Williams. Uh, so I call it the Williams Law. So, previously, it was garbage in, garbage out. Now, it's garbage in once, garbage out forever.
Let me demonstrate. Anthropic released a, um, study a few days ago, maybe a few weeks ago, but very recent, where they have trained one model to like owls, that the nocturnal birds, and then they asked that model to generate nonsensical random number data. They took that data and took another model, which was the same base model as the first one, and they didn't train it to like owls, and they fed it this nonsensical random data, and that data, uh, made the new model, the trainee, to go from not liking owls to liking owls. What this demonstrates for them is not that surprising, which is, large language models transfer biases over to their trainee. But it is very important to us because if we train our models on garbage data, and then we let that garbage data to be propagated down and down and down, and next, you will have that garbage out forever.
And how do we know about the data that, uh, we have in our system? We reason about it. We reason about it in two ways. Uh, what data needs to be ready, and what's the purpose it's going to be consumed? As you do this transformation, you will not do it in a heartbeat. You'll have to transform your data semantically, basically in the, in the OLAP style, high-performance side, and then the casual interface, context-aware side. And this will take some time. And most of the companies that we have, and we work with, um, they are somewhere on this journey from silo to integrated to standardized to, you know, many of them semantic, and many of them trying to be agentic. space, but really, it's, it's a journey on this to to get somewhere through an ontology.
An ontology, you can pick a biology book and read about it. What's ontology in real life? It's something like you see in the animal kingdom, right? You have your domain, um, you have your, uh, kingdom, phylum, class, order, etc. And in the enterprise, it's the enterprise level, line-of-business level, function level, capability, all the way down to attribute, all the way down to your JSON. And what we said at the beginning, we want use cases that are cross-domain and are real-time. And to be really cross-line-of-business, you have to operate on the enterprise level, on the domain level.
So, how does such a domain-driven enterprise look like? We have a path forward, and it's called domain-driven design. Hopefully, all of you have, uh, chosen this talk, um, so that you know, or you want to know more about DDD-driven design, but it is a really, really good approach I've used with many clients, um, where we can make sense of the best process possible and, uh, create knowledge around that processes in that organization. Um, why use it? It, it is based on the needs of that line of business or multiple lines of business, and we can use it to drive many things, organizational design, others, I'll explain. But really, at the end of the day, it doesn't matter what's behind this, these domains, whether it's, uh, your database design, your org design, or your operating model. At the end of the day, you want to understand your business on that enterprise level. So you can reason about use cases that are cross-domain.
Uh, let me give you an example. Uh, this is that one of the companies I work with, the business-to-business-to-customer financial recordkeeping example, where they have a, I mean, extremely simple domain model. Uh, the small gotchas that, uh, you know, we had to uncover was the difference between a person and participants, and the person, participant, and beneficiary. And they roughly align it to something called value streams, but you could call it domain groupings as well.
Another one was, uh, for a company in the event production and hospitality example. So much larger scope, and we were given the ability to transform the whole company. So we have much, much more departments involved, and it goes from assets to all the way to accounting to all the way to workforce planning. Um, but we are able to build their own domain model to be utilized as the basis for their knowledge ontology. And then what you do, you reason about all of these domains and their subdomains and all of that, um, to understand where the data is from, who owns it, and then what happens with it.
There are some key roles in the domain-driven design team, from a product manager to engineer to someone who facilitates creating that model, the architects. But what's not on the slide, the most important thing is to persuade someone in charge to care. So, if the remit goes from the CEO, or it goes from someone really like a COO or potentially CIO, you have a shot. If the remit comes from someone, uh, who's, uh, somewhere in the, in, in the lower sides, right? So, uh, someone from the line of business or function or capability, you will only operate on that level and you will not get to the agentic promise, which is cross-line-of-business use cases in real-time, right? So, but it can be done. This is a recordkeeping, uh, example, which is a smaller set than enterprise. This is a true enterprise example.
Uh, all right, so very quickly, what are the domain subdomains and domain components? So, domain is a collection of highly cohesive functional business functionality and data. Uh, they should ideally be mutually exclusive and have very clear, clear boundaries that you write down. Uh, subdomains is a smaller piece, and domain component is a thingy, right? Uh, the true reusability comes from reusing domain components, right? Because you could have the same calculator or observer or researcher or whatever domain components you want down below. This is extremely interesting to write down precisely.
And for example, my client has a, a domain model, um, uh, steering committee. Every week, we meet, and we have a domain model under semantic versioning. So, every time we add a top domain, top-level domain, it goes from 0.something to 5.something. Every time we add a subdomain, it goes from 0.5.1 to 5.2. And if we'd add a domain component, it goes from 5.1 to 1 to 5.12. And, uh, what it can do is that as you're reasoning about new things coming in, use cases, business process requirements, you can train, uh, a language model, in a RAG fashion, to understand your domain model and tell you whether your use case, what type of domains it should be using, whether it, uh, conflicts with something you already have, or whether you want, um, uh, to, uh, improve it and you need a new, uh, domain model decision record. Yeah.
So, domains really are influencing everything from your composable platform architecture, how you compose, uh, actual code to your, uh, to your events in an event-driven architecture. There are interdomain events, intradomain events. There are L0 events that are talking only within a subdomain. Uh, they, uh, influ, the domain model influences data ownership. The context for you read about context engineering completely outside of the, of this topic here, but super important to know about. They really, uh, talk about the NFRs and some many other things in the organizational construct. And then all of the naming conventions are based out of the domain model across the enterprise, hopefully, right?
And so, how do we get to one? How do we get to a domain model? Uh, we run a workshop. So, as you have brainstormings, you also have events running in this domain model. So, we call it event storming. A little bit of a cheeky name, but basically, it's a workshop that we do where we do, uh, event storming to model end-to-end events in a specific representative use case, and all of the use cases afterwards. Then we identify the domains that are apparent from that, uh, event storming, and then we, then we do all of the other work that needs to happen.
A typical execution roadmap looks like this. One to two weeks to align stakeholders. Weeks two to five, you do the, the domain-driven, uh, design approach. You educate a lot of people. There's a lot of preparation. And then you run the workshop where you do event, end-to-end event maps, and define the common language, also called ubiquitous language. And at the end, you cascade it into a domain model. Copilot, ChatGPT, Q developer, huge help. But that's not the only reason why we are doing this. The reason is that we're bringing all of these people who have different backgrounds, different understanding, business, technology, technology, management, operations, into one room, and we talk about the things, end-to-end, in a, in a single, single room, single format. And yes, you have inputs and you have outputs and you have the process, but at the end, you really need to bring folks together, and it's really about the humans.
Um, I have a story for you, which is, these events, they really vary based on the level of detail that the normal one is a strategic event storming, which is like high-level, how you get to, you know, from, how do you get through a use case, what events are present, what, what, uh, actors are present. And the lower one would be a tactical event storming, which is much more detailed, goes to API spec, goes to, goes to your JSON payload. But if you really want to do an enterprise level, which we were, uh, faced with one of my clients, we came up with one level above that, was we called it, not strategic, not tactical, but the stratospheric, uh, dom, event storming, where we took really end-to-end use cases representative of that business and really understood how it works.
The ground rules, really, is like, you know, you've done, domain, you've done, um, uh, design thinking sessions, you've done workshops before. Nothing surprising. There are some rules. You want to show events. You want to show some hotspots if there's too much discussion about something. You want to highlight actors. You want to highlight external systems. This is how it could look like, you know, there is an end-to-end scenario for, you know, buying a new spin bike and then doing something and paying for it. And you always map those, um, those events as something that happened. So, it's, it's in past tense. And, you know, here is a sample event storming use case if you want to try it out yourself. Uh, either ordering a pizza or opening a new account.
And interestingly enough, we had this exercise yesterday here in a room over there, uh, where we had an event storming session workshop. So, we tried it out with a group of, um, random friends who some of you are here, and you've seen some of these slides before, but it was very, very good interaction, and it's a lot of work to make it happen, but at the end, you're creating the agentic future. This is some, some one of my other clients, very big room, very big, uh, you know, set of events that are happening, in a sequence. And, um, we added some, uh, enhancements to this workshop. We also talk about the customer experience considerations. We talked about, uh, some future enhancements outside of the scope of our engagement. And then we also identify some domain objects.
An interesting thing was that I observed is that as you're bringing in multiple types of people, they have a different understanding. And so, when we mapped out the first happy path of an event map, we started doing the second use case, and they were like, "Should we take all of that down? All of those stickies and then start a new?" Because in their minds, this other use case was completely different. It is fulfilled by a completely different department, and therefore we has to start a new. We have to start a new. And I was like, "No, actually, let's just use a different color and let's just mark up the existing end-to-end flow, the happy path that we have." And I was like, "That would never work." However, we, we did do that. And in the end, they added like four stickies here and there, and it was completely mind-blowing to them that business-wise, it was a completely different workflow in a different system using different people, but logically, it was the same thing with a little tweaks here and there. And that will enable this, this com, understanding across the enterprise through these workshops.
So, remember, you want a use case that's across lines of business, and you want a use case that's real-time. You can make it happen if you understand the data model behind your enterprise, also called domain model, and you can get your domain model if you have a good enough, uh, support from above and you run these workshops that you can learn yourself how to do. And with that, thank you for your time. I'd like to answer some questions. Yes, exactly. Thanks, Pal. So, there are some questions for you. Let's start with the first one. How far are we in multimodality when it comes to using databases directly indirectly as input?
>> Uh, early seconds, not early days, but early seconds. That's where we are. Um, every company I work with has excellence in pockets. So they have like pilots that are going on. Uh, but they worked with a, with a, uh, with a company out of, um, out of UK, and they said, uh, and we started talking about the pilot, and he, and the, um, I think it was COO, said, "Don't talk to me about the pilot. I have more pilots running now right now than British Airways." So, I want to scale, and we, we're not anywhere near scaling anything like that, at least what I've seen.
>> Mhm. Perfect. Thank you very much. Next question. So, should architects build capabilities for AI to be self-healing or otherwise correctable?
>> Ideally, like, uh, yes. What I've seen self-correcting capabilities were on the infrastructure side. I have not yet seen a very good data self-correcting set of capabilities. So, infrastructure, we understand how it works, right? We knew that since Docker came out that you just treat your, uh, parts as a, as disposable assets, and you, and you plan for failure rather than try to recover from a failure. I have not seen a good example of data going wrong, meaning like there is a present hallucination in the enterprise data, and being able to self-correct from there, but it's an interesting topic of a lot of research by Accenture.
>> And the last one, does the rise of agent use cases mean the end of front-end applications?
>> I subscribe to what, uh, what we heard in the morning, which is, um, uh, from, from Tomas, it's not your job will be replaced by AI, but your job will be replaced by someone who understands AI. And for me, it's the same as when, you know, the internet came out, which is suddenly we didn't have too many people physically switching telephoning, but we had other people, like, uh, folks who set all of this, um, all of this up yesterday night, uh, who have the skills, uh, to, to help us usher this, this agentic future. So, your skills will be to orchestrate agents, to build agents, to train them, to decommission them, to, to make them better. Those are the skills that you, and that is somewhat transferable to front-end skills as well. Your skills will be to understand how to auto-generate and how to auto-generate CSS, etc.
>> Perfect. Wonderful. That's all the questions we have, actually. Thanks again. Thank you, guys.