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.
- Enterprise architecture often addresses large and complex enterprise with large and complex systems. How to effectively get to grips with understanding and describing this is difficult. One well known approach is to modularize. In other words, to break the system down into a set of easier to deal with modules in the modeling world, the term component is often used as an alternative. It's common to design components so that they contain or encapsulate other components. They in turn may encapsulate more components, and so on. So, how is this done in the TOGAF framework? Well, instead of modules or components the framework calls them building blocks. So, what is a building block? Well, it's a package of functionality defined to meet the business needs across an organization. Building blocks have a type that corresponds to the enterprise's content metamodel. In other words, a building block can represent a high-level process, an actor, a business service, an application, a data entity. All of these and more are entities within the metamodel. A building block has a defined boundary and is generally recognizable as a thing by domain experts. It might be better to think of it as a thing which has purpose in the context of the system. It may interoperate with other interdependent building blocks. There are two types of building blocks. Architecture building blocks, or ABBs, and solutions building blocks, or SBBs. These relate to a specific area of the enterprise continuum. Let's look at how they're used. First, let's look at architecture building blocks. Architecture building blocks capture architecture requirements. For example, the domain requirements. So business, data, application, and technology requirements of the architecture. They direct and guide the development of solutions building blocks. And architecture building blocks are high-level conceptual or logical in nature and platform independent. And next, let's look at solutions building blocks. Solution building blocks define what products and components will implement the functionality described in the target architecture, define the implementation of architecture, fulfill business requirements, and are product or vendor aware. This means that a solution building blocks might be provided by a particular product such as a software suite provided by a particular vendor. This also means that, in effect, solution building blocks are platform-specific. So, how do you use a building block? It depends on the phase you're in. In Phase A, the architect will consider what building blocks may be used to present the architecture vision. In the early period of an architecture practice, it's possible that there will be few building blocks in the architecture repository. But over time, these building blocks will increase. And so, it may be possible to select building blocks already in the repository or to develop entirely new building blocks. In phases B, C, and D work is done to understand the baseline and target building blocks, the gaps between them, the time taken to fill the gaps, and the impact on the existing system as well as consulting with the stakeholder. Then, after making further checks, and once constraints and other factors have been considered, the architecture is committed to the Architecture Definition Document. Finally, in Phase E, the solution building blocks are identified. You'll then need to consider how the work to fill the gaps identified will be completed. Ultimately, comparing baseline and target building blocks allows identification of the gaps in architecture. Because building blocks can be considered in a similar way to the components of a system. You can consider using them in predefined ways. In this case, they can be thought of as patterns. A pattern can be defined as an idea that has been useful in one practical context and will probably be useful in others. In the TOGAF standard, patterns are considered to be a way of putting building blocks in to context. For example, to describe a reusable solution to a problem. Once a building block has been used to solve a problem in one context, it might be useful in a similar one. Patterns in this context have been used in software development for a while, but have recently been adopted into architecture frameworks as they tend to meet the same needs. If you're developing, for example, object-oriented or component-based software fields, similar terminology might be used. Patterns can be used to help identify combinations of architecture or solutions building blocks that have been effective in delivering solutions that you encounter. Finally, what makes a good building block? So, a good building block should be well specified so that it can eventually be successfully implemented or deployed. Reusable, replaceable as long as their replacement provides the same functionality. Assembled or composed of other building blocks, or sub-assembly of other building blocks. And, particularly in the case of solution building blocks, they can consider implementation and usage, and how it might evolve to exploit technology. And that's the end of this video. Next, we'll be looking at 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.