1. ADM Architecture Requirements Management, Steps 1-5
Into the last bit here. This is the Adm architecture requirements. Management Steps. This is the center of the Adm cycle. It is called a phase, but it’s not really a phase. It is continually operating during the entire architecture development method. It is the process by which changes can be taken into this process, us. So if something happens, you’ve identified a requirement too late, you’ve already passed that phase B, C or D and now you’re into E and beyond and a new requirement comes in. This is the process by which we handle these changes. Okay? It could be legislation, could be some assumption that you have made something that was missed, a new company policy, it’s a change.
So I’ll make several notes before we get into this. First, this is not the typical adm step, okay? So as I went through all of the steps in those many previous videos, this video is not going to really follow that pattern. The lexus of Control passes. And I’m going to back up here to the diagram. But you’ll see the Requirements Management has connections to each of the phases a through H, through these arrows. And so the nexus of Control passes from Requirements Management feeds into any of the phases and the work done in that phase feeds back into Requirements Management. It’s more like a Control hub than an actual place where these decisions are made. I’m going to indicate where this control passes.
So as you go through these steps, you’re going to see it’s either in the Requirements Management Central Hub or it takes place in one of the phases. My own personal assessment, this is my own opinion, but I don’t mind expressing it here, is that the documentation, the toga spec is very light. Some of the steps only have three words and there’s no definition, there’s no description, there’s no further explanation of what those three words stand for. And so you’re just left reading the words and trying to read into what it means. Here’s a quote that I’ll pull out from the togaf spec and I think it’s very helpful. It says, note also that the Requirements Management process itself does not dispose of, address or prioritize any requirements.
This is done within the relevant phase of the adm. It is merely the process for managing requirements throughout the overall adm. So the requirements management Hub is just a control Hub. Changes come in, they get addressed into the adm itself, but they basically are just getting redirected, put into repositories. We’ll see in the following steps. I’m going to pull out an example here just so that we can have something more tangible to work with. So let’s pretend, imagine that you’re in the Phase G, which is Implementation Governance. Now Phase G can last a long time. If you have a lot of transition architectures, you can be many, many months in Phase G. And as an architect, again, you’re monitoring these changes.
You’re making sure that the performance is what you’re expecting it to be. And then suddenly a request comes in from some stakeholder. So this is the It department as a stakeholder that they want the entire company to get onto a ticketing system for support requests instead of using emails and phone calls and things that are harder to track, which is a very reasonable request. And of course, most big companies have this. But for this is a hypothetical example, this is what we’re dealing with. So how do we handle this change when we’re already into, we’ve got architectures to find transitioned architectures, target architectures. We’re already into implementation of a bunch of changes and this change comes in and you’re like, no, I can’t do it in 2015, you have to wait till 2017, January at the earliest.
Well, they’re not going to like that. And it’s, it’s not a process that works for everybody. So we need to be able, flexible to handle this kind of thing. Okay? And all employees of the company will be affected by this. So step one of requirements management says identify document requirements. This is at the adm level. So at this point we’re using business scenarios and we are documenting what the actual requirements, the problem definition is, okay, let’s assume that at this stage, we have not yet received this specific change request. But we’re in this business scenarios process, we’re identifying the problem. Step two says prioritize requirements. So now we’re in this adm cycle.
We want to get this done, that done, this done. We are prioritizing. This is very similar to the work package work that we did. We’re confirming stakeholders that these are requirements and these are priorities. These are being recorded in the requirements repository. And again, this is very similar to Phase enf where we are building work packages and finalizing implementation plan. Step three happens in the Requirements Management Center. Phase itself is to monitor baseline requirements. This is an example of a togaf specification that just says three words monitor baseline requirements. And to me that means we want to see that there’s no changes to the baseline.
Okay? So that as we are going through this process that the architecture as it exists, other than what we’re implementing in terms of the transition architecture, the baseline requirements stay true. So we’re checking for changes in this environment. Now, step four, now we’re getting into back into the adm and it says identify the change requirements. And so based on what the change is, either you’re going to be removing certain things, so it’s possible that the change is going to be, this is no longer a priority. We no longer wish to do this or add new requirements. So in the case of this It ticketing system, it’s a new requirement or to modify the existing requirements.
So again, if a change comes through and it’s like, well, we want to upgrade everyone from 8gb of Ram to 16gb, well, that’s not a super change, it’s just a modification to the existing requirement. So in our example, we’ve got a new requirement, which is this ticketing system. So step five also says identify changed requirements. But now we’re into requires management back into the center phase. Okay, the last step four, we were in the Adm. Now step five in the requirements management phases, identify change requirements and prioritize them. And I believe that the architects and the relevant stakeholders that need to make these decisions in terms of what priorities, you record these new priorities in the requirements repository and ensure that conflicts are identified and managed.
So a lot of what you go through in the Adm steps is identifying conflicts. And this is no different. If a new change comes in, we need to understand this is going to impact this other team, this other project. These are the stakeholders that are affected. We have to make sure that all of this is handled. And finally, there’s a document called Requirements Impact Statement that when this change comes through and we decide to maintain, we’re going to make a statement to say this is what the impact of the change is. And that goes to the architecture team. So that’s the first five steps. There’s ten total steps of this. I’m going to end the video now and we’ll pick up step six through ten in the next video.
2. ADM Architecture Requirements Management, Steps 6-10
Okay, we are into the requirements Management phase, which is the center phase of the adm hub. We are on step six now, which is to assess the impact of these change requirements. We have flipped over to the adm side of this, assessing the impact. So in our theoretical example, we said we are in phase G, which is implementation phase. So what is the, the impact of this change requirements on the current phase? It may be none. We maybe want to continue with the current phase and implement these changes in a later phase. What is the impact on previous phases? So we have to go back baseline and target architectures, any processes? Do we have things in our requirements that are meant to help teams communicate with it.
Where this new requirement would overrule that we meet to decide, depending on whatever the change is, whether we’re going to implement this change immediately or we’re going to defer it to the next round of the adm cycle. And so that’s sort of that go or no go decision. We’ve prioritized this. If it’s got a lower priority, if it can wait, if it’s a bigger impact and riskier impact, we can defer these things. Otherwise we can say, you know what, we can implement this. It’s low risk, it’s low effort, it’s high value. Those are the decisions that we’re making at this stage. In the last phase, last step, we talked about the requirements Impact statement and now again in the adm side, we are also issuing a requirements Impact statement.
And this is like version two or version three, right? Going on to step seven. Step seven also in the adm cycle says implement requirements for Phase H. Now this is a little bit confusing, I’ll try to explain it, but if you’re post implementation of everything and you’re sitting in phase H, this is the monitoring phase, the change architecture, change management phase. You are watching the environment, you’re watching the legislation, the competition, there’s certain drivers that cause change and this is the step, step seven, where this can be implemented if they do not require a new round of the cycle. Okay? So this is different than if the changes are happening while you’re defining the requirements or while you’re implementing, if you’re in phase H, you are able to implement these changes at this point.
Step eight says in this we’re slipping back into Requirements management is to update the requirements repository with information relating to changes requested and it depends on anything that changed, target architecture, transition architectures, any stakeholder views, the repository has to be kept up to date. Step nine, we’re flipping back to the adm. Here is implement the change in the current phase. So we’ve already assessed in step six the impact of the change requirements on the current phase. Now that we’ve gone through seven and eight, step nine says we can implement that change in the current phase. So how does this change affect the current phase.
And finally, the last step of step ten is to assess and revise the gap analysis for past phases. So the gap analysis is done during phases B through D. It identifies the gaps between the baseline and target architectures and depending on these gaps is what drives the requirements. So we have to sort of go back and ensure that nothing was missed, that we’re not now introducing new problems, et cetera. So this is the last step of this requirements management. It’s done in the adm phase. What else is affected? Well, that’s it. And again, this particular step, the requirements management phase, it’s not really well defined.
And so really what that leads me to feel like is within your enterprise, within your company, you need to have a process to manage change. And here are some general steps. Right? The adm has outlined for you general steps that you can follow to manage change. And it differentiates between the adm itself and changes that can be handled by the adm and the central hub that just manages the control. And so as long as you understand that you’re going to really highly customize this for yourself, you’re going to have to define in more greater detail what the actual process is. Create your checklists, have an architecture change management process.
The togaf spec does not do a great job of defining what that process really needs to be. What that means for you is you’re not going to find a lot of detail on this on the exam. You just need to understand that this phase exists and that as I said earlier in the last video, that the assessment and the prioritization and the implementation, that all happens in the adm in a normal phase, this is really just monitoring and updating requirements positories to them. I want to sincerely thank you all. This is the end of the course, the real end. I’ve done a thank you a few hours ago in a previous video, but this is the detailed section. I want to thank you so much for lasting this long, for watching all of this.
