 Brian Layle, who is a business tech fellow at Raytheon Technologies. Brian's the business transformation lead for digital technologies in the missiles and defense business at Raytheon, where the focus on co-leading strategic business initiatives with partners across multiple locations. He's a Raytheon certified architect, certified business architect with the business architecture guild, and has published multiple guides and papers in those domains. He's also been a great contributor inside the open group on the topic of business architecture mainly. In this session, Brian's going to give us an update on some of the business architecture guides and best practices added to the TOGAF ecosystem, and then work through a case study. Case study is what everybody's interested in, of course. Brian's going to work through a case study based on a real successful practice on how to drive business value into resulting cross-functional solutions. So, a virtual welcome from the open group, please to Brian Layle. Over to you, Brian. Thank you, Steve. I think we're sharing, coming across mine. So, thank you for the great introduction, Steve. What I want to take you through, as Steve described, really comes back to being able to take enterprise architecture to a strategic level and using some of the methods and tools that are now built into the architecture framework and the open group architecture forum. I'll provide those to you and then take you through that case study. So, I'll start with context that business architecture, of course, is and always has been a phase in the ADM, but can also be used and applied in a way using the same tools and methods to lift enterprise architecture to a strategic level of impact. And that's what we'll talk about today. Let me go ahead and progress. So, let's start with a quick reminder on some of the guides and methods that are now built into Togaf itself, including the new release. When that comes, you'll see a lot more instruction on how to use business architecture methods within the architecture development methodology and then the linkage to these guides that we'll talk about here. Let's start in the center. All of the pieces are there to leverage business architecture for a strategic tool and method to lift up your enterprise architecture to the next level. That starts with these core concepts of value, capability, organization, and information that, as you can see here in the general descriptions. These are about the basic constructs and elements that one should understand about the business needs and the business context before then driving down to solutions where, of course, solutions can and often are a mix of roles and processes, information, and technologies. We've also provided a set of guides that are now part of the Togaf ecosystem. I'll start with business models up here. Business models are not themselves inherently part of the business architecture. They're really a construct that is part of the formulation of the strategy on how your business organization intends to deliver value, but it's an important tool for the business architect and the enterprise architect understanding business needs and strategic drivers. Then with that, there are now a set of published guides. The update, the business capability guides, is due to come out very soon, but the original guide is there. Then open group series guides on value streams, organization maps, and information maps are now part of your tool set. What I want to do now is go further and talk about how we're going to leverage some of these methods and tools for something beyond just a project level in your enterprise architecture. We'll start some of that contact here right at an area that's of very much interest to a lot of attendees today, and that is agile practices. Although I'm going to go on after this and not put it all in the context of Agile, let me start by saying that if you look over here about what skilled Agile is after, being able to understand business strategies and in value perspectives, value propositions at a lean portfolio management level, and then being able to drill that down into a very rapid cycle of learning and development to turn that understanding of the business and strategy into focused investments that are developed rapidly, demonstrated rapidly, and then evolved as you learn. The really business architecture helps in that in a number of ways. Making sure that it's understood what the value proposition is, the capabilities that are desired, which information is impacted, which elements of an organization are impacted before then launching into a very effective Agile development cycle. So as you probably all know or are aware, the Togaf wheel over here is agnostic. It does not prescribe a development methodology. And as such, this can be certainly applied and practiced in an agile manner. The key that I'll bring you back to and show you a case study on an example of is that in addition to business architecture being a phase of the development methodology and enable or two agile practices, you can pick up the methods and tools that are now provided in part of the Togaf ecosystem and you can apply them in a way that really helps understand this portfolio management level of your agile practices and really makes them much more strategic and impactful beyond just being a phase once you're in a specific single project and applying those methods just within the scope of that project. So let's go forward next into that. So first of all, let's start with that second example I gave. Let's say you are now at the level where you're implementing a project. You are fairly well defined. You've got all the strategy understanding. You've got the leadership buy-in to your top value streams and you're really just down in your implementing. You're in a project whether it's following agile practices or other practices. What you might call the operational view of value streams focusing on that context for a moment gives you some very important constructs that are inherent to understanding your business or your agency that help understand how you're going to deliver value and who that value is delivered to and what some of your most important buy-in streams are. So you have that context to ensure that anything you are providing solutions for or developing is inherently responding to and providing that value because the value is in the eye of the stakeholder not of the developer. And so some of those operational value streams are things like acquire material, manufacture product, report financials. Some of these apply to some businesses and agencies and some may not. But you want to start to build up an understanding of those core value streams and then how those then drive your capabilities that are developed that are mapped to Boyd. I'm going to look at an example of that here in a bit. But notice a lot of these operational value streams if you're specifically helping to improve a system that is for your supply chain to more efficiently or rapidly acquire material or going to do something with higher quality to manufacture products where you're going to report financials in a more timely manner and you're going to develop systems that help support that. These are already at the level of, hey, I know I'm in that part of the business. That's what I'm going to improve. And I want to measure value for whatever I develop, whether it be technologies, information flow, new processes that help improve that value. They are about specific context parts of the business. Some value streams can be about a broader view of business like see optimized investments here. This now reaches across a number of different elements of a business or agency. But it is still about one discipline. This is about optimized investments. It's about your financials, even though it reaches across many different areas of your organization. So what I'm going to do is show you how to apply value streams at a bigger level, at a more strategic level. So let's start here with some key principles that you want your value streams to follow. And here's where you'll see, even though there's a lot of synergy between agile practices and the business architecture discipline, sometimes there is a little bit of difference in meaning of what value streams are meant to mean and what they apply to. So I'm going to go through some principles here that you'll see a lot of these in the open group series guide to value streams. Sorry, Brian, John here. Can I just need to cut in? I think we're moving the slides for you. You need to move the slides yourself. You'll have that ability if you can click on the arrows to the left and right of the slide. Okay. Sorry about that. Let me share screen again. You shouldn't need to share the screen. You will, you have control of the slide deck. You just have to click on the arrows to the side of the slides and you'll be able to move the slides. Okay. All right. Give me just a second. I apologize. We didn't, okay, got it now. All right. So I'm going to go to value stream principles and changes. Thank you. All right. So some key principles. Value streams are value centric and that, of course, should probably be true, but there are value streams that show a path to a completely new type of value. I'm going to give you an example of that. So there's those operational or elemental value streams that are about key subjects that your business or your agency does to deliver value, but you can also use them as a way to, at a strategic level, find whole new ways of delivering value for your organization and enterprise architecture is a very important part of that. They provide a business centric representation of how stakeholders drive value. In other words, they are a pure business representation. They're not about how you've operationalized or implemented your processes, your tools, and your roles, and your technologies. So that can include a portfolio level view. They represent an aggregation of views, and they deliver a crew value in the form of value items, and those value items can again be at this portfolio level that very compatible with skilled agile practices. You can start to understand how to use enterprise architecture at a level that delivers strategic value to your portfolio, and that's what we'll go into next as an example. Let me make sure I deliver advanced slides in the right way. All right. So to give a little context, the example that I'm going to use is what is called sales and operations planning. So a quick one-minute intro to that context before we go further into the business architecture aspects and the strategy aspects is it's basically a portfolio level view of decision making to aggregate market demand across your product areas, view the impact on limited supply resources, and then develop scenarios to optimize and balance demand and supply, the demand against all of the resources of your business, your agency, and develop an optimized plan. So it goes through these cycles of aggregating the demand, aggregating the supply, reconciling those two, and then a top management review very importantly delivers one plan for your business, your agency to say, for the next cycle, often a monthly cycle, here is the plan of where resources will be allocated against that demand. So we optimize whatever it is we're trying to optimize. If you are a profit-making company, maybe trying to optimize profit, but the value may be focused on the customer or your end consumers. So with that, let's go ahead and dive into this specific example. So now I want to apply these business architecture tools that can be used at a strategic level for this context. So this is now viewing that same sales and operations planning construct in a value stream form. In this particular case, it may be your executives, your leadership that runs your business functions, as in supply chain, manufacturing, engineering, those kinds of elements of your organization. And what the value you're providing to them is the ability to forecast the segregate demand, plan supply resources across the portfolio, generate these scenarios and then drive one business plan. And what that might do is provide the value of enhancing total profitability. Along the way, there's certain other views of this value stream that because you're optimizing your resources, you can also be more effective for your customer or your consumers, more efficient, providing them a better product at a lower price, and so forth. Against these stages of the value stream, once you understand who you're providing the value to and what that value is, you can then start to measure capabilities, your ability to be able to provide that value as a business, and then start to do a heat assessment, a heat mapping or color code that says if that's the value we're trying to provide through these stages or sets of activities, then where are we currently have gaps in the ability to do that? And you might, for example, come up that business planning and customer management are to your capability areas where you then need to be able to provide significant new capabilities to be able to deliver this value. So in this case, the new value is achieved by looking across your product portfolio and a view that goes across your business functions. Why do I say that? Because this value stream is not just in your supply chain or just in your manufacturing or just in your engineering or just in your finance. It is across all of those capabilities and parts of your organization. So getting this right and be able to deliver this value right, understanding these capability gaps, and then being able to fill those with the optimized combination of tools, information, technologies, roles and processes, then can deliver a whole new kind of value to your business or your agency. And so then those capability gaps to do that must be addressed through the synchronized management practices, information or technology. With that, we'll go ahead and dig a little deeper. That strategic view of how to deliver a new kind of value to your business, not just optimizing something that already exists like your product development or supply chain or customer management for those particular areas of your business, but coming up at the level, the same level that Scaled Agile talks to, and being able to optimize at a more portfolio level. That set of practices in that context tied to sales and operations planning then has evolved into a more integrated business planning viewpoint. In other words, the practice itself that has been applied across many industries has evolved into a bigger strategic impact called integrated business planning. That integrated business planning, to continue this case study, lives between your strategic planning for your business or your agency and above the annual planning. This is also where strategic use of business architecture fits. This is why it's a good example and something that I'm able to provide, having seen the success of this in my own company. And so what happens here is the value of business architecture can be focused also on the path of digital transformation. In other words, one of the things that I've seen with this more strategic view and use of business architecture as part of your enterprise architecture practice and applying it up here at the portfolio level is I've seen examples where we've been able to go from a lot of what you hear in technology these days about digital form of dollars. And I've been able to see something to me that's even more powerful, which is turning your data into dollars. So in other words, you can start to optimize the use of your information at a strategic level and say, hey, we can find new ways of generating value and new ways of generating by having this strategic level context of applying our enterprise architecture practices. We can find new ways for us to be able to deliver value and become more efficient and more profitable as a company. And I want to end this set of notes with some context about the relationship between business architecture and business forecasting. Because you'll find as you start to apply these methods and tools up here at this more strategic level and understand how enterprise architecture can become a discriminator for your business here agency, you start to also look further ahead. You start to be more forecasting. You start to say what's coming down the road and using your enterprise architecture practices as part of that ability to be more proactive and act early. And so that includes what I have seen where some of your business architecture artifacts, such as capabilities to develop product, manage material, manufacture product, and forecast financials. Those are both the activities that deliver value and they relate to capabilities. You start to evolve from an understanding of develop product as a value to be able to develop optimal products. Because you, again, you've brought your business understanding through business architecture up to this strategic level. So across your whole portfolio, how you develop optimal products, how do you order material early so that you are looking across everything your business does, all the capabilities it has, all the products or services you might provide, and be able to optimize your build order material already to satisfy your customers and stay on time. Leveraging common platforms on your product development and then forecasting realistic financials, not just having a financial forecast. So this is where we've seen some success of enterprise architecture practices in this more strategic path. So I'm going to do my second to last slide with a mention of a couple of ways we've applied some of these findings, just as ideas that you might be able to leverage. And then we'll end with a reminder of where to find some of these resources within the TOGAP ecosystem. So one tool that I have found useful is after going through all of these methods and methods and guides that we've talked about that are now part of the open group, such as business models to characterize and crystallize how your business strategy is going to lead to delivering value and who that value is going to. And then as an architect, being able to understand the key value streams that are in the context of your particular initiative or sometimes particular project, understand how that maps to business capabilities, where that relates to and is acted on by elements of your organization, what information map is required to be able to deliver those capabilities. That whole context, once you have it mapped out, you can do something very powerful. You can start to put a quick visual of those artifacts on one page, literally like this page, but with your particular artifacts. And with that understanding, one of the things you've done is not just captured the artifacts, you've trained your mind, you've trained your mind as the enterprise architecture lead or as the business architecture lead on an EA effort. And you've trained your mind to be able to understand and be able to show executives or other leaders or other key stakeholders the flow through all of these elements in one view of how business strategy has been crystallized through a model that then informs gaps in your capabilities and focuses value delivery, how that value delivery is going to be enabled through key capabilities, what elements of your organization that maps to and what key information concepts are required and understand that context before then going into the solution level where you talk about roles, data, processes, technologies. And that's where your agile practices really start to kick in and give you rapid capabilities. But understanding this context, that can be invaluable. This can be your, as you might have heard the term, your elevator speech, where if you only have five minutes to convince a leader, you put up this map, you walk through it, and then they believe you about why you should go down a certain road and what you're going to do to then solve that problem. So those relationships and mapping provide the elevator speech for leadership alignment on practices such as scaled agile portfolio management priorities. So with that to leave plenty of time for questions, I am going to end with a reminder of where you find some of these methods and resources. Everything I just talked about are now our TOGAP series guides. You see the list here, and when you get a copy of this brief, this is a link to provide you the go to the library and then be able to pull up each one of these sets of methods and tools that are also then brought out in TOGAP itself about where to apply them and how to apply them to then go to the guides. So with that, I will stop for questions. Brian, thank you very much. I'm trying to get back up there, but people don't really need to see me. It's more important they need to see you, but thank you for that overview and thank you for all your contributions over the years. So first question, you showed us a slide a few slides ago now where you were talking about mapping your capabilities. That's the one, the traffic light slide, I would call it. So the question was, what happens when I do that and it's all red? How do I start? Well, excellent question and I appreciate what was underlying the question, which obviously that question meant the person asking it realized that it's important to do this mapping from the value perspective and then into the capabilities. But let me also give a warning. If you're mapping, first of all, you map your value stream stages and the value in stakeholders in that particular stage and then determine which business capabilities are critical for delivering that value with those stakeholders. And so it's usually a much longer list than this, of course. This is just for example. So you do the mapping first without colors and then you add the colors. So I would state that if you start finding these are all red, once you've done that mapping, you say you have five or six capabilities. I think you're probably calling them red for reasons other than delivering this value. In other words, often it's tempting to come from a bottom up and say, hey, I know that these tools could work better. They're providing information technology management or financial management to support that stage. I've been in the business for decades. I've seen all the problems. So I'm going to call it red because there's so much we can fix. And that's not allowed. What I just described is not OK in terms of how you color code or heat map these capabilities. What makes this yellow is a gap in a build it over this value and this value only to these stakeholders. Right. Thank you. Thank you. And next question. Let's see. We just started mapping capabilities based on market models. How do we deliver the one page elevator pitch to get the sponsorship and interest from the exact team to let the enterprise architects do this process? Well, let me answer part of that question first from what worked for us. I don't know that I've ever run into a situation even though we've had many successes at applying enterprise architecture at a strategic level following these kinds of methods and tools. I would say those successes have never started by convincing the whole executive team. They basically always started because we were able to convince an executive on the team and then build from there. Now, don't get me wrong. After we've gotten going, I've certainly had many situations in my role where I then do present to the whole executive team. But I don't generally present to the whole executive team with this kind of construct, with this one pager. That's more like getting in the door. By the time I'm presenting an approach to the whole executive team, we're already then applying the business architecture, the enterprise architecture context and showing you how to solve the problem. But based on a solid understanding of here's the business problem we're solving, and here's why that's the right business problem to solve. So I would say the other part of the question is then based on that assessment, it just comes back to what is probably already obvious, speaking in business terms, not speaking in architect terms, not speaking in information technology terms, or any of those, but what is the business value? What are the capabilities of the business, which is not IT capabilities? These are business capabilities, showing how to show the linkage to value, and if you're speaking in that context and therefore you're really sure you're solving a real business problem, that only some waiters agree is a business problem, then you can usually get through to an executive and then build from there. Right, thank you. That terminology point is so important, speak the language of the people that need to understand what it is that you're trying to do. Thank you for that. Question on agility, kind of almost where you started. How can agility be applied to strategic business architecture? That's interesting. Yeah, so maybe certainly agile practices can and are valuable to apply correctly in any areas and that can include business architecture itself. So let me agree and validate the premise. I would be a little careful though in that just as the whole TOGAF wheel teaches us where there's no prescribed link at the time, you're not going to find something in TOGAF that says you must spend two days in phase A and then two weeks in phase B and then two months in phase C. You're not going to find that because there's nothing wrong with following iterations and cycling through the whole wheel very quickly and then coming back and doing it a more stately and comprehensive pace. I would say the same applies to the use of business architecture at a strategic level up at your lean portfolio management levels of scaled agile. Certainly it's completely fair to set a fairly rapid time frame to cycle through, but if the context is how can you make sure to time box it and get through the business architecture rapidly so you can then get on to development. I have to be honest, I don't really agree with that mindset. If you haven't really captured what business architecture can help you capture at the strategy level of your agile practices, then I don't think you have any business doing development. Thank you, Brian. So just time for one more question. Excellent presentation. How often do you suggest one should revisit the solution concept or the one pager and also how often do you revisit the business architecture? So the context I was playing here and I'm very glad some of the key message came across. When you're really working at this more strategic level, you tend to be talking about fairly big initiatives, even though you're doing agile development once you understand the solution space and how that responds to the business needs through this kind of mapping. And then you may be doing agile development or rapid development or chunks of capabilities. If you're really executing against a broader value stream construct that your leadership is bought into, that whole context, that sustained team that is managing at a portfolio level to deliver multiple releases or release trains for your efforts is probably going to go on for quite a while. That's part of the benefit to having agile portfolio management is a sustained team that's focused on a value stream construct. So you probably are iterating fairly rapidly in terms of delivering the solutions in the context of that strategic understanding to deliver a whole new set of capabilities at a portfolio level. But that value stream itself, that portfolio construct is probably going to last for at least a year or two in your cycle. If you're instead down at an individual project level, then of course you want to be iterating on this whole cycle of understanding the business need and then how the solution is headed right direction in a much more rapid cycle. Thank you, Brian. We do have at least a couple more questions I can see in the Q&A. If you get the opportunity to have a shot at answering those, we'd appreciate it. But we have to move on to the next speaker now. So thank you once again, Brian, a big virtual round of applause for Brian Lail. Great job as usual, Brian. Thank you. Thank you.