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

Before We Start

1. What is Enterprise Architecture?

Hi there. I want you to understand TOGAF at a high level before we even get into chapter one of the TOGAF specifications, because the specification doesn't really do a good job of explaining exactly what TOGAF really is and what it's used for. What we need here is an informal introduction to TOGAF before we get into the formal one. So what is TOGAF? TOGAF is an architecture framework and is the leading standard for enterprise architecture. Like other architecture frameworks, the main purpose is to define the desired future state of an enterprise and the steps required to reach that future state from where we are in the present state. TOGAF defines the future state of the enterprise—what it calls the target architecture—using a process called the ADM, the Architecture Development Method. The Adm is the central thesis, the core, and the heart of TOGAF. TOGAF contains a lot of other things to support this process, like a way of storing and classifying documents, a governance model, reference models, and a way of developing other architecture capabilities, among many more. So you'll have to understand all of that eventually. But the first thing to understand is that there is a process for defining an enterprise architecture. So what does that get you? Why does a company need architecture? Well, that's a good question. The architecture function is what connects the overall long-term strategy of the enterprise, as defined by the executives and the board of directors, into an actual plan that gets implemented evenly across the organization. So imagine the board of directors deciding that the enterprise should move more and more of its services to an online form and start to phase out some of the in-person services to customers. This is a goal that might take many years to fully implement. It probably needs to be implemented in phases. It can't just all be done at once. So how does it do it? How does the CEO communicate? Does he just go and tell the vice presidents one day, and then the vice presidents pass the message down to their managers, and the managers pass the message down to their employees? Is that how it works? Of course not. What this needs is a plan. Someone must step back and define which services can and cannot be made available online. It needs someone to see if the underlying applications, data, and technology are already there to support such a move or if we need to make changes to the way the company does business. To support that, it needs an architecture group. Then those architects can work with the various project managers and business managers to break that work up into phases and make it happen according to his schedule. So TOGAF, and then the ABM, is a process for turning the overall executive strategy into a work plan that gets implemented. It's also a cycle that repeats. You set a goal for the future; that's called the architectural vision. And then you slowly move your business application data technology into that, meet that goal, and then when you reach that goal, you can set a new goal instead of a new vision. The ADM process is so generic that any company can modify it and implement it. That's why it's an industry standard. So, to summarize, TOGAF contains a process called the ABM that helps you define the future state of the enterprise. You can figure out what steps are required to get to that future state from where you currently are. TOGAF contains many other tools and processes to help manage that. In today's fast-moving business environment, it's important that all parts of the business are aligned and moving in the same direction when change happens, because change is always happening. If an enterprise never changed, you would not need an ARC architect. But very few enterprises are like that. I hope that gives you a clearer picture of what an architect does and what TOGAF is. Now, let's get into studying for this exam.

Hide

The TOGAF 9 Level 1 Certification

1. Details of the Exam

Actually consists of two exams. There's the Part One exam and the Part Two exam. Now both exams can be taken together, which means at the same time during the same session, or you can book them and take them separately, like days apart or weeks apart, however that works for you. Part One tests your understanding of the TOGAF nine specifications. It goes into the definitions, the concepts, the phases of the ADm, the Enterprise Continuum, etc. In general, it's testing one concept at a time. And if you pass this exam, you can call yourself TOGAF 9: The Foundation. The Part Two Exam is actually more about taking the TOGAF and applying it to several scenarios. So you'll be given several paragraphs to read about a particular company and their particular problem. And at the end of that reading, you are asked a question and have to choose the best answer among four based on the TOGAF spec. If you pass the Part Two exam, you can call yourself TOGAF Nine certified. And of course, they are dependent on each other. You must pass the Part One test before you can take the Part Two test. And this course focuses on Part One. I do have another course talking about Part Two. Let's talk about the part one exam. This exam is taken in person at a testing centre local to you. There's no online version. It has 40 multiple-choice questions. You only need a 55% grade to pass, which means 22 right out of 40 questions. You have 60 minutes to take those 40 questions, which are about a minute and a half each. It is a closed-book test, which means you cannot have any reference material. You cannot bring anything with you. Don't bring your notes; you can't bring the spec. You basically have to do it from memory. You do have the ability to review all of your answers, all 40 answers, as much as you can within those 60 minutes before submitting. So you can go back and forth if something strikes you that you remember from a previous question. Okay? So if you still have time left, you can review those questions after submitting the test. You'll be graded immediately; you'll know if you passed or failed the moment you get up from your chair. Okay? and you'll leave the exam center. Part One: TOGAF Foundation On screen are the eleven major areas of the TOGAF Nine specification. That part one exam is testing you. You can see the number of questions and the area of study in this course. I've tried to cover all of these areas. So you're going to have your basics and core concepts in the next lesson. Later on in the course, we're going to get into the Enterprise Continuum. There's a standalone lesson for that. All of the ADME phases I'm adding a lot of videos going into each of the Adm phases, one by one, step by step. and those types of things. So as you can see on the screen, the ATM questions are the majority of the questions. And the enterprise continuum and building blocks are also getting lots of points. So if you're going to study those two or three things and you know them very well, then you're guaranteed or almost guaranteed to get more than 55%, right? So here is a little bit more about the testing process. First of all, there is a cost. Currently, it costs $320 US currently. And of course, this is going to be localised to your currency. Canadians will pay Canadian dollars. other countries, it will be in your own currency. The test is available through Pearson View testing centers. It used to be Permetric, but they switched to Person last year. Go to the website at Pearson View.com and see where there is a test centre near you that offers this test. The great thing about the website is that you can book the test online. You can pay online with a credit card. You'll find a map of the testing centres near you. You can find out which testing centre provides the test because not all of them do. After booking the test, if you change your mind, you want to postpone it, you don't feel like you're ready, or something comes up, it's very easy to go to the website and change the date of the test or the location up to 48 hours before the time of the test. So be sure to make that change in time so that you don't miss out. Now what happens if you fail? If you fail, two things happen. One is that there's a minimum waiting period of at least a month before you can take the test again. And the second thing is that there is a fee for taking the test again. Now you may want to pay the $320, but I think you can go to the Open Group and get a discount on the retake. So if you fail the test, that initial 320 that you paid is gone, and you have to wait that month. Okay? So coming up next, I'm going to give you a little quiz, and after that we're going to get into the basic and core concepts.

2. Introduction to Basic and Core Concepts

So in this section of the course, we're going to talk about the basic and core concepts of togas. An architectural framework is three things: It is a set of definitions. It involves processes to create an architecture and manage that architecture. And it is a content metamodel that allows you to store the content. In this course, of course, we're going to get through all three of these things. But in this section, we're talking about the basic and core concepts. So it's very important that you understand why you have to define the enterprise, what an architecture is, what an architecture framework is, the concept of architecture domains and BDAT, what adm gets you, and things like that. So coming up in the next two videos, we'll talk about the basic and core concepts of TOGAF.

3. Basic and Core Concepts

About the basic and core concepts of TOGAF. The definitions in this video and in the next are part of the basic and core concepts of TOGAF. I recommend that you go to the spec, look up these core concepts, and read the definitions yourself as well. And, of course, we're talking about enterprise architecture because it's an important part of the exam. So what is enterprise architecture? Let's break it down here. An enterprise, according to the specification, is any collection of organisations that has a common set of goals. Now, if you are an architect and you're in a very large organization, a multinational company with 60 offices, 300,000 employees, and divisions within this company, the chances are actually very small that your goal is to create the architecture for the entire company. Okay? You're not going to be creating hundreds of applications that are interconnected or all of these things in one architecture. You're going to define enterprise as the business unit that you happen to be working for. So, if you work for a multinational corporation with many divisions, but only one of them, that's the enterprise you're concerned with. You're not concerned with the larger enterprise. The other thing is that your company might actually be technically divided into two or three different corporations for legal and tax purposes, but you're all working together. That could be one enterprise. You could have partners, okay? You could have systems that partners have access to and that they need to be able to log into. They're a user; they're considered a stakeholder. They're not technically employees of your employer, but that's part of your enterprise. So enterprise is really the scope of the architecture that you're going to need to be defining. Now, within the TOGAF spec, they give two definitions for the term "architecture." I've taken a slice out of it. The number one definition says a formal description of a system is needed to guide implementation. and I've underlined the guide implementation part. So think of an architecture document as something you can hand over to the development team, or to the outside contractor with whom you're developing these systems, and they'll be able to refer to it and say, "Oh, that's how they want us to do this." So it's a guide for the implementers. And number two is the structure of components, their interrelationships, and the guidelines governing their design and evolution over time. So with architecture, it's a high-level view of a system, okay? So the structure of components and the relationships—these are the boxes and lines—mean that system A sends data to system B. System B does something with it, sends it to System C, which is going to be defined within your architecture document, and you're going to be able to make decisions, yes or no. We should do it this way or that way based on this architecture. So there are rules; there are principles; there are guidelines within the architecture document that guide you into the future, and that makes decisions easier. So why do we need formal enterprise architecture now? The spec, unfortunately, in its normal method, has a very complicated sentence to explain this. The purpose of enterprise architecture is to optimise across the enterprise an often fragmented legacy of processes, both manual and automated, into an integrated environment that is responsive to change and supports the delivery of the business strategy. Wow. What does that mean? Okay, so it mentions the fragmented legacy of processes. So over time, as your organisation has grown in the past ten or 15 years, you've brought on new systems. Not often. Do you just bring everything on at the same time or is it added piecemeal? Sometimes decisions are made that are very shortsighted. Sometimes the business changes and the systems don't change to keep up. You could have systems where entire parts of the system are no longer needed, but you can't really remove them with all this wonderful stuff. So, a fragmented legacy of processes is integrated into an integrated environment. So when you start to do enterprise architecture, you start to think of the system as a whole instead of the individual parts that are responsive to change and supportive of the delivery of the business. The purpose of applications and technology is to support the business strategy. So once the business decides we want to do this, the whole organisation and the technology underneath it need to adapt to deliver what the business needs. So let's break that down. All enterprises have legacy systems. There's no single document that exists that covers all of them. So that's just a fact. Over time, over 1015 years, you may have documentation, but if you're going to be a new employee, you're going to sit down and want to read about the systems; you're not going to look at one document. There's not even usually a single person who can explain how everything works. So Mark has been working here for ten years, but he's moved on to a different department. And you can't just keep calling Mark every time something comes up. Enterprise architecture talks about the plan for the system going forward. And I just talked about this, but you'll be able to make decisions once you decide we are this type of company. We do stuff in an agile way. We only support open systems that are supported, where the source code is available, etc., etc. Once you start making those decisions, that becomes a plan for moving forward. We've all been in this position, where you've worked on this project for nine months. You've tested it, you've got it running in a development environment, everything is great, you're rolling it out to staging, and surprise, something else breaks or there's a last-minute requirement. Now people who have not previously been involved in the project start to become aware of it, and they say, "No, you can't take away this one system." We use it for this. And you're like, what? When did this happen? Nobody knew about this. So you don't want surprises. When you make big changes, there's a term called "technical debt." And basically, the more decisions that you make, the more they accumulate—it's like a big snowball rolling down a hill. Okay? So over time, you make a decision, you make another decision, and these things just drag on until they become a big mountain that you're carrying on your shoulders. So what are the positives of enterprise architecture? Ultimately, you get to a place where, when you're more responsive to change, things are easier. There is less development cost, less maintenance, and less support. The complexity of the system gets broken down. So now you don't have this monolithic application that does 500 things. As you start to break that down, it becomes easier for everyone. The risk goes down. When this complexity and cost are linked to risk, purchasing becomes simpler and faster. So if you do decide you're going to go out and buy this system off the shelf, that whole thing doesn't take two years. It can be faster. We previously discussed Togap as enterprise architecture. It's an architecture framework. And what is an architecture framework in general? Not just Togap, but anything that calls itself an architecture framework is going to have a vocabulary. And by this, we mean when I say "business requirement document," you know what that n architect When I say enterprise, the definition of enterprise has a meaning within the Togo spec. And if you know Togof, then you know what I'm talking about. set of tools or building blocks. And so within the TOGAF spec, there are these chapters that you can go to and say, "This is the capability framework, this is the architecture capability, this is the business capability." This is a way to analyse the transformation readiness of your organization. There are tools within the framework for you to do architecture work—a method for designing the target state. We haven't yet discussed the Admiral Architecture development method, but it is what it is and a set of recommended standards. And so again, TOGAF is going to have certain things that they want you to have a look at, like the triple IRM or the TRM, things like that. So these are the core concepts in the TOGAF standard. This is what you're going to be tested on. This is the part of the specification that matters for this exam. And so the rest of this course is going to be focused on these items. In the next video, I'm going to go through each of these briefly, and we can then review that. So if you do want to look at the definitions, they're in chapter three of the specification. And coming up next, let's get right into the core concepts of TOGAF. So stay tuned for that. You.

4. Core Concepts: Architecture Domains

Alright, let's get into the core concepts of TOGAF. The first of the core concepts is called Architecture Domains, and there are four of them. You'll see the other core concepts of the Toga Standard on screen. I'm going to go through them briefly in one video at a time, and then we'll go through them in more detail. The four architecture domains that are abbreviated as BDAT are one of those fundamental concepts of TOGAF, and that's why it's called a core concept. So what is an architecture domain? Tog calls an "architecture domain" the architectural area being considered. Now, that's not very helpful, but if you looked at the domains, you might make more sense. So if you look at all of the architecture of your organization, it can be bucketed and divided into four major categories. There's the business architecture. So all of your business plans, your strategies, the key business processes, and the needs of the business go into the business architecture domain, and that's where you are looking at the business problems, irrespective of the underlying technology that's needed to solve them. Okay? And the business architecture needs to be done first because it's basically the needs of the business that drive the technology that you're going to need to put in place, not the other way around. The second architecture domain is data. And the data, of course, is the record that you're keeping. The customers, the products, the orders, all of that historical information You need to give it structure to it. When data is passed between applications that falls within the data domain, there's an API that can be called that returns data. All of this is part of the data domain applications. Now, these are the ways that users and customers interface with the technology. And so if you have to have an order entry system, that's an application that falls within the application domain. So the need to enter an order is a business requirement. The order data itself is a data requirement and the application that accepts that order falls into the application domain. Finally, underpinning all of this is the technology, which includes hardware, software, networks, operating systems, and anything else that users don't normally interact with but is required to support the data and applications that support the business. So those are the four architecture domains. And you'll find this repeated over and over within TOGAF, particularly when you get into the AD. Each of these is treated as a separate phase by the administrator, and you must complete the business first, then date applications second, and technology third. So there's an order to them, and we'll get into that when we get into defining the architecture. So those are the four architecture domains. In the next video, we'll talk about the central figure of TOGAF, which is you, the member.

5. Core Concepts: Architecture Development Method

Alright, let's talk about the next core concept, which is the architectural development method known as ADM. The architectural development method is the core concept of TOGAF. It's what we're going to spend the majority of our time on, and it's the heart of the TOGAF. This is the process by which architecture is designed. OK? It's a step-by-step, phase-by-phase approach to defining the architecture, getting that implemented, and then monitoring for change. The Adm consists of nine phases. You can see it on screen as represented by those yellow circles, plus the requirement management, which is centred in the center, which is that orange circle. It is an iterative process. So once you go through the preliminary phase and step onto Phase A, it goes around in a circle. And after some time, when you've defined the target architecture, implemented it, and returned to monitoring, you start the process over. And so if you do it right, this is just a wheel that keeps turning. There are two basic types of architectures that we focus on: baseline and target architectures. Now the baseline architecture is your architecture as it exists today. So that's the meaning of baseline: the current state of the system. So we'll talk about it when we get to the adj. But the baseline approach is often just to go out and document what you currently have. The target architecture is the architecture you want after you've come up with what you need. Once you've decided, okay, we're going to need to implement a brand new X and a brand new Y and modify Z. That's the target architecture. Now, sometimes the target is just too far. You may have to change everything. Maybe you've got 50 systems in your enterprise, and you all know that 20 of them have to be gotten rid of and 30 of them need to be changed. Well, that's just too big a bite to take in one sitting. So what you end up with are transitional architectures, and so you can have a three-month plan, a six-month plan, a twelve-month plan, and finally, within two years, you reach your target. So the transitional architectures are those that happen in between as you're transitioning to the target. We're going to get into Adm much more detail, but this is just that 30,000-foot view. Coming up next, we're going to talk about the outputs of each of these phases. These are known as deliverables, artifacts, and building blocks. Stay tuned for that.

6. Core Concepts: Deliverables, Artifacts and Building Blocks

In this video, we're going to talk about deliverable artefacts and building blocks. This is another core concept, of course, of the TOGAF specification. As you go through the ADM cycle and start creating documents, these become deliverables. Deliverables are contractually specified, reviewed, agreed to, and signed off by stakeholders. Okay? So as you go through this, you're creating a roadmap, you're creating requirements, you're creating definitions, you're creating implementation plans, and you are contractually obligated, basically, to create these documents. And they come as outputs and deliverables. An artefact is an architectural work product. What that means is that as you're creating these outputs, you're going to create diagrams, you're going to create lists, and you're going to create matrices. You might not even include some of these artefacts into the actual documents, but you create them anyway because you need that list of stakeholders, their titles, their email addresses, and their contact information. That's a list. And that goes into an architecture repository, which we'll talk about in a little bit. But an artefact is a small item, which is an anagram of list or something that gets created to go into a deliverable but is not itself a deliverable. Now, as a building block, this is very important, and it's not really covered that well within TOGAF. But you have to understand that an architecture is made up of building blocks, okay? So you're doing this at a very high level view. When you're saying that you need an order entry system, you're not actually designing an actual order entry system. You do not know the classes and the database names, the table names, the field names, and all these wonderful things. You can just say we need an order entry system. It must accept orders, modify them, delete them, archive them, and meet all of these other requirements. But you're not designing the system, you're specifying what it must do. So the order entry system is a building block, okay? And so, anytime you need an order entry system, whether it's for a customer, for an employee, for a support staff member, or for an executive who needs to check on reports, the order entry system stands in as a building block. Similarly, the architectural building block is now a requirement. It's an order entry system. It's called ABB. The next building block of the solution is its actual implementation of that. So if you do have an order entry system that can be used in all of these different scenarios, well, that's the building block of the solution. And so there is a relationship between architectural building blocks and solution building blocks. Of course, an architectural building block is a requirement. The solution is a building block is the solution. And both of these go under the heading "building blocks." Now, we will talk about how these building blocks can then be abstracted; they can be very specific, like an order entry system, and they can be very general, okay? These building blocks are then arranged in a business continuum. We're going to talk about the Enterprise Continuum. coming up next.

Hide