1. Phase E – Opportunities and Solutions
Full name of opportunities and solutions. Phase E is the halfway mark through the adm cycle. You see here, we’re at the 06:00 on that adm cycle, which also means we are halfway through this course. So congratulations to you personally for making it to the halfway mark through this course. The purpose of phase E, Opportunities and Solutions, is to generate the initial architecture roadmap. Remember when we were going through the bdat, phases B, C and D, we were generating candidate architecture roadmap items for each of those architecture domains. And so in this phase we’re going to actually finalize an architecture roadmap, pull everything together and basically say, okay, we want to do this and this, followed by this, followed by this.
A roadmap is sort of a list of work items. It’s also a schedule or a timeline to say we have to do things in a certain order in order to get from here to there. Also related to that are transition architectures. So if you are not able to develop your target architecture all at once to do one giant leap between where you are and where you want to be, then you’re going to have to develop transition architectures as temporary stopping points in between. So let’s say you’ve got these giant plans to change the nature of your business, but you can’t just one day flip your switch or snap your fingers and suddenly the business changes. If you need to implement smaller changes, then those go into transition architectures.
Also recently added in toga 9. 2 is a new objective for this phase called Defined Solution building Blocks. Remember earlier in this course we’re talking about architecture building blocks and solution building blocks. And so in phase E, Opportunities and Solutions is where we start to pull out generalizations of solution building blocks that can be reused in other parts of our organization. The inputs, again, you’ll recognize a lot of them. It does say product information planning methodologies. So as we’re starting to talk about roadmap, we’re starting to talk about planning, migration. We need to know how our company does planning and get involved in things more like that.
You’ll see that those draft architecture documents bdat are part of this, any change requests for existing business. So there may be, as we’re going through this, people requesting to make changes. You’re going to evaluate that through your governance model and the roadmap that you’ve developed, the candidate roadmap that you developed become inputs as well. The steps now we’ve transitioned from defining the architecture, which were all pretty similar steps into the planning, which is a new set of steps. We have to understand how our company deals with change. So corporate change attributes, any sort of business constraints. And so oftentimes we don’t work in ideal situations where it’s greenfield and we can make any decision that we want.
There might be certain contracts that are imposed upon you. You must use this vendor for hosting or there might be certain budget limitations, there may be certain things that are off limits, et cetera. So understanding what you can and cannot do and what your timeline constraints are, et cetera, maybe there’s a new opportunity that must be implemented before September 1. And so you have to reorganize what you want to do in order to get the architecture components in place before September 1, et cetera. So you have business constraints. Also during this phase we’re going to look at our gap analysis.
We’re going to basically consolidate all of those requirements. So the B 3d phases get all consolidated interoperability. So basically sometimes you’ll get conflicting requirements where something needs to be more restricted and also be more open. And so you need to sort of reconcile conflicts among things, make sure that your interoperability between your own units and between outside units are reconciled and consolidated, any sort of dependencies. And so if you can’t do something until something else is done, then you have to mark that as a dependency. You’ll know that you can’t implement this system until the hardware is upgraded, et cetera.
Business transformation Risks. So again, make sure that the business is in a state of knowing that you’ve got certain risks and you’re going to be doing business transformation. This is where you start the migration strategy. So how are we going to implement this? Are we going to hire somebody as our internal team is going to do it? Do we have constraints on them? Identifying work Packages and so your architecture roadmap gets turned into work packages. You can say we need an implementation team to go off and do this six things and that can get carved out into its own project, other work packages get carved out to other teams, et cetera.
Transition architectures, as we mentioned, if we can’t get from the baseline to the target in a single jump. And finally you get an architecture roadmap, which is what you want to do on top of a calendar and your implementation and migration plan, which basically becomes part of project planning where you’re going to now have to bring in people, business units, implementers project managers to put together more of a project plan for getting some of this work done. The outputs from this phase are your architecture definition document to version all the stuff to version 10, your architecture requirement specification, your capability assessments.
You’ve got your roadmap and then the draft version of your implementation plan. So you’re just sort of putting these items together. Now, notice that we haven’t gotten sign off on things yet, we haven’t reviewed everything with everybody and put them to put pen to paper yet. That comes up in phase F. Now we’re, we’re coming to the end of where artifacts are starting to be produced. So there are benefits, diagrams, product context diagram, but unless I’m mistaken, this is pretty much where you’ve now created everything that you’re going to create in terms of requirements in terms of documents.
2. Phase F – Migration Planning
To F is called migration planning. Now we are getting very close to implementation and so we are going to finalize the architecture roadmap and finalize the migration plan, as well as making sure that the migration plan is aligned with what we know to be our enterprises approach to change. You’ll notice that within this phase, the previous phase, earlier on, understanding your business ability to change is integral into having successful changes. Essentially. Also the purpose of this phase is to ensure that the business value and business cost of these work packages is understood. There’s really no purpose to go and propose a million dollars worth of work that’s going to end up having zero impact on the bottom line.
It’s not going to reduce cost, it’s not going to increase revenue. And so we need to have a good story to tell and actually some solid numbers to say we’re going to spend this much money and we’re going to basically save or make this much on the back end. So inputs into Phase F are again all of our reference materials, all of our architecture repository, the vision, the draft requirements and the architecture documents, the roadmap, the implementation plan that we worked on in Phase E. In terms of steps for Part F, we need to make sure that we also understand how our company runs in terms of management frameworks.
And so do we have project management framework, pmp, prints, two, et cetera. We need to make sure that there’s a business value to every work package. So if you’re going to peel off four or five requirements and try to get a team together to implement them, you need to understand this is going to unlock $250,000 worth of value or push us closer to our business goals in some way. Then we start to do more like project planning, which is estimate resource requirements, estimate how long it’s going to take, then we can prioritize certain things.
So if things have very low value or have relatively high cost, you might want to push those things around so that they’re implemented in different orders. We need to confirm that the roadmap and the architecture definition document that we previously created are still valid, so it becomes a polishing stage. At this point, we finalize our implementation plan. So we did a draft version of this in Phase E and now we’ve got the final plan. And at the end of Phase F we basically say, you know what, the architecture development now is over. We’ve designed an architecture, we’ve designed a roadmap, we put together work packages.
We are now ready to hand over these packages to the implementers. There’s a point now in Phase F where we can say what did we learn? What would we do differently next time? How can we grow as an architecture team to make this process even better? The outputs from Phase F are the finalized implementation migration plan version 10. They also finalized all your architecture documents. So the architecture definition is finalized, architecture requirements is finalized. The architecture roadmap we talked about solution building blocks in phase E and in phase F we’re going to have any architecture building blocks.
So can we generalize some of these things and reuse them in other future cycles? Do we need to start more? architectural work is required. And so we can get any requests for architecture work out of this as well? Make sure that our governance model is implemented. And if we did learn something from our lessons learned, then we may need to go back, back to the preliminary phase and touch on our architecture capability. So if there are lessons learned, then we generate change requests and we say we need to hire another person, or we need to modify our Togoff steps for this, or we need to do this part earlier, et cetera. So change requests for architecture capability is an output. There are no artifacts produced. So again, the architecture is done.
3. Phase G – Implementation Governance
Phase G. This is called Implementation Governance. We’re at the left side of the adm cycle now. Now Implementation Governance is interesting because it assumes that the architects are not the implementers. And so our role is not to then change our hats from writing up the documents to then become encoders and starting to create applications. Our role is basically to ensure that the people that are entrusted with creating these applications are doing it. And so the purpose of Architecture Governance is to ensure conformance. An informant is one of those lovely words and it just means that what you plotted out for your architecture is actually being implemented and you’re also performing Architecture Governance.
And Architecture Governance is one of those things where if there is a change required, so let’s say you’ve created your architecture now, but the implementation team says, oh, we’re not able to do it exactly like that, but we have a solution that will actually make it better and cheaper, how about we do this instead? Well, they can’t just do that without coming back to Architecture team and going through the Architecture Governance process. That becomes a change requirement. And then you go and modify the architecture based on if that change is approved. Right? So the inputs are again all of our documentation from the architecture repository, the definition, the roadmap Implementation Governance model.
So how do you govern the Architecture contract? So the Architecture Contract is basically optional in the Toga, but it’s highly recommended. And the idea here is that when you hand over the documents, the Architecture definition and the roadmap and the work packages to the implementation team, it is wise for you to sit down, go through it and get them to commit to sticking to your architecture. And that is usually done through an Architecture contract. And again, if you’ve got a model where if they want to deviate from it, they have to come and do a change request that has to be reviewed and approved, that gets a part of the contract as well.
So they’re not going to go and themselves choose not to implement something or to choose to implement something not according to plan. So the step for Phase G is to make sure that the scope of your changes and the priorities are all confirmed. Identifying who’s doing the development and deployments, the resources and the skills. You’re a guide, you’re not actually doing the implementation, but you’re available to help in terms of making certain decisions or making sure that what they’re discussing is in conformance. You are doing compliance reviews. And so if there’s a team that’s coming up with their own solution level requirements, that you review those documents to ensure they’re compliant implement business and It operations.
And then once they’ve got this deployed, the post implementation review. So you created an Architecture contract with them, they said they were going to do A-B-C and D and you would basically go and need to go verify that. And then you can say, Chuck, yes, when they did A-B-C and D and you can consider the implementation completed. Now, remember that if you have transition architectures, so let’s say you are doing three or four sequential implementations in order to get to the target architecture, then each of these implementations gets reviewed against the transition architecture. But then you go back into phase G for the next phase of work.
And so phase G could be a very iterative thing where you go from one to six on the steps here and then you go back to get the next implementation package done until they’re all done. So I pulled out, we talked about the architecture contract, but I pulled this out from the spec. That the toga standard 9. 2. It says Joint agreements between development partners and sponsors on the deliverables, quality and fitness for purpose of an architecture. So that is from part chapter 43 of the Toga 9. 2 specification, any of these compliance assessments. So as you’re reading their requirements and they’re watching their work and you’re looking at the beta and all that stuff, then that’s part of your outputs change request.
So if they do come back and say we need to make changes to the architecture based on these factors, and then at the end of this, not a document per se, but architecture compliant solutions are deployed. So that’s a major milestone, right? If you’ve developed target application architecture and it’s all implemented, then pop the champagne, right? The ultimate goal is to get to there. No artifacts are produced in this phase. So we are not quite but we’re almost at the end of the adm cycle. At the end of phase G, again, you’ve got solutions implemented, your target architecture.
4. Phase H – Architecture Change Management
The end of the adm cycle. This is Phase H called Architecture change management. Now, Architecture Change Management really is like a holding phase where you’ve done all of your architecture work, you’ve done all your planning, you’ve done your implementation, and now you’re just waiting for changes to happen. The main purpose of Phase H is to maintain what’s called an architecture lifecycle. This includes architecture governance, which is any kind of changes that are taking place within your architecture landscape. They are getting a change request. You’re going through a proper governance process, approving those changes and making sure that the documents are updated to reflect those changes if they are approved.
Finally, you do not want to lose your architecture capability in this part as well. So you might be in Phase H for a little bit of a while, and it makes sense that people will then be transferred to other projects or working on other things. But you do not want to lose your architecture capability. So you have to keep mindfulness of the fact that when you do finally go back and start Phase A over, when you start the next round of architecture changes, that it’s not been 18 months since the last time you’ve done any kind of architecture work, and those people are no longer available to you. So keeping your architecture capability in some form is an essential part of having strong architecture capability.
Now, the inputs to this are a bit immaterial. All of your stuff in your architecture repository is an input. So since you’re not actively creating architecture documents right now, anything that’s in your repository is an input. Your definition, your roadmap, all these change requests that might be coming, governance, your contract, et cetera. The steps for this are interesting. So establish value realization process. So you’ve just gone through this whole process of creating an architecture and getting it implemented now is the job of getting the value. So let’s say you said that doing this piece of work will result in cost savings of $750,000 over the course of twelve months.
Well, you are basically going to want to make sure that that value is realized. And so did this process result in you being able to end the contract with this vendor to cut that particular cost, to shut down this process, et cetera. And if not, then your work is basically adding for expenses and not saving money. So a value realization process is making sure that the value that you thought you would get, you do indeed get. You deploy monitoring tools, you want to make sure that your applications remain in compliance. You want to make sure that you are getting the sales, you’re getting analytics, you’re getting tracking, and those use of those things manage risk any kind of architecture change management, the change requirements.
So let’s say you’re not getting your value, let’s say you expected to develop higher sales for a particular feature, and that’s not actually resulting in the higher sales that you forecasted. Do you need to make small changes in order to meet your performance targets? And if so, that becomes a change request that can be done as part of your architecture governance. And you can go and implement or get someone to implement those changes that will hopefully unlock the value that you thought was there. So basically governance and then the process to implement change. So once you’ve got these change requirements and you start to approve them, then implementing them, the outputs from Phase H.
Now, again, we’re in this maintenance type model. So any kind of architecture updates, if you do need to go back to the baseline, because once you’ve got to Phase H, your target becomes your baseline, your architecture is implemented. And so you have a baseline architecture. But as things change, you can go and update your baseline architecture if you need to change the framework, if you need to change your architecture principles, if you need to sort of again, move steps around, reduce things, any kind of now requests for architecture work remember when we started off on phase a? One of the inputs to phase A is a request for architecture work.
So you might at some point enjoying Phase H, realize that we need to start up a new cycle, then there’s enough changes or the changes are going to be so large or impactful that we should probably do the whole adm cycle again. Well, that gets into the form of a request for architecture work. That’s basically a project kickoff document. And you’re going to get that approved to say we can start a new cycle for architecture work. Statement of architecture work. The architecture contract. So if again, the teams are promising that they did things and any kind of compliance assessment. So as you’re going on making sure that things have not changed in terms of compliance.
So there’s no artifacts that are produced. These are just contracts and documents. So that is the end of the adm cycle, but it’s not the end of the adm itself. We’re coming up into requirements management, which is the center part we’ll talk about in the next video. One of the key outcomes of this phase, phase H, is do we need to kick off a new cycle? Do we have enough changes or significant enough changes to kick off a new cycle? Or can we accommodate these change requests in the course of normal business without having to start the adm over that’s?
5. Requirements Management Phase
Dm, which is called requirements management. You can see that requirements management sits in the center of the adm cycle and has arrows going between all of the phases of the adm cycle. Now technically it’s a phase, it’s the 10th phase of the atm, but it’s something that’s constantly running during the adm cycle and actually can be considered to be driving the adm cycle. It’s a continuous process us for handling change during any phase of the adm process.
And as you were going through the adm process, there are times when you’re going to encounter changes and it’s important to be able to handle changes. You don’t want to be in phase f of the adm and then suddenly a new requirement comes in, an important requirement comes in for phase B and you have to say no, I have to wait until this cycle is complete and then I’ll have to get to that in the next nine months or something. So being able to handle change and adapt to change is sort of a critical skill and that’s why the requirements management phase exists within the adm.
So the purpose of requirements management phase is well to keep itself going. So to ensure that the process of requirements management is sustained throughout all the phases, it also manages change while the adm cycle is in process. Finally, it’s called requirements management and it does actually provide the requirements to each of the adm phases. And that’s why there’s the arrows that go back and forth. So requires management phase actually is more of a flow management. There are steps to find in, requires management within the toga requirements, but you don’t actually do any of the handling of change within the rm phase.
So in my example before when I said that there’s a new requirement that came in for business requirements, well the requirement management flow would cause you to stop what you’re doing and go back to phase B, the business requirements management management and you handle the change within phase B. It also basically is the controller of the repository, the architecture repository, so any requirements that are coming and going between the different phases.
