 Hello, I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognised experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organisation can be derived when they're used in unison, that some of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required, and recruiters can take the guesswork out of the recruitment process, all backed up by our Open Badges programme. Is this a banana or a bear? Yes. Boolean logic and a common IT pun, although for many within the IT world, it is actually just a logical response. So what? Well, our IT systems are mostly based upon logic like this, something either is or isn't this discreet and precise, and usually logic in a way that humans don't normally. This is everything and language is a great example of this. LEAD, lead or lead? Is that lead as in lead of a team that can lift you up, or lead as in a heavy weight that could drag you down? When architecting, context is not just about what is outside the boundary that is more of interest, it is now recursive and repeated inside the system. Internal context becomes key. And understanding things like Boolean logic is not only important when coding a system, it's important when receiving information from a coded system. That itself has become part of the context that we all need to know. So welcome, everybody. I hope that all is running well now on the, on the Webex. Great to have you with us. And we have a great session lined up on the benefits of the Togaf standard today. So and I'll introduce our speaker in just a moment. But before we get going on that, just a reminder or some guidance to those who may be joining us for the first time. The way to ask questions of our speaker today, please do that through the Q&A channel. That you will find that if you click on the three dots in the bottom right-hand corner of your screen, then that will give you the chance to click on Q&A and please use that to ask questions of the speakers. I'll have a Q&A with the speaker at the end of the session. But please do use the chat channel to communicate with other participants on the Webex today. And anything else that you want to share with us, please use the chat channel for that. So great stuff. We'll move on. Now, sadly, we were supposed to have a double act today, Rita Sundari and Samuel Bandaru. And unfortunately, Rita has taken ill. So that's the bad news. The good news is that Samuel is here and able to give the presentation on his by himself. So that's great news. Thank you for that, Samuel. So we're going to be hearing about the benefits of the Togaf standard. To do that is Samuel Bandaru, who is a business manager at Architects Inc. He has over 15 years of experience across a range of industries. And with a sound understanding of enterprise architecture design and project management, Samuel has been an active trainer and practitioner of the Togaf standard. In fact, he's seen the evolution of the Togaf standard across its last three versions, which is going back some sometime now, Samuel. So a warm welcome to Toolkit Tuesday, please, for Samuel Bandaru. Over to you, Samuel. Thank you, Steve. Thank you for those kind words. We really appreciate this opportunity to be a part of this ongoing series, the Toolkit Tuesday. The topic for today's Toolkit is the top 10 benefits of the Togaf standard. So let's go ahead and dive in. Well, we're living in VUCA times. So VUCA is characterized by volatility, uncertainty, complexity, and a lot of ambiguity. And that often creates a need for change. This is the norm in certain industries and areas of the business world. So it also makes it difficult to analyze a situation and plan for a meaningful response. So the result is paralyzed, executive decision making, stifled developments, overwhelm leadership, things like these. And dealing with changes in these VUCA times requires a structured approach or an architected approach. Now, we can make use of an analogy of the construction of a building. Now, you really can't build a house without a blueprint. Well, you can, but it may not turn out as, you know, you'd hope for. Probably would be pretty loosely constructed, might even fall over taking you and your possessions with it, right? Similarly, this is not an ideal case. And you want to avoid the confusion, the clutter, the resulting conflicts of any haphazard planning, construction, and development. So either what we want is an architected and structured approach. Now, that's made possible with the help of enterprise architecture. So much along the lines of constructing a construction of a building with the help of a blueprint, you would also want to build, change, or manage your enterprise with a structured approach. And that's precisely the purpose of enterprise architecture. So an EA framework or enterprise architecture framework provides a framework for change, linked to your strategic direction, linked to your business value. It also gives you a view of the organization, which helps you to manage your complexities, manage risk, strike the right balance between business transformation and operational efficiency. Talking about frameworks, the Togaf standard is an example of a leading enterprise architecture framework out there in the marketplace. It's a proven framework used by some of the world's leading organizations to manage their change. So let's briefly look at the benefits that the Togaf standard provides. Now, before we look at the benefits, we've got to understand one thing. That is developing and sustaining an enterprise architecture is a complex process, a technically complex process which involves many stakeholders. It involves many decision processes within an organization. So using a framework like Togaf standard does provide us with a host of benefits to deal with this complexity and meet expectations of different stakeholder groups. So you could list a whole bunch of benefits, but listed out here are the top 10 benefits that we really appreciate. And I'm going to quickly go over the list and then after a while we'll look at some of these in detail. So Togaf standard helps you manage change. That's at the heart of it. It standardizes the architecture development process. It helps you manage risk and security. It provides a framework for architecture governance. It provides you with a robust framework for defining value, deriving value. It results in enterprise architecture development that is consistent and reflects. It is focused on the needs of the stakeholder. It provides you with an integrated holistic view of your organizational landscape. It's versatile. This framework can be used across any industry, any size, and it's freely available. And it's the most up to date body of knowledge that you could lay your hands on. So let's briefly go ahead and take a look at this standard. The latest release of the standard is the 10th edition released this last year. It expands on the material that was already available, making it easier for adoption, easier to use. It provides us with these three things that you see here. It gives us the ADM, the content, the Togaf content framework. And it gives you a bunch of these guidelines, techniques, and advice. We will look at these briefly a little bit more in detail. But then what value do you think using a framework like the Togaf standard brings to the table? So first and foremost, it provides us with a practical starting point for any architecture project. It gives you a starting point. It avoids the initial panic, especially when the scale of task becomes apparent. It is a systematic codified common sense. So most of the Togaf framework is actually based on common sense that's been documented, that's been codified. And you realize it as you start using this framework, the standard. It captures what others have found to work in real life. And it contains a whole bunch of these baseline set of resources that you could generally put to use to help you along your way. And as you start building enterprise architectures and you start planning for the migration and implementing these architectures. Now, let's go ahead and take a look at the benefits of the Togaf standard that it provides to different user groups. And we'll start with the EA practitioner. So enterprise architects need to deeply understand the business and the technology and how they can be modeled to support the business strategy. To that effect, the Togaf standard provides an integrated holistic view of an organization's landscape, which enables good strategic decision making. The framework divides the enterprise architecture into four primary domains. These are your business data application and technology. You can see them here now added on to these. There are other domains like motivation security governance that you could define that cut across these primary domains. So the Togaf standard does support definition of these different domains that could be used to address specific concerns that your stakeholders might have. The standard itself takes the strategy into consideration. So you're looking at the business strategy that you take into consideration. It provides a methodology and a set of tools and techniques for designing and implementing enterprise architecture that operationalizes that strategy. Now, keep in mind that the Togaf standard itself is very generic and it can be adapted for any organization, any, any situation, any vertical, any domain. Let's briefly talk about how it does it. So the standard gives you a framework for identifying and implementing change. It does so by providing you with the ADM, the architecture development method, a content framework, a set of guidelines, techniques and advice. And let's go ahead and take a look at each of these briefly. So this is your ADM or the architecture development method. Now, the ADM provides the practitioners with a definition and description of a standard cycle of change that is used to plan, that is used to develop, implement, govern, change and sustain your enterprise architecture. So it's iterative, it's cyclical, you use it, and a number of these ADM cycles produce the desired enterprise architecture. Now, going hand in hand with the ADM is the Togaf content framework. It gives you a definition and description of the building blocks that are there, that could be there, that are there in any enterprise. Also, it gives you a checklist of architectural output that could be created. Then you have a bunch of these guidelines, techniques and advice that is really useful for the practitioners as they, you know, traverse this journey, designing the architecture, planning for migration, implementing the architecture and sustaining the enterprise architecture. Now, let's go ahead and take a look at the benefits that the Togaf standard provides to, let's say, an EA consultant. For the consultants, the Togaf standard provides a modular, scalable framework that enables the organizational transformation for different use cases and different architectural styles. So if you're a consultant, you might be involved in defining or developing an architecture, maybe let's say to support your organization strategy, which in turn can be used to drive changes to the enterprise architecture. So a consultant might use the Togaf standard to define a business strategy, identify value chains, value streams, business capabilities and processes to support that strategy. Now, this is followed by the IT architecture components required to support the business. So the standard provides the consultants with a robust taxonomy, a robust methodology to articulate things like what you see here on the screen and present these to the stakeholders. Now this could facilitate discussions, aid comprehension and eventually lead to decision making. Let's look at the benefits that the Togaf standard provides to tool vendors. Now the tool vendors are the ones that deal with enterprise architecture tools that facilitate architecture work. So for the tool vendors, the standard provides a whole bunch of resources like a reference model for architecture views, deliverables that the architecture must ideally produce the structure of the Togaf architecture depository. Also provides them with a detailed ADM and guidelines on how to use the ADM and the structure of a governance framework to facilitate automation of your architecture practice. Let's look at some of these components. So here you have the enterprise meta model. This defines the different types of entities that a tool must define for modeling that describe the enterprise. Also describes the relationships between these entities. So the content that you produce using this, this meta model across the ADM would be stored in a depository and Togaf also gives you a structure for the depository. Let's go ahead and take a look at it. So here's your repository. So this one defines formal taxonomy for different types of architectural assets alongside dedicated processing tools for your content storage. Moving forward, let's look at the benefits that the Togaf standard provides for enterprises. So enterprises of all sizes across different industries use the Togaf standard and its set of best practices that their EA teams require to effectively structure and align their enterprise architectural efforts. So here are some of the benefits that the standard itself brings to the table. It helps these organizations to operationalize their strategy. It defines the enterprise architecture at different levels of granularity. It helps you to address concerns of different stakeholders at different levels. It helps them manage risk and security and helps with enterprise architecture governance. Let's briefly look at some of these. So the first one is operationalize your enterprise or your business strategy. Now the Togaf standard can be used to fill the gaps between a business area that is right at the top and the implementation which is right at the bottom. By defining these interfaces in between the business, the data, the application and technology components. And not only does it help you define the four domains or the architectures for these four domains but also helps you in carrying out the actual implementation. Making sure that the implementation is aligned with the actual specification. Another benefit was using the Togaf standard to define architectures at different levels of granularity. And you can see that here. Now so we use the Togaf standard to define architectures at different levels. So this in turn can be used to address different stakeholder concerns, stakeholder needs at different levels within the organization. So each of these architectures that you see here typically does not exist in isolation but sits within governance hierarchy. So the broad summary architecture at the top, they set the direction for the narrower and detailed architectures downstream. An example here. So here's a diagram that shows the business capabilities and enterprise needs to meet its purposes. Now these are defined at two levels here, L1, L2. So the top layer is L1 and the ones below, that's your L2. Now these could represent the full scope of what the business does today or what it desires to be able to do sometime in the future. So you could take something like this and heat map it to add in some perspective. So let's look at an example. Now these heat maps could show a range of different perspectives including things like maturity, effectiveness, performance. Value or cost of cost contribution of each of these capabilities to the business. So this heat map that you see here shows the capabilities at the desired level of maturity in green. One level away is in yellow, two or more levels away are in red. So something like this helps you with your business analysis and helps you in planning your business architecture. The TOA GAF standard can also be used to help organizations understand different stakeholders' concerns, try to address them, articulate them and address them and manage any conflicts. So let's look at some stakeholder groups here and their typical concerns. So let's start with the concerns of a typical CEO. The concerns could include things like restructuring operations, leverage information strategically, cut costs, support digital transformation, support sustainability. And along each concern, you can see that on the table, you can see how the TOA GAF standard could be used to address these concerns. For example, if it is, let's say, leveraging information strategically, the TOA GAF standard could be used to provide actionable insights on data. Now I don't want to go to the entire list because of lack of time, but then along similar lines, other stakeholders could be identified, the concerns could be articulated and you could meaningfully try to address them with the help of the TOA GAF standard. The standard also helps you to manage any risk and security concerns associated with a business transformation effort. So the standard deals with these concepts throughout your architecture development cycle. So this is baked into an ADM cycle. And this diagram illustrates the fact that security is a cross-cutting concern. It cuts across all the four domains. So this is an ongoing exercise. This is an ongoing concern that we deal with risk and security across all phases of the ADM. Now the TOA GAF standard also provides you with the framework for architecture governance, with the help of which your enterprise architectures can be managed and controlled at an enterprise-wide level. So this diagram highlights the major structural elements required for any architectural governance initiative. Lastly, let's talk about who actually uses the TOA GAF standard. So 80% of the global top 50 companies use and benefit from the TOA GAF standard. 60% of the Fortune-Finded companies use the TOA GAF standard one way or the other. So you can see that the TOA GAF standard is pretty popular. It's widely used across the industry. So Oliver, I'll hand over the control back to you to conclude this session with Steve and see if there are any questions. Over to you, Oliver. Thank you, Samuel. I'll come straight back in. I appreciate that overview very much. There's obviously so much that could be covered in the TOA GAF standard and it's hard to do it in a short time, but it is obviously a tool that attracts a lot of interest from people who might be on the session day. So thank you for covering that. So just a few questions or rather a comment from me initially. One of the things that I hear as a benefit, one of the most common benefits I hear is the standard provides a common language for doing enterprise architecture within an organization and within that organization's partners. Is that something you see as well? Absolutely. So imagine a large organization which has multiple teams working on multiple aspects of defining your enterprise architecture. Now if all of them were to use the same standard, it would guide them with a common methodology, common framework for producing the content, a common repository which will bring all content into a single repository and avoid any conflicts or any duplication of effort. Absolutely. So a similar question here is there's so much in the TOA GAF standard. How do you get going? Not everyone has an EA team that's been operating for a while and running smoothly. How does someone in an organization who might be on this call try to use the standard to gain some traction for their enterprise architecture activities and acceptance within their enterprise of that discipline? Yeah. So if you look at an organization, Steve, there are many moving parts to an enterprise. Now the TOA GAF standard can be used to identify these moving parts, define their architectures and the relationships between these different moving parts can be used to articulate the concerns of the stakeholder and try to address them by providing them with the right views to aid comprehension to facilitate discussion to aid decision making. That's how you gain traction. It can be used to define the business value in very definitive terms and explain to the stakeholders how that business value would be impacted with some architectural intervention. It can be used to produce a complete traceability of how the high level goals and objectives eventually get translated down into effective business processes and our business architecture and IT architecture. It can be used to identify and mitigate risks. Now there's a whole bunch of things I could talk about, but these are some of the things that are really at the top of the mind, a lot of stakeholders. So try to address these, try to gain the confidence, get their buy-in, get their support, get their commitment and eventually make this more popular, make this more acceptable within a given enterprise. You mentioned IT there or IT architecture and I think one of the things that again we hear a lot is folks often use the TOA GAF standard, they equate it with IT architecture and they perhaps miss the opportunity to use it for things like business architecture or security assessment, some of those things. Can you say a little about how it might be leveraged for some of those things? Yeah, so that's actually the case with a lot of organizations. With their enterprise architecture practices, they are mostly focused on the IT side of things. So they completely overlook the business side of things. So this is where the content framework, the content metamodel can be used to provide them an overview of what the enterprise architecture is all about. So this content framework provides a structural model for all the architectural content that allows major work products that an architect creates. And this can be used to define these consistently and again in a structured manner and present these to the stakeholders. Now this content metamodel or content framework could be used along with the ADM to leverage, to understand and appreciate the significance of the business architecture. So if you use the content metamodel, enterprise architects will soon begin to understand and appreciate the benefits that the TOA GAF standard provides. One of them is traceability from business to data, business to application, business to technology. And you realize that the IT architecture is just an enabler. It exists there just to support the business. So it makes more sense to actually define the business first and then see how the IT can be architected to support or IT enable or automate the business. What do you, Steve? Okay. Thank you, Samuel. And I think, you know, there's a question here, which in the interest of time, I'll lead you down a path towards answering it. It's about a similar to another one about how do you get going? But, you know, how do you pick the parts of the Steador run to you? And I think one of the things we tried to do with the 10th edition is to have the TOA GAF series guides focus on the how to of this, you know, how and more of a business architecture element and, you know, many other things that are covered in the more than 20 plus series guide. So how do you kind of pick what's right for you? Yeah, so there are a whole bunch of these series guides out there available on your TOA GAF open group website, TOA GAF library. So depending upon what's the need at hand, you know, you can cherry pick from there. The good part is that the TOA GAF standard can be customized. So you don't need to really get overwhelmed by its enormity, its comprehensiveness, its size. So look at what exactly are the requirements at hand and then you can you can cherry pick parts of the TOA GAF standard to help you along your way. So if you're a practitioner working on, let's say roadmap development, you know, the practitioner is going to be exercising the steps for the TOA GAF ADM phase E. If you're a practitioner, that's really going to be dealing with a lot of risk and security issues. So there is a TOA GAF series guide that's there in the library that you could potentially make use of. If you're dealing with SOA or MSA Microservices Architecture, again, there are a bunch of reference documents available in the TOA GAF library to help to get you started to give you head start and to help you along the way as you put the TOA GAF standard to practice. That's right. You know, and tailoring is the key. So often, folks are almost apologetic about, oh, we didn't use everything and that's that's exactly what we intend to use the bits that you need to use and that are most relevant. So, Samuel, we'll, we'll leave that topic there. We really appreciate you sharing your insights today and particularly for stepping in and sharing the load that that would have been readers as well. So please give her our best wishes for a recovery and very much appreciate you joining us today. Thank you, Steve. My pleasure. One last, one last thing, just a few words about two weeks time, which will be August the first, I believe already. How did that happen? We are going to switch gears to another used and standard from the open group, another tool for the architects and that's the IT for IT standard, the IT for IT reference architecture and specifically how that can be used to enable software engineering at scale. And to deliver that, we will be joined by Luke Bradley of Vodafone Group Services. It would be great to hear how Vodafone are using that inside their organization. So for now, that's it. Thank you for joining us today. We appreciate your attendance and any issues with the earlier on with the sound will be dealt with in the recording. So please look back on on the open group YouTube channel and wherever you are in the world, stay safe and well and hopefully see you in two weeks time. Meanwhile, I'm Steve Nunn. This has been Talk It Tuesday.