8. Phase E, Opportunities and Solutions, Step 8
Okay, we’re on to step eight of phase E opportunities and solutions. This says formulate Implementation and Migration Strategy. So you need to create an overall strategy that will guide the implementation of the target architecture and any of those transition architectures that are done before you get to the, the ultimate target. So the first activity is to determine an overall strategic approach. So how are you going to implement these solutions or how are you going to explore opportunities? There are three basic approaches to strategic approach. So approach number one is called greenfield. greenfield is kind of the best place you can be because it’s a completely new implementation.
There’s nothing that’s there existing. You can just get the software, if that’s a software based solution, install it on a server, start playing with it, start setting it up, and then when you’re happy with it, release it to users. There’s no things that are being turned off. It’s not replacing anything, it’s just a completely new thing. And that is called greenfield. So that’s one approach to implementation. The other approach is called revolutionary. And revolutionary is a radical change. And what that implies is that there’s an existing system and you’re going to create a new system that replaces it. And so there’s going to be a day when the old system is shut off, the data is migrated and the new system is turned on.
Okay? So on a Friday night or on a Saturday morning, there’s going to be this migration. And so on the next day, the old system is no longer available. And it’s the new system that everyone works with that’s a revolutionary change. There’s obviously a certain level of risk associated with revolutionary changes because if the new system doesn’t work, it’s very hard to go back to the old system. Okay? So it’s pretty radical. It’s better, almost better, almost always better to have to fix the new system than to contemplate going back. And the third approach for implementation of your target architecture is the evolutionary approach. And what that allows you to do is to, if you’re adding a new capability, it could be a phased in approach.
Okay, so you’re starting to add new features to an existing application. The users don’t have to install anything there’s? No, it’s just a new menu that pops up one day and people start using the functionality in that menu. Okay? That’s an evolutionary approach. Or you can have what’s called parallel systems. And so not switch on, switch off. Both systems are running, the data is being synchronized and when everything is satisfied and everyone’s satisfied that the new system is working, then you can turn the old system off and that’s also an evolutionary approach. Okay? So that’s the implementation strategy. What you’re going to need also is to mitigate and address risks that were identified in the last step, the consolidated gap solutions and dependencies matrix.
And so there’s risk mitigation strategies. One is called quick win. Now I love this because it is really just an analysis of the stuff that you’re trying to deploy. What is the easiest items to deploy that have the most benefit to the users? Okay, so let’s say you give yourself a month starting today, a month from now, you want to deploy A, B and C. What are those and what is going to provide the most value? And those are quick wins. And what ends up happening is that’s a risk mitigation strategy because the users see a lot of the benefit of what you’re trying to do very quickly because it’s a quick win. It’s a low risk approach. It’s not something that’s going to cost a lot of money and take a lot of time.
The other approach is called achievable targets. And so togaf doesn’t really define this very well and the internet hasn’t been very great at defining it either. But essentially if you’ve got an ambitious goal, let’s say you want to replace every system in your business with some big monolithic system, well, that’s super ambitious and super risky. But if you broke that down to achievable Targets and you said, okay, well, I’m not going to replace 25 systems, let’s just replace two, and then in a future phase we can replace three and four, replace five and six, and it’s just sort of like those are more achievable. Okay, so that is another approach.
And then the third approach is called a value chain model. And that’s a well known approach, but basically you’re delivering the value to the user incrementally. So let’s say you’re aiming to get some performance gains out of your application. Do you go from having a slow application to super quick in one go? Or do you deliver the performance gains phase by phase by phase, similar to achievable Targets? But this is more the value that you’re delivering. It goes from 10 seconds to load to 5 seconds. Well, 5 seconds isn’t great, but it’s a lot better than ten. If it goes from five to one, everyone’s going to be pretty happy.
And if you go from one to half a second or a 10th of a second, then you’ve hit a home run. So going from, you know, when you’re trying to achieve a really big goal, sometimes you set intermediate goals and that’s the value chain model. So the stuff that comes out of this strategy is basically what goes into when you’re creating work packages, which is the next step, step nine. And so the quick wins get identified. They’ll get done in the first work package. If you need to break something up into achievable Targets or the value chain model, then you’re going to have two and three and four work packages to deliver those incremental approaches.
So the work packages come out of your strategy here and at the end of this step, you should have agreement between your stakeholders for the implementation and migration strategy. Okay, so you haven’t created the work packages yet, but if you say, we want to deliver A, B and C very quickly, and we’re going to go and deliver enf soon after that, and that’s half of the value. And it’s going to take us six more months to deliver 100% of value, but at least we’ve delivered within two months half of the value. People will buy into that, and that’s that’s part of that step. So that’s the end of step eight if you can get agreement coming up next, I kind of alluded to it, but step nine is the work package of step, and so I’ll explain that now.
9. Phase E, Opportunities and Solutions, Step 9
All right, we’re on to step nine of the phase II Opportunities and Solutions, which is to identify and group major work packages. So your key stakeholders, planners and any enterprise architects should together assess any of these missing business capabilities that are identified in your vision and target. So this is your gap analysis and your roadmap. Okay? So this comes out and using the consolidated Gap Solutions dependencies matrix, you logically group the various activities into work packages. So there’s going to be some things that make sense to be done together. You’re going to have this strategy that’s going to tell you what you’re going to do 1st, second and third. So this may already be pretty simple.
Once you’ve got your strategy done, the consolidated Gap Solutions and Dependencies Matrix comes back into play here. Now you’re going to fill into the solution column of that matrix that says the recommended the proposed solution mechanisms. Okay? So you’re going to need to understand it’s this green field approach or this evolutionary revolutionary. This is where these approaches get documented, whether it’s an existing system with minor enhancements or it’s a brand new system, things like that. And you’re going to classify all your current systems that are under your concerned consideration as either being mainstream. Mainstream means it’s going to be part of the future.
It’s part of the target contain. Contain means it’s expected to be replaced or modified sometime in the next three years. So you’re not going to want to do a lot of major work on a system that’s approaching its end of its life, right? Or replace, which means the existing, existing set of work packages are going to replace this system and you’re going to have to classify this. So you’ve got your toplevel work packages, you’re going to define and refine and analyze these work packages and decide how things are done. You’re grouping work packages into portfolios and projects. So now we’re starting to think about this implementation team, okay? The people, the project managers, the developers, the consultants that are going to be doing this work.
And so we’re going to package these up into portfolios and we’re going to say this work package is done within this business unit by this team, etc. So that’s the whole purpose of identifying these work packages. I mean, it makes it sound simple, but I’m sure it takes a little bit longer to really nail down exactly what’s going to be done when. I mean, you have your roadmap, but now you’re starting to really get an implementation plan together. Coming up next, we’re going to take these work packages and we’re going to lay them on a calendar and this will be interesting. So that’ll be step ten.
10. Phase E, Opportunities and Solutions, Step 10
All right, we are wrapping up phase E here, opportunities and Solution phase. The step. Eleven says create the architecture roadmap and implementation and migration plan. So the first substep of step eleven is to consolidate the work packages and the transition architectures into the official Architecture roadmap, version zero one, which is a high level document that outlines the timeline of the progression from baseline target texture to target architecture. So you’re going to look into at a high level, three months, six months, nine months, twelve months, 24 months.
This is what you’re going to have available to the business. And so this timeline goes into the draft implementation and Migration Plan, which is the second part of this. So the roadmap here is going to get fed into the next phase, phase F, which is the actual migration planning phase. So one of the tips that togaf recommends is that the transition architectures must have a clear set of outcomes. Like I said in the previous phase, tell the business that you’re going to roll out phase A of your plan, but they’re not really going to see anything out of that. The Phase A is necessary, but it doesn’t actually contain any business benefits.
So be clear about that.The implementation plan, which is the second part of this step, demonstrates the activities necessary to realize the roadmap. So the roadmap is going to promise features and functionality and it’s going to say, oh, within six months you’re going to be able to use your phone to book an appointment. And then in the implementation plan, you’re going to actually talk about the teams. And basically it’s a very high level project plan roughly with estimates, et cetera, how long it’s going to take, when you’re going to start, when you’re getting it done, how much it’s going to cost, et cetera.
So that is Phase E and that is step eleven. So you’re basically going to have this implementation plan. These are outputs for this phase. That’s it for phase E. And we’re going to maybe it’s time to take a break, maybe you want to get up, stretch your legs, have a glass of water. We will get into the next section, phase F, which is the Implementation and Migration Planning. As you know, we are out of the architecture definition. We’re now into the planning a bit and after F comes the implementation, which is really the wrapping up of the architecture bits over into the final stretches of our architecture work here. So stay tuned for phase.
