- In this video, we are going to look at the last two areas of the ADM. Change management and requirements management. Lets start with 'phase H', change management. Enterprises exist in an environment that is ever changing. Some changes originate from outside of the organization and some from inside. Whatever their origin, each change needs to be assessed by the organization to consider whether action is needed. The architects will be involved with this process, having responsibility for deciding what action is needed on the enterprise architecture, so making sure that change is effectively implemented is crucial in order to meet the requirements of the target architecture. Ensuring that the change happens, is what 'phase H' is about. And the objectives of the phase are to, Ensure that the architecture lifecycle is maintained. This means, making sure the architecture development model is continuously being used. As the end point of the ADM is making sure it continues to work for the organization. Ensure that the architecture governance framework is executed, making sure that the principles and governance processes are being followed. And, ensure that the enterprise architecture capability meets the current requirements. This means, making sure that the architecture is performing as it should and all the developed systems work. It's important to understand that change can originate in several ways. It can be strategic or top down, Like when a new senior leadership team take control of the organization. They may notice with a fresh perspective things not being structured in the way that they should. They might want to restructure elements of the organization or the entire organization. This is an example that is likely to instigate numerous changes, and these need to be managed. In other instances, bottom up change might be necessary to correct or enhance existing infrastructure. Technology for example, might be really outdated and even present security concerns that need addressing. Change can also originate from ongoing projects, projects may inhabited by a lack of change within the organization. Any of these examples might create a request for change or RFC. Any RFCs should be handled by the architecture board. Examples of these kind of changes are technology changes, such as; new technology, withdraw of technology or a change in the standards. Business based changes such as changes in strategy, or even business as usual changes. Lets deal now with the final activity in the ADM, requirements management. The architecture development model needs to be able to respond to dynamic requirements, that come from all phases of the process. So, what do these requirements tend to look like? And how should you manage them? Well, there are three objectives of requirements management. One, to ensure that the requirements management process is sustained and operates for all relevant ADM phases. Two, to manage architecture requirements identified during any execution of the ADM cycle or a phase. And three, to ensure that relevant architecture requirements are available for use by each phase as the phase is executed. Requirements management sits at the center of the crop circle and interacts with all the phases. The ADM is continuously driven by requirements management. Enterprise architecture requirements can arise at anytime and so is a dynamic process. Requirements are also frequently subject to change. Requirements management is used to prioritize and identify the impact of change requirements. The ADM phases concentrates on reflecting and describing these requirements in the architecture, as well as managing the gaps that requirements can cause. That's it for this video and this module. Next, you will have the opportunity to test your understanding with some questions in the knowledge check.