 Live from Las Vegas, it's theCUBE, covering the AWS Accenture Executive Summit, brought to you by Accenture. Welcome back everyone to theCUBE's live coverage of the AWS Executive Summit here at the Venetian in Las Vegas. I'm your host, Rebecca Knight. We have three guests for this segment. We have Mirim Besarik. He is the Managing Director of Accenture's Global Cloud Initiative. Matt Lancaster, Associate Director of Technology Architecture Science, and Miha Kral, Managing Director of Cloud Strategy at Accenture. Thank you so much for coming on the show. Pleasure. Thank you for returning. I should say Miha, you're a veteran. We're talking today about event-driven architecture. Before we get into the nuts and bolts of it, I need a definition. So what is event-driven architecture? Sure, so event-driven architecture, I think the simplest way to think about it is when we're doing complex series of transactions, it's actually breaking it down into its constituent pieces and treating all of the segments of a transaction as separate events that can be reacted to as they happen, right? So if you're shopping and you're putting something in the cart, that's an event. If you're going to the next page, it's another event. If you're checking out, that's another event, right? And as opposed to treating those all as sort of one step follows the other, right? A lot of times there are sequences and things that can happen in between there. If there's a next best offer or a product marketing interstitial that needs to be put in, those things can be reacted to and composed much more simply than actually writing all the logic to put them in a big sequence. So on a high level, I would say it's an architectural style, right? It's a style of putting systems together, which is an evolution of the most common styles that we used so far. And we went through several evolutions about every decade we get a new and better architectural style. So reactive event-driven style is just the one that is currently shaping to be the one that is going to replace the older architectural style called microservices. So why would an organization implement this event-driven architecture? What kind of business challenges would the organization be looking to solve? So if you want, I'll start there. I mean, just think so. You have a world where today, I believe we're in the slowest time we're ever going to be from a technology perspective. Which is my point. And what we saw this morning, right, gentlemen, the amount of innovation that everyone is doing, including AWS, is going to be mind-numbing. So the question is going to be, how can we and what tools can we use to help us adapt for those capabilities in the future? So I think that's really one of the things that Matt will say, I think it's easier than ever now. It was harder before, but it's getting easier as the providers and everyone else is making their services more readily available for consumption. Yeah, I think in a lot of ways, as an industry, we're almost forced to move to this paradigm, whether we like it or not. Because I think everyone understands that every company has now become a software company. Once again, whether they like it or not. And that means major changes to the organization model, the way people deliver. We need to be much more product focused and teams need to own their product and things like that, right? Which is becoming the common sort of business model that successful companies are operating around. If the architecture is still a traditional command and control architecture, two years later, they're going to be back to that old org style. And frankly, the market is going to punish them out of existence. So we need something where all these wonderful, complex components that we saw in the sessions today can be decomposed into one team doing one thing with one set of components and they don't necessarily need to be aware of what all the other teams are doing because they just need to react to one another's events when they're interested in them. So the system, business systems, always grow to the largest possible extent of what is still manageable and controllable. And using traditional architectures on top of this modern technology that allows us now to make way more complex systems, we're already having clients that we see that the governance, control and transparency is at its limit. So if we want to go beyond that barrier of complexity and not fear that suddenly systems will become chaotic, we need a new architectural style and we see already those limits happening and that's why we already have an answer. We have an answer that is after microservice architecture, which is reactive event driven. Would you say that moving to this kind of architecture is difficult? It's a great question. And I think it's gotten a bit easier. There's definitely some magic to actually taking a step back and decomposing the business systems and saying, okay, this component or this piece of the transaction or this piece of the organization fundamentally does this. These business events are what they really need to focus on and then make the components, functions and systems actually emit and perform the business logic of those events and do more domain driven design then get into picking and choosing whether it's serverless functions or sort of micro nano service on Kubernetes, right? The components allow us to cleanly separate and stream out events and react to each other but if we don't do that initial stuff on the business side, then it becomes really difficult to know who gets value where. I think the art of the possible in this space is very much anything can happen and I think about things like when we run a lot of our cloud footprint we're already 93% in the public cloud for Accenture's IT and I think about how we consume those things. What can we optimize? How can we do things differently? Even on a concept of running infrastructure if I have better event driven capabilities I can react more efficiently. I can really make it more a consumable service more a utility service than I've ever had before. So I think that's one of the draws for me. When you say difficult here is if developers that are writing codes today and they already went through a couple of waves of reinventing themselves if they already know that they need to do that again then it's not difficult. For the developers that feel that they arrived and they already can code for the cloud and that's it. It is a difficult reinvention when they realize that although yes their existing knowledge of procedural programming of traditional way of coding systems in the cloud they need to throw lots of that knowledge away and relearn how the systems are properly composed so they use cloud the way the cloud is intended to be used. And just to add to that a little bit I think there's a lot of folks that will sort of take a very traditional imperative programming paradigm and try to jam it into things like AWS Lambda and Kinesis and streaming. And what they end up with at the end is sort of like a tortured circus freak of an architecture. And it just doesn't help anyone and ultimately people spend six months and then get super discouraged on doing this stuff when they could have taken a step back and done it right the first time which I think is why it's important to understand that it's only a few composable components. The more layers you put in the more complexity you're adding. The more you horizontally grow the better off you are. And if you're streaming events you have functions that react to those events microservices that react to those events and then the gateways that can actually stream those out to interfaces that's all you need. You don't need, we don't need to over complicate this like we have every other generation of architecture. I'm trying to picture that tortured circus freak of an architecture. It's cool. In terms of Accenture's own experience in this area I know that your company is already leveraging event driven architecture. Can you tell our viewers a little bit more about your own experience? So let's start with our clients first. We serve a very broad spectrum of clients and luckily not everybody's at the forefront and also not everybody's at the tail end. We have a lot of clients in a high tech industry in communications and in media where the needs for the leading edge is very clear and we are focusing particularly when it comes to that latest innovation event driven included particularly on those industries. We kind of belong in the front part of there and that's why Merrim and his organization is extremely verse in those modern styles. Yeah, I think just to add to that a little bit since I play in a slightly different space than you most of the time. I work with a lot of banks, insurance companies, capital markets and the adoption that I see in those industries of this stuff is massive, right? The problem with most banks is that they've tried to change core banking systems now two or three times. They're still sitting on mainframe stuff built in the 70s and 80s and most of what they, with payments and with different financial services and stuff they can't actually add that stuff to the speed and convenience that their customers are demanding and so there's a lot of fintech startups that are disrupting that market and if they don't change those core systems and they don't become more event driven and we don't sort of decouple, decompose and then eventually rebuild, we're going to find folks really fall behind in the marketplace and I think they realize that the real magic of this is that we can, it's not a big bang three year transformation anymore, right? We can build the core and then realize value within the first six months and then continually iterate and evolve and hollow out those legacy systems and eventually turn them off which is very opposed to the old way of saying we're going to do this three to five year transformation after five years you probably maybe kind of will realize some technology value. And to Mariam's point earlier, no CEO is going to go in front of his board or her board and pitch a five year transformation, that's a really good way to get fired. Yeah, I mean even in our own internal environments one of the things we always think about is what are we trying first, what are we failing fast at? Because that's one of the key things for us in all of these capabilities and the other thing that's, what's happening with this space, cloud, microservices, event driven architectures, everything is enabling this powerful change for the first time I would say in a long time, the network engineer, the app architect, the technical architect, the infrastructure engineer, every one of them working together to start to think about this, hey all these things are happening in my environment, these events are happening, what should I do differently? How does this help me automate my capabilities? How do I react to things differently? How do I make sure that I'm catching my infrastructure before it fails, my application before it fails? There's many, many levers that you could use in this space and we're frankly trying all of them because I think the goal to me that helps is I want an automated IT experience that has actually less people managing it but more people reacting to the events and kind of we're creating the world where this event driven architecture you could say eventually is going to evolve into all this AI stuff, we're going to be the managers of AI in the future. The AI is going to run our infrastructure and I think that's the most fun part about this. I think two additional points on that I think it was very well said. One of the things that really excites me about this space is that it becomes very understandable, the technology piece, the software piece becomes very understandable to the folks who understand the business side, the marketing side, et cetera. If what you're doing is just sending out events which are a piece of business functionality or marketing functionality or whatever, it becomes explicable in plain English. You're reacting to one another's simple business events and then all of those composed together can create the same value chain that before had to take six months and only a math PhD could understand. It's approachable to much broader business people not just to arcane, unique, yeah. That's right. And to the AI point, I think one of the most disappointing things to me in our industry is that most of the AI projects have boiled down to a shitty chatbot that nobody actually looks at. I know, I know, and this is the part we're missing, right? It's like great. They can't actually do anything and when you finally get to a person they have none of the same knowledge. So if we democratize that information it all gets streamed out to all interfaces all at once. And they can say, okay, you know, if you didn't get your room in time the system will go ahead and rectify that. And you don't, it creates a great customer service experience instead of an IVR in text, right? Which nobody likes. And I like the point, I think you hit on a point that that's very near and dear for me is as IT practitioners, we've dealt a long time with the siloed ownership of data. This democratization of data is a very powerful tool I think that helps gets enabled by some of this event driven capability because so many times it's people feel that, oh, I own the data, I can't share this with you or I need to understand what you're doing with it. Expose your data, give your teams a chance, give them the events, let them react because you don't know what you're going to create coming from it. Set your data free. We heard that this morning. Set your data free. Set your data free. And there's very relatable examples of this, right? I mean, how many of us have gotten off a flight? The gate has changed. It shows that on your mobile app. You walk up to the gate edge and you're in an unfamiliar airport. Where do I go? And they say, oh, your gate hasn't changed. It's not updated on my screen. You go to the board in the airport. Oh, it's not updated here either, right? Then you go to the original gate. They say, what are you doing here? You have five minutes to get over to the new gate, right? And then you book it all the way over there. You look at the defibrillators on the wall. You're thinking maybe I'm really glad those are here. You get to the gate and they haven't even started boarding yet and you finally get the late boarding announcement, right? It's three bad customer services experience in one. And if all that data goes to all those interfaces all at once, you have none of those bad. Well, if event-driven architecture can solve that problem, I'm off for it. You're in. Marim, Matt, and Miha, thank you so much for coming on theCUBE. Thank you for having us. It's a great conversation. I'm Rebecca Knight. We will stay tuned for more of theCUBE's live coverage of the AWS Executive Summit coming up in just a little bit.