 The subject is EA Next, next generation enterprise architecture for the digital age. So our presenters are Randy Potter, who is Senior Director EA Practice North America for Capgemini. Randy leads a team of EAs to advise Fortune 500 clients on their digital transformation initiatives, innovation and the impact of new technology on their business. And Ghanar Prakash Ponasami, Enterprise Architect Digital Acceleration Centre Capgemini India. Ghanar has more than 17 years of IT experience in various architect roles such as Enterprise Architect, Digital Solution Architect, Delivery Architect and Technical Architect. In this session I'll look at the next generation enterprise architecture for the digital age. Gentlemen, a warm welcome from the open group, Randy Potter and Ghan Prakash Ponasami. Over to you gentlemen. All right, thank you Steve. So real quickly let's jump into it. It's fairly fortuitous that we actually come last because the last four or five presentations really get consolidated into what we're going to talk about here. This idea of the next generation architecture came about a little over two years ago. And several years ago there was this topic of buka, right, that started running around the idea of volatility, uncertainty, complexity and ambiguity. But there weren't good answers to how to address that, particularly from an architectural perspective. So a lot of what we started to do two years ago is to put together some ideas on how to address that. And I'm going to go ahead and go to the next slide here. And, you know, at an overarching level, there were really three areas that we started to focus on. One was the idea of anti-fragile architecture and I'll spend some time on that in just a minute. Agile architecture, which we've already heard a little bit about, but I'll talk about that particularly in the context of digital first and digital transformations. And then Prakash will talk about architecture automation. And those are really the three pillars this stands on. We took those ideas, baked them into our current enterprise architecture maturity assessment, which is based on Togaf 9.2, plus some inner learnings from Capgemini. And then we've also added these kind of three additional pillars. So, you know, what was discussed in just the prior session about automation can't stress that enough just because we got to be able to go a lot faster than we do today, right? So real quick, I'm going to do a lot of this will be real quick. Anti-fragile architecture principles. Some of these will be familiar just from a pure architectural perspective. But this all really came together two years ago based on a book from Naseem Tlaib. He wrote a book in 2012 called Anti-Fragile. And it's about all kinds of different systems, not necessarily computer systems at all. He talks about politics and government, you know, and almost any kind of thing. But anti-fragile is not what you typically think of in terms of we normally think of resilient systems or robust. Anti-fragile is actually something that improves with stress and time. So, you know, that'd be a neat trick if you could do that with architecture all the way through your build and run, right? So we started looking into that one of the key things that this starts with is the idea of increasing your options. Some of you may be familiar with an ERP package that a few years ago decided to deprecate one of their largest packages and kind of force people to move up to the next version within like about five years, which many of our clients have millions and millions of lines of code customizing this ERP package. And frankly, that threw them for quite a loop. Most of them got, you know, pretty upset about it to tell you the truth. But what had happened was the clients, they had basically painted themselves into a corner. If they had done things differently, it would not be as painful to do the upgrade. And when I call it an upgrade, I wouldn't really actually call it an upgrade. It's like a combination migration and rebuild. Now, if they had incorporated some fairly simple principles that we're going to talk about here, they could have avoided a lot of that. A good example of creating options for yourself from an architectural perspective is leveraging something as simple as API. So if I'm doing APIs on my systems, and sometime in the future I decide that I want to do something different with that system, or I want to provide different access to that system, that becomes actually pretty easy. I have built in future options that I don't even know about today. So that's just one simple example. But that's an important one. The next one is stressing the system. So from an antifragile perspective, if you think about like the human body, right? If you sit around like me for the last three months in this office in my house, not doing anything, your body starts to get pretty fragile. But if you get up and you work out and you stress your body to some limited amounts of pain, hopefully, then you get stronger. And that's the idea here with stressing the system. In 20, I think it was about 2010, I believe Netflix had a major outage. And they decided to replan the way that they think about their systems. And one of the things they did is they decided that we've got to actually try to test things and break things in production to see what happens. Because a system that big, they don't have a realistically similar system for a quality assurance or a pre-production environment. And so they came up with something called Chaos Monkey. And Chaos Monkey is basically, it's an approach and a plan for being able to plan and execute breakage in the production system. Now, the important part is you need to be able to manage that safely so that you're not taking out users. And there's other systems too, Gremlins, another one that you can do that with. But it's important to architect the system so that you can stress it in production. And then the next one is similar to that, is build for recovery, not failure. So typically in the past, we've tried to build systems that cannot fail. The problem is, is when they do fail, they usually fail rather dramatically. There's, you know, I can think of a particular airline a few years ago had a fairly major outage and it took days to get back online. And because one particular part of that system wasn't as robust as the rest of it. And they don't, you know, and it wasn't well tested in production, I'll put it that way. And then the next one is distributed versus centralized. So if you think about centralized systems, the danger with that is if that goes down, then you're down. Now you can have a, you can have essentially a centralized system from an infrastructure perspective, but at least your services need to be distributed and robust. Easy way to think about that one is microservices and containers and being able to run that. Another way to think about it from an infrastructure perspective is from a, you know, the whole cloud industry and how they build their data centers and to be able to, you know, fail over to a completely different data center and building in the capability for that. So all of this, these are what we would call our antifragile architecture principles and building those into the capabilities that we that we implement. And then Agile architecture, which has already been talked about a couple of times today, but really thinking about this in terms of, you know, iterative architecture MBA or minimal viable architecture. I've also heard it called minimal value architecture. But if the idea is rather than boil the ocean for my current state and then, you know, think about design the future state and then start doing all my transitions over the next five years. Instead of doing that doing iterative approach focusing on change, focusing on the customer experience. So you wouldn't want to do that exclusively. It's not just about the, you know, the front office systems or the front end systems. But it's it that's a good place to start and when you're right now what part of what prompted a lot of this is all the digital transformation that's going on in our industry and people, you know, it was said in one of the sessions previous to this that all of that digital transformation and those digital journeys are adding complexity to the current it landscape. And so focusing on that and how it integrates then into your back office is a good place to start on integration isn't just about the way we typically think about integration of systems. But it's also integration with the business and the prior session that from mega that talked about, you know, really looking at business outcomes. Part of what agile does is it embed business into the process. So you've got a product owner who's supposed to be from the business and they're supposed to be injecting that direction and value from a business perspective into everything from the scrum teams to your planned implements, etc. So that's two areas of focus around integration is that back office back into your legacy systems are sorry the front office into the back office, but also integration with the business, which leads to the next point. And that was talked about earlier as well is enterprise architects can't just sit in the ivory tower, produce standards and sit on the, you know, architecture review board and shoot, shoot things down just because they don't they don't meet some, you know, 250 page standard that they've been the solution to the enterprise architects have been directed to follow. They need to the enterprise architects need to be in those program increments that are going on, which is usually a quarterly planning exercise, but they need to be in that there's certain reviews that they need to be a part of to make sure that things are staying on track. And it's a two way street. And that is that those leads to the next point, which gives them the opportunity to consult and guide, not just produce standards, but to actually consult and guide on that. But it also is a feedback loop being in those lower level. So, you know, I wouldn't say you have to go to every scrum meeting every day. Definitely, you have to have too many EAs make that possible, but you do need to be in the program increments and the reviews. You do the, you know, sprint reviews and you're going through those, you're going to get feedback that you're going to hear that you wouldn't otherwise. And then lastly is tools and frameworks. So, you know, this was this was talked about a couple of times already, and that is integrating your tools and frameworks from an EAM perspective with those agile tools and making sure that, you know, both of them are kind of bidirectional and feeding each other. So with that, I'm going to turn it over to Prakash to talk about automation. Thanks, Randy. Hello, everyone. So, as part of the next, I would like to take you to those kind of automation options available and hope to get started into the next journey. Architecture automation is about automating the certain enterprise architecture activities, such as current state architecture assessment and application and technology architecture level. And the enterprise architecture is both a meta-model and standard, and there is that existing available operators at organizational level. Let's look at those one by one. Nowadays, the modern EA tools having additional features like even in a couple of previous presentations we have seen about like such as strategic transformation management, portfolio management, technology management. So those are all the additional features has been captured in that modern tools. Industry analysts such as Gartner and Foster predicted that by 2023, 60% of EA tools will become intelligent and 60% of EA tactics will be intelligent into their business and operating itself. To see the realization of these predictions nowadays, EA tools started incrementing more projects. In our case study, that use case, we have used Orbis iServer as an enterprise architecture, and there is that product features to implement that automation part. When we engage with the big digital transformation, getting to know about business capability and process from existing enterprise ERC systems is essential. The modern EA tools has built-in features in form of projects or APA integration to get those business processes in PPM and standard and populated into enterprise architecture. Which helps the business executives and stakeholders start to define or redefine the business process from EA tools, which becomes a kind of a front-ended tool for business stakeholders. Instead of that, they have a kind of restriction access enterprise application systems. And sit back to that enterprise. In that way, the dynamic changes. Prakash, your audio is kind of flaking in and out. You might want to just slow down a little bit and make sure you're as clear as possible on your end. Okay. Is it final? In some cases, the asset and the process information, like will be stored as a configuration item in the integrated process. So what we have to think of those information also into a repository. Some of the product features, which not compatible with that current CMDB sources, that EA tools have some sort of an effectivity to import based on that Excel-based process. In some cases, the application level information will be obtained in the application portfolio management tools. These information will be essential when we take the decision for digital transformation. So this also can be integrated into EA repository. So in order to accommodate the information we read from the all the resources or the all sources, we cannot rely on the single framework standard. And moreover, we cannot use the framework standard assets. It requires the tailored applications of the tailor customizations to meet that customer's metamodel requirements. In that case, it has been a combination of multiple frameworks like Togoff with the payment standard and additional metamodels to depict about these resources. Along with that industry reference architecture. Like in one of our client example for the telecom industry, we have integrated Togoff, the payment standard along with that reference architecture from EM4. So overall, the enterprise architecture repository becomes the center source for all enterprise information. And this automation approach will ensure that information available on enterprise architecture repositories. Now we just look into that EM maturity assessment. Can you just move to the next slide? So now you might get some idea about antifragile principles, agile architecture and architecture automation. So now let's have a look how to conduct an assessment about where we are on that next step. So this is the assessment approach data. We have an assessment on the strategy like above value case and mandate for the role of enterprise architecture within the organization principles and constraints as just few minutes before and improved about that architecture. Competency and capability. This is it is the community of competent enterprise and project level architects supported by appropriate training and accreditation schemes. Governance and assurance. Community and culture. It is the corporate culture and application of enterprise architecture in all change initiatives as we just captured the agile architecture part few minutes before. Architecture content. It is a comprehensive and integrated description of current and future state of business operation and supporting information systems and infrastructure landscape. Just before we just captured with that in what way of customizing the model to capture those informations in an automated way with the right set of or the right year repository. Then. Final one is about framework method and tools. It is a robust scalable and sustainable framework and with supporting tools for architecture development and this ongoing maintenance. I just covered kind of the process and methods to generate that year repository as well as preparing that documentation approach and that integration approach with that from that interesting enterprise applications. In order to make that year repository. Next, thanks everyone. All right, thanks, Prakash. I'm going to go back to this slide. One of the things that one of the interesting automations that we were using a tool called Orbis I server. But one of the really interesting automations is to automatically generate diagrams. And to enable people who are just using Microsoft products to leverage those. So that was the automation side of this was really important. Obviously, as was spoken about before having that centralized repository is important, especially for reuse. We have 8000 certified architects around the globe. And so being able to, you know, a capture some of that information and be able to reuse some of those artifacts and mix and match them is a big deal. So I'm going to go ahead and skip over to our conclusion. You know, obviously things are, you know, the whole idea around Bucca is, you know, volatile uncertainty complexity and ambiguity. That's not new. The difference is that it's happening so fast. And, you know, we just had at least one black swan event, which was COVID-19 that really threw a wrench into everybody's thinking for the year 2020. So definitely be one year a little go down in the history books. So going forward, we're talking about we need to be future proof. And that's where anti fragile comes in need to be agile and flexible as enterprise architects. So that's not just about what kind of architecture you produce what the artifacts are. As was said earlier, it's critical that what you produce can be used by others. The key thing for an architect to be able to do is communicate, right, communicate and sometimes translate. So being able to do that and then automate as much as possible because you just don't have time to build all this stuff by hand. And there's good tools now, particularly in the eam space to consume existing products out there and to be able to, you know, basically build a majority of your current state. Immediately and better yet, to be able to refresh that frequently so that you always have an idea of where you really stand versus where you're going. So, Steve, I'll stop there and we'll take any questions anybody may have. Thank you both very much, gentlemen. Round of applause if you could hear it, but thank you. It's black swan event is an understatement isn't it. So, something that I wanted to to ask you recently saw a significant I'm actually looking for the name of it now, a significant publication from cap Germany on an ea report that was published either this week or last week. It was actually last month. Last month was it okay. It was a great piece of work and some, some interesting things came out of that one of one of the things that I took from that was the, the key role that enterprise architect are playing in transformation activities. The number was 95% said they were key contributors to major transformation efforts, coupled with, you know, and there was a there was a but, but we need to be using more agile architecture approaches and lots of the things that you that you've talked about here. I know it's not directly what you've spoken about but I know quite a few of our audience has seen the, seen the report or at least aware of it. Are you in your practices. How does that report change what you're doing or does it already reflect what you're, what you're doing with your customers. It's really a reflection of what we're doing. I mean, it was about three years ago really started to notice the impact of digital, you know, digital journeys digital transformation. And as was spoken about earlier by one of the other panelists that that is causing that plus the significant increase in your new technologies from IOT the blockchain, especially artificial intelligence. Things coming together are creating a big mess. What happened after the financial crisis in 2008 is that a decent number of large enterprises cut their enterprise architecture programs. And those of those started coming back strongly probably in about 2014. You really started to see an increase by 2016 and 17. And there was this need for, we can't do enterprise architecture the same way we used to, because it takes too long. Things will have changed by the time we're done. So yeah, that whole agile architecture approach is critical. So we are definitely a reflection of what the feedback was from that that report. That was intrinsic information that we've already knew and understood before the report. It was actually a good validation of where we were going. Yeah. Yeah, I mean what what you just described that that. The occasion of a lot of a practice is being being shut down as one of our one of our later presenters for home of my BM does a great presentation talking about that's the latest of the ea winters, you know, ea goes out of fashion for one reason or another. And then the sun comes out and you know, it might be a little different, but it's still on the rise and still very important. But what happened was, and I'll use one client example. I won't mention the client, but a large multi billion dollar retailer basically did, you know, they cut their program. Yeah. And they started doing all this, you know, digital work, especially on the customer front end things. They started doing some changes on their ERP package, and we're surprised to find that all of a sudden there were all these new integrations that they were going to have to do that they didn't expect like 26 new integration to the ERP package. And nobody knew that and it was a multi million dollar, you know, change with a multi million dollar run factor. So, you know, that's what happens when you're not doing enterprise architecture. At all. Right. And you're leading it up to a solution architect here one there. Those are the kinds of problems you're going to get. Right. I think I know exactly the retail example that you're talking about. But yes, it's great. Gentlemen, we are, we are out of time. So I'm going to, I'm going to leave it there. But again, thank you very much for your, for your thoughts today and for joining us. So again, random applause. Thank you both.