TOGAF 9.2 Foundation
This module starts by explaining what Enterprise Architecture is, and looks at the core concepts of the TOGAF Framework. This module is supported by videos and a PDF, and is followed by a quiz to help support your understanding.
This module will cover:
- Enterprise Architecture
- The Architecture Development Method
- The Architecture Content Framework
- The Enterprise Continuum
- The Architecture Repository
- Architecture Capability
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 firstname.lastname@example.org to let us know what you think.
- There are a number of different operating frameworks that can be used for enterprise architecture. So, what makes up the TOGAF framework? The TOGAF framework is made of multiple elements. This consists of the architecture development method, architecture content framework, enterprise continuum, architecture repository and architecture capability as well as two reference models. We'll cover each of these core concepts in more detail but for now, we'll concentrate on the essentials. First, we need to talk about the architecture development method, abbreviated to ADM. The ADM or crop circle as it's also know, is the literal heart of the framework. Just about every aspect of the framework has some kind of connection to it. All the circles except for requirements management can be regarded as a phase and each circle has an overarching objective that's described buy its name. For example, the objective of Phase A is to establish an architecture vision. Each phase has a more detailed set of steps that are used to meet its objective. Underpinning the ADM is a set of formal documents known as deliverables. These deliverables are passed between phases in order to support the phase. The phases within the ADM are; the preliminary phase, which describes the preparation and initiation activities required to create an architecture capability. This includes customizing the TOGAF framework and defining the architecture principles that will underpin the ADM. Then Phase A, the architecture vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the architecture vision and obtaining approval to proceed with the architecture development. Phase B deals with business architecture and describes the development of a business architecture to support the agreed architecture vision. Next, Phase C, information systems architecture is a composite phase that describes the applications and data that make up the information systems architectures to support the agreed architecture vision. Then, Phase D deals with technology architecture and describes the development of the technology architecture to support the agreed architecture vision. Phase E is opportunities and solutions. This phase conducts the initial implementation planning as well as the identification of delivery vehicles for the architecture that are defined in the previous phases. Then Phase F, migration planning addresses how to move from the baseline to the target architectures. This is done by finalizing a detailed implementation, and migration plan. Phase G addresses implementation governance. This involves the architectural oversight of the implementation. The last phase in the cycle in Phase H, architecture change management. This phase establishes procedures for managing change to the new architecture. In the center is requirements management. This examines the process of managing architecture requirements throughout the ADM. Now that we've covered the ADM, let's look at the other central parts of the framework. First, the architecture content framework deals with how architects can document and describe architecture. It also shows the sort of documents that can be produced and the information that will likely be contained within them. The content framework consists of a model that describes the deliverables recommended by the framework, the artifacts that describe the architecture and a meta-model which describes the elements that could be used in those artifacts. Deliverables are contractually specified and formally agreed documents. In other words, official documents that will be regularly reviewed. Artifact is the term used to describe the lists, matrices and diagrams. These lists, matrices and diagrams are the three ways of modeling architecture. Second, the enterprise continuum is essentially a classification system. It describes and classifies the different types of architecture assets used or developed by the architect. It may well take dozens, hundreds or even thousands of them to fully describe the entire enterprise. It makes some sense to use some kind of classification system in a similar way that a librarian would classify all of the books in the library, which is where the continuum comes in. The enterprise continuum contains two parts, the architecture continuum and the solutions continuum. Third is the architecture repository. This is where all the deliverables and information on architecture assets are stored. Think of it as a kind of folder structure where information can be stored. It can be created using documents or content management tools. Users of specialist architecture tools will also find repository facilities. Fourth, we need to look at architecture capability. Enterprise architecture can often become a complex working environment and architecture capability covers how to manage this complexity. It consists of two aspects, the capability framework and operation capabilities. The capability framework consists of the following key items governance bodies, these govern and direct all activities. A skilled resource pool, this is made up of well-trained and knowledgeable architecture professionals who are assigned roles and responsibilities according to their skills. Project portfolios, architects commonly need to deal with project and portfolio management people. This therefore, forms part of the capability framework as do the relationships between architects and the people involved in business operations. The architecture repository and its associated enterprise continuum classification system is needed as part of the overall capability. Capability is what the architecture can do. Operational capabilities cover all of the common activities that you might expect of a formal department within an organization. In other words, a truly capable architecture practice might be a department with considerable responsibility to control what goes on within that department. TOGAF also gets used with other frameworks. Here you can see the activities of the other frameworks that work alongside TOGAF. This important aspect will be further considered in several sections to come. Te technical reference model or TRM, is one of two reference models that have been part of the framework for many years. However, in the most recent version, the information has been moved into a document that is now in the TOGAF library. Think of this picture as a kind of service catalog, with each of the colored boxes representing a class of service that you would normally associate with information technology systems. Business applications serve customers and are served by infrastructure applications such as mail and office application. Through interfaces, the application platform provides a variety of services to underpin the business applications. And in order for any application to talk to another, there needs to be a communications infrastructure a good example being the internet. Overall, this is high-level information and is often referred to as a foundation architecture. Architects wanting to establish an IT architecture could follow some of the suggestions outlined in this reference model. Finally, there is the integrated information infrastructure reference model, which usually gets abbreviated to the IIIRM. Another reference model that's been recently moved to the TOGAF library. The IIIRM is a subset of the technical reference model that excludes the networking and infrastructure architectures. The consumer and provider applications are the business applications previously referred to and the idea of this reference model is to suggest that they interact with each other via a broker. This loosely coupled approach is, as far as the framework is concerned, the route to enabling boundary-less information flow. Those are the core concepts you need to know about TOGAF. We'll cover most of these in detail in the next module but, before you move on, make sure you complete the knowledge check to test your understanding.
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.