 So, we're going to have a brief presentation to start off with and then a panel session on the Open Agile Architecture Framework. So, to introduce our speaker and panellists, our speaker this morning is Frederick Lee, who is the Associate Director Corporate Technology Officer at DXC Technologies. Frederick is leading the development of DXC's new Agile Architecture Framework and has over 25 years experience with significant expertise in technology, strategy, enterprise architecture, lean, agile and digital. And after Frederick's presentation, the panellists we have, we are, their pictures are on the screen. We have Thierry Fraude, who is the Enterprise Architect for IT, a group Michelin IT. Thierry has for the last three years been working as an Enterprise Architect for the IT department at Michelin, where his main focus is to develop the long term IT technologies, articulate transformation roadmap and deploy IT capabilities to support business strategy and priorities and to support innovative thinking. Also, we have Antoine Longin, Chief Innovation Officer at Mega International. Antoine has contributed to the foundation of the HOPEX Enterprise Architecture Toolset and is also involved in standards organizations such as the Open Group and OMG. Long time contributors, welcome Antoine. We have, welcome back to Peter Haverland, Chief Technology Officer at Latitude Financial Services. Peter has almost three decades of experience spanning financial services, management, consultancy, technology and energy. He's currently CTO of Neobank Latitude Financial Services and is focused upon leading the digital and agile transformation of the company. He served as the Vice Chair of the Open Group Architecture Forum and as a member of the Open Group Governing Board. A reflection of his passion to stop solving the same problems over and over again and to help enterprises transform and grow. And also we have, last but by no means least, Paddy Fagan, who is STSM Chief Architect, Watson Care Manager Development at IBM Watson Health. Paddy is an expert in the architecture and design of enterprise business applications, working across software as a service and on-premise solutions in health services. So, welcome to all of our panelists and Frederick, I'm going to hand over to you for a few introductory slides. Thank you. So, the AF team has talked to many architects and those architects working for large enterprises who are deploying agile scale. And most of those architects said that the shift to agile impacted them. Slide two contains a small sample of the FABA teams we've heard. I think everyone can read them. The bottom line is that architects are challenged. The processes are tested as being waterfall. The technical skills are questioned and the ways of working are challenged as not agile. The net is that in that agile scale world architecture is too often neglected. So, we've gathered some evidence from the field from those large enterprises. When the agile scale succeeds, we get sometimes hundreds of other teams that run in parallel. And if the enterprise neglects the actual discipline, and I'm talking here about discipline, not the three, the traditional role of the architect, it has consequences. First, when the bodies that separate teams are not well defined, we can either have read or not work or we can have blind spots. And when that happens, it translates into missing pieces that has a bad impact on the quality of customer experience, but also on security or even safety. The second point is that when the enterprise and its system are not good enough, it results in many explicit and implicit dependencies. And that seriously slows down CICD pipeline. So the one of the main outcome of agility, which is not there, and it also causes integration problems down the road. When independently developed components do not interpret nicely, and we've seen major actual refactoring which jeopardize the economy of those transformations. The photo image on the left illustrates those integration problems. Third point, traditionally shared assets are identified by the enterprise architect in a common manner and imposed in a common and control style with actual committees and so forth. This no longer works. So we need new actual practices to drive the creation of shared assets such as France's digital platforms. And the last point though, IT strategy claims it drives alignment with the business. We see at the same time, too often, the business creating target operating models that have few if any IT involvement or inputs. So we think that a jolly scale processes are not enough. Enterprises need a new actual framework. And our group has created one, the open agile actual framework. And I'm going to introduce in a few words what it is all about. So that holistic framework breaks down the silo at separate business and IT. It's not just business IT alignment. We have also extended the scope of the classical enterprise architecture over experience design, top left, product architecture, operations architecture, and software architecture, which was traditionally in scope of enterprise architecture. We have shifted from a requirement static framework to a value driven framework. We complement iteration with set base concurrent engineering. And that extension of the scope help us target new personas. And we have developed specific value proposition for each of them. I'm not going to think of time to go through each of them. Let's say that the panelists we have assembled today are committed to the agile actual framework through the participation to workshops and all offering work. Our goal today is to start a conversation which I hope will motivate you to read the OF document and start applying the framework to guide your digital and drive transformation. Steve, I suggest we start the panel now. That's great. Frederick, thank you for the introduction. And if all the panelists are available, I can see at least a couple on video. If you can, if you're not in a good place to do that, then understood. Your answers are more important. But welcome. Welcome, gentlemen. Frederick has given us some context and some introduction to the topic. And digital transformation, agility, top of everybody's mind right now. Is digital transformation primarily or only a front-end endeavour? Let me pick on you, Pete, since I haven't been able to for a while. Steve, I was hoping I couldn't wait, mate. I was expecting it. Hello from sunny Australia. I probably don't need those though because it's in the middle of the night here. So is it a front-end only endeavour? I don't think it is anymore. I think maybe a couple of years ago, you probably saw people trying to find those terms. But really, when you looked at the work, what you were looking at was, yeah, it was a little bit like a lot of the omni-channel type projects over a couple of years ago. I think from a management point of view or a company point of view, the entire value of digital transformation these days is to actually go full stack and go into the core. In addition to that front-end layer, that's usually where the next generation of value lies. And so as a result of that, I think that's something that the framework is trying to address because there isn't a great deal of material out there that actually talks about some of these topics in this context. So we have a customer-centric design methods, approaches like domain-driven design or independent services, which might cover more of the technical side. But what we don't have is something that actually covers all of those areas in addition to the operating environment that you need as well as the implementation methodology that you need. So short answer, no. It's ridiculous. Next question. Okay, all right. Well, there you go. Thank you. Let's see. Maybe this one's for you, Thierry, as another customer organization. What do you think people talk about a bimodal operating model? In your experience, what do you think of the limits of such a model? One for the system of record and one for the system of engagement? Hi, everybody. Sorry to not enable the video, but I need to limit my bandwidth. The bimodal really is for me the practice of managing two separate modes of IT delivery. So mode one is a traditional one. I'm facing on accuracy and stability, and usually the way of working is based on a waterfall predictive approach. And the management model is more controlled in command style. And the mode two is, of course, exploratory and facing agility and speed. The way of working obviously is based on HAL and DevOps adaptive approach. And the management model is based on empowerment and leadership mindset. Usually what we see is that we recommend to start deploy the mode two, the HAL way, on a system of engagement or system of innovation, because they are the one subject to continuous flow of change and need to change rapidly. And mode one is considering more efficient for system of record, for ERPs, service delivery, for example. But for me, it's quite strange to have this kind of two separate world, because how we can ask our people to change and believe in the value of an HAL principle one day, because they are working on project on system of innovation, for example. And the next day, we have them to believe in the opposite, because they are moving to a team delivering services around ERP, for example. So for me, it doesn't really make sense. And I think we make adoption of a new way of working very difficult. Also, what I see, at least in my organization, is that systems that experience a high rate of change are not always as decoupled as we would like from system of record or for core system, if you were, and as we would like. And finally, our capacity to evolve quickly and very rapidly are limited by our ability to also to make a quick change to this system. So, like I think Pete said previously, we need to induce a digital way of working into the core of our system as well. So, at the end, I prefer to consider a multi-model delivery model, if you want, where we no longer have either agile or waterfall project, but rather agile team with different level of adoption, different maturity, of course, but sharing the same core values and the same beliefs. Right. Okay, Jerry. Anyone anything to add to that? Or I can move to the next question, if not. Okay. What lessons have you learned from architecting digital platforms? I mean, it's what everyone's trying to do. And you guys are helping your customers do that. In some cases, you're doing it for your own organizations. Any lessons learned from what you've done so far? Maybe Pete or Patty? Yeah, there are a few, Steve, and I'm just looking at the chat with one or two questions. The biggest thing, I think, which is worthy of discussion is that I think there's a much more symbiotic relationship between some of the topics here, like there are specific architecture patterns that were needed to realize some of these outcomes. In line with specific implementation approaches, which I don't hand in hand with those patterns, right? Or maybe the other way around, right? So, I mean, the idea of a monolithic solution and an agile way of working doesn't really fit. So, you start to see these requirements to actually implement this stuff. So, the biggest lesson for me is the way that the company is managing itself primarily through its financial management process is very critical to putting the operating environment in place that actually allows you to embark upon an agile implementation method. But if you don't actually know what the architecture patterns are to enable that, you're going to have issues. So, you have this kind of three-legged stool that's kind of got to be balanced in order to actually carry it forward, I think. And I just want to comment on some of the questions because some of the questions are around things like cloud, SOA, and REST and other technological patterns, which invariably facilitate one of those three leagues of the store. Right. Understood. Any other lessons learned from protecting digital platforms? So, I guess I was just going to jump in there, Steve. I think from my perspective, the other lesson really is that this is a whole organization thing, right? There's no point in setting out IT and saying, we're going to be agile without thinking about how that affects your relationship with the rest of the organization and finding a way to work together that makes sure that everybody comes on the journey with you and understands the value they get, but also the changes that are going to be exposed, right? Nobody likes change. And so, in any change in element of change management, and sometimes, and it probably doesn't suit us necessarily to say that at the IT, but to say that we own that change management piece and we're responsible for bringing that change management journey around to people and bringing them on it with us. And to me, that's the other part of it. And yes, there are lots of technology elements and technical elements, but actually sometimes it's the pieces that bring us outside of our natural areas by fatigue that are important to embrace and bring on this journey. And again, it's something we try to capture in the documents and express some of our experience and so on. Right. And there are some questions coming in from the attendees. Where can they get more information about the document? And I'll maybe one of my colleagues from the open group can dive in and give some pointers to that in the chat channel. Because obviously, as Frederick said, part of this is to inspire interest and inspire people to read the document that a lot of work has gone into. So, let me take another question from the audience. There's quite a few coming in, but this is about roles and responsibilities. What do you think the role and responsibility of EA and enterprise solution architects is in an agile software product centric delivery organization? So, enterprise and solution architects in an agile software product centric delivery organization? I'm happy to share a view. I think the role is not that different than the roles they've always played. I think they need to be the vanguard for the new ways of working. They need to be the vanguard to explain those dependencies between the different dimensions in terms of operating environment, implementation method and then architecture. Organizations invariably need a group of people who are willing to get out in front and act as mentors and guides and coaches for other parts of the organization, particularly those with less experience around agile. So, I think that's their primary role. Clearly, they still need to perform those roles within projects. So, solutions need to be architected and then multiple projects or even programs need to be supported. So, I think that's where they still play. Right. Good. Okay. Let's pick another one here. Let's see. We have kind of one that's short enough to answer. How do you think the statement of solution architecture impacts the view of business architecture? Thanks for the question. Again, I think for me, the idea that you have a solution architecture, which is fundamentally made up of autonomous, independent components, should inform your business architecture in a similar way. So, I think the idea that you're striving for autonomy and you're striving for speed through autonomy means that your business architecture should also reflect that. So, you should have capabilities within your business which do not have a lot of dependence on others and management approaches which don't require excessive amounts of cross business unit management. And in that way, what hopefully you'll have is you will have this autonomous operating environment that actually delivers the speed and the responsiveness that the enterprises are for. Right. So, on that capabilities skills topic, another question that's just come in is, how do we promote any suggestions for promoting and developing business architecture and design skills and agile architecture skills? How do we get people to listen to the fact that these are skills that organisations need? Well, it's a question, I believe, we've answered here in the Erocon Group pretty much every year since I've been involved. How do we get people to listen to us? Maybe there's another little agile or DevOps kind of drill wisdom in here, which is just to show people rather than tell them. That's probably the best approach, I think. Start small, pick a business unit and try and roll it out. It's not easy to try and tell people that you've got a better way of doing things, especially in this environment. I don't know that I've been very successful doing that. Just personally, in my career, it's usually the other way around where I try and carve out some guerrilla fashion project and do it that way. Okay. But mind you, I wouldn't want to miss an opportunity to plug another Erocon Group framework, the Erocon VA Business Architecture Framework, which is actually more concerned with exactly this. If you haven't, for those who are interested in that, I highly recommend checking that out as well. Yeah, that's right. The OBA, the Business Architecture, Open Business Architecture documents, they are all available on the Open Group website and thanks for the plug. We're nearly out of time, but let's talk about lean. People about agile digital lean practices. How does lean management facilitate agile at scale, do you think? Maybe one for you, Thierry? Yes. At least I can share with you what we have done in my company. We all know that succeeding in agile at scale transformation needs a manager leadership. Manager leadership is central to the change. And honestly, the first years, we didn't do much coaching and support for the manager. And manager was not really involved in a way. I mean, agile was seen by them as a method for developers. You see what I mean. And so to help the manager, we have equipped them with a lean management system because a lean management system as agile and developed shares the same body of knowledge. They share the same key principle, like continuous improvement, like building quality and powering people. And the lean management system has, of course, a long history. It takes its roots in Toyota production system. It comes with a large toolbox that allows manager, I think, to easily move from, I would say, concept to practice in their day-to-day management roles. And so really for us, the lean management system helps us to end costs if you want the behavior our chiefs require. And we use it as the primary method of sustaining our agile transformation in my company. Thank you. Okay. We're just about out of time, but I'm just going to take one last question. Many large companies today still follow a vision, you know, plans. Does that defeat agile architecture or does it increase the need for it? Paddy, you're smiling. Well, I obviously, given my work for a very large corporation, I guess, and I think it can defeat it. I think it can defeat it if you allow it to. But I think, you know, to me, the answer there is in sort of treating those global visions or grand plans as constraints and say, how do we achieve agility within this? Yes, this is the vision that we need to deliver. But how do we set ourselves up within that, given that constraint, to deliver in an agile way, to operate in an agile way, to evolve in an agile way? Because, again, you know, even from my own experience, the thing about these grand visions is they're not immune from change themselves. And so what you need to do is sort of deliver to that vision, because that is what you've been asked to do, but yet to retain that agility so that when the vision evolves or changes or however it's described at the point where it happens, you know, that you're set to do it. So I think, yes, that's there, but I think, you know, it just becomes one of those constraints that you encode into your process and say, you know, this is just part of us being able to do what we do. It doesn't stop us operating in this way, but we just need to be informed by it. And that to me is the way to bridge the gap between the two. That's a great, great answer. Thank you. I mean, it gets you right into the whole, you know, corporate agility versus, you know, agile development methods and all of that area, but it's a big topic. But that's a great answer. Thank you. Gentlemen, in the interest of time, we're going to have to leave it there. I'm afraid there are some other questions in the Q&A. If any of you feel so inclined to answer them, then please do. But we're going to have to move on to the next, but thank you all.