>> 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 Merim Becirovic he is the Managing Director of Accenture's Global Cloud Initiative. Matt Lancaster, Associate Director of Technology, Architecture, Science, and Miha Kralj, Managing Director of Cloud Strategy at Accenture, thank you so much for coming on the show. >> Pleasure. >> Thank you. >> 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. 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, that's another event, if you're checking out, that's another event, right? And as opposed to treating those all as 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 a 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? >> Well 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 mind boggling. >> 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 is, Matt'll 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. >> 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 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 work style, and frankly the market is going to punish them out of existence. So we need something where all of 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 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 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 demand-driven design, then get into picking and choosing which, whether it's serverless functions or micro-nano-service some Kubernetes, 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 we run a lot of our Cloud footprint, we're already 93% of 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 the concept of running infrastructure, if I have better event-driven capabilities, I can react more efficiently, I can really make a consumable service more 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 code 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's 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 that Cloud was intended to be used. >> And just to add to that a little bit, there's a lot of folks that will take a very traditional imperative programming paradigm and try to jam it into things like AWS Lambda and Kinesis streaming and what they end up with the end is sort of a tortured circus freak of an architecture. It 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's only a few code 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 gateways that can actually stream those out to interfaces, that's all you need. We don't need to overcomplicate this like we have every other generation of architecture. >> I'm trying to picture that tortured circus freak of an architecture, it's ugh, 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 is at the forefront and also not everybody is at the tail-end, right. We have lots of clients in the high tech industry in communications and 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 Merim and his organization is extremely versed in those modern styles. >> 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. 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 that they built in the 70's and 80's 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 determining 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 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 Merim'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 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, 'cause that's one of the key things for us and all of these capabilities and the other thing, what's happening with this space, Cloud, microservices, event-driven architectures, everything is enabling this powerful change of making 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, all of 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 less people managing it but more people reacting to the events and 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's going to run our infrastructure and I think that's the most fun part part about this. >> I think two additional points to that, I think it was very well said, one of the things the really excites me about this space is that it becomes very understand... The technology piece, the software piece becomes very understandable to the folks who understand the business side and 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. (laughing) >> It's approachable to much broader businesspeople, not just to arcane, unique eyes. >> Yeah 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 chat bot that nobody actually likes to interact with. >> I know and this is the part we're missing, right. >> Because they can't actually do anything, 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, if you didn't get your room in time the system will go ahead and rectify that and it creates a great customer service experience instead of an IVR in text, which nobody likes. >> And I like the point, I think you hit on the point 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 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 from Andy Jassy. >> 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 agent, 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 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 experiences. >> Well if event-driven architecture can solve that problem, I'm all for it. >> You're in? >> Merim, Matt and Miha thank you so much for coming on theCUBE. >> Thanks for having us. - Absolutely, pleasure. >> 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. (digital music)

(rhythmic music) >> Live from Orlando, Florida. It's theCUBE covering Microsoft Ignite. Brought to you by Cohesity and theCUBE's ecosystem partners. >> Welcome back everyone to theCUBE's live coverage of Microsoft Ignite here at the Orange County Convention Center. I'm your host, Rebecca Knight along with my cohost Stu Miniman. We're joined by Miha Kralj. He is the cloud native architecture lead at Accenture and marathon runner I should say, too. >> That's true, yes. >> Thank you so much for coming on theCUBE, Miha. >> You're more than welcome. >> So I want to start the conversation by talking about the difference between cloud immigrant and cloud native. There's a big distinction. >> Yes, there is. Cloud became a new execution platform for a whole bunch of businesses and what we are going to see now is that lots of companies are using cloud in two different ways or two different forms. Even if you listen to analysts, they are talking about mode one, mode two so when we talk about cloud native we are mostly talking about both technologies and processes but also team organization that is very much inspired by cloud, that went through all of the transformations that we saw, for example, in companies like Netflix, like Uber, like very much how Amazon is organized internally, how Microsoft is organized internally so we are talking about very new approach. How to architect applications, how to actually have a process to develop publications and push them over into production, how to actually run the complete automation, a set of tools, but of course it's completely new enabling platform on top of that or underneath that that allows us to run those cloud native style of applications. >> An oversimplification I've heard is those born in the cloud companies will start out cloud native. The challenge you have for those that, the cloud immigrants, if you will, is there are so many different things that they need to change. Not just the way they architect things, the way that they run things. It's a real challenge and it's companies like yours I think, that help them do that immigration process, right? >> You are actually bringing up the really good point 'cause one thing is if you start from nothing. If you are in a green field and you build, you can say I'm going to take the best automation, I will buy the best people and I'm going to go full-on cloud native. That totally works. You can also be in the old world and you can say let me build cloud native like a separate IT organization and you hire some people in the old IT and some in the new IT and so on and so on and lots of our clients do that. We kind of create a bimodal type of IT organizations with two sets of technology stacks, two approaches. The thing that is really hard to do is to actually integrate those two into a very good hybrid cohesive schema so that you can have a system that one part of the system is traditional on-prem database that goes through its own rhythm of development and then you have systems that are cloud native, very rapidly developed, lots of the minimum viable products that are actually sourcing the data from the old world. So it goes from hard, harder, hardest. >> So do you have a schemata of how to make the decision? What strategy is right for which client or is it really just so dependent on the client's unique set of circumstances? I will try to reframe your question because it is not old or new 'cause it is always that dilemma. If you're looking every decade we go through the same rhythm of refreshing. We get a refreshed wave of architecture. If you remember 30 years ago when I was still young we had a traditional monolithic architecture which were refreshed into client server and into a service oriented architecture now into microservices and in the future we already know that we are going into reactive and driven architectures. Whenever we have a new architectural style we always get also new set of processes. Historically with the waterfall development then we refreshed into rational unified processes you'll remember that from ages ago and then the traditional right now we are doing agile and we are going towards lean development and so on so everything refreshes. So your question is very much asking when is the right time that you stop using the previous generation of architecture, process, tools and platform and jump to the next generation 'cause you can be too late. Obviously we are talking about companies that they need to modernize but you can also be too early 'cause lots of the companies are right now wondering should they go serverless which is also cloud native style but it's way ahead of typical containers, simple for natives. So when is it time to go from VM based traditional SOA into microservice containers versus reactive, event driven on let's say, azure functions. Those decisions are not easy to do but I can tell you most of my clients have kind of a spectrum of everything. They still have a mainframe, they have a client server, they have SOA architecture, they have microservices and they're already thinking about event driven serverless. >> Absolutely, and by the way, they can run that docker container on linux on the mainframe because everything in IT is always additive. So it's challenging. I've spent a lot of my career trying to help companies get out of their silos of infrastructure, of product group and in a multicloud world we feel like have we just created more silos? How are we making progress? What's good? How are you helping companies that maybe are stuck behind and are threatened of getting obsoleted from being able to move forward? What are some of the patterns and ways to get there? >> Our approach is very much trying to find what's really behind, what's the business reason behind? 'Cause until I realize why somebody wants to modernize it's very hard to give the answer to how do you modernize. Not to oversimplify but we typically see that value formula coming. We want to reduce specific detriments and we want to increase specific benefits and hat's why people need to go through those modernization waves. You can reduce cost and historically we were dramatically cutting costs just by automation, clonization, all of that. You can reduce risk. If you remember a few years ago everybody was talking that cloud is too risky, now everybody says oh, I'm reducing the risk and improving security by going to the cloud. You can increase speed and agility so you can suddenly do things much faster and enable more experiments. I personally find the number four most interesting which is you get better access to new software innovation. Here is the question. When is the last time that you remembered and a technology vendor would give you a DVD and say this is our latest software that you can use. >> Yeah, probably a Microsoft disc but you know, back in the day. >> Nobody is shipping software for on-premises anymore. Maybe, they do later in a cycle but all of the latest software innovation is cloud first or cloud only so it's only logical if we see the business that depends on business innovation, they need to start building their systems in a cloud native world 'cause they are going to source natural language processing, artificial intelligence recognition, all of the complex services, they have to source them from the could and therefore they want to build apps in the cloud native style. >> Yeah, it's an interesting challenge. Things are changing so fast. One of the things that I hear from certain companies is they, is that, well, I go and I make my strategy and then by the time I start implementing it I wonder if I made the wrong decision because some new tool is there. You mentioned Azure functions, wait, no, I was just getting on Kubernetes and getting comfortable with that as opposed to most companies, oh, I'm starting to look at that thing so these waves are coming faster and faster. >> You just exposed that you are an architect. Let me explain why. >> The technologist is charged, sorry. >> When I hire people into architecture roles, one of the common interviewing questions will be first, explain one of your previous solutions and then the question comes if you would start again today, what would you do different? Every single architect that I know are always dissatisfied with their previous choices and decisions because there were new wave of technologies that came in during the engagement. What you are expressing, whenever I get a person that says no, I did everything perfectly and I would not change anything, I might have a different role for these people. >> So I mentioned before that you are a marathon runner. I'm curious to hear how your job is similar to running a marathon because as Stu was just talking about, the pace of change, that is the one constant in this industry and to be a marathon runner, you got to keep a good pace. How do you sort of make sure that you are keeping your stamina up, keeping your eyes on the future to make sure you know what's coming ahead? >> That's a very interesting analogy and I was doing that comparison not that far back before. The first part isthat in order to have a good time at the end of the race you need to have good nutrition, you need to have a good preparation, you need to have all those things so the moment when I compared it back to my regular work, nutrition, we usually compare it with how do I keep my skills up which usually, at least in my case, it is between four to six hours every day either reading I usually say to people I try to make something, teach something and learn something every single day and you have to do that four to six hours every single day just like preparing for marathon and there is a whole bunch of those other activities that all need to be aligned then once you actually start running with the client, when you start doing engagement with the client, that even when you hit the wall, even when you get tired, first you know the reason why you are doing it, you know what the end goal means, what the finish line looks like and you know that you are prepared, that this is the best that you can get. Is it easy? No, it's not. We are kind of used in the IT industry to do that and reinvent ourselves every second year. >> When you look at the cloud navtive space what are some of the challenges and pitfalls? How do you manage that? What advice do you give at a high level? I understand there's a lot of diversity out there. >> Oh, where are the challenges and lessons learned? How much time do we have? So I would say the most obvious one would be jumping into that pool of cloud computing without preparation, without guidance, without help, without mentoring, tutoring or somebody to guide you. Get less than perfect experience and declare that is not for me therefore it's not for any of us ever. Right? I see lots of those generalizations where although it's clear that the whole industry is going in that consumerization direction and we are charging by consumption and all of that that we have clients that started it either early, they didn't have a fantastic experience, they got into specific roadblock and then for several years they don't want even to have a discussion anymore. The other problem is not enough upscaling so simply not enough thinking how different that knowledge is. A discussion with a CIO that says that IT's the same for last 30 years, you know, a machine is a machine is a machine. Coding is coding is coding. Nothing really changed ever. It is really hard to have a discussion to say the devil is in the details. Yes, technically we do the same thing for 30 years which is we make dreams come true in IT. We create something that was never done before but how we do that, and tools of the trade, an approach is dramatically different. Every decade brings a dramatically different result. Trying to explain that in supportive way is a challenge on its own. >> Miah, what about your team? How are you making sure that you have the right people in place to help execute these solutions? And this is they have the right skills, the right mindset, the right approach of the continual learning and the constant curiosity that you keep referencing? >> Well, you are asking a consultant how does consultant know that he's successful? When the client is happy. I'm serious, very simple here, right? How do we make sure that the client is happy which is very much corollary to your question. We really first need to make sure that we are educating our clients all the way through. The times of delivering something without a massive knowledge transfer, those times are over. The easiest way to explain that is that what we are telling is that every business needs to become software business. It doesn't matter is it bank, insurance, health provider, they need to learn to actually make critical competitive advantage solutions in-house. So how do we actually teach engineering to companies that historically were not engineering companies? All of my team are half coaches and half engineers or architects or whatever they are. Being a coach and being a mentor and kind of allowing our clients to do things independently instead of just depend on us is one of those major changes that we see how we actually ramp up and train and support people. >> Miha, we've seen and talked to Accenture at many cloud events. Accenture's got a very large presence. I've been watching the entire week. Activity in the booth, one of the four anchor booths here at the show. What's different about Microsoft, your view on Microsoft, what you're hearing from customers and also speak to how Accenture really lives in this Microsoft ecosystem. >> I think that I understand the question. Are you asking me about how Accenture and Microsoft cooperates together in that new world? >> Yeah, why does Accenture have such a large presence at a show like this? Accenture is at all the cloud events. >> So Accenture has specific targeted, strategic alliances with large technology vendors. The size of the alliance, the importance of the alliance is always directly reflected both from, of course, the size of the market but also our belief in how successful a long-term specific technology stack is going to be. We have a very strong, firm belief that with Microsoft we actually have an amazingly good alliance. Actually we call it alliance of three. We forgot to mention Avanade as well, right? Which is dedicated to creative entity to make sure that Microsoft solutions are built, designed and then ran correctly. We jointly invest obscene amount of money to make sure that right solutions are covered with right Microsoft technologies and developed in the right manner. >> Great, Miha, thank you so much for coming on theCUBE. It was a pleasure having you. >> You're more than welcome, anytime. >> I'm Rebecca Knight for Stu Miniman. That wraps up our coverage of Microsoft Ignite. We will see you next time on theCUBE. (rhythmic music)