 Good afternoon, good evening, and good morning. I think just the panelists ourselves cover all of those time zones. And it's been really great to be able to talk to all of you. Stephen and I are going to be tag teaming this. I'm going to be taking the first section, and he's going to take the second one. But I think you'll find that we're going to collaborate during each content of the slides as we go. And I do welcome you to try and put questions in. If there are questions that we see, we'll address them while we're actually presenting. And we will also look at questions at the end of the presentation. Stephen, did you want to say hi to yourself, just to do an audio check, something else? Sure. And yes, I'm the good morning part of the session here. So good day, Alec. And let's get on and share our learnings from the Business Capability Guide. Absolutely. This is, you know, it was quite a journey to get here. And what we want you to get out of this presentation is exactly what do we mean by the term business capability. I think there's a reasonable amount of consistency, but there's a lot of confusion at times as well. And the intent of this guide and what I hope you get out of this presentation is a better level of precision on what we mean by business capabilities. And hopefully, as you see the examples that we're looking in, that you can see why business capabilities are such an essential part of enterprise and business architecture. And then we're going to go through a few examples of how we develop and use them in practice. And as Sonia mentioned, there's only so much we're covering in the narrow scope of actually business capabilities and creating business capability models. In future guides that we're planning already, we're going to go into specific more detail about how we would use business capabilities within our business architecture practice. I think it's really important to remember here that above all else the identification and use of business capabilities is a means to an end. And that end is to help business leaders and planners get a better understanding or a more collective and coherent understanding across the business of what the business actually does and what it needs to do. And therefore provide them with the visibility and the insight required to help people make better business decisions. Absolutely. Defining a business capability is an art of abstraction. We're trying to create some very high level enduring constructs so that are not going to change for very long. And so we're going to go through a mechanism and process here to try and help you do that by starting by defining an actual business capability. You can see the definition here. We're starting with a definition for business capability that's been around for almost a decade now or over a decade now. And the reason mostly for that is because it's been established for a long time and many people including Business Architecture Guild and many other people are using this as the definition. And so it's important to note that the business capability is what the business does. It's not how it does it. It's not why we're doing it or it's not where in the organization that that capability is realized. I think where we find, for example, one of the biggest things is what about business function and within the open group, the business function is stated as the capability that is closely aligned to a particular business organization. And so that is a specific mapping of a business capability to an organization when it's used in a business function. And we're also finding a lot. Yep, sorry. I was thinking that this distinction between the what versus the how is really important. And understanding that distinction will help us avoid getting caught in the trap of discussing down in the depth detail about current processes and operations. Really ensuring that architects can maintain a view of the business at a sufficiently abstract level to help clearly identify where gaps are occurring, where overlaps and redundancies exist today. And where to prioritize investments, change efforts to achieve tomorrow's vision. So we really wanted to stress the distinctions here between what it is, what it isn't. Readers and users of TOGF may be wondering about the need for this new concept of business capabilities in the first place because it's not explicitly included as part of the current meta model within TOGF. But as Alex stated, rather there is this concept of function, which in itself describes a unit of business capability. But as mentioned earlier, the practical application of business and enterprise architecture is where things start to get a little bit confusing since function is more commonly described in an organization or a business unit setting, being a process or an operation that the organization performs on a regular basis as part of its day-to-day activities. So that's quite different from business capability, as we'll see as we go forward in the webinar, which just deliberately separates itself from the organizational structure and the process charts in order not to constrain thinking about what could be or what needs to be. So when we go to, I'm hoping the description itself will help you better understand it, right? So first off, this always seems to be the more interesting aspect of creating your business capabilities is actually coming up with a name that everybody can agree on. Most of the time you want them to be as clear as possible, it shouldn't require necessarily a definition for you to be able to understand what the business capability is. But we do recommend that you have a description or a definition depending on how precise you want to be. But the real key here is to make sure that it's, that it's very easy to understand and it's not, we shouldn't be writing a novel here. And so our example here, I realize our slide doesn't actually have, is around recruitment management, is the name. And I think for most of us, we've probably been on one side or both sides of the recruiting process. And we've created a definition here, a description here says that recruitment management is the ability to solicit, qualify, and provide support for hiring new employees into the organization, right? So that's the kind of level of detail that we want to get to when we're describing a capability or in defining a capability. And there's some usually a noun-verb combination there. But we're looking because it's what we do and how we do it, it should be more of a noun aspect of it than an action-oriented word. And Stephen, you've probably got a few more words of guidance on that topic. Yeah, I think that when you start capability mapping, you're going to be really challenged to find terms that are clear and concise enough that those terms can resonate with and be easily understood by the business stakeholders and which aren't ambiguous enough that they might mean one thing to one person and something else in a completely different part of the company. So there will be lots of tooling and throwing and iteration to go through as you just develop the first set of names and descriptions. So the important thing is really to be patient with this and use it as an opportunity to start building a dialogue with the decision-makers who will ultimately need to own the capability model. Absolutely. And the guidance that's been put in the chat window and the guidance that we also put in the guide itself is if you should be able to start with the definition or the rule where the organization has the ability to do X, right? So capability components is another aspect that we've added to the capability guide where we're suggesting is capability is usually a combination of people or roles, processes, some information and tools that together are able to deliver the what of a particular capability, right? And this is done to also help make sure that we don't fall into the trap of possibly identifying what would be a capability component as an actual capability, right? So if we look at the slides here, and I know this might be difficult to see, but in our recruitment management we have some roles of people who would have some activities to do in this, right? We've got the recruiter in this situation, a manager who's trying to hire somebody, and a candidate or candidates themselves. And you can see that there's going to be some processes that are within that capability that are executed and some actual information that is usually contained within the capability itself. And some tools in this situation, we've listed largely only information technology applications as tools, but tools can be almost anything. You want them to be whether that's an actual building, whether that's any other tool that you need to be able to do it. But all of these things, even though you may have a role that is used in another capability, we are thinking of this in the context of an abstracted container called a capability. So all these things should be within the scope of the recruitment management capability. So in actual practice, I find that it's less important that you spend a lot of time trying to get a complete, fully documented table, as we've shown in the example here. It's less important trying to get this table 100% accurate and 100% complete. Rather, it's the process of going through this exercise that's most valuable because it'll help you refine the name and the definition of the capability itself, check whether it's actually needed at all at the same level, perhaps, as other capabilities you've identified, or if it needs to be further decomposed into more detailed descriptions or broken up into child capabilities. So it's more the process that you go through in defining each of these components rather than coming up with a completed spreadsheet or table that you're going to be using in the future. Yeah, I would say the same thing. We usually use this in the concept of trying to come up with the definition of a particular capability. And where I find people starting to get into the name and the description, they're putting a lot of that, other aspects of it. And so one of the questions is, does the process indicate the how? It indicates the how within the capability but not how that capability is used outside of itself. And so that's kind of the distinction that I go with, is that there are some things within that particular business capability that is opaque to some degree outside of itself. Okay, so now we've got a capability name, we've got a definition, we've got some components to help us better and more clearly understand what it is. And now we're going to turn, and I'm going to turn the lead over to Steven to talk about how we actually create a business capability model so going from individual capabilities to actually looking at them as a larger piece and how we would actually create that model. Okay, so a business capability model or sometimes called a business capability map is a graphical or a tabular representation of the complete set of business capabilities that an organisation has today, all that it might need to have tomorrow. And by presenting it in a visual format, you can start to see at a glance where the business needs to focus its attention, which really helps enable better communication or decision making across and between business leaders. So let's look at how you actually build the map and what you end up with. The first goal is to capture and document all of the business capabilities that represent the full scope of what the business does today irrespective of how well it does it or how it does it, which is where you get into value streams and processes and so on. Or in fact what it desires to be able to do in the future because we can start to use things like heat mapping to visually identify current versus future state or perceived gaps in the capability model, which we'll talk about a little bit later. But for now the architect's role is really to identify a starter set of business capabilities that adequately reflects the complete business on a page. And there's a couple of ways to go about this. Ideally using some sort of facilitated workshop with the senior leadership team to identify all of the top level business capabilities that make up the core of the business. Working from the ground up through all of the business units to identify what each does is another approach to take when you don't have the luxury of gathering all the senior leaders together in one place at one time. But that is more of a highly iterative process. So you'll end up with some combination of the two approaches going back and forth, refining the model until you have general agreement across the enterprise about what is the 20 to 30 or so, because that's just a real rough guide. Top level capabilities that represents the business today. And I think in, you know, it's absolutely, and this will depend on the size of your organization. I know for my own organization we're a fairly big organization and so you end up having to do kind of both top down and bottom up just to be able to reconcile them. And usually when you're doing that bottom up, you're doing it based on an organizational structure because that's the way most people would do some of these workshops where you're going down to a specific business unit. So for me, going down to the surgery business unit to understand how they're doing things. And then as you move up the layers, we end up having to reconcile capability definitions or find where there's contention where we've got two business areas that might have defined the same capability, either semantically different at the name or slight differences in what they think it means. And that really ends up being a great conversation for business cross business areas because when you can find out that you do have common capabilities across business areas, we might have an opportunity for us to do something to either centralize that or to use more common tools or to get some better standards so we get better consistency, especially where one area of the business might be executing better than another where they have some ways to understand better how to more consistently and better use that capability. So it's really quite an interesting art and all of you have to be very good facilitators to be able to have some good meaningful constructive dialogue on capability names and definitions. That's equal through this. So this slide depicts some of the areas that you can start to look at. When we say do your homework, we're not suggesting everybody rush out and do homework after this webinar. This is more getting yourself in a place where if you're going to be running facilitated workshops, you've got a starter set that you can put in front of business leaders rather than a blank page which doesn't tend to work quite so successfully. So there is multiple areas across the business that will have documented information that you can go to and use as reference information to start developing the business capability model. So let's look at just one example which is the organizational structure. We've used this example here because it's something that is so easily accessible. Your company's organization chart can really divulge a wealth of information about your business capabilities to get you started on the mapping or modelling process. Because you can see at a glance that your business needs the ability to, in this example, develop products, distribute products, and procure supplies for manufacturing those products. It also needs the ability to manage relationships with partners and suppliers to provide after-sales service and support and so on. The key message we want to put across here is not to make the mistake of simply taking the organization chart and transposing it straight onto your capability map. As we mentioned earlier, an organization chart really reflects more accurately the structure of business functions at a point in time. And these, as we all know and are working for organizations, tend to change quite frequently, at least annually if not more regularly than that. Whereas business capabilities are inherently stable and it's often the case that a single business capability will be delivered or used across multiple business units, sometimes under a different name. So there is certainly not a one-to-one relationship but the organization chart is certainly a key area that can be used to inform you about which capabilities are necessary to include, at least as your starting map. Yeah, I think everybody would normally start with an organization as a starting map because there's usually, we can find some degree of correlation between the way you've organized the business and key business capabilities. But it's important to note some of those other things. I know for myself I like to follow the money because a lot of times following the money in the business plan or in your financial reports, they are going to highlight areas where there's some key business capabilities that are required that may or may not become apparent within the org to start. So when you say do your homework, it really means that I think we need to understand the business strategy and a few other aspects of what the business is trying to do, including the organization so that we can ensure that when we're selecting those top 20 to 30 capabilities, we want to put on that level one capability model or map that they're the right ones that we want to be showing to our most senior stakeholders. So let's look at the structure of a typical business capability map or business capability model itself. And on this chart we can see some typical names of capabilities that we might find in a business. You'll see that the naming convention is where we've used a noun or in some cases you may say that's actually a compound noun. But the point is it's describing a what. What does the business do? Other concepts to be aware of. You'll see that there's three stratification tiers, strategic core and supporting. And there's a second concept about leveling which I'll go into very shortly. The first one about the stratification is really used to help communicate logic to business stakeholders about the relevance or importance of different capabilities to different stakeholder groups. The stratification is the process that you go through to classify, group and align business capabilities within these three categories or tiers or layers. The purpose being to break up the model so that it can be more easily understood by non-architects and users. And it was when we said a collection of 20 to 30 capabilities that's not something to aim for. That just happens to be about the typical number we find when businesses go through this process as being distinct business capabilities that most completely represent everything that a business operation does. Each stratification tier provides a different perspective or a different focal point for each stakeholder group. So allow you to organize your analysis and your planning activities in a more structured way. For example, the top tier, the stratification one, is often aimed at the executive function, their span of control, business capabilities that are related to strategy and direction setting. The middle tier which we've called core and again you don't need to use these terms, these are just typical examples. That's really the customer facing elements of the business. As Alec mentioned, where the revenue really comes from. For the bottom tier groups, the supporting ones, those are business capabilities that are essential for the business to function but are more behind the scenes, playing a type of a supporting role. Yeah, I'm going to try and answer a couple of questions here in my supporting area. Tim is asking why 20 to 30, that seems high because APQC says you could start with 12. You know, there's, I think there's some, whenever you're dealing with a large number of senior stakeholders, you're going to find that we're going to have some compromise to be had to put some things on the top level for a variety of reasons. And I'm just thinking on the one that we've just been doing for our own organization and we've fluctuated between 16 and 24 and I don't know that we've landed yet but that we're hopefully, I would say if you can go lower, that's probably better but just an experience, it seems to be 20 to 30. And it's interesting also to find at times, I found anyway, when you start to say so what are the top level ones and why is this one here versus that one or can these decompose some really great questions around how that gets formed? In fact, the second concept that we're talking about if you want to move to the next slide, Alex, is about levelling and this is where you'll start to narrow down the exact number of level one capabilities that you're going to be ending up with. So levelling is the process of decomposing each top level or level one business capability into a lower level in order to communicate more detail about that. And we do this in order to find the right level of detail to communicate information to the particular audience or stakeholder group concerned. So top level business executives may only want to see that level one capability map with the example that we showed on the previous slide whereas architects and planners will expect to see a much greater level of granularity and this only becomes evident when we decompose and down, we provide more granular definitions and this can then be used by those people involved in more detailed analysis and planning to really understand the nuances, the distinctions about the particular capabilities that are being used at a lower level. So when you go through the levelling process, you start to question, is something a level one or a lower level capability? And you can start to, as Alex suggested, move between 16 and versus 24 level one capabilities. It all depends on who you're communicating the information to, how deep do they want to go with this? And so if you put all your capabilities together, you may end up with literally hundreds in a spreadsheet. So levelling is really important in order to be able to break that down, decompose and build up into an appropriate viewpoint that matches the perspective of the audience that needs to be using the business capability model to do their planning and analysis function. Yeah, there's an interesting question from Galena and I'm not answering everybody's questions yet, but I'm picking a few that seem to be relevant to the slide at hand. You know, what if the enterprise has a bunch of businesses that are different from each other? So for my own organization, we have an emergency medical service, ambulance service that obviously is rather different than what we operate to deliver surgery or deliver lab tests, right? So the top level capability model or map has to speak to the enterprise, but when you get down to a specific business area, this is where you potentially can use some of the capabilities that are a few levels down so that you can have a more relevant conversation with a more lower level executive. But the top level map should be the map that are all of the capabilities that are core and key to the entire enterprise, right? So no matter what business unit you might go and decompose down to at the next level down, you should still have that inheritance back up to the level one capability. So next we want to, this is where you want to start to do that mapping of capabilities and I led into that where you actually want to map to business in this situation organizational unit. We can start to create maps of capabilities mapping to value streams. So we're going to go give you an example of that moving forward. Sometimes we can map capabilities to specific business initiatives, right? In our organization we're suggesting, we're starting a project, that project is trying to improve one or more business capabilities to achieve something, right? So we've actually mapped our projects and sometimes programs to specific business capabilities. And then there's another way to make connections and map capabilities where we actually try to look at heat maps which is looking to say, so visually how can I see whether there's a heat map for strategic contribution or its relative effectiveness, right? So how mature is the capability? There's a lot of different ways and typically a heat map is going to use the normal stoplight metaphor because everybody seems to know red, green and yellow. So you can use a heat map as a way to reorganize capabilities so that you can map between some of these other perspectives as well. I think this is really where the rubber hits the road with business capability modelling. For many business leaders, the first time they see a business capability model or a business capability map, it's kind of a Eureka moment in itself. We often hear that, my goodness, this is the first time I've ever truly grasped the scope of what my business does and the first time I've been able to see it on a page. So that is really useful to see new leaders just developing their business model in the first place. But there's so much more that can be done with business capabilities that are far more beneficial to the organization, which is really when you want to be putting them to work as part of your business strategy, your business analysis, and planning activities. And so these examples here of how you map to other business architecture contexts and do heat mapping is really where you start to deliver value back to your business stakeholders about why are we doing business capability modelling in the first place. So then this is just an example where we're trying to map in this situation we've chosen two business capabilities learning management and project management and we've seen that in this situation IT ends up having a requirement to do project management as the real estate function or business area. And then learning management, HR is doing it in sales and marketing and information technology as well. So what that allows us to go and do again is to say is there an opportunity, right? Let's see if everybody's doing that and I can use my own example in my own organization. I actually have seven different organization units who all deliver education and not unsurprisingly they use seven different learning management systems. And we have a number of distributed teams within that that supply some different components of that and we're able to look at that and say is there an opportunity for us to do this more efficiently and actually coming up with ways to actually have educators follow a more standard process so that the people themselves are doing something differently or whether I have common supporting tools or whether we just even have common standards around what skills are being, how skills are being tracked in the way we do that because as you might imagine in healthcare we need to know at times whether a particular provider is able to do, has learned something so that they're able to deliver a particular service. Anyway, this is just one example of mapping organization to capability and it's obviously a very simple example but I hope it shows you how that could start. The flip side of that of course is that if you have identified that a capability is being used across multiple organizations or multiple business units that should be a red flag to say if I'm going to go and make changes to that capability I need to be aware that it's going to impact across multiple different parts of my business and often when we go doing transformation work or roadmap for new technologies we sometimes forget that making change in one part to a solution or a service that a business provides internally or can have significant downstream impacts on other parts of the organization and so by doing this cross mapping we can at least quickly identify all the relevant affected groups and stakeholders that we need to be across if we're going to be making changes in one particular area of a capability. The other very interesting way to use this I've used in the past is mergers and positions as well so when you think about where you've acquired a company or you've merged organizations this is a really great way to go and start to do that analysis. And then here's an example of the heat map. In this one we've decided to I think are in the guide we've suggested that this is a maturity or relative maturity so what we're saying here is that is this capability operating at the level that the business requires it and if not then we would look at the red one and we'd say HR management or government's relationship management we go and go down and look at the definition and say how is that capability looked now and what does it need to look to be able to meet the requirements of whatever the business strategy or value stream or whatever is indicating that this particular capability is not at the strategic level at this level one. It's just a way to say if I look at where we're investing our time and energy is it related to where we think that we might have some pain. So heat mapping doesn't happen magically. All we're doing is taking the basic or the core capability model that we developed earlier and we're asking questions of it and those questions can be asked and why depending on who the stakeholder is that is asking the question. But it's a very powerful visual tool to help quickly identify the areas that you want to be spending time on developing more detail or looking to invest more in and again any information that you want to ask and we'll end up with a different color scheme, a different heat map whether it's which capabilities are performing better or worse at this point which are contributing more or less to the bottom line which could be outsourced without affecting the overall mission of the company and so forth. This is a very simple example of a red yellow green traffic light and any type of color combinations to quickly indicate which are those capabilities that you want to be drilling down on and really providing insight to help better decision making going forward. The last example of a map is we've changed our paradigm here from an internal service which is recruiting management which is arguably external stakeholder facing because you're going to people outside of your organization to try and recruit them to become part of your organization but in this situation we've chosen a value stream example. In the chat room we've had a couple of questions about value chain versus value stream and we're going to hopefully deal with this particular topic in the next guide that we're working on right now but just to give you a hint of what's coming we want to show in this particular value stream this is putting the action and how of these capabilities been organized to help support us getting in this situation from getting from product to sales right and how are we getting through that logical chain of stages so that and understanding which capabilities support which aspects of each of the stages. It allows us then to understand the value question so when you did well this one's read if you actually overlaid that heat map on this one we might find that while some people think that a problem is payment processing we may find that if we don't have and set up the right aspects of how we do our purchases up front that a prior value stage and a capability at the base stage is actually the thing that's causing the problem at the pain point which is further down the value stream so hopefully a simple way to build these to value stages and value streams. This is a really powerful tool when you're going through strategic planning thinking about how a future business model or a new revenue stream might be wanting to work and so you'd start off with the value stream defining what are those major stages that you would go to in order to deliver value to a customer or to an internal stakeholder and then cross map the various business capabilities that are used to deliver that value stage and as you can see on this example we've just listed out the nine or so business capabilities that apply some apply to multiple value stages when you go through this process you may find that hey we don't have a business capability today that is required to support a key value stream or a key value stage within that value stream and that is really useful information so before you go out and make drastic changes to a business you can really see where you need to be investing in capturing or creating that capability whether it's in-house or using partners and suppliers to do so for you but taking it to the next level and as Alec mentioned putting the heat map viewpoint on top of this is a very very powerful tool for business architects and for enterprise architects to use to help business leaders plan for prioritise their investments and develop really useful roadmaps for what they need to do to get to the point where they are actually delivering on the core value streams that they want to be doing. And I think that's the last slide in our presentation as I mentioned before what's next for us is actually coming up with a value stream guide