This module takes a deep dive in to the different phases of the Architecture Development Method, focusing on the objectives and approaches to each of the 9 phases. This module is supported by videos and a PDF, and is followed by a quiz to help support your understanding.
This module will cover:
- The Architecture Development Method
- Preliminary Phase
- Phase A: Architecture Vision
- Phase B: Business Architecture
- Phase C: Information Systems Architectures
- Phase D: Technology Architecture and Foundation Architecture
- Phase E: Opportunities and Solutions and Planning Techniques
- Phase F: Migration Planning and Techniques
- Phase G: Implementation Governance
- Phase H: Architecture Change Management
- ADM Requirements Management
This course is intended for anyone looking to understand Enterprise Architecture. It is helpful however to have several years' experience in IT in a variety of roles, or to have an understanding of Enterprise or IT Architecture.
Prerequisites of the Certifications
There are no formal pre-requisites for this course.
We welcome all feedback and suggestions - please contact us at email@example.com to let us know what you think.
- 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.
In a varied career that began in 1974, John Coleshaw has trodden a relatively unusual path whereby his roles have split evenly between Business and IT. In the early 80s he was the Credit Manager for a multi-national electronics company, and at the same time built a computerised financial and credit analysis tool using the original version of the IBM PC. In the mid-80s, whilst performing the role of senior underwriter in the Credit Insurance industry, he managed the IT system, as well as developed an innovative risk analysis tool. At the start of the 90s, as a manager in a financial information company, he developed an early form of expert system whose purpose was to predict corporate failure.
His current career as an IT trainer began in 1998, specialising at the time in Object Oriented programming languages. In 2002 he started developing and delivering IT Architecture training and has now had the opportunity to meet and discuss architecture matters with over a thousand architects. The courses he trains now span both The Open Group (TOGAF and ArchiMate), and BCS.
He has a book to his name, one written in the late 80s on Credit Risk Analysis.