Pass The Open Group TOGAF OG0-092 Exam in First Attempt Easily

Before We Start

1. Introduction

Hi there and welcome to this class. TOGAF nine-one certification exam, part two. I'm the instructor, Scott Duffy. In this class, we're going to go over what it takes to pass a certification exam. For part two, we'll go through the Togas specification and explain those parts that you need to know. Before we get into that, I want to tell you a little bit about myself, if you don't already know. My name is Scott Duffy, and I've got more than 20 years experience in software development. I've got more than ten years working as an architect and I'm TOGAF nine one certified. I'm a member of the Open Groups Architecture Forum, and I also hold a commercial licence for TOGAF, and I'm licenced to teach this course. The TOGAF standard, which I hope you know, is run by a consortium called the Open Group, and its abbreviation is the Open Group Architecture Framework. You can find all of the documents on their website. It's Opengroup.org. OpenGroup is a collection of over 400 companies, universities, and governments that came together to create and work on this standard. Now, the Toga Standard itself has a long history before that, starting with the US Department of Defense over 30 years ago, and has since been turned over to the standards body called the Open Group, where it has been worked on and developed to where it is today. The main thing that you need to have right off the bat is a copy of the Toast specification. It is very important that you get a copy of this and be familiar with it. The exam primarily tests your knowledge of the specification, and I can't imagine passing this test without many hours of intimate knowledge of that document. The goal of this course is for you to take and pass the TOGAF exam. For part two. In this class, I'm going to be focusing on what's important for that exam and not necessarily what you need to implement within your enterprise. As you know, they don't always match what it takes to pass. First of all, you've got this course and the supplemental materials that come with it. Now I'm sometimes asked if this course is the only thing that you need to purchase to pass the test, and the answer is yes. You're obviously going to need the specification when it comes to the Part Two exam, which happens to be an open book exam. However, this open book exam is based on the specification's PDF, and you should be familiar with it, including how to search it, all of the sections, how it's organized, and so on. Also, there's going to be some work on your part. Unfortunately, I'm not able to deliver you a course that you can just sit back and watch and then go take the exam the next day. You're going to actually have to do some homework and do some studying and note-taking. I'm a firm believer that only you realise what you need to write down and what you don't. So if they're unclear about something within the Togas specification, you can make notes about that. If there are things that are completely clear to you, then obviously you can skip over that memorization with any certification; you need to have a good memory. Now, luckily for this exam, it's an open book exam, like I said, so you don't need to have an amazing memory as you can always look something up during the test. But you have to be able to look at a question and already understand what it is that they're asking so that you'll know where to go to look it up. Finally, practise this part two exam, which has a unique question structure, which we'll talk about in the next lecture. But it's very important that you practise with these types of questions so that you're not stuck on the day of the test. "Looking" is something that you've never seen before. Coming up in the next video, I'm going to talk to you about what you need to know about the exam itself. So come back for that.

2. Details of the Exam

Welcome back. In this lesson, we'll go through the details of the Part Two exam. So it takes two exams to be fully Toga certified. There are two exams: Part One and Part Two. Now, you can take them both together at the same time in the same session, or you can book them separately and take them days apart or weeks apart. It's up to you. So that was Part One, and hopefully you passed it or are planning to take it soon. Test your understanding of the TOGAF specification. In general, test one thing at a time, and it's a very detailed exam, just asking about definitions and concepts and such. And passing this gives you TOGAF 9 foundation credentials. Now, the Part Two test, which this course is about, is how to apply the TOGAF standard to several scenarios. It's more of an application exam, and if you pass that, it gets you TOGAF 9 certified. In this course, we're focusing on the Part Two exam. I've got another course for Part One. So the Part Two exam is taken in person at a testing centre close to you. There are eight scenario-based questions. It uses a very unique gradient scoring system so that there are four multiple choice answers. And the best answer gets five points, the second best gets three, the third best gets two, and the worst answer gets zero points. It takes 60% to pass. This is an increase over the Part One exam, which only required 55%, which means out of eight questions with five points each, that's 40 potential points. You only need 24 points to pass. There are 90 minutes to do these eight questions. There's an open-book exam. This is another unique feature where you can refer to a copy of the tower specification in a PDF format. During the exam interface, you do have the ability to go back and forth and review your answers before submitting the whole test. It's not a scenario where you answer the question and then you can never see it again. You're graded immediately, and so you're given your password failure right on screen. And when you leave the exam center, you are given a piece of paper that says you're TOGAF 9.1, you are given a So the requirements of the Part Two exam are listed on screen. This course basically focuses on each one of these individually. So you can see that these requirements all start with how to apply them: how to apply the emphasis on enterprise architecture, how to apply architecture governance, how to apply the TOGAF architecture content framework, how to apply building blocks, all of these, and I'll go on to the next screen. Here's how to customise the technical reference model, the triple IRM model, the key content deliverable to the ATM cycle, and so on. And again, the whole course is focused on each of these. This is my experience with the ProMetric Testing Center and the exam itself. It's around $320 plus tax to take the exam. It's obviously localised to your currency. Not every Prometric testing centre offers this exam. So you go on to the website at prometric.com, and you can then search your local area for testing centres and see if they offer this test. You can do the booking, cancellation, and recharging of everything online. You get unlimited changes up to 6:00 p.m. on the previous business day. So if you want to book the exam for Saturday, you have until Friday at 6:00 p.m. To make changes to that if you fail the test. If you fail the Part Two test, you are still certified as Part One foundation. But you do have to come back at least a month later and take the test again. You do have to pay again. Now, I've been told that you can get a discount if you contact the Open Group and say that you failed. They'll actually give you a voucher for a cheaper price. You don't have to pay the full 320 again, but you do still have to pay something. You're going to have a different experience at the Prometric Testing Centers than I to have a different experience to me. Now, while I was in the process of studying for my test, I took a lot of notes. And so what I ended up with was a couple of pieces of paper that I could carry with me as I went to the Prometric center. I actually put the papers in my pocket. I had some time to get there about 20 minutes early, and I can sit and just review the notes one more time just before taking the test. Now, the testing centres themselves are not usually dedicated for testing because I don't know if that's a viable business. So they've got technical training schools. You'll go there; they'll teach programming courses, they'll teach Cisco networking, and they'll also offer this testing in a dedicated location. So what that ends up being is that this is sort of a side business for them. You're not going to get the biggest computer monitors. They probably are LCDs, although some CRTs still exist, but they're smaller screens on older equipment, maybe a bit slower. It's not your home system for sure. You will get one or two erasable sheets so that you can make notes. You can't take it with you. You have to turn it back in at the end. You get an erasable marker as well. I'll talk about how I use this. One of the things I do is calculate my score as I go. So as I go through those eight scenario questions, I will try to assess whether I'm very confident or only somewhat confident of the correct answer. So obviously, if I'm 100% or 90% confident, I give myself five points. And if I thought, "Well, it's a 50-50 shot," I couldn't decide between two. You can get five or three points for that if you're right. And so I'll take the three points and give myself a five, or give yourself a three. In my experience, you're never going to give yourself a zero, are you? So that's what I do. It took about 60 minutes for me to finish this test. I reviewed it, I completed the exam, and then I was ready to submit about ten minutes after that. So your assignment is to go to the OpenGroups website, look at the exam detail page, and particularly, I want you to think about a date for when you'd like to take the exam. Mark it on your calendar. Set a goal, because you're never going to achieve a goal if you don't set it first. So give yourself these two weeks, three weeks, or however much time you think you want. not too long. Set a goal and work towards it. Coming up next, we will talk about a quiz on what we've covered so far. Thanks.

Hide

TOGAF 9.1 Specification for Part 2

1. The Role of the ADM in Change Management

Hi there. In this lesson, we're going to go over the exam requirement that says how to apply the emphases in the development of an enterprise architecture. This really gets to the heart of TOGAF right off the bat, doesn't it? Let us now go over what the ADM is. The ADM stands for "architecture development method." This is a process for identifying the major business needs and designing a plan to take a company from where it is to where it needs to be. Business requirements can arise from a variety of sources, which are referred to as change drivers. Obviously, the business executives can decide that they want to alter the strategic direction of their company. This can be an overall strategic change of direction. And let's talk about an example now. Many large newspapers are facing challenges in modern times. As print sales decline, they are losing the interest of people who want to have a newspaper delivered to their door every day. Compounding this problem, the prices for advertising are falling as well, and advertisers have more choices for where to spend their money. So the newspaper decides to open an online newspaper and charge for that as an additional service. But it was not as simple as just taking the existing articles and throwing them on the website, right? Every department is impacted by this change. The ad department now has changes that they need to make to the way that they sell ads and operate. With advertisers, subscriptions become more complicated, with more options for people who want the online edition and not the paper edition. Finance is impacted as well. Every department is impacted by this change. Even the editors are split as they now have online editions that can be different from the print editions. And deciding to have an online newspaper is a big change for the company. As a result, it is the architect who takes the strategic lead and searches the architectural landscape for gaps. The gaps are put onto a roadmap, and the roadmap becomes the plan. Working with project managers, developers, and teams from each department, the change is implemented in an orderly fashion. And that's just one type of change. The government can introduce new laws; competitors can emerge that require swift action for competition. Each department has systems that they want to improve; this is just the natural progression of system improvement of systems. There are new versions of software that come out. There are changes that come from above, changes that come from within a company, and changes that come from outside. And so the architecture group is the people that manage that change using the ADM process and decide which changes can be done immediately, which need to be delayed, and which changes require a complete rethink. Another run through the AD cycle. In the next lecture, we'll go over the ADM in more detail.

2. Applying the ADM Phases to Enterprise Architecture

Hey there. Welcome back. In this lesson, we're going to talk about this specific exam requirement: how to apply the AD phases in the development of an enterprise architecture. As with the Part One exam, the Ad, ADM is the focal point of this exam as well. There's no avoiding the fact that AD is the central thesis of TOGAF. To remind you, AD consists of this preliminary phase. Up at the top, you've got those eight phases A through H arranged in a circle, and you've got requirements management in the centre of it all. And to remind you, the phases A through H are often called an "architecture development cycle." So the Part Two exam does cover the phases of the AD in scenario form. And for the purposes of this discussion, I'm going to group them together. You've got the preparation and startup activities, which are the preliminary phase. You've got the defining requirements and planning implementation, which go from A to F. You've got the implementation phases, which is Phase G, and you've got monitoring for changes, which is Phase H. and hopefully you know most of this already. So in "Preparing for Start," you've got "defining the scope of architecture work," establishing your architecture capability," tailoring TOGAF to meet your specific needs," and "defining architecture principles." These are the main things that you want to do in that preliminary phase. In the definition of requirements and planning of implementation, which are phases A through F, you want to start with this high-level vision, refine it down to a more detailed requirement, and then go through all the steps in the B, C, and D phases. You received your communication about this plan and the various approvals you need to get. You start planning a flotation, grouping work packages, and communicating with the people who are going to be doing the implementation in Phase G. That's when the implementation starts and the architect falls into more of a governance role. So the work of defining is done. And now you're just monitoring the implementation team to ensure that your target architectures are delivered and to ensure that the business value is realized in the final phase of the cycle, the monitoring phase. Now, what you're doing here is monitoring for changes. There's going to be change requests that come through—the business changes, the environment changes, and the new competition legislation changes. There are 50 different factors that come through. And in part of that governance role and part of that monitoring role, you're going to be looking for changes and deciding whether you can accept them into the environment or whether you have to kick off a whole new architecture development cycle to handle the changes, depending on their size. Again, you're continuing this governance function, and finally, you also want to make sure that you're not losing your architecture capability. So oftentimes, within organizations, you go through this project of defining architecture, and then people move on to other projects, and this architecture goes into a binder and sits on a shelf or in a directory or in a knowledge base, and no one touches it for months or years. And you're effectively losing the architecture capability. The documents get out of date. The people may have moved on and no longer be in those roles. You don't backfill when they move on. Part of the responsibility is to keep this going. Coming up in the next video, we'll talk about architecture governance. Stay tuned. Bye.

3. Applying Architecture Governance

Back. In this video, we're going to talk about the exam requirement that says how to apply architecture governance in the development of an enterprise architecture. So, from the TOGAF Spec, the term "governance" means the discipline of monitoring, managing, and steering a business to deliver the business outcome required. That's pretty simple. It's basically all of the functions that go into managing and steering businesses. Now, architecture governance is more specific. It is defined as the practise and orientation for managing and controlling enterprise architectures and other architectures on an enterprise-wide scale. It is concerned with change processes and the operation of product systems. So this is a more specific form of governance, which has to do with your architecture and managing change. So within an enterprise, there are many different types of governance. You've got your corporate governance, which is your board of directors and the CEO and all of the C-level executives. You've got the technology department, specifically. So oftentimes in many modern businesses, the technology department is huge, and technology is a major way that they deliver their products and services. And so technology governance is massively important, especially with hackers and security and all of the things that these people have to worry about, and governance specifically. So now we're talking down to the server level, making sure that the uptime of the servers and your IT resources are aligned to your business goals. And finally, you've got this architecture of siness goals. And Architecture governance is more on the business side, where you're looking for changes within the business and how much you do have to adjust how the business operates in order to deliver the correct solution. The TOGAF Spec talks about the characteristics of good governance. It's sort of a general set of principles that apply to sort of all levels of governance, not just architecture governance. But the spec itself does mention these, and I thought I would mention them to you. So the number one characteristic of good governance is discipline. Then you have transparency. All actions are available for inspection and independence. So you don't want biassed governance; you don't want someone who will play favourites and always prefer a financial decision over a technical decision, and so on. So once they make decisions, obviously, then they have to stand behind them and not try to shirk that responsibility. Finally, responsibility is required to act responsibly. Of course, they must make decisions that are in everyone's best interests and are not merciless or rash. These are all six characteristics of good governance. Architecture Governance So within the Toga backside of enterprises, architecture governance is a system of controls that is on top of all architecture components, okay? It ensures compliance with internal and external standards. So if you're going to have, for instance, your architectural principles be that we run on open-source free software like Linux and Apache and things like that, then someone's going to come along with a closed-source Windows-based solution. The architecture governance is going to be that place where it's going to say, "Hey, wait a second, why are we doing this?" Why are we going against our own standards? questions like that. This also involves the system as well as processes. So you need the proper documentation; you need architecture; you need a repository; you need these things. Again, with the transparency and the openness, you need to be able to make decisions, record them, and provide explanations as to why they were made so that later in the future you can go back and relive those decisions. and is also responsible for practises that ensure accountability. And maybe that includes reporting and having a website that people can go to and see these things. Now, within the TOGAF Administration, there's one specific phase that all has to do with governance, which is the phase G phase, implementation governance. Now that's just one aspect of governance, right? So that's basically governing the implementation of the solution. It is not the only instance of time governance that occurs within the AD. On screen are the drivers of change. So you'll see on the left, you've got various processes, you've got monitoring and compliance, and you've got dispensation. Dispensation is when a governance team makes an exception. So let's say you want to have that window system and they approve it, but it's a dispensation, so they probably end up saying you can do it, but you have to look for a replacement within two years or whatever. The content of the governance repository is these documents, so any of those authorities and architectures, and then there's the repository itself. As far as processes go within architecture governance, there are several processes that go on, and we saw that in the last diagram. But you've got policy management; you've got compliance. So ensuring that things that are going on are following the architectural direction Dispensation—I just mentioned giving people exceptions for a limited time to avoid getting into trouble, as well as monitoring and reporting. So again, going back up, maybe there's a report that goes to the CEO or to the board of directors to say that the company is aligned with its business architecture. There's business control, environment management, and architecture governance. Now, in a very large enterprise, architecture happens all over the place. You're going to have many layers and levels of governance. You can't just have one group or one team in a 60,000-employee company that's responsible for making these decisions because nothing will ever get done. There'll be a huge backlog. Nobody will be that smart to be able to make all those perfect decisions. So what you end up with are layers and levels of governance. So you're going to have architects that work in groups in many different departments. You're going to have many of those developers work with those architects. They're going to have governance at that level. So a person that works in this particular department can go to their local government to ensure that they're in compliance. But there's not a global government. And again, we got different times and different countries, so drawing geographic lines makes sense as well. So you have the Canadian governance team and the American governance team and the European governance team and things like that. So it can certainly be divided. So, that was architecture governance. I know it was a lot. Hopefully, that made a bit more sense. Next, we're going to talk about the architecture content framework. Stay tuned for that.

4. Applying the Architecture Content Framework

Well, hello again. Welcome back. In this lesson we're going to talk about this specific exam requirement: how to apply the Torah Architecture Content Framework. So says the TOGAF 9 specification, but the Content Framework provides an underlying structure for the AD that defines inputs and outputs in greater detail and places each deliverable in the context of the enterprise's holistic architecture view. So this is a great example of how TOGAF words, things, and things don't often make a lot of sense, but what they're saying essentially is that the Content Framework is a way of organising the inputs and outputs in very specific detail, defining relationships between each of these inputs and outputs, and putting it into context. So the other thing that the Togaspect says is the ContentFramework should be used as a companion to the ATM. The ATM describes what needs to be done to create an architecture, and the Content Framework describes what the architecture should look like once it's done. That's an awesome description right there, and I pulled that right from the spec. So again, the AD is a process, and so you follow it step by step, step by step. But the Content Framework is sort of a snapshot of what the architecture should look like once it's done. There are now other content frameworks besides TOGAF. One, Zachman has a framework, and there are other frameworks that you could use besides this. But the ADM's Content Framework is an option. I am putting this on screen here. This is an example of the Content Framework. This is sort of like the detailed one. This is the summarised one thing to notice here is that it's organised accordingto the ATM phases, pretty much. You've got the preliminary and Phase A stuff at the top, which is the vision. You've got the architecture. So the B, C, and D architectures in the middle And of course, you've got the opportunities and solutions. Migration Planning (ENF) ENF), Governance (GN) And so the documents relate to each other like this. The Content Framework also comes with extensions. And so obviously, what we just talked about was the AD outputs going into this content model. Well, you can have other parts of the AD that go into governance, as we just talked about in the previous lesson. Well, there are extensions to the Content Model for Governance. If you go into the Together specification, you can see how adding governance into the content model changes it. As a result, those governance logs and the things you need to record during the governance process, as well as some of the other extensions to the Content model, are visible on screen. These are optional. You're not going to use all of them, but if you want to, they're there. I'm not going to cover them in detail. I don't think that they're on the exam in that detail. Simply understand that this is the content model. and you can now pick and choose the extensions that go on top of it so that you will have an architecture that looks the way that it's supposed to. So that was the content model. Next, we're going to talk about building blocks and how those are used. Stay tuned.

5. Applying the Concept of Building Blocks

Hi there and welcome back. In this lesson, we're talking about building blocks. The exam requirement is to apply the concept of building blocks. So if we go to the Tog Nine specification, Part Four is devoted to the content, framework, and building blocks. And it says a building block is a package of functionality defined to meet the business needs across an organization. So I have underlined your package of functionality. So you can think of either an architecture building block or a solution building block as being the architecture. Building blocks are a concept, an analogical construct of this functionality. So for instance, the customer service function could be a building block. If you've got a product or service that needs customer service, you could say this box on the screen is related to customer service. It's an architectural building block. Now, if you've got customer service software, you've got the underlying system that supports the agents that make the phone calls and receive the phone calls. That's a solution. So that's a building block for solutions. So again, it's a package of functionality that can be plugged in wherever you need it to meet the business's needs. Very generic. The other thing is that a building block has a type that corresponds to the content method model. And so the type is an actor; it's a business service. Like I said, customer service is an application. It's a piece of data. Those are examples of building blocks. The entire department is not a building block, it is a type. Next, a building block has a defined boundary and is generally recognisable as a thing by domain experts. I'm surprised that this wording is in the specification, but it is. But if you look at it, if you're an expert in architecture and you're an expert in customer service, you'll be able to look at the function and you will say, "Yes, there's a boundary there." Customer service begins here and ends there. When a customer service person enters an order into the system for the customer, we move into the sales function; we don't move into the customer service function, et cetera. You can draw a line, and there's no greyness where the boundary exists. A building block may cooperate with other interdependent building blocks. So this is an important concept, is that building blocks don't offer all the stand alone. You can build the building blocks on top of other building blocks, right? So within the customer service building block, you could have the ability to accept inbound calls, you could have the ability to accept faxes, the ability to accept emails, the ability to accept to do outbound calls, right? All of those sub-functions are also building blocks. So maybe the ability to receive emails and act on them is a building block that can be reused independently of the phone call function. So these building blocks can be as large as you want or as small as you want. You can have building blocks within building blocks. So a good building block has the following characteristics. So it considers implementation and usage and involves exploitation of technology and standards. So in the customer service example, as more people start to tweet and you want to add the ability to respond to Twitter messages to your customer service function, this building block evolves over time. So you've suddenly used the customer service building block in another architecture. When you add the ability to respond to tweets, that function becomes sort of implicitly part of that function. It can be assembled from other building blocks. Like I said, it may be a subassembly of other building blocks. So the reverse is true, and ideally a building block is reusable, replaceable, and well specified. The example with the customer service function is that you could potentially outsource the entire function. So everything you've defined as customer service, you can do it yourself. You have your own team within the same building answering the phones, making the phone calls, responding to emails, and then one day you can say, "You know what, we've got this company in the Philippines that is going to do the call service function." So you don't have to change your architecture. Now, maybe there are some technical things below that the solution has to change, but the function of customer service doesn't necessarily change depending on who's doing it. That's an example. So, to sum up, an architecture is a set of building blocks depicted in an architectural model and a specification of how those building blocks are connected to meet the overall requirements of the business. So this is the important bit: When you think of an architecture, it is essentially a set of building blocks. So zoom in one level deeper and you've just got this function. Talk to the sales function, talk to the service function, talk to the database function, talk to this—these are all just boxes that are talking together. You can zoom in even deeper and see more detail on those. I grabbed this from the spec. I sort of zoomed in. As you can see, the ADD phases include building block components. So this one is Phase A. You are doing a high-level model using building blocks, using candidate building blocks that are not necessarily finalized. You can see that phases B, C, and D also use building blocks, developing the baseline, developing the target, and performing the gap analysis. Those have building-block components to them. And phase II, which is when you associate the gaps with work packages Gans building blocks Coming up next, we will talk about stakeholder management techniques. So stay tuned for that. Thanks.

Hide