 This session will show how the OAAF, the Open Agile Architecture Framework can help architect the change journey of enterprise transformation and will throw some light on the next OAAF development iteration. So a warm welcome please for our three speakers. Thank you. Ron just talked about autonomous things and robots. During this session today, we'll talk about autonomous human beings and teams. So it will be complementary because we think that human beings and teams are also central to digital and social summation. Since the OAAF snapshot was published last July, we have collected feedbacks, identified improvement opportunities and gauged in conversation with actual forum officers. And since the OAAF contents a lot of new material, some of it being a real binding shift compared to traditional action method, we acknowledge the need to have meaningful conversation with the enterprise architect community. And we thank the executive and the staff of the Open Group to give us the opportunity to share our view on the next iteration of the OAAF. The Open Group is not alone in that broad agility market and especially an event occur on October the 2nd. So very recently, SAF, the Scale Agile Incorporated Organization, announced the new version of SAF.5.0. Though this version has not been published yet, the preview start by acknowledging that agile product delivery is not enough. You need business agility and here I am quoting the SAF preview. Since the beginning, the OAAF took enterprise agility and business agility as one of its core, let's say objective and scope. So from this standpoint, we think that there is convergence on the market. And since also SAF is starting to talk about business agility, which is quite new, we think that we will start this morning presentation also talking about business agility and sharing some thoughts with you about business agility. The second major change that SAF did was to add customer focus or centricity to their big picture. You know the SAF big picture with a lot of things, not very readable, but now you've got customer centricity at the middle of it. VF snapshot has also put customer at the center, but we talk about customer experience. And we think that it's another indication of the convergence of direction here. I will not continue to do that comparison point to point, but just say that though the SAF moves into a direction that is very aligned with the AF, it's still weak on the actual side. And we believe that it's really the sweet spot of AF to actually provide the architecture knowledge, know-how and methods to enterprise that move toward agility at scale. We will start the presentation by talking about the case study, because we realize that in order to present this new concept, you need to illustrate them with concrete examples so that case study will be in the banking domain. And we will present first how that bank operates before the agile transformation, and we will show how the bank is transforming toward business agility and agile operating models. So let's go to slide two. Yes. So the siloed organization that we present here is very similar to many of the banks' organizations with variations that we can't find. That organization does not facilitate outside in thinking, because it's really siloed oriented, and it does not also facilitate cross-functional collaboration. Therefore, the bank is slow to collect weak signals, give meaning to them, and respond rapidly to those weak signals. And the bank, when it has to change, changes through waterfall programs that focus on the run side of the bank, and those programs take a lot of time to deliver. On slide three, it's a simplified view of an information system that many banks share in terms of variation of it. In those types of systems, one change in one application impacts many more applications. It creates many dependencies, and the result is that it takes a lot of time to implement new products, new requirements, because of those dependencies. And the monolithic nature of those types of systems end up costing a lot and slow innovation a lot. So in contrast, we will define business agility, and for us, and we were inspired by a book published recently, which title is See Sooner, Faster from the MIT Press, where business agility is the ability for the enterprise, for that bank, to see sooner, so to sense what's going on in the market, what do the competitors, what client wants, and act faster. And in the example that we presented before the agile transformation, the headquarter identifies potential threats and opportunities, and it takes a lot of time to go through the other silos, because in general it's marketing that sense and to result into giving meaning to those signals, and it takes a lot of time to actually respond to those signals. In contrast, we think that agile teams that are teams of teams sometimes which are closer to the field can see earlier than others, and because they are autonomous, they can respond more rapidly. And we'll see in more detail how that agile transformation really improves the speed of sensing and the speed of acting to respond to those changing in the environment. This model requires, as we said, autonomous teams that are cross-functional, and this is what Jean-Pierre is going to present in the next slide. Yes, thank you for that. So as you can see in this slide, the business is now organized to meet the needs of market segments. You have to example the consumer market and the SME market, not this one. Tribes which regroup small teams named squad own a product family, for example consumer credit, or part of customer experience. Tribes and squads are aligned to streams of work that develop and deliver products and customer experience. These agile teams are cross-functionals to reduce friction between the traditional functional silos of the organization. All relevant competencies and skills are represented, included, of course, Haiti. Agile teams have business KPI, such as revenue growth or profitability. These teams have the freedom to make business decisions and are accountable for business results, of course. Cross-functionality is facilitated, at least by the reorganization of working space. Building floors are no longer dedicated to a function, such as marketing or Haiti. Building floors regroup all the people who are working on the same product or customer journey. Both old teams mix business and Haiti competencies. So an agile organization, reshaped teams, reshaped offices, needs collaboration tools and, of course, new ways of working. Agile ceremonies are part of this new ways of working. So an agile organization, localization and composition of teams are different, but what is the main difference is the governance. The way these autonomous teams are governed is quite different. The strategy is deployed through assigning objectives and KPIs to tribes. Tribes have the freedom and resources to be able to decide how they are going to meet their objectives. Business objectives and budgets, including Haiti budgets, are reviewed together every quarter. Unlike managing yearly budget cycles, the agile organization is able to manage quarterly budget cycles. The tribe sponsors assign objectives and target KPIs. Objectives and KPIs are covering both the change the bank and the run the bank. Agile ceremonies are used to decompose objectives, manage backlogs, assign work and allocate resources, both on the change the bank and both on the run the bank. At the end of each quarter, agile teams conduct retrospectives about sales, about projects, but more times are conducted and analyzed to improve ways of working and optimize resources allocations. The biggest shift is to combine business objectives and IT objectives, business KPIs and IT KPIs, for the same tribes and the same teams, and assign them to the tribe leaders. This slide summarizes the current situation that the semi-tribe has to improve and the objective it has been assigned. The three major problems in this example the semi-tribes need to address are improved the competitivity of its suffering and to boost sales, of course, to reduce economic and regulatory capital consumption and to fix legacy system, information system, which gets into the way of a good client experience and costs too much to run and to maintain. So in this organization cross-functional teams are accountable for both business and IT outcomes. An example of this is the objective to reduce the capital consumption. This reduction needs both a business objective, which is improving the loan product and to increase sales and an IT objective, which is to improve calculation engine about the reduction. So Fred Eric now will summarize the lessons learned from this new organization. Thank you Jean-Pierre and just for those who are not in the banking industry, SME stands for Small and Medium Enterprise. So it's a market segment within the banking industry. So now we'll talk about these attention points when the bank has deployed that model. What you are showing is a situation where the bank has only deployed a giant scale that way at the headquarter, excluding the branches and the middle offices. The attention point on the left reflects the shortcoming of these dual models and also that dissociation of design and execution, so to speak. There are some tensions on budget, commercial priorities, and also the interlock with other initiatives is less easy. For instance, leveraging loans to Small and Medium Enterprise to cross-sell cash management services to that same market segment. The key success factor on the right applied to most of the tribe we reviewed. Freedom needs to be balanced by accountability. Teams need to be small and stable. We need to have enough experience, expertise in those teams so that they can be autonomous. I will not quote all the success factor, but just to give you a sense of what good looks like. Greater agility can be achieved by extending the agile organization to the branches and the middle offices. We think that the current state is not yet ideal and though the headquarter is now agile, the field is still organized on a geographical basis. People work for branches and branches are located in various geographies. The bank is considering extending the scope of tribes and branches to branches and middle offices. So it's on the left here, instead of being separate, it would be included in the tribes. That means that in that model, geography is less important. You can have someone who is selling or supporting SMEs. It happens that they are located in one branch, but they no longer really report to the branch manager, but they report to the tribe leader. Antoine will now describe the consequences of that new organization on the operating model. Thank you, Frédéric. In the example that has been achieved in the bank project currently in progress, Jean-Pierre, you said that's not only happening to your environment, but you see this happening in many banks all over the place. It means there are some patterns of architecture which underpin this approach, which basically are the various aspects that we are trying to cover within the AAF. So at every core of it is the notion of this product intentional architecture. It adopts, you know, we have all this term customer experience. This is really adopting this outside view for building the architecture. And it's going to drive the selected business outcome that do matters for the customers and the criteria we're going to use to measure them. And this outside architecture, it shape the way the enterprise is going to be organized. This is a team-based approach. And the way it shape it is that we're going to mirror the product architecture with the notion of streamed aligned team, which is going to take into account from to back the way to deliver those business outcomes in a proper manner. So this mirroring approach is really how the intentional and operational architecture are going to be fit together. The streamed aligned team, because they cover the anti-value stream, by nature they are cross-functional. This is not a layer approach to it. If you want those product architecture, which match the customer experience to be effective, you need these streamed aligned teams. But if you only have those streamed aligned teams, you're going to lose the value of the entire enterprise and the common assets. So you must be organized to nurture the common value of the enterprise, the risk being that the streamed aligned team becomes against silos. And this is done basically in two ways. The first one is to having a notion of competencies and supporting teams. Those competencies teams, they brought the know-how of the enterprise and the various disciplines, including legal, security, and, you know what, the architecture, which is a key asset of the enterprise. It is not something that you're going to delegate at outsource. It is something you're going to nurture so that those streamed aligned teams are able to do their business properly. The other part of it is the platform teams. So if you don't want each team to reinvent the wheel, you need to factorize, you need to mutualize and help the team doing their core business while providing services that are enablers and preferably self-services so that you minimize the dependencies on the thing you rely on. The same thing if you're using the architecture team as a team where you delegate the architecture. In fact, you have dependency on that team. You don't have the knowledge within the tribe. And you wait for architects to be available to do your work. The same way the platform needs to provide services that you can use not being too much dependent on it, but leverage on it. Of course, when you have all this operating model working, you still have independent autonomous teams. And for them to make up an enterprise as a whole, you need some common way to align them towards the common goals. Jean-Pierre already mentioned the way agile governance needs to be set up, which is tribe-based with autonomy with common ways of going in the same direction, with three main items that we'll develop later, which is a common purpose, shared consensus, we'll talk about it, and as a notion of guardrail, a way to control things with overseeing without being too much prescriptive. Of course, with all this, it doesn't make architecture static. So it's going to be a continuous architecture activity that move from that intentional architecture to operation on the grounds, getting the feedbacks. But because you're tribe-oriented or stream-aligned team, the signal from the market, the connection to customer experience is going to be better. So lower signal are going to be heard earlier. The way to react is going to be done easily because you have the shared understanding on how to react and you have the direct connection to the solution you're going to provide with continuous delivery. This means that the role of architecture is key in maintaining those various aspects. So if you have team leaders in charge of both the design of the run and the running itself, architects need to be close to this new leadership. They need to be friends of the team leaders so that this design and running can go smoothly within the organization. So where does it come from, all this? This kind of breakthrough of the way we were doing traditional architecture. And I think most of you are aware of the thing called the Conway's Law, aren't you? Let me study it again. Any organization that designs a system will produce a design whose structure is a copy of the organization communication structure. So there is a very tight connection between the thing, the design, and the architecture of this thing being produced. This is the idea of connecting together the design of the run and the run. And Mark Cormac has demonstrated that loosely coupled organization developed much more modular design than tightly coupled organization. If you have a global team that work together, the tendency is to say, we share. So we don't API's ourselves, I would say, in a kind of brutal manner. So if you want autonomy, you need that kind of communication that will need to formalize the relationship between the teams and between the systems they conduct. So this is why this is what they call a team-first architecture. And to do it, they apply what they call the Reverse Conway Manoeuvre, where instead of thinking of the architecture in isolation, you go in to first shape the enterprise organization in a way that mirror, as we said, the product intention of architecture and the organization of the company. Is it moving? So of course, the key aspect, this is kind of my mantra, I would say, or preferred topic. The trick of architecture is to create boundaries. Life is a continuum. You wake in the morning, you do things, at the end, you've done some work, but what is the aim of it? In processes, you have the notion of operation, action, and you need to put boundaries between processes. The trouble is all those boundaries are somewhat artificial. It's because you need to decompose things. You can't handle the whole world at once. And the more systems become complex, the more you need to decompose. And modularity is here to help us create those autonomous paths that we can manage. So in a way that we minimize dependencies, it is if I change something, I don't want everything to be changed, because I was working at the search life scale that I don't have created those boundaries. Life is like this. Sales create boundaries. Then you have organism, then you have society. So we all work in architecture by doing modules. Now we need some criteria how to do this modularization. And we've seen three of them. I'm going to three more than three of them. The one is the journey, the sub-journey, the business outcomes that we got from the product architecture instead of the beginning. Another criteria, as we've seen, is the value stream, which is going to provide us the scope, the front-to-back scope that make up the boundary of the team. And the third one, which is another topic we have in the agile architecture framework, is a single domain-driven design. The domain of activities, in terms of resource being managed, activities being performed in a manner that you can split them and provide those results with some kind of, again, some kind of interaction API that provides the proper dependence between the module. When you've got that split, of course, you minimize the dependencies, but you can't help having dependencies otherwise, again, you recreate silos. The goal is to manage those dependencies in such a way that they become non-blocking. So what do we mean by non-blocking? We mean that they don't go out of the scope of the team which has the dependencies. So first they need to be identified, then they need to be owned, and then, of course, if you don't have control over them, like you have some resource of some architects you rely on, but they're not available. You don't have the skill of architecture, you have no autonomy, so what do you do? Wait, this is a blocking dependency. So you must organize the dependencies so that they are non-blocking, and one clear way to do it is to provide self-servicing. I can't provision the resource myself. I know it, I've been taught how to do it. It's provided by another team, but I can't exercise it myself. So as we've seen, now we need the alignment part. You know how to run, you know how to decompose, you know how to manage dependencies. How can we do to become together? So Jean-Pierre mentioned some mechanism to do the agile governance, and I want to note three other items here. The first one is a shared purpose. Of course, you need a shared vision. You know where to go. This notion of purpose, the reason that of your organization, the reason that of the system, is what makes you happy and what makes you understand what you're doing. Of course, to do this, you need some kind of awareness. If the understanding of where you want to go is only split by team, there's no way you're going to come together. So as General Mac Stanley said, this global awareness is having a global, the holistic viewpoint of your organization. It's not something you need to hide. You're not going to hide information for power. You're going to share it for the global understanding. It doesn't mean you need to be a generous team. You need to know everything. You need to know where you go together. This is a mantra, think globally, act locally. And the last thing you need to have is that kind of how you make things happen in a kind of rigorous manner that you go all together in the same direction. Do you do control, procedure, going in each room and checking that the work is done? That's a traditional command and control. You provide those notions of guardrail, force function, which provide you guidance, which empower people by providing rules, guidance. You know that well, architecture principles, this is beyond architecture principles. All the things that rule the way you're going to go together. So now that we've summarized the various pieces of architecture landscape, Frederic is going to tell us how it applies to the IT departments. Do we still have IT departments? Just because Antoine talked about platform in one of the previous slides, I'd just like to share with the group that Christophe Klein from BNPP and myself will do a presentation tomorrow afternoon that will focus on that aspect, platform and especially renewable digital platforms. But coming back to, which is part of information technology, coming back to information technology, you remember we said tribes own variety. Does it mean that the central IT department disappears? No. It's only the capability that are critical to the success of the tribes that move under the control of the tribes. There is still room for a central IT organization for, for instance, operating the infrastructure for also legal and investor obligations and also shared capabilities. The other aspect will be that refactoring, that modernization that Antoine presented as so important. So we'll move now quickly. I just want to introduce an approach that actually you can read in the EF snapshot around how to handle the legacy system. But the idea is that in the head of SOA people believe that just creating APIs on top of legacy monotech system was going to make the system agile. And actually that's all true because those APIs do not shield from knowing the internals, which means that you've got abstraction leak meaning that the consumer of the API need to understand too much of the implementation behind the API which creates further coupling. So that's why SOA actually resulted in higher coupling as before, though it was not the OCEAN intention. So what is important is the number three is to start modularizing the system. So you start to do it at cost-grain level. You create a separate sub-system. You connect them through APIs or events. And then you can start implementing yet finer-grained services called microservices that will redevelop the functionality of a sub-system. And that's number four in a way that will be much more moderate in agility. And at the end of the day when you've done that for a sub-system you can decommission that part of the sub-system and that's called the stronger pattern and at the end of the day you get rid of the old system described in the AF snapshot. Second thing, in terms of changing the way you look at the world instead of looking at architecture as layered business information system technology, you take the business domain and you start modularizing the system based on the business domain. I will not go for the sake of time in more detail in presenting the concept that helped do that. It's the strategic pattern of domain-driven design. For those who are interested you can find that material in the AF snapshot. Let's say that the ideas that you directly implement your business ideas in your software systems. So there is a much direct connection between business to speak and software. So as we've seen during all the presentation all that requires a lot of change and succeeding that change is really a profession Yes, thank you for effectively transforming an organization, a neutral organization is a change management stake. So it's not big bang, it's in three stages. Successful seeders follow three stages. The first stage is to build a strong coalition assembling an executive team and this team must collaborate effectively. It's not a question of a sponsor, it's a matter of a coalition of sponsors and this sponsor must create a real team. This coalition needs to have a non-preneurship mindset and to have some architecture skills of course you see to design the rights, the rights drives with the right ITM. The second stage is this coalition has to identify and to mobilize the right middle management pioneers. These pioneers will be the first tribe leaders about the most important business goals and the most important IT pain points. The third stage is to create, to shape squad agile teams and to provide support when needed by these teams. In this organization agile teams are free to engage honest conversation with executive sponsor with the coalition and can share with them issues and particularly innovation ideas. So agile transformation truly requires a change in management style moving to from command and control to a servant leadership with architecture skills. It's the beginning of the conclusion. In terms of conclusion we created that slide with free key messages and we think that those messages you can read them understand them easily because it really summarizes the idea that we have developed but please take a few minutes reading them to think about the questions that you'd like to ask so we can move directly to the question part because I see the time is running fast and thank you very much for listening to us. Thank you gentlemen. Let's we've had some questions coming in but it's not too late. You're going to need you're going to need this I'll go over here probably the best way probably the best way of doing this so anyway we do have some questions come in do you see the role of solution architects becoming more engineering focused working closely with DevOps delivering within the boundaries provided by enterprise architects so will solution architects become more engineering focused? I think one of the difficulties transitioning toward that new way of architecting is that the same words may have different meanings. When I hear solution architect I hear an architect that creates a sort of IT solution that embeds processes and business but mostly an IT solution during our all presentation we didn't talk about IT solutions we talked about architecting the agile enterprise so I'm not sure what the solution architect will do in the future but I think we have clarity about what architect needs to do to really help the enterprise become agile and digital but solution engineering as a cross architecture is absolutely key for those teams to be from to end they really need to have solution engineering and architects are the vector of it so of course they need to know the technologies they do said base engineering they know concurrent engineering that kind of skill is absolutely key for architecture to be a powerful discipline here. Thank you, we'll move to the next question probably one mostly for Jean Pierre what is the time scale that you had or expect on your journey and where are you at this point? It begins two years ago it's from my experience in a very long way what is important is in two years to to onboard the most important business tribe about the most important objectives and most pain points IT states and I think that between four or five years you will be able to transform a traditional bank legacy system to a new one and to a new organization Thank you Do you have something to add, Frédéric? or next question Just to say that what Jean Pierre is presenting when we look at other banks that are doing the same thing we are about the same type of time frames Thank you Is the fully agile operating model the death of intentional architecture emerging architecture seems to be becoming more and more common I would not say that remember the diagram that Antoine presented the first input was that intentional architecture because if you don't have an intentional architecture there is no way you can define the boundaries of your agile teams especially the teams of teams that are the tribes but that intentional architecture is there to be challenge and is evolving so it evolves through those iterations to an imagined architecture but both are necessary I could add, I wish I missed the fact that those teams they also start from small teams like the squad and they can move to teams of teams which is provided by the open group they explain how this emergence happening when you move from squad to team of teams and the relationship between the intentional and emergent architecture and you move from team where you hold everything to distributed teams and the emergence is going to roll out in different manner so yes look at the DP book for that also Thank you Antoine, you beat me to it I was going to say that it took my line, thank you How do you manage the life cycle management of the platform or architecture across the various silos and how does this work for a domain driven, model driven approach Actually, we will cover tomorrow afternoon with Christophe Claire from BNPP that topic but let's say that the key is to create non-blocking relationship between the platform teams being infrastructure platform and the consumer of those platforms and one example of non-blocking is the development of self-service If you provide self-service to development teams they don't have to wait anymore for the infrastructure and upstream to get the resources they need to deliver the product and therefore you've got a loose coupling between the platform team and the consumer of those platforms and DDD can be applied both on the business domain to create loosely coupled applications but it can be also applied to the infrastructure domains to architect the platforms themselves in a modular manner The key difference is that for the platform the domain concept will be more technology concepts as in the application it will be business concepts We're running out of time but I'll try this one quickly Is there a danger that decentralized tribal IT gets too big or it doesn't have enough competence due to its size We had a seminar also in France about what was not working in Agile and it was exactly the problem that was faced the lack of common assets managed by architects and nurtured by architects which led to poor efficiency finally So of course if you dust all the tribes in isolation they will become silo again and of course an organization is beyond those streamlined teams all the culture and you must have it running so you must allocate part of your budget to nurture those common culture for sure and this is why we mention about safe and so on they have a lot of things about it but a good understanding on how to nurture this is a key role of us architects and safe if you look at it and maybe they will fix fact in the new version 5.0 but they don't talk about the platform they don't explain how to articulate platform teams versus streamlined teams So that's just an example of the actual weaknesses of safe and that's exactly where we think that there is a sweet spot for the year Gentlemen in the interest of letting people go to the break we'll leave it there but thank you Jean-Pierre Le Cam, Antoine Longin and Frédéric Lee Thank you very much, gents