TOGAF 9.2 Foundation
This module looks at some of the concepts introduced in the last module, namely the Architecture Development Method, Building Blocks and the Enterprise Continuum. 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
- Building Blocks
- The Enterprise Continuum
- Applying the Enterprise Continuum
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.
- In the last video, we looked at the make up of and rational behind the Enterprise continuum. Now we need to understand how it's used to classify architecture assets. Well, there are a number of different ways that assets can be classified. A good starting asset example, is the idea of an Enterprise resource planning system or ERP. ERPs provide a one-stop solution for any enterprise that needs to manage its finances, customers, orders, products and people. When enterprises are considering introducing new systems a very common starting point will be to sit down and get some idea of what those systems need to do. The idea itself could be regarded as an architecture asset. In this case, the idea is to consider an ERP. A well known example of a physical implementation of an ERP is SAP. The ERP architecture asset is an effective supporting and guiding SAP as a solution asset. In formal modeling terms, this can be represented by a relationship known as realization. The SAP solution asset is said to be realizing the ERP architecture asset. Let's imagine an enterprise in the insurance sector that wants to implement an ERP. There's an adaptation of SAP that's tailored to work in the insurance context. It retains the fundamental features of the common system version, as well as embracing requirements for the insurance industry. In the formal modeling world, the SAP insurance version inherits everything from the more general common system version. In this case, it's a form of specialization. So what is it about the specialized SAP asset that makes it suitable as an insurance related system? It is being guided and supported by an industry specific framework called Acord, and Acord is an architecture asset itself. It's an industry specific one, specialized from a foundation asset. ITIL, the IT infrastructure library is an example of a foundation specific solution. The Acord framework identifies processes, data and information, as well as capabilities and components all related to the insurance industry. The insurance enterprise manages to get an agreement that SAP will adapt their system to support the enterprise whilst retaining the fundamental insurance capability. We can now classify this asset in the enterprise continuum. By placing the asset at the rightmost edge it reflects that extensive adaptation of the asset that has occurred. If the adaptation was not complete, then the asset could be positioned further to the left. Just how far to the left would be up for discussion. So how was the adaptation arrived at? Well, the insurance enterprise had a good reference model which describes their practices and processes in sufficient detail. This allowed the enterprise to tailor the solution to suit their needs and make specific requests from SAP. Classifying assets requires both a complete understanding of the asset and consensus as to exactly where it should be positioned in the continuum. Some of you may disagree with where we've positioned the assets, that's fine, there's no absolute answer. The TOGAF framework recommends using building blocks to represent architecture of systems. Here the assets that qualify are the three SAP items. Each one of these is an actually system that can provide functionality to the enterprise. All of the other assets are there for reference purposes only. The entire process shown has simply been to classify a set of architecture assets. There remains the matter of how this information is retained all of the classifying activity takes places within the context of the ADM. Architecture assets naturally group themselves to reflect the phases of architecting. For instance, there are business related assets used in Phase B. Application and data related assets in Phase C and technology assets in Phase D. Given all of these assets, it's useful to talk about the architecture repository. It should be regarded as part of an overall enterprise IT repository and is a suggestion on how the different types of documents can be stored. It has seven areas. The architecture meta-model which organizes the information in the repository. The architecture capability which supports the governance of the repository. The architecture landscape which contains views of the architecture at a particular point in time. The solutions landscape which contains solution building blocks. The standards information base which captures standards and regulations. The reference library that provides guidelines and the governance log which records enterprise governance activity. The architecture landscape and requirements repository have been divided into three areas to make it simpler; strategic, segment and capability. These are known as levels of granularity. Strategic architecture is the coarsest grained with a longer time period, broader scope and a higher level of detail. This represents the long-term planning of the architecture. Segment architecture is slightly more fine-grained. It can share some of the characteristics of strategic architecture but sits below it in the organizational structure. Capability architecture is the finest grained level of enterprise architecture, the equivalent of solution architectures. The standards information base is important. It embraces both standards and regulations that apply through the bedapt domains. For governance purposes, all building blocks should be standards compliant. Finally, let's place our insurance assets in the appropriate storage areas. The ERP idea is a useful reference item. The general SAP is a solution building block. Acord is a reference asset. SAP organization specific, another solution building block. The insurance specific SAP is another solution building block. Notice how this asset evolves. Initially it's placed in the architecture landscape as an architecture building block but then it's changed to become an organization specific reference model. The remaining assets can now be stored in the reference area also. And that's it for this module. You'll now have the opportunity to check your understanding with a knowledge check and you can check out all of the graphs and charts used in this model, in the resources section.
About the Author
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.