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.
- It's probably not surprising that a busy and effective architect practice will generate a lot of documents, diagrams and other architectural artifacts. So nothing could be more appropriate than creating a library to store it all. And exactly like book libraries, the facilities provided by the framework are a classification system and a repository. So, what exactly does this library look like? The term Enterprise Continuum is a bit intimidating. And at first sight unlike anything else you've dealt with. In reality this is an elegant approach to how all architecture documentation is cataloged and stored. In order to understand this, let's start by considering what a continuum is. A continuum is a range or spectrum bounded at either end and you can place multiple points on a continuum too. However whilst it's closeness to the previous point means it will be pretty similar. It won't be exactly the same. And if you compare those two items with this final point, the presumption is that it will be significantly different. So, how does this idea translate into the Enterprise Continuum? Well to start with, the continuum is represented by four columns. Each column has a name. Foundation, Common System, Industry Specific and Organization Specific. The foundation area on the left is very generic. But as we look to the right, the continuum gets more and more specific. Fundamentally, the Enterprise Continuum will consist of multiple architecture assets. Some of them are resources used to guide systems development. Such as patterns, data models and reference models originating from within the organization or from external sources. Some of them are used directly to represent systems. These assets can also be referred to as building blocks. All of these assets fall into the four areas that are identified in the continuum. So, let's look at these four areas of the continuum in more detail. Organization Specific assets are the most valuable to the organization. They should be tailored to the way your enterprise does business. Your core processes and bespoke systems fit in this category. They may be core competencies which other enterprises find very difficult to match. Industry Specific assets are more general. Applying just to those enterprises operating in a particular industry. The banking industry for instance, uses certain technologies to print bank notes and to store large volumes of money. The film industry has sophisticated software to develop the fantastic CGI effects that we've all become very used to. When you get to the Common System however, assets here can be used by any enterprise. Things like relational databases, security, networking, printing, archiving, file streaming, document management to name a few. But these things didn't suddenly magically appear from nowhere. They stem from foundational work. Such as, the theory of databases, the principles of encryption, the fundamentals of communication systems and these are all examples of foundation assets. The important thing to remember is that the left of the continuum represents general concepts that benefit enterprises as a whole which underpin more specific architectures used within industries and at an organization level. The Enterprise Continuum promotes the reuse of architecture assets throughout the architecture processes of the ADM. The Enterprise Continuum can be divided into the Architecture Continuum. And the Solutions Continuum. The Architecture Continuum row is meant to represent conceptual and logical assets or ideas. The Solutions Continuum row represents physical implemented solutions. This is a very important aspect. The ideas within the Architecture Continuum are used to direct, guide and support the eventual physical solutions. It's worth remembering that in the Enterprise Continuum is the context of the enterprise itself. Which includes things like drivers, strategies, organizational structures. The deployed solutions represent actual tangible physical solutions. So, we've mentioned architecture assets. What exactly is an architecture asset? Well, we'll look at what assets are in the next video where we apply the Enterprise Continuum.
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.