Pass Your The Open Group TOGAF 9 Certified Certification Easy!

Prepare with top-notch The Open Group TOGAF 9 Certified certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All The Open Group TOGAF 9 Certified certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

ADM: Planning Implementation

1. Phase E: Opportunities and Solutions

Welcome back. We are on to phase E: opportunities and solutions. But first, congratulations. We have together made it through more than half of the ADM phases. As you can see, phase E is now past the halfway mark of the phases, and as they stand in golf, we're now working the back nine. So in the Opportunities and Solutions phase, there are four main tasks. the initial, complete version of the architecture roadmap to determine if an incremental approach is required to formulate the implementation and migration strategy and to identify group work packages from the Toga specification. The objectives of this phase are twofold. One is to generate the initial complete version of the Architecture Roadmap based on those individual gap analyses that we did in each of the four architecture domains. And number two is to determine whether an incremental approach is required or else to do all the changes in one deployment. And if you need to do an incremental approach, we need to start defining the transition architectures that will continue to deliver continuous business value. So our approach based on those objectives is to basically just figure out how to deliver the target architecture. And you can see on screen that there are four components that we need to come up with during this phase. The inputs are again largely the same. We're almost about to drop some of these, but we're still relying on these external reference materials. Product information. This is information about products that are part of the recommendation. So, if we need to implement SAP, you'll need to know how SAP is implemented, the timelines involved, the resources needed, and this is product information. All the rest through number seven come from other phases except planning methodologies, which are how you plan. Going through here, we get towards 13 and 14, where we start to have to create change requests. Now, in an enterprise environment, a change request is basically an approved request to make a change. So if you want to switch email providers from Solution A to Solution B, change requests have to be made and submitted to various places. So we're going to start to take some of these change requests, gather them, and then come up with the candidate architecture roadmap. The steps are pretty straightforward. We basically just have to figure it out—this is implementation planning, of course. So we just need to figure out the key change attributes to determine if there are business constraints. So let's say the company doesn't have a lot of money to do some of this work. Well, that's a business constraint. You'll have to figure out what you'll be able to do with the budget you'll be given. Or let's say you've got a contract for certain services, and it's very expensive to break that contract. And so you've got three years while you're waiting for the contract with that company to end. Those are not their business-to-business constraints. You're going to basically take all of the gap analysis from those three phases, covering the four architectural domains, and put it into one. You're going to review those requirements in those phases as well. the interoperability requirements, refinement, and validity dependencies. All of these are explained in more detail in the toe gas specification. But for the purpose of the test, you don't really need to know each of them individually. You need to confirm readiness and risk. So, for instance, if you're making a proposition that the company do some massive change, changing your entire workflow system from something homegrown to an off-the-shelf system, there is risk, and there's significant risk there. You need to know and understand the readiness of your company. to do those transformations. We need to then also start coming up with a strategy. So how are we going to do this implementation? Not the specific work packages, because that's coming up next. But basically, before you start to define those workpackages, you need a strategy for defining them. Number nine is to identify and group major packages. So as we say, if we're going to change major systems, we're going to group them together into one piece of work, and then this can be done separately, and these are done over this time frame, etc. We need to identify transition architectures. So you've got your baseline, and you've got your target. If you're not going to be able to implement your target architecture all at the same time, what you end up with are phases or stages of it. So if you're going to implement System 1 first, then System 2 second, and System 3 third, those become transition architectures, and you're going to have to start laying those out and say, "Okay, in six months, this is probably what our architecture will look like." And in 12 months, that's what it'll look like. And finally, the finalised architecture roadmap, implementation, and migration plan The outputs again: you've got requirements, specs, and definition documents. The roadmap and implementation plan are at version zero, which are the minimum documents for those things. The artifacts—there are only two. We're now getting to the point where there are going to be almost no artefacts because we've already done the analysis, and now we're starting to inch towards implementation. But there are two. One is a product context diagram. Again, this product is the one that you're using in the target architecture and the number two benefit diagram. And that's it for Phase II. Next up, migration planning. Stay tuned.

2. Phase F: Migration Planning

Hi there. We're back into Phase F, migration planning. As you can see, migration planning is getting closer to the end of the ADM cycle. And I bet you're as excited as I am. The review that we started off with is on screen, but I think it's better to sort of read right from the specification. The objectives are to finalise the architecture roadmap and the implementation plan. Number two is to make sure that plan is coordinated with the enterprise approach to managing change. And number three is to ensure that the business value and cost of workpackages are understood by key stakeholders. The approach is quite simple. The purpose of this phase is to create the implementation plan for the migration plan. in the inputs. You're going to take a lot of those finalised documents from previous phases and use them in the design of this implementation plan. The steps are not simple, but they're pretty straightforward. Number one is to confirm management framework interactions. So the enterprise or the organisation that you work for might have certain frameworks—not architecture frameworks, but business frameworks. These are how they run projects, how they do accounting, and how they do certain business processes. There might be certain frameworks that you have to comply with. This is where you start to understand, okay, when we go into projects, we need to do it in an agile model, a scrum model. We need to break work packages into time blocks, and we need to deploy them in small bite-sized chunks as opposed to big projects. Number two, assign a business value to each work package. Essentially, if you think implementing this new system is going to save your company $500,000 a year, that's the business value. $500,000 a year is the savings or the new business or the profits that you're going to get from implementing this, and each work package needs to have that, which goes into number three, which is the costing, the timing, and the resources to get that value. And so you may find, as we go into number four, that there are things that have high business value that might not cost much or take a lot of time to implement. and those can be prioritized. First, you try to go after the easy wins, the low-hanging fruit, and all the other enterprise cliches. Sometimes you're going to need A before B. You're going to need to change your data model before you implement an enterprise CRM like that. Number five is to confirm the roadmap and confirm the architecture definitions. That is basically finalized, in that these outputs from your previous phases are confirmed. Number six is to generate the plan. Number seven is to you for recompleting the architectural cycle. This is the moment where you can see that the architectural development is over. And now we're moving on to implementation. Lessons learned are something that's done at the end of this process as you're going to implementation, but you're realising you've done things wrong or something happened during the architecture development cycle, so you'd do it differently. Maybe things need to be tightened up. Maybe things need more time. Lessons learned. The outputs, obviously the most important, will be the implementation of Migration Plan version 1.0. You're also finalising your architecture. So your definition, your requirements, your roadmaps—those things are now closed the door.They're not draughts anymore. Reusable Abbs. ABB stands for "Architecture Building Blocks." We haven't really gotten into them in this course just yet, but Amy B's are. Let's say during the process of creating your architecture, you built yourself some building blocks that you could reuse again. So let's say your architecture roadmap is done in a certain way and follows a certain structure. Next time you're going to create an architecture roadmap, you might as well start from a copy of this roadmap and then just put the bits in place that need to be, as opposed to starting from scratch. So what you're doing is taking some specific output, some specific documents, and turning them around and making them into generic things or reusable things. So those are architectural building blocks. The other types of building blocks are solution building blocks, but they have more to do with the technology, have more to do with the solution, and have more to do with the results of your architecture turning into solutions. And so those building blocks can be called SPBS. Number six is when you start to gather requests for architecture work for the next cycle. So if there are some major changes coming downthe pipe, you're going to have to go getapproval to start the architecture work for that. Number seven is the implementation of a governance model. We've talked a bit about governance and there'sa governance section coming up, so we'll getinto that in a few minutes here. But really, you're going to have to start to decide how change gets recorded, approved, and accounted for within your organization. Number eight is a change request for architecture capability. So what that means is that we talked a little bit about the architecture capability of your organization, but that is really the size and the structure and the people you've got in place and the process you've got in place. The support you have from senior levels of management to have an architecture organisation within your organization, an architecture department, an architecture group, So do you need to get approval to hire more people? Do you need to get more serious? Maybe the next phase of your cycle you're going to say, "You know what, we really cut some corners this time, but next time we're going to do this properly." Or maybe you've learned that you can change some of your own DM model, your tailored framework, if you will, and that becomes a lesson learned. We really need to do this a little bit differently. This didn't work. That worked. So change requests are formally written and approved. Things that say "you know what"? We need to really hire somebody to help with this, or we need to make a change to the way the company handles architecture. It's not always the case, but it could be, especially when you're doing it for the first time. Again, as with the last couple of phases, we're getting into this part where there's no artifact. We're done with the architecture definition, and so for the rest of the ATM, there are no artifacts. That is it. And so your assignment is to review Chapter 14, which talks about re-migration planning. Hopefully, this overview has made that reading a little bit better for you. Coming up next, phase G. We're almost done. Implementation governance. See you at the SEC.

3. Phase G: Implementation Governance

Alright, we are back and it is time for Phase G implementation governance. How exciting. Implementation Governance. Implementation governance is phase G. It ensures conformance with the target architecture during the governance phase, which handles change requests, updates the baseline architecture as changes are implemented, and ends when all of the solutions are fully deployed. So this could potentially be a long phase. You've done, hopefully in only a few months, all of the work from phases A through F, and as the teams go and create the solutions, you are now managing that process as an architect. So the objectives—the official objectives—there are only two of them. One is to ensure conformance with the target architecture through those projects. And number two is to perform the architecture governance function. The approach: obviously you want to establish an implementation programme that enables the delivery of architectures. And what this means is working with the solution teams, because not often the architect will actually be there purchasing the products, implementing them, or working on the business side, but you need to work with them to make sure that what they are doing will actually deliver what you are promising. In terms of the transition architectures, if you're doing a phased deployment, you want a deployment schedule that affects the roadmap. So, if the roadmap says we'll have X in six months, Y in twelve months, and Z in 18 months, you have to make sure that those phase deployments, the schedule reflects the roadmap you need to follow the standard for architecture governance. Of course. Number four is to use the organization's established portfolio or programme management approach. So if you're using Scrum or Agile, however, whatever the programme management approaches, this is what you're going to use. And finally, define the operations framework to ensure that the solutions that you've developed are going to be adaptable for, let's say, two years, four years, or six years, so that they're still useful. So the inputs, as you can see here, generally, are all of the existing inputs from the beginning of the ADM: the definition documents, the roadmaps, the request for architecture work, if it exists, and the migration plan. So in this phase, we have to confirm the scope and priorities for deployment. And that was once, in the last phase. You defined the priorities, and now you need to go and actually confirm them with the stakeholders. You need to identify the deployment resources and who's doing what. Is it being outsourced? Are you doing it internally? Do you have to hire a contractor, or are you doing it? Who's doing what? Number three guides the development of solution deployments. Now again, you may not be the tech lead or the person who's actually executing, or maybe you are, but you need to be in the governance role, making sure that development follows your direction. Number four is architecture compliance reviews, which indicate whether or not they are selecting a solution. Let's say they go off and custom-build a new solution for the back end. You need to review those specifications and make sure that they are compliant with the architecture that you've designed and any of those principles, rules, and constraints that are in place. Number five: implement business and IT operations. Number six: post-implementation review and close the implementation. So again, this phase ends when the solutions are deployed. So one of the outputs is an architecture contract. And I saw this term, and it's like, what is an architecture contract? The specification states that it is a joint agreement between development partners and sponsors on the deliverable, quality, and fitness for purpose of an architecture that is not entirely clear. I would suggest you stop after 49 togas. It'll give you some more information. But essentially, if you're going to go off and hire an outside partner—let's say it's IBM—to implement it, IBM Consulting is going to go off and develop something for you and implement it. There needs to be an agreement, and in this case, they're recommending it be written that what's developed and what's deployed meets certain quality and fitness for purpose rules that are set into the contract. And so you've dealt with architecture and the people who are implementing it, whether they're internal or external, who need to promise, swear, and pick a fight that what they're developing is going to match what you envisioned. Number two, compliance assessments So you're going to be creating documents to say, "It looks like Project X fulfils nine out of the ten things that we wanted to do, or what have you, change requests." And finally, this isn't a document, but the architecture solutions are deployed. and that is a result of this phase. And as we said in the last video, we have no more artifacts. So go ahead and have a look at Chapter 15. It's pretty much what I outlined here. Chapter 49 talks about architecture contracts. I don't think it's super important for the exam, but it's interesting to understand what they mean because it's just a term that's probably not used in a lot of enterprises. We're almost there. Coming up next is Phase H, the change management phase. Stay tuned.

4. Phase H: Architecture Change Management

Here we are in Phase H, architecture change management. This is the last phase of theadm cycle, although we still have therequirements management phase technically to talk about. So architecture changes management. Now we're post-implementation of solutions rolled out, and we are now in that part where it's like keeping the architecture alive, ensuring that the change is tracked, monitoring changes to the business, and ensuring that your architecture capability is maintained. So obviously, at the end of deployments, a lot of teams get dispersed and people start working on other things. One of my responsibilities is to ensure that the architects and people in charge—the governor's capability—do not go off and do other things, and we forget about the company's architecture for a few years. And of course, tracking changes is a big part of this. So ensure that the architecture lifestyle is maintained, ensure that the architecture governance framework is executed, and ensure that the enterprise architecture capability meets current requirements. So for approach number one, we need to know what the drivers of change are. So when you're post-implementation and you've reached your target architecture, it's not always a strategic thing to say, "Oh, now we need to think about five years from now." Sometimes change just happens, right? The operating system vendor comes up with a new version, suddenly there are new mobile technologies, and the sales teams are screaming for mobile ways to use your applications. You are basically reacting to reality, and this is what is sometimes called bottom-up as opposed to top down.But these are strategic things to do, too, but that's not always strategic. Number two, the enterprise change management process, determines how changes are managed. So obviously, as requests come in and we need to have this and I would like to have that, you go through a proper change management process. Number three, the ongoing question is: how do you determine what is just a maintenance type of item versus having to rethink the entire architecture and go through the ADM again? So there's a balance between someone saying they need to modify an application to add mobile capability, which isn't a significant change to the architecture versus enterprise-wide. People are getting rid of their desktops and are going to entirely work from their mobile phones. Then you wonder, "Well, then, how does that impact?" and that you may have to go through an architecture phase for that. The documents that are needed are a lot of the stuff that's in the repository, so you'll recognise a lot of them. Here again, we have change requests. So there are technologies that change, and there are business changes. So if your company wants to enter a new line of business, or maybe there's another line that another competitor enters, and any of those lessons are learned, So as you have gone through the implementation process, maybe you've realised that you didn't get the value you were expecting to get. You went and did this, and it ended up costing more than you expected, and the profits are not coming back to you as much as you expected. It happens. That's a lesson learned. And what can you do differently for next time? Or, in the worst-case scenario, do you decide to go back and restart using this application that you were using previously or not? Implementation governance goes on. The architecture contract we talked about in the last phase, any of the compliance assessments—those are all inputs. Again, this is keeping change management alive and the architecture alive post implementation.So the next step is establishing a value realisation process. Again, we're talking about value. And when you did an implementation, did you get the value you expected? Deploy monitoring tools, manage risks, and provide analysis for architecture change management. Create change requirements to meet performance goals. So obviously, if you are expecting to make a certain amount of savings or to cut costs, do you have to then change the project a little bit in order to meet that? Is there something you can do? Manage governance and activate the process to implement, change the outputs, or implement any type of architecture that updates your framework's change. So if you realise that you have to change the way that AD works within your organization, your new principles, any new requests, and the market should work. So again, if you do decide to start thinking about the future that comes from this phase—all of those updated statements, contracts, and compliances—this is a phase that could last an indefinite period of time until your next assignment to redo the architecture. Again, no artifacts. That concludes this phase of architecture change management. Phase H. I suggest you look at Chapter 16 of the TOGAF Specification. Pretty simple. I think we can see that we've really covered A lot of the difficult parts of the ADM are in the BDAT bits. When you're assessing those differences, even the preliminary phase is a bit difficult. We've moved on from migration planning and implementation governance to change management. This is a lot easier from an architect's point of view. Maybe it is or maybe it's not, depending on your situation. But you're monitoring work, you're doing assessments, and you're tracking changes, making sure that the work that you did—the great work that you did—wasn't for nothing. Next up, this is the last bit of the ADM. I'll just touch on it briefly. It's architecture requirements management. If that central hub doesn't have a phase letter, then we'll be right back.

5. ADM Architecture Requirements Management

Here we are in the last phase of the ATM cycle, the architecture requirements management phase. As you can see, requirements management sits in the centre of the ATM cycle and interacts with each of the phases. Through it, it operates continuously during the ADM process. Requirements change all the time, and it doesn't really matter what phase you're in. Requirements management involves assessing the impact of these changes. It could be a new competitor, legislation, an assumption that was later proven, or any of a million other reasons why something changed. Maybe you missed a requirement earlier, and now you have to accommodate for it. As you can see, the TOGAF spec objectives correspond to what was just stated, namely that the requirements management process is maintained for all relevant ADM phases. The objective is to manage architecture requirements identified during any execution of the ATM cycle or in any phase, and ensure that the requirements are available for use by each phase as the phase is executed. Since it's the centre of the hub, it continuously drives the ADM cycle. At each phase of the ATM, the architect should identify which requirements are relevant for that phase. And number three, there is no specific tool recommended within TOGAF for managing requirements. So the inputs are the usual cast of characters: the various architecture inputs, the steps. This one is a little different, but it doesn't have the same straightforward steps as the others. This phase is really about managing the interaction between requirements management and each phase. So the steps are continuous, and the steps are assigned to either requirements management or the Adm. And I highly recommend that you go to the Toka Nine documentation, which I've linked to in the assignment section of this chapter, and look at the steps and the way that they're laid out. So I've summarised them here. Number one is to identify and document requirements, and that's obviously happening. Requirements are documented during the BDAT phases, which are B, C, and D. Number two is, based on the baseline requirements, to determine priorities, confirm stakeholder involvement, and buy in to her parents' repository. So at the end of BDAT, you end up with baseline requirements that need to be approved. Number three is to monitor baseline requirements. And that means you have to keep track of any changes in the architecture that get introduced into the environment. Number four: identify requirements to remove, add, or modify the priorities. And this comes from the AD cycle. So you're creating requirements documentation in ADM. A new requirement comes in; you move things around, remove them if they're no longer needed, or add them. There is also a number five in the overall aspect that says identify change requirements. But these are from non-ADM sources. So you are at any of the phases of the AD cycle, and then a new requirement comes in, and you have to put that down and decide what to do with it. Number six is to assess the impact, and then where do you act on it right away? Do you stop what you're doing? Do you have to go back to phase B or can you finish this and deal with it later? Or maybe you don't have to do anything. The seventh item on the list is the phase H implementation requirements. So phase H is the management of architecture change. And so if there is architecture that needs to be changed, this is fed into the requirements management phase. And number eight updates the requirements repository. Now requirements repositories, which we haven't really talked of before, It is recommended within TOGAF that requirements be stored in a repository. This is different than the architecture repository, where the architecture describes the makeup of the systems and processes within the company. The requirements repository is really the storage place for the business requirements and the technology requirements. These can be the baseline and the target that get stored separately and maintained through this process. Number nine is to implement changes. So if you are in the midst of the ADM and a new requirement comes in, you have to deal with it. And number ten: assess and revise the gap analysis. So if you've identified gaps between the baseline and the target and something changes, you may have to redo your gap analysis. The deliverables include a detailed requirements impact assessment document as well as any updates to the architecture requirements. There are no artifacts, and that is requirements management. That's what you need to know for the exam. Your assignment is to review Chapter 17, which talks about this specifically. I want you to look at the list of steps because they are different than what we've gone through in the past eight, nine phases, and you might want to look into Requirements Repository Chapter 41.6, and the link is here. Well, coming up next, I know you're excited. This is the big one; this is the admquiz, so stick around for that.

ExamCollection provides the complete prep materials in vce files format which include The Open Group TOGAF 9 Certified certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to The Open Group TOGAF 9 Certified certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.