Pass The Open Group TOGAF 9 Certified Certification Exams in First Attempt Easily

The Open Group TOGAF 9 Certified Certification Practice Test Questions, The Open Group TOGAF 9 Certified Exam Practice Test Questions

Want to prepare by using The Open Group TOGAF 9 Certified certification exam practice test questions efficiently. 100% actual The Open Group TOGAF 9 Certified practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. The Open Group TOGAF 9 Certified exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with The Open Group TOGAF 9 Certified certification practice test questions and answers with Exam-Labs VCE files.

The TOGAF 9 Level 1 Certification

7. Core Concepts: Enterprise Continuum

In this video, we're going to be talking about enterprise continuum, which is another one of the core concepts of the TOGAF 9-1 spec. So what is the Enterprise Continuum? Now, it's a bit of a funny word, right? It doesn't actually tell you what it means. A continuum in this case just means a line. and you can map your architecture along this line. Now, for your specific company architecture, it's going to be along the right of the line, but as you get more generic, it'll be mapped to the left. The idea is basically that you can go off and find generic solutions that exist for your industry or for businesses in general. You can grab these generic solutions out of these other organizations, bring them into your company, and use them to create your architecture. It is really just a view of the architecture repository. It's not a separate thing. It's a way of classifying the items in your architecture repository as either being very generic, industry-specific, or common systems or foundations. On the left, the most generic is on the left; the most specific is on the right. There are four classifications within Enterprise Continuity and within TOGAF. The most generic classification is called foundation architecture. The CRM is an example of a foundational architecture. It is just something that is so generic that it can apply to any situation or to any company. Okay? And if you take a look at the CRM, which we will do later, you'll see that it's not very useful because it's so generic. Common-systems architecture is a little bit more specific. Okay? So the Triple IRM is a software services model within TOGAF. And that's an example of a common systems architecture. It's a slightly more specific rule that doesn't apply to every situation, but it applies to many. The industry architecture classification is now getting a little bit more specific because it's specific to your industry. So if you're in the banking industry, you can use some banking industry architectures, or if you're in education, or if you're in any other industry. Those are organisations that provide architectures that you can borrow. And finally, on the most specific side of the continuum, is the organization-specific architecture. I saw another video within this course specifically about this. It goes into it in more detail with more diagrams. So keep an eye out for that. This is the Enterprise Continuum. It's one of the core concepts of TOGAF. It's something that I found it difficult to understand when I first started reading about Tograph. It took me a little while longer than you would expect to really grasp this as a concept. So this is the classification system. Coming up next, we're going to talk about the things that are being classified, which are the contents of the architecture repository. So stay tuned for that.

8. Core Concepts: Architecture Repository

So in this video, we're going to talk about the next core concept, which is called the architecture repository. So what is the architecture repository? I tend to think of the architecture repository like a filing cabinet. It is just the place where all of your architectural outputs are stored. This is where the deliverables go: the artifacts, all of the different views of the architecture. So if you have to create one architecture document for the technical people, and a different document for the business people, and a different document for the financial people, they all come and get stored in a repository. Now we just finished talking about the Enterprise Continuum. And so the Enterprise Continuum classifies the contents of the repository based on how generic or specific they are. The repository contains architectural output at various levels of abstraction. All of your reference documents, the TOGAF specifications in the repository, your industry architectures It's not just stuff that you do with your company. Now there are various components within the repository. These are the drawers of my cabinet. So you've got the architecture metamodel. Okay. The architecture capability is the template for which you do your architecture. So when you're going to be assessing the capability of your architecture group, and you do this from time to time, these documents get stored into their own drawer within your repository. The architecture landscape Of course, this is the biggest part. This is the part that we concern ourselves with. It is the baseline and target architecture. All of the architecture documents that are needed are the outputs of the phase, which are going to the architecture landscape standards information base. So these are external standards. Okay? So TOGAF is a standard. You may have SIF or other standards that you're wanting to comply with. Okay? So all of the standards that you need to support—the documents for that—are going to the SIB drawer reference library. So these are external reference models. So if you do go to your industry and get an industry architecture or a common systems architecture, these get stored into the reference library. These are things that you're going to adopt in your enterprise. Finally, the governance log. So as a governance organisation that starts to make decisions and says yes, we will accept this type of design, we're not going to accept this type. We have these principles, all of the decisions, and the log going to the governance log, and we'll talk about a lot of these things in terms of the governance log in a separate video. The architecture capability is also a separate video. So this is covered in the course. So those are the architecture repositories. the core concepts that you need to understand about this. If you have any questions, of course, leave them in the discussion board at any time. This video, the previous videos, and the next videos are on the right of the course, and you just enter a question. and I'm here to answer it for you. In the next video, we're going to talk about establishing and maintaining an enterprise architecture capability as the core concept of TOGA. So stay tuned for that. Bye.

9. Core Concepts: Architecture Capability

Okay, now we're down to the last of the core concepts, which is the concept of the architecture capability of your organization. So what is the capability of architecture now? Obviously, the architecture functions and supports the business. It takes business goals and designs, applications, data, and technology to meet those goals. And so how good is your company at this? Do you have a person who is a full-time architect, or is it just a part-time role? Is there a group of architects? What about the manager of this group? Are they devoted to architecture? Is there a governance board? Do you follow all of the proper processes and procedures that are lined out in TOGAF? So obviously you can rate yourself on a scale of one to ten, say, for how good you are at architecture. And so maybe the one is that you're just starting out—you've just hired your first architect. Nobody really knows what they're doing. It's an experiment, really. You're just starting out. It's at basic level one. But then you can work your way up to a nine or a ten where architecture governance is strong and you've got a group that supports it. Everyone knows what they're doing. You're firing on all cylinders. That's sort of the rating scale. And the other question is, does your company support this architecture? Does the CEO and the executive team respect the architecture's decision? And what happens if you are trying to get an architecture developed? And then the head of the IT department says, "No, we're not going to do that." Or the implementation group says, "We don't think we need to do A, B, and C. We'll just do de and F." Once you start having problems, how does that get resolved? What are the various rules and responsibilities? So, once again, we have business architects, data architects, technical architects, and the governance board. So everyone's got a part to play. Again, your skills as an architect, how well trained you are, how good you are at these job templates, the processes you have in place, So that's it. Those are the core concepts of TOGAF. Hopefully, they made sense to you. Like I said, a lot of these are covered elsewhere in the course. And so don't feel like if you don't understand something, that's it; you are stuck. Feel free to go on, go to those videos, and get deeper into them. Go ahead and read the Togas specification. Part one covers a lot of these things, and hopefully, after this set of videos, that will become a lot easier for you to do. Coming up next, now that we've gone through the basics and core concepts of TOGAF, it's time for a quiz. So stay tuned for that.

ADM: Starting Out

1. Introduction to the ADM

And now we come to the AD. As I said previously, this is the most important part of the exam, and it is. The Architecture Development Method is the way in which an architect defines and implements the architecture. It consists of a preliminary phase plus eight phases arranged in a cycle A through H, with hand requirements management sitting at the center. The ADM cycle is meant to be done sort of repetitively. So you go from A to H. You're going to pause on H for a while until another change in business comes along, and then you can kick off through A again. You never really need to go back to the preliminary phase more than once. The preliminary phase allows you to get prepared to get into the Architecture Development Method. You have to define what the enterprise is. You have to gather the tools if you're going to use any kind of software, if you're going to use other frameworks, if you're going to have Toef and Zachman's Scrum method and all these other frameworks, and you're going to figure out how that is going to work together. You're going to customise the ADM for your company. Once you get through all of that, you're ready to start. So this is the AD. In the following set of videos, we're going to go through each of these phases one by one. Later on in the course, I get much more detail into each of the phases of each of the steps. So we have the overview coming up next and the detail later in the course.

2. What is the ADM?

Hi there. So in this lecture we're going to be talking about Adm. The AD stands for Architecture Development Method. The TOGAF nine. One specification defines ADm as a method for developing and managing the life cycle of an enterprise architecture. It is basically a set of nine phases, a preliminary phase plus eight phases that make up a cycle that surround the continuously ongoing Requirements Management Phase. Each phase is itself made up of steps. You can see here the basics of the AD cycle. At the top, you have a preliminary phase, sometimes called Phase Zero, and it's only done once. Next, you have a series of eight phases labelled A through H, arranged in a cycle. All of that is surrounding the continuously ongoing Requirements Management Phase. Now, all phases have inputs, steps, and outputs. The outputs, which are, as you know, deliverables, are in the form of documents, and they get saved to the architecture repository. Knowing the phases, the inputs, the steps, and the outputs is key to passing the certification exam. The ADm is designed to be generic and fit into most enterprises, but it can be modified or extended to meet your specific needs. So you can create your own AD for your own enterprise that is unique to you. For example, if your company's proxy is very heavily technology focused, like Cisco, which makes routers, you may want the technology requirements to come before the business requirements, and you can certainly modify the EDM to do that. Or if you have a smaller company and you can't support all of the faces and all of the steps that are needed to create an architecture, you can actually trim back on that. And some of the outcomes do not have to be as complex. That's a high-level overview of what the ADA will cover in the following video. We'll talk about the phases of the AD, and then eventually we'll go through them one by one. Yeah.

3. Brief Overview of the ADM, Part 1

Hello, and welcome to this overview of the Adm. In this and the following two videos, we'll go over each of the stages of adoption and provide a general overview. Later in this course, I'll go through each phase in more detail. And then even later in the course, we're going to go into the steps—the individual steps of each of the phases. And so the ADM is the central thesis of TOGAF. It's the most important thing that you need to know about TOGAF. And so we're really going to dive deeper and deeper into this. I prefer to go at it in layers where you get this overview first, more detail second, and much more detail third. And hopefully, that will help you understand TOGAF a lot better. So you can see the picture of the AD on screen. The architecture development method It has a preliminary phase up top; that's the first thing that you do before you've ever gotten into the DM itself. You only do it once. And then the AD cycle goes from A through H in a circle. It's called the architecture development cycle. And then, when you're done with H and you're ready to start architecture again, you go back to A. So it's a circular, iterative process. The requirements management phase is in the center. This interacts with each of the phases. So if you get changes during the development of the architecture, you can handle changes using the requirements management process at any phase. So you could be in phase A, and suddenly a change comes in, and you handle that. Maybe you go back to B and update that in C and D, and you're back into E. This whole thing, ADH, is sometimes called the Architecture Development Cycle. Now let's talk about the preliminary phase. As I just said, it is the first thing that you do before you get into the AD. and you only do it once. It is the planning and initiation of activities that will set you up for success with architecture definition and implementation. One of the things you must do, and one of the goals of the preliminary phase, is to define what the enterprise means to you. and it's going to be slightly different for each of us. So if you're working in a rather large organization—a government or a company that has many different lines of business—chances are very good that you're not responsible for every line of business and every application and for every interface with the customers in your entire organization. So this is the fragmentation of architecture—the partitioning of architecture. And so you are going to have your own definition of what this enterprise means to you. And so as an architect, you may work with this business unit only. And this business unit has ten applications that they run within their portfolio. And so your enterprise is that business unit, those applications, and anyone who interacts with those applications. Okay. Enterprise also concerns itself with outside partners. If you have people who are contractors or vendors—and they can log into your systems through some type of VPN—they're integral users of your applications. Those are also part of your enterprise. You're going to choose frameworks. We're talking about TOGAF, and so obviously one of the frameworks you'll probably choose is the TOGAF framework. But you may decide that for the implementation and the service management of your enterprise, you're going to go with ITIL, which is a standard for service management. And that means you're going to have to swap out some of the steps of TOGAF—migration planning and implementation, governance, and those things—with your ITIL steps. And we're going to get into tailoring TOGAF in a second. But you're going to choose frameworks. Maybe you need COBIT for architecture governance. And so that will be another change to your specific toga. For that kind of framework, you're going to evaluate the various capabilities and maturities of your enterprise. So is your enterprise or the type of place that is resistant to change okay? Is it going to be very difficult to make wholesale changes? Are you going to have to do things one step at a time, drop by drop, to get the company to move? And what is your capability? What's your architecture capability? What are your enterprise capabilities? What are you good at? What are you not good at? What do you need to get better at? Your architecture principles are very important. So these are the guiding lights that are going to take you through certain decisions. If you go and follow certain principles and say that whatever you're going to do is going to be in the best interest of the customer, et cetera, then those make some decisions a lot easier. People will come to you with things that help them, but don't help someone else. And it's like, Oh, this goes against one of our principles. The vision phase is Phase A. It's the first phase of this architecture development cycle. And so the vision phase is really where problems are defined and solutions start to get formed. It's a high level. We call this in Tokyo zero one level." This results in a very preliminary document that identifies the problems. It's a very business-focused analyst role. You're going out, you're talking to stakeholders, and you're going to say, "These are the three things that we really need to address, the most important things, and these are the solutions." We're going to emphasise this more, go more online, provide more customer services on the web, et cetera, et cetera. and that becomes your vision. You're going to go out and sell this, and you're going to go to various stakeholders and say, "We're going to become a much more customer focused organisation with a lot more online services." Customers will help themselves. They won't be able to call, and they won't need to call our call centre to get anything done, and so on. And so you're going to go out and sell that to various people, and hopefully they're going to love it and they're going to say, "Yes, we need this." That is the high-level vision of 0.1. This is also the point where you get your Statement of Architecture Work approved. And the Statement of Architecture work is a project approval for the job that you're doing, which is creating this architecture. You're going to have a project plan; you're going to have a scope, resources, or any kind of roadmap to getting the architecture bits done. So when does your job need to be delivered, when does the sign-up happen, and when does implementation start? KPIs and metrics. KPI stands for Key Performance Indicators. And so the key performance indicators are the measures of success. And so at this stage, you're going to say, "Well, if I can reduce costs by $500,000 per year, that is a measure of success." If I can take out 4 hours per week of this person's time and free it up for other things, that's a measure of success. You are going to go through your statement registration work and define some of these measurements. A communications plan is very important. There's going to be a lot of people who have an interest in what you do. But some people are more important than others. TOGAF contains a communications plan activity where you're going to basically rank people. Now there are people who are important, but they're not going to have a lot of input into the plan. And there are people who have a lot of input, but they're not very important. And everything in between, okay, so you'll need a communications strategy. Not every single person needs a meeting, but every single person needs a weekly email update. Once you've gone through that, I said, you're at this high level of vision. You've got the solution pretty much mapped out. You're going to create this online system where all customers are going to be able to help themselves a lot more. You've gotten basic approval for that. Now you're going to get into more detail. To has this acronym called BDAT, whichis a business Data Application technology. Of course, the business section is the one you're going to develop first because the business requirements dictate what the technical requirements are going to be. So you're going to develop the baseline business architecture. To version 1.0. Baseline means the current architecture. How does your business currently operate? What are the business processes? How does an order come in? How does the customer get served? How does an invoice go out? Those are your business processes, and this is your baseline business architecture. The target architecture is the future state. It's the ideal state. It is the direction you want the company to take. Okay, if you're standing here now and you want to go over there, there's the target. And version 1.0 again finalised business requirements. And so now, at the end of Phase B, you've got your architecture. When you identify the gaps between the baseline and target, these become your requirements. And so let's say you've got a state where customers have to call to get anything done. There's no system online that allows them to do anything. And the target state is that you want them to be able to go online and do something, and then the gaps are that thing, right? So that's the business architecture, and you're going to find very similar steps as we go into data and application. It's the DNA and the BDAT. They are done separately, but they can be done in any order. They can be done at the same time. They can be done sequentially. It's up to you. You're going to develop the baseline and targetdata architecture for this finalised version 1.0. You're going to develop the baseline application architecture to version 10. Again, we're going to get a lot more detail into this when we get into these videos for these phases. But this is the overview. We're going to identify the gaps between the baseline and the target. And finally, there's the technology architecture again. This is the T in the dot acronym. The baseline and technological architecture get developed to their final versions. Version 1.0: The technology architecture exists to support the business data and application layers. You also identify the gaps between the baseline and the target. Hopefully you can see these steps are very similar between B, C, and D. It makes it easier to remember. And when you get into the exam, you'll know that this is what you basically need to do to define an architecture across the four domains. So that's it. We're at the end of the architecture definition part. At the end of Phase D, you've got a fully defined architecture for business data applications. As we get into it, we're going to start to consolidate those. But I'm going to pause the video for now, and we'll take it up again in the next video.

4. Brief Overview of the ADM, Part 2

Alright, we're going to get back into the overview of the AD. Now we're going to get into the rest of the phases. Phase E of the Admission Opportunities and Solutions Phase At the end of Phase E, we're going to have a complete version of the architecture roadmap. All of the gap analyses from B, C, and D get consolidated together, and you've got an architecture roadmap. Then you need to determine if an incremental approach is required. Sometimes you're going to make a bunch of analysis in BC and D and you're going to say, "You know what, we just need to swap out this and swap that, and that will solve a lot of our problems." And you can do that in one step. Sometimes, though, you're going to have so many things to do that it makes sense to break up the work packages into incremental work packages. These are called transition architectures. So you have your target architecture, which is the final state that gets you to meet the definition of the target architecture. But then transition architectures get those states in between as you increment one project, a second project, and a third project, and then you formulate the basic implementation of a migration strategy. So how are we going to break this out? What does it make sense to do first? What does it make sense to do second? You're going to group work packages so these three or four things can be done together, and those two things will be done later. And so, at the end of Phase E, you've got yourself sort of a basic plan. Phase F has to do with finalising this plan. So now we're really getting into laying things out on a project schedule, working with the project managers, working with the implementers, getting estimates for how long it's going to take to develop these projects or to outsource these projects, and putting them into an actual schedule. You're going to make sure that whatever plan you're coming up with matches your enterprise's approach to change. And so what that means is, again, if you're working in an enterprise that's very resistant to change, and it takes a lot of effort and a lot of work just to make small changes, we'll make sure your plan is based on small changes. And if your company is more risk-taking, things move quickly, there's agile development, and deployments are redone every six weeks, you might approach change differently than in that previous business value. Of course, you can't recommend a change if you can't explain what the value of it is. So change for change's sake is sort of shunned. If you can put a dollar value on it, if you can say you're going to save this much time and save this much money, okay, you're going to get this information quicker, and you're going to be able to make decisions more accurately. Those are the business values that you need to put together. And this is part of the sales process for getting this all approved. And again, you're working with project managers. You're talking about implementation costs, resources, and who's going to do it? Are you going to outsource it? You're going to have internal people doing it. And by this phase, the end of phase F, now you've defined the architecture, you know what you're going to do, it's all broken up into work packages, you've got a schedule and a plan, and you're basically done with the architecture. The architecture is defined, the plan is in place, everyone is agreeing, and that's when you move on to the next phase, which is implementation. Now your job as an architect during the implementation phase is to ensure that the implementers are conforming with your architecture. And so if you lay out that you need an order management system, it needs to have these features and these functions, and your primary job is to make sure the one that they choose has them as it's going through deployment, development, and testing. The test plan includes these requirements that you've identified, and if things start to have problems, then you start to address those governance issues. Of course change happens, and during the implementation it might be that something's not possible, it might be that there's a new version out, it might be that this company has gone out of business, it might be that support for this is no longer possible, et cetera. And so change happens, and you do your regular governance duties. And the implementation team might say, "It would be easier for us if the requirement was X," and you can approve that or deny it. As soon as something gets implemented, your job is to update the baseline architecture, which is the current architecture. So if you're in the state where you're redoing transition architectures, as the transition architecture goes live, then the baseline architecture gets updated. Phase G ends when solutions are fully deployed. So you're at your target architecture, not your transition architecture. Phase H is the last phase of the ADM cycle. It's architecture change management. One of your jobs here is to ensure that you don't lose architecture capability. This could last. Once you've implemented your target architecture, you may not have justification to go right back to redefining your architecture, right? Hopefully not. So you have to keep the architecture functioning. You also want to ensure that governance is occurring, so that change comes in and changes get approved, denied, and logged, and that following proper architecture governance, your architecture capability needs to be maintained. So team members that leave get replaced, and you improve. If you want to improve as an architecture group, you address any monitoring, so there are changes to the business, there are changes to your industry, there are competitors who come, there are technology changes, Microsoft comes out with new versions of things or whoever, and then these change requests come through. The centre phase is a bit complicated. It's the centre of all of these, and it's always going on. So it's not part of any cycle. There's no specific time when the need for management starts. As changes come to the requirements, management has a process to address them, which can have an impact. Do you go back to phase B and re-address this if the business has a new requirement and you're already past the business architecture phase? Maybe there's more discussion that needs to happen, or is it an amino change that you can just sort of roll in? It doesn't really impact you. There are lots of different ways that change can happen. So that's the end of the ATM overview. Like I said, we'll get into more detail on each of these later in this course. I want to talk about a few more items relating to the ADM, and I'll do that in the next video.

5. Brief Overview of the ADM, Part 3

Hi there, welcome back. And in this video, we're going to talk about that last section of the overview of the ADM. and in this particular video we're going to talk about iteration. It's important to note that iteration is not mandatory. If you're going to be implementing the TOGA aspect within your organisation, feel free to just follow the steps A through H and then back to A and just do a normal "one phase at a time" approach. This is not covered in the first part of the exam as well.So if you're just interested in the Part One exam, you're not interested in the Part Two exam. You can skip this as well. But look at the diagram on screen. There are many different ways that you could iterate through the ADM. One of the examples is called architecture development iteration. They've been given names. And so we can give an example: the baseline first architecture. This means that you go from B to F only thinking about yourself. With the baseline architecture, you don't address the target, and you don't address the gaps. So it's very quick to go through the architecture. The business data application technology consolidates them from B to F, and then you go back to B. And now you can start thinking about the target architecture based on your architectural vision. But then that doesn't have to be as detailed. You can return from B to F and finally let light pass through the target architecture. Then, on the third pass through, you can get into the real on the third pass through.This is just one option. There are many different options in this kind of iteration. Another example is a target-first architecture where you concern yourself mainly with the target architecture. and that the baseline side is what's done last or done very lightly. There's an iteration around transition planning. You can see there's a loop between ENFarchitecture governance, which is G to H. Okay, the architecture capability Now as an organization, you have a certain level of architecture capability. The preliminary phase is where you establish your architecture capability and evaluate your architecture capability. And so you might want to iterate once you're done with H or you're back to A; you may want to say, "Okay, let's readdress our architecture capability." Where are we assessing it? Where do we want to be? Implement new tools, hire new people, and organise ourselves differently. Okay? So, halfway through the H and A steps, the architecture capability can be iterated on. So at this point, I do want to encourage you. There was a lot of talking about the AD. If you've been watching the video straight through, you might want to take a break. Maybe it's time to get up, get a cup of tea or a coffee, have a break, and come back tomorrow. It's up to you. But this will be a good period for you to stop because now we've overdone an overview of the ATM. We're going to take a quiz. So stay tuned for that. And then after this, we're going to get into each phase individually, one video at a time. So take a break if you wish. Take the quiz. see you on the other side.

6. Preliminary Phase

In this lesson, we're going to talk about the preliminary phase of the ATM. The preliminary phase of the ATM consists ofthe preparation and initiation activities that are donebefore you get into the main adm cycle. It is in this phase that you define what the enterprise means. You choose the frameworks that you're going to be using, hopefully including TOGAF. You evaluate your own enterprise's maturity and capability and its ability to adjust to change. And you define architecture principles, which will be the guiding lights that will drive you as you're making architectural decisions throughout the process. The objectives of this phase are to, one, determine the architecture capability desired by the organization. So you may be sitting at a point right now where you're just getting started with formal enterprise architecture. Well, in this phase of the ATM, you pick a point in the future in which you want more advanced architecture capability, maybe a larger team, a better governance structure, better processes, and so on. The second objective is toestablish that architecture capability. Hopefully you have an organisation behind you that supports the formal growth of the architecture capability, and you're able to go out and make those changes that allow you to establish this desired architecture capability. So the approach is that those are the objectives. And now let's talk about how we're going to get to that. First we have to define what it means by "enterprise," and we'll get into that when we get into the steps. Identify the drivers for change and the key business elements that are getting you into this in the first place. In most organizations, you don't just start an architecture project on a whim. Usually there's something that happens that says we need to make the following five changes because of A, B, and C, and we might as well do this properly. Let's get into a formal architecture framework. As a result, there are drivers that people expect at the end of the process that your solution will be able to solve problems that have already been identified before you even begin the process. defining the requirements for architecture work, which is a project beyond the creation of software and the design of your business processes. The actual architecture work can be considered a project and treated like a project with timelines and budgets. And these requirements for architecture work are the requirements that go into your architecture work. Defining the architectural principles is extremely important. Having these principles allows you to make decisions later on in the process that are unambiguous, which actually makes your life a lot easier. Maybe it's hard to come up with some of these principles and say, "This is what we want to do," and it will be difficult for us to act against our principles. But once you make those decisions, the rest becomes easier. To find the frameworks to be used again, TOGAF should be part of that. However, you may wish to incorporate other frameworks such as Zaccoman and others. defining the relationship between management frameworks within your organization. Going to be a number of operationalframeworks, your computer and It team. I have an operations framework. your project management team. I have a project management framework. Business team. I have a business framework. and this is your architecture framework. and evaluating your enterprise architecture maturity. The inputs—we're going to skim through this. The inputs are some of the least important aspects of the TOGAF exam. So you've got the TOGAF spec, the other frameworks, any board strategies or business plans, and other things. any other major framework operating in the business. We just talked about project management frameworks like Scrum, architecture capabilities, partnerships, and contract agreements. You may be in agreements with companies like Microsoft, IBM, and others to do development work or host your sites, and those might constrain you, and you may not have the ability to do the kinds of changes you need to do. So these are the steps. This is what is important in this phase. The first step is to identify the enterprise organisations that will be impacted. As an architect or an architecture group, you have a domain in which you operate. Now, maybe you're only operating within a single department, underneath a larger department within that organization, and so that's the scope of your work. We'll get into this later, but you may end up doing things that do end up impacting other people, but that's more collateral. Your main work is with the businesses that are your clients and the applications that are under your purview. Okay, that's your organization's confirmed governance and support frameworks. Governance in TOGAF is extremely important. These are the people who carry out the checks and balances, who keep track of the decisions, and who must be fair and transparent. Define and establish the architecture team. It's very rare that there's just one architect that runs an entire company. What you're going to find, especially as you get into larger organizations, is that you're going to have a business architect, you're going to have a data architect, and you're going to have a technical architect. These are domains of expertise, and people cannot be, you know, the absolute top master in all of the domains they need to be. And so an architecture team works together to develop the architecture. Identify and establish the architectural principles. As I said in the Objective section, your principles are very important. There's a whole chapter in the Talk aspect to talk about principles. I recommend you go read it, and you'll see things that you're going to be making decisions about among those business data application technology domains that will guide you when you're making decisions. Taylor To GAF TAAF is not designed to be implemented "straight off the paper." Every company is going to be a little bit different. Some companies are very large. Some companies are very small. Most companies have different concerns than other companies. One organisation might value security above all else. Other organisations may value speed. Other organisations may value taking the time to do it properly. All of these things are slightly different, and you can go into TOAF and adjust it to your needs. For instance, if you do have a very securely consciousorganization, let's say you work for a bank or avery high secure institution, there are things you need todo along the way to add those security reviews. Security is a totally separate specialization. You need to bake that in from the start, as you know, so you can toggle to match your particular needs. Step six is to implement architecture tools. Now, there are some very expensive tools to manage your architecture framework and your repository. All of your documents go in one place: the workflow and how things get approved and such. Other people just do things in file folders. They use Microsoft Word, and they use Physio for diagrams. There's a whole wide range of options for how you're going to create this architecture. Then you can start now within the preliminary phase to decide what tools you're going to use to implement this. The outputs. Again, these are important. You probably should look at them. There are not going to be a lot of questions on the test about them. The Organization Model for Enterprise Architecture This document describes how your company does architecture. Number two is the tailored framework we just talked about. tailoring TOGAF, that becomes an output of this. Phase Number Three is the Initial Architecture Repository. You may have a number of documents, diagrams, lists, and other things that can get pulled together and put into a repository. It's also possible that you've done some form of architecture before and it just wasn't particularly TOGAF. So get those documents together and organise them. TOGAF does have a content metamodel, and you can organise them according to the content metamodel, according to the Enterprise Continuum. I'm going to define both of those later in the course. They're separate videos on the ContentMeta model and on Enterprise Continuum. So check those out. Number four is any restatement of the business principles. So as you've gone through this, the business principles and goals might be at a very high level, may be very vague, and may be very confusing. As an architect, you're going to say, "No, we can restate these." It means the same thing, but it means more to us when we work with it like this. The Request for Architecture Work So like I said, the architecture project is a project, and the requirements for that are a request for architecture work. In technology, we have statements and statements of work. So this is the request for architecture work. Very similar. the governance framework. The governance framework, like the architecture repository, will have locations for documents, log files, project plans, decisions, and your principles. Well, that's it. For the preliminary phase, I'd like you to go to Chapter 6 of the Togas spec link on screen and read through it yourself, skimming through it. Hopefully everything that I've said here has made sense, and that document will be a lot easier to read. We also have a brand new section nine of this course, which goes through all of the steps in much more detail. Hopefully, you'll find a lot of value in that, so check that out. Coming up next, we're talking about Phase A, the architecture vision phase. So stay tuned for that. Bye.

So when looking for preparing, you need The Open Group TOGAF 9 Certified certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, The Open Group TOGAF 9 Certified exam practice test questions in VCE format are updated and checked by experts so that you can download The Open Group TOGAF 9 Certified certification exam practice test questions and answers files in VCE format.