Why TOGAF Is More Important Than You Think.
TOGAF

Why TOGAF Is More Important Than You Think.

73 / 100

What is an Architecture? What is an enterprise architecture

Introduction to TOGAF.

In this video, we will describe who is the open group and the multiple components in TOGAF®. So the open group is a global consortium that enables the achievement of business objectives through IT standards. They have hundreds of member organizations which contribute to the consortium and their standards, specifically TOGAF®. Boundaryless Information Flow is how it’s often referred to. And it’s their vision. And very briefly, it means that it has the ability to deliver the required information in an understandable way to the correct people and over systems in a timely and secure way. So TOGAF® itself was first developed back in 1995 and was initially based on research done by the Department of Defense and the US government. After spending millions of dollars and years of research, the Department of Defense gave explicit permission to this open group to use what we call TAFIM or Technical Architecture Framework for Information Management as a starting point for TOGAF®. Now since then, the open group is been very successful and furthering TOGAF® and is now in its ninth version or major version 9.1 at the time – right now. The Open Groups Architecture Forum is the place where changes to the standard are discussed and revised.

Now, aside from the some introductory components, TOGAF® is largely made up of the Architecture Development Method or we often refer to that as the ADM and including some guidelines and techniques. Now these describe how to actually produce the various architectural components required to do…actually have an enterprise architecture. It is a method in that there is an order to do it. So the architectural components should be developed in a specific order for best results or expected best results. The guidelines and techniques provide further information around the practical application of the ADM. Now these are the refinements and suggestions from the architectural forum member over decades of experience of doing enterprise architecture. Now in addition, there is an Architectural Content Framework, which describes a structure for storing all architectural documents and other outputs from the ADM. Perhaps the most important outputs are the reusability architectural components. Then there is the enterprise continuum and tools section, which describes the categorization and storage of the outputs. The TOGAF® reference models including TOGAF’s foundation architecture and the Integrated Information Infrastructure Reference Model, even if neither model is used. Reference models form the part of the foundation of creating enterprise architecture practice.

Finally, there is the Architectural Capability Framework, which centers around building up and maintaining enterprise architectural practice. Now this includes information around the relevant skill sets and business processes required to operate amongst other things. Now TOGAF® is a large standard and framework. And it’s difficult to understand and apply the framework without it being split apart into components. Now note that the intention is for TOGAF® to be considered and applied as a whole framework though. So this splitting apart is merely for describing different pieces in isolation. It is best to apply the framework holistically at first. While it is possible to use pieces of TOGAF® separately and successfully, the full magic of TOGAF® is only realized when the full framework is applied.

Architecure Domain

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

Discussing development method

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.

Leave a Reply