1. Phase F, Migration Planning, Step 1
Okay, we’re on to phase F, which is the migration planning phase, and we’re talking about the individual steps under that. Migration planning is the phase just before the implementation. It’s when you’re finalizing the migration plan that you started in the last phase, which is opportunities and solutions. You’re ensuring the plan is coordinated with your enterprise is approach for change. You’re going to determine the business value and make sure that that’s understood by stakeholders. This is where you start thinking about implementation. I mean, you were thinking about the implementation in the last phase in terms of the migration plan draft, but now you’re getting into costs and resources and timing and all of those final things.
And so we’ve gone through the process of developing the architecture, we’ve created a plan, and by the end of this phase, we’re moving on to implementation. So step one of the seven step process says confirm management framework interactions. So the various parts of your organization have different management frameworks, okay? So we’ve just gone through the togaf process and the adm process that is your enterprise architecture framework. You may have alternate pieces to that, some of the plugins to the Content metamodel, zachman framework or some other frameworks that work with your architecture.
But you have other management frameworks. I’ll give you some examples. One is business planning. So from the business level, from the executive level, from the CEO, and those vice presidents of your organization, they may use a type of framework to do business planning. Okay? So you’re going to, within your implementation, you’re going to have to work within that. So how they spend money, how they make decisions, various check ins that they’re going to require. So resources are allocated, procurement, all those wonderful things. The enterprise architecture, of course, we’re in the middle of that.
So it’s the structure and the context of all of your four domains from business data, application technology. We’ve just gone through that, the portfolio of project management. So project management is a well defined space. I’ve mentioned Scrum a few times. There’s some other project management frameworks, pmi, pmp, things like that, that talk about how you plan and implement projects. And you’re going to have to work with the project management group, project managers in particular, in terms of how you’re going to fit into this process as the architect and how that implementation plan is going to get implemented by the implementers.
And finally, operations. We go through all this planning, and we’ve been talking for a long time, hours now, about planning. But operations is really the group of people who deliver service to the customers, okay? They keep the servers running, they keep the factories open, right? They’re keeping the phone lines open, all of those things that are required to actually do the work. So we go through planning, we go through development, but operations. And so obviously there’s all sorts of operation frameworks and all of those things. So those are the people you have to work with. So that was step one coming up in the next video, we’ll talk about step two.
2. Phase F, Migration Planning, Step 2
Alright, step two of the migration planning phase is to assign a business value to each work package. And so if you’re going to do it all at once, of course you only have the one work package. If you’ve got a number of transition architectures and you’re going to take a phased approach, you’re going to have multiple work packages. And so you’re going to start to give what is the benefit to the business and express that as a value. Is there reduced costs to the business? Is there increased revenue? Do you gain some efficiencies through these work packages? Right? If there are operational costs or there’s future end of life scenarios and things like that. So these are the business values and you’re going to come up with these numbers in this step.
Now also in this step are the issues of the success factors. So when you’re developing these work packages and you’re talking about implementation planning, you need to start thinking about success. And I don’t mean from the point of view of a development project that gets deployed. That’s not of success, that is a form of success. But the real success is the leveraging of the business value, of the acquiring of the business value by the company. And so if you’re expecting that you’re going to be able to squeeze out $100,000 a month of savings through this work package, the critical success factor or the measure of effectiveness is going to be, well, if we can get to 75, 80, 85, whatever that number is, we can call that a success.
If it’s below that, then that was not a success. And then you’re going to have to analyze what went wrong, what didn’t get implemented, if there was a violation of the architecture contract, or if there was just a miscalculation. But we create the business values here and then you talk about what it takes to be successful. Now the togas spec says that work packages are the basis of what gets implemented. And what that means is we’re not yet at the state of evaluating individual projects. Okay? So when we get to implement, we are talking to the development teams and the development managers, we’re going to talk about projects.
We’re going to see we need these six resources to be working on that project and these ten resources working on that other project. Breaking work into projects is separate than talking about these work packages, these collections of value that are being deployed. So at this stage, we’re talking about work packages. Finally, and very importantly as well, is you’re going to have to start to define what the risks are. Okay? So it’s all well and good to say we can squeeze out $100,000 a month of savings, but is that guaranteed? No, it’s never going to be guaranteed. So what are the risks? What can go wrong? What are the things that you don’t really know at this point? What are the outside factors that are going to influence this.
If you’ve got a dependency on another project, if you have a dependency on legislation changing or competitors not doing this as well, maybe you’ve got this plan for a new line of business and your calculations are dependent on the fact that your competitor is not in that line of business. Well, that’s a risk. The whole area of project management, by the way, pmp and pmi has whole books written about assessing risk. And so, yeah, we’re going to leverage risk assessment in this state up. So that’s step two. We’re talking about business value now. We’re actually going to talk about costs. So that’s step three coming up next.
3. Phase F, Migration Planning, Step 3
Okay, this is step three of phase F migration planning. In this step we’re going to estimate the resource requirements and come up with some initial project timings. So this is where we are coming up with the costs to implement our dreams. Here in the last step, in step two, we came up with the values and the benefit benefits to the company. In this step we’re coming up with the costs. So we’re going to do cost estimates for each of those requirements and work packages and projects. Now we have to differentiate here between what are called capital costs and ongoing operational costs.
Even when you’re buying software, software often has an upfront cost and then an ongoing maintenance costs could be 10% of the original purchase price that goes into a support contract or for updates. Then of course, there’s costs of the servers. If you need new hosting, you have people that you need to be hired. Every time that you come up with new applications and new data and new servers, you need the people to run those things. So we have to understand that there are ongoing costs and capital upfront costs. So it sounds simple. Probably you need to do a little bit of work to come up with these accurate numbers. Step three is to estimate the costs coming up next, we’re going to then start to do some prioritization. So stay tuned for that.
4. Phase F, Migration Planning, Step 4
Okay, step four of the migration planning is to prioritize these projects. And so we are going to take an approach and TOGAF recommends that we do this from a what they call quick wins approach or the low hanging fruit. So you get the projects that have low risk. Low cost can be done quickly and easily and deliver the most business value, the most bang for the book. You do those first and what that does, first of all, it gets them out of the way. It upfront. You take your business value and you put as much of it as soon as possible because that’s just good for everybody. And then you’re basically going to do the more difficult tasks in a longer phase and you don’t end up with taking a year and a half to get the first thing done.
So you get some stuff under your belt, the project, the business owners see some benefit right away. So prioritize your projects, you know the benefits, you know the costs. And then you can work out which ones are quick and easy and cheap to do and do those ones first. Now there are risks. We had in the last lecture, we talked about the assessment of risks. In this lecture we’re going to review those risks and we’re going to ensure that they’ve been mitigated as much as possible. Okay? So let’s say for a particular implementation, at any point in time, a competitor might come and launch before you with a better product or a different product or the same product, but just before you if you’ve got long plans.
But to get out a product to the market, having competitors beat you to it is going to take a lot of that wind out of your sales, take a lot of that benefit away from your things. So those become risks and then you start to think about how you can mitigate those risks. So can you get this product out faster, right? Can you get into the market? Can you modify one of your existing products? Can you, can you? Can you? So you start to figure out how can you mitigate these risks? You’re going to meet with the stakeholders, the business owners, the technical leads, the implementers, and you’re going to have to agree on this prioritization. So you’ve got this plan here, everyone’s going to sit around a table and they’re going to say, yes, we agree that that’s the best plan.
And lastly, in step four, you’re going to based on this risk and the risk assessment, you’re going to revise some of your plans. So let’s say you’ve decided on some mitigations off of this meeting and off of this prioritization. You’ve decided that there is a way that you can launch a little bit earlier. You go back and revise your planning, revise your definition document or transition architectures or roadmap, anything that needs to be revised within toga there’s this concept of residual risk this is important to know what’s the difference between initial risk and residual risk? So the initial risk, when you make a plan and let’s just say that there’s a risk involved, well, that’s the initial risk. You haven’t done anything to mitigate the risk.
That’s the initial risk. Once you’ve done the mitigation steps, you are oftentimes left with still some risk, right? Again, there is really not very many things in life that are slammed donk guaranteed the benefits will be realized and there’s not a chance that a single dollar of that benefit would not be realized. So you have residual risk and the residual risk is the risk that’s left over once you’ve done everything you can to mitigate anyways, that it was step four. The prioritization, the stakeholders agreeing on this and doing your make sure the stakeholders also agree that the residual risk is acceptable as well. So now we’re getting closer, we’re getting on to step five. Coming up next.
5. Phase F, Migration Planning, Step 5
Step five of the migration planning phase says confirm Architecture Roadmap and update the Architecture Definition Document. So you want to go and update the Architecture roadmap, including any transition architectures. So we’ve got up to this point, prioritization has happened and we know what we’re doing first and what we’re doing second, what we’re doing third. That’s all been agreed upon. And so now we’re going to go back to the roadmap into the architecture document and make these updates based on these decisions.
Remember, the transition architectures are the architectures that happen after each implementation project, essentially before you get to the target architecture. So if you have three projects to get you to the target, you have transition architectures in between each one. And so you review that update that is needed. Okay, so there’s a table within TOGAF an artifact called the Transition Architecture State Evolution Table. It’s a wonderful name. I don’t think they shorten that, but they should. And what it does is across the four bdat architecture domains, you can map out how those domains progress over time.
Okay, so when you go from transition one, transition to transition three, filing to target, that table will draw you draw a picture for you essentially to see how that transition happens. And again, so if there’s any changes to the approach that has happened up till now, from steps one to four, you’re going to have to update your Architecture Definition document as well. That goes without saying. So that was step five. It’s probably pretty straightforward once you’ve agreed on the priorities, it’s just a matter of shifting things around. Coming up next, we’re going to finalize the implementation plan in step six. So come back.
6. Phase F, Migration Planning, Step 6
Step six is to generate the implementation and migration plan. Of course, this is one of the main purposes of the migration planning phase is to finalize this plan. So much of the detail of the plan has already been gathered from previous steps, right? So the plan that we’ve been working on one through five at this point is basically laid out. So now we just need to finalize it and, you know, go through a proper planning process to get this into a schedule. And so this should also include all of the other projects if there’s dependencies. So let’s say you require all of the desktops of your employees of your company to be upgraded to more memory or to more recent version of Windows.
So if that’s a dependency, that has to be called out and that becomes part of the schedule. So if they’re upgrading everyone’s desktop in January and your deployment time is in June, then you can say, well, it should be fine, but this is a dependency. So this is where you come up with an actual project plan and everyone can tape this to their office wall and it becomes what you’re doing in terms of an implementation plan. Coming up in the last video for this phase. Step seven is the closing of this particular cycle. So let’s get into that.
7. Phase F, Migration Planning, Step 7
So here we come to step seven, which is the last step of the migration planning phase that says complete the architecture development cycle. So in the first set of phases from A to F, we have been defining the architecture and making the plans to implement that architecture. At this step, step seven, we are now completing the architecture development. That stuff is finalized, essentially, and we’re moving into the implementation phase. Of course, we do have change management processes that can handle changes after this point, but at this stage, the architecture definition and the requirements are finalized. oftentimes companies do a lessons learned session where they go around to all the various stakeholders and parties, including the architecture group.
And get people’s opinions in terms of what could be done differently, what went well, what didn’t go well. The next time we go through the adm, we’re going to do this differently and that gets taken into the organization and those are lessons learned and you’ll basically adjust how you do it if it makes sense too. In the toga specification for phase F mentions this specifically, so I thought I would mention it. There are times if you’re going to go through what’s called an iteration process of the adm, this is basically the step at which you go back to phase B. So you do bcde and then F, and now that you’re here, you go back to B and you go a little bit deeper, you get a little bit more detailed.
You’ve created enough of the plan that you can do things a little bit better the second time around. Before you start implementation, it’s up to you whether you do iteration. Iteration is not on the test for the part one exam, so you don’t need to know this. But togaf does have this concept of going through multiple phases and then slipping back and doing them again because you can go a lot faster and learn things in later phases that you can implement back in the previous phase. So that’s it for migration planning phase, phase F, we’re getting into implementation, which is the last two phases of the adm. So coming up next is phase G, implementation governance.
