In this video, we will define the ten phases used in architecture development. This Architecture Development Method of TOGAF® is its core. All of these phases or activities are done iteratively in a cycle as enterprise architectures are defined and implemented. As the business continually changes, the architecture will need to change with it. Wherever the business strategy or vision statement document changes happen, this should be a signal to look at what must change within the architectures. Even when the business continues with the same strategy periodically, the application and Technology Architectures should be reviewed in order to keep pace with the new releases of hardware and software and other changing conditions. The primary phase is around setting up enterprise architecture practices and capability. There should be some principles, but not too many here. Try for less than ten. Define for this. And its TOGAF® won’t be used as it is. Then any changes need to be fully defined and agreed upon by stakeholders. While that may be tempting to consider this complete when it’s done, periodically, this should be reviewed and the capability changed if required. As the business changes, the principles and processes may need to change with it and the rest of the phases will depend upon this phase.
[Heading: Development Method. The Architecture Development Method provides a tested and repeatable process and is used for developing architectures. The Architecture Development Method establishes an architecture framework and is used for developing architecture content. It uses transitioning and governance.]
So Phase A is the Architecture Vision. For each architectural developed or architecture developed, it is like launching a project with such as a PMO or like a project management office. The relevant stakeholders must be identified and the other proper scope agreed upon. Similar to a project charter, an Architecture Vision is created and approved before proceeding with any architectural work. So Phase B is where the Business Architecture is developed upon that vision, alright. So then we get into Phase C. This is where the Information Systems Architecture developed based on the vision and the Business Architecture. Now note that this includes both the data and application of architecture domains. Okay. And then we get into Phase D. This is where the Technology Architecture is developed based on the vision and the business and information system architectures. Okay.
So, moving along here, let’s get into Phase E. This is where the opportunities and solutions are examined. This can be considered to be an implementation planning. Or, if the vision is extensive, then implementation architecture. So, into Phase F, this is where migration planning is developed. This is the plan for how to move from the current state architecture to the final state architecture through. And basically, there can be an additional intermediate architecture as well. So don’t think that like, say, Phase F is just one single thing. Phase G is where implementation governance is done. This important phase allows the architects to ensure that the transition to the final state architecture is proceeding as planned. And then, Phase H is where architecture change management is done. Change management for the new architecture should be established. And this is the final phase as such. Now the requirements management phase is not really a phase. Rather, it is something that should be done as required during all of the other phases. As an architecture is developed, various requirements will present themselves and need to be managed to ensure that the result will meet the business need. Often, an enterprise architecture practice will have a number of folks, you know, looking at this at all times.