Part V: Enterprise Continuum and Tools


Chapter 38                             <<< Previous | Next >>>

38.1 Introduction | 38.2 Structure of Part V

This chapter provides an introduction to and an overview of the contents of Part V: Enterprise Continuum & Tools.

38.1 Introduction

It is usually impossible to create a single unified architecture that meets all requirements of all stakeholders for all time. Therefore, the enterprise architect will need to deal not just with a single enterprise architecture, but with many related enterprise architectures.

Each architecture will have a different purpose and architectures will relate to one another. Effectively bounding the scope of an architecture is therefore a critical success factor in allowing architects to break down a complex problem space into manageable components that can be individually addressed.

The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.

This part of TOGAF discusses the Enterprise Continuum; including the Architecture Continuum and the Solutions Continuum. It describes how architectures can be partitioned and organized within a repository. It also describes tools for architecture development.

38.2 Structure of Part V

Part V: Enterprise Continuum & Tools is structured as follows:

  • Introduction (this chapter)
  • The Enterprise Continuum (see 39. Enterprise Continuum) describes a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts, showing how the different types of artifact evolve, and how they can be leveraged and re-used.
  • Architecture Partitioning (see 40. Architecture Partitioning) describes the various characteristics that can be applied to classify and then partition architectures.
  • The Architecture Repository (see 41. Architecture Repository) shows how the abstract classifications of architecture can be applied to a repository structure so that architectures can be organized and easily accessed.
  • Tools for Architecture Development (see 42. Tools for Architecture Development) provides guidelines on selecting a toolset to create and manage architectural artifacts.

return to top of page

Leave a Comment