This chapter will help you understand the Enterprise Continuum, its purpose, and constituent parts. It also introduces the topic of tools standardization.
Key Points Explained
This chapter will help you to answer the following questions:
• What is the Enterprise Continuum?
• How is the Enterprise Continuum used in developing an architecture?
• How does the Enterprise Continuum promote re-use of architecture artifacts?
• What are the constituent pieces of the Enterprise Continuum?
• What is the Architecture Continuum?
• How is the Architecture Continuum used in developing an architecture?
• What is the relationship between the Architecture Continuum and the Solutions Continuum?
• What is the Solutions Continuum?
• How is the Solutions Continuum used to develop an architecture?
• What is the relationship between the Enterprise Continuum and the ADM?
• What is the Architecture Repository?
• What are the high-level issues with tools standardization?
Definition of “Continuum”
Noun: a continuous extent of something, no part of which is different from any other.
[Source: Wiktionary.org]
(Syllabus Reference: Unit 5, Learning Outcome 1: You should be able to briefly explain what the Enterprise Continuum is.)
The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.
(Syllabus Reference: Unit 5, Learning Outcome 2: You should be able to explain how the Enterprise Continuum is used in organizing and developing an architecture.)
The Enterprise Continuum enables the architect to articulate the broad perspective of what, why, and how the enterprise architecture has been designed with the factors and drivers considered. The Enterprise Continuum is an important aid to communication and understanding, both within individual enterprises, and between customer enterprises and vendor organizations. Without an understanding of “where in the continuum you are”, people discussing architecture can often talk at cross-purposes because they are referencing different points in the continuum at the same time, without realizing it.
The Benefits of a Consistent Language
Any architecture is context-specific; for example, there are architectures that are specific to individual customers, industries, subsystems, products, and services. Architects, on both the buy-side and supply-side, must have at their disposal a consistent language to effectively communicate the differences between architectures. Such a language enables engineering efficiency and the effective use of Commercial Off-The-Shelf (COTS) product functionality. The Enterprise Continuum provides that consistent language.
(Syllabus Reference: Unit 5, Learning Outcome 3: You should be able to explain how the Enterprise Continuum promotes re-use of architecture artifacts.)
The Enterprise Continuum enables the organization of re-usable architecture artifacts and solution assets to maximize the enterprise architecture investment opportunities.
The “virtual repository” that is the Enterprise Continuum consists of all the architecture assets; that is, models, patterns, architecture descriptions, and other artifacts produced during application of the ADM. These can exist both within the enterprise and in the IT industry at large, and are considered the set of assets available for the development of architectures for the enterprise.
The deliverables of previous architecture work, which are available for re-use, are examples of internal architecture and solutions artifacts. Examples of external architecture and solution artifacts include the wide variety of industry reference models and architecture patterns that exist, and are continually emerging, including those that are highly generic (such as the TOGAF Technical Reference Model (TRM)); those specific to certain aspects of IT (such as a web services architecture); those specific to certain types of information processing (such as e-Commerce); and those specific to certain vertical industries, such as the models generated by vertical consortia like the TMF (in the Telecommunications sector), ARTS (Retail), Energistics (Petrotechnical), etc.
The enterprise architecture determines which architecture and solution artifacts an organization includes in its Architecture Repository. Re-use is a major consideration in this decision.
(Syllabus Reference: Unit 5, Learning Outcome 4: You should be able to describe the constituent parts of the Enterprise Continuum.)
The Enterprise Continuum consists of three parts as described below, and illustrated in Figure 5. Each of the three parts is considered to be a distinct continuum.
(Syllabus Reference: Unit 5, Learning Outcome 5: You should be able to explain the purpose of the Enterprise Continuum.)
The Enterprise Continuum is the outermost continuum and classifies assets related to the context of the overall enterprise architecture.
The Enterprise Continuum classes of assets may influence architectures, but are not directly used during the ADM architecture development. The Enterprise Continuum classifies contextual assets used to develop architectures, such as policies, standards, strategic initiatives, organizational structures, and enterprise-level capabilities. The Enterprise Continuum can also classify solutions (as opposed to descriptions or specifications of solutions). Finally, the Enterprise Continuum contains two specializations, namely the Architecture and Solutions continuum.
The Architecture Continuum offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships (e.g., to show that an Organization-Specific Architecture is based on an industry or generic standard).
The Architecture Continuum represents a structuring of Architecture Building Blocks (ABBs) which are re-usable architecture assets. ABBs evolve through their development lifecycle from abstract and generic entities to fully expressed Organization-Specific Architecture assets. The Architecture Continuum assets will be used to guide and select the elements in the Solutions Continuum (see below).
The Architecture Continuum shows the relationships among foundational frameworks (such as the TOGAF framework), common system architectures (such as the III-RM), industry architectures, and enterprise architectures. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy.
The Solutions Continuum provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum. The Solutions Continuum defines what is available in the organizational environment as re-usable Solution Building Blocks (SBBs). The solutions are the results of agreements between customers and business partners that implement the rules and relationships defined in the architecture space. The Solutions Continuum addresses the commonalities and differences among the products, systems, and services of implemented systems.
(Syllabus Reference: Unit 5, Learning Outcome 6: You should be able to explain the purpose of the Architecture Continuum.)
There is a continuum of architectures, Architecture Building Blocks (ABBs), and architecture models that are relevant to the task of constructing an enterprise-specific architecture, that are termed by the TOGAF standard as the Architecture Continuum. These are shown in Figure 10.
Figure 10: The Architecture Continuum
(Syllabus Reference: Unit 5, Learning Outcome 7: You should be able to list the stages of architecture evolution defined in the Architecture Continuum.)
Figure 10 illustrates how architectures are developed and evolved across a continuum ranging from Foundation Architectures, such as the one provided by the TOGAF standard, through Common Systems Architectures, and Industry Architectures, and to an enterprise’s own Organization-Specific Architectures.
The arrows in the Architecture Continuum represent the relationship that exists between the different architectures in the Architecture Continuum. The leftwards direction focuses on meeting enterprise needs and business requirements, while the rightwards direction focuses on leveraging architectural components and building blocks.
The enterprise needs and business requirements are addressed in increasing detail from left to right. The architect will typically look to find re-usable architecture elements toward the left of the continuum. When elements are not found, the requirements for the missing elements are passed to the left of the continuum for incorporation.
Within the Architecture Continuum there are a number of re-usable Architecture Building Blocks (ABBs) – the models of architectures.
A Foundation Architecture consists of generic components, interrelationships, principles, and guidelines that provide a foundation on which more specific architectures can be built.
Common Systems Architectures guide the selection and integration of specific services from the Foundation Architecture to create an architecture useful for building common solutions across a wide number of relevant domains. Examples of Common Systems Architectures include Security Architecture, Management Architecture, Network Architecture, etc.
The TOGAF Integrated Information Infrastructure Reference Model (III-RM) is a reference model that supports describing Common Systems Architecture in the Application domain that focuses on the requirements, building blocks, and standards relating to the vision of Boundaryless Information Flow.
Industry Architectures guide the integration of common systems components with industry-specific components, and guide the creation of industry solutions for specific customer problems within a particular industry.
A typical example of an industry-specific component is a data model representing the business functions and processes specific to a particular vertical industry, such as the Retail industry’s “Active Store” architecture, or an Industry Architecture that incorporates the Petrotechnical Open Software Corporation (POSC) (www.posc.org) data model.
Organization-Specific Architectures describe and guide the final deployment of user-written or third-party components that constitute effective solutions for particular enterprises.
(Syllabus Reference: Unit 5, Learning Outcome 8: You should be able to explain the purpose of the Solutions Continuum.)
The Solutions Continuum, shown in Figure 11, represents the implementations of the architectures at the corresponding levels of the Architecture Continuum. At each level in the Solutions Continuum there is a set of reference building blocks that represent a solution to the business requirements at that level. A populated Solutions Continuum can be regarded as a re-use library.
Figure 11: The Solutions Continuum
In Figure 11, moving from left-to-right increases the solution’s value; that is, products and services provide value in creating systems solutions. Systems solutions value is used to create industry solutions, and industry solutions are used to create enterprise solutions (also termed customer solutions). The right-to-left direction increasingly focuses on addressing enterprise needs.
(Syllabus Reference: Unit 5, Learning Outcome 9: You should be able to list the stages of architecture evolution defined in the Solutions Continuum.)
The solution types within the Solutions Continuum are looked at in detail in the following sections.
Foundation Solutions are highly generic concepts, tools, products, services, and solution components that are the fundamental providers of capabilities. Services include professional services – such as training and consulting services – that ensure the maximum investment value from solutions in the shortest possible time; and support services – such as Help Desk – that ensure the maximum possible value from solutions (services that ensure timely updates and upgrades to the products and systems).
Example Foundation Solutions would include programming languages, operating systems, foundational data structures (such as EDIFACT), generic approaches to organization structuring, foundational structures for organizing IT operations (such as ITIL), etc.
A Common Systems Solution is an implementation of a Common Systems Architecture and is comprised of a set of products and services, which may be certified or branded. It represents the highest common denominator for one or more solutions in the industry segments that the Common Systems Solution supports.
Common Systems Solutions represent collections of common requirements and capabilities, rather than those specific to a particular customer or industry. Common Systems Solutions provide organizations with operating environments specific to operational and informational needs, such as high availability transaction processing and scalable data warehousing systems. Examples of Common Systems Solutions include: an enterprise management system product and a security system product.
Computer systems vendors are the typical providers of technology-centric Common Systems Solutions. “Software as a service” vendors are typical providers of common application solutions. Business process outsourcing vendors are typical providers of business capability-centric Common Systems Solutions.
An Industry Solution is an implementation of an Industry Architecture, which provides re-usable packages of common components and services specific to an industry.
Fundamental components are provided by Common Systems Solutions and/or Foundation Solutions, and are augmented with industry-specific components. Examples include a physical database schema or an industry-specific point-of-service device.
Industry Solutions are industry-specific, aggregate procurements that are ready to be tailored to an individual organization’s requirements.
In some cases an industry solution may include not only an implementation of the Industry Architecture, but also other solution elements, such as specific products, services, and systems solutions that are appropriate to that industry.
An Organization-Specific Solution is an implementation of the Organization-Specific Architecture that provides the required business functions. Because solutions are designed for specific business operations, they contain the highest amount of unique content in order to accommodate the varying people and processes of specific organizations.
Building Organization-Specific Solutions on Industry Solutions, Common Systems Solutions, and Foundation Solutions is the usual way of connecting the Architecture Continuum to the Solutions Continuum, as guided by the architects within an enterprise.
An Organization-Specific Solution will be structured in order to support specific Service-Level Agreements (SLAs) to ensure support of the operational systems at desired service levels. For example, a third-party application hosting provider may offer different levels of support for operational systems. These agreements would define the terms and conditions of that support.
Other key factors to be defined within an Organization-Specific Solution are the key operating parameters and quality metrics that can be used to monitor and manage the environment.
The relationship between the Architecture Continuum and the Solutions Continuum is one of guidance, direction, and support. For example, Foundation Architectures guide the creation or selection of Foundation Solutions. Foundation Solutions support the Foundation Architecture by helping to realize the architecture defined in the Architecture Continuum. The Foundation Architecture also guides development of Foundation Solutions, by providing architectural direction, requirements and principles that guide selection, and realization of appropriate solutions. A similar relationship exists between the other elements of the Enterprise Continuum.
The relationships depicted in Figure 12 are a best case for the ideal use of architecture and solution components.
Figure 12: The Enterprise Continuum
(Syllabus Reference: Unit 5, Learning Outcome 10: You should be able to explain the relationship between the Enterprise Continuum and the TOGAF ADM.)
The TOGAF Architecture Development Method (ADM) describes the process of moving from the TOGAF Foundation Architecture to an enterprise-specific architecture (or set of architectures). This process makes use of the elements of the TOGAF Foundation Architecture and other relevant architecture assets, components, and building blocks. At relevant places throughout the TOGAF ADM, there are reminders to consider which architecture assets from the Enterprise Continuum the architect should use. The TOGAF standard itself provides two reference models for consideration for inclusion in an organization’s Enterprise Continuum: the TOGAF Foundation Architecture and the Integrated Information Infrastructure Reference Model (III-RM).
(Syllabus Reference: Unit 5, Learning Outcome 11: You should be able to describe the Architecture Repository.)
Operating a mature architecture capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these architectural work products require a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.
The TOGAF standard provides a structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization. This Architecture Repository is one part of the wider Enterprise Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.
(Syllabus Reference: Unit 5, Learning Outcome 12: You should be able to explain the relationship between the Enterprise Continuum and the Architecture Repository.)
The Architecture Repository is a model for a physical instance of the Enterprise Continuum.
Figure 13: TOGAF Architecture Repository Structure
(Syllabus Reference: Unit 5, Learning Outcome 13: You should be able to describe the classes of information held in the Architecture Repository.)
At a high level, six classes of architectural information are expected to be held within an Architecture Repository:
• The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content.
• The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
• The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time.
• The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization. The Open Group provides an example of a Standards Information Base on its web site.10
• The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
• The Governance Log provides a record of governance activity across the enterprise.
(Syllabus Reference: Unit 5, Learning Outcome 14: You should be able to list the three levels of the Architecture Landscape.)
The Architecture Landscape holds architectural views of the state of the enterprise at particular points in time. Due to the sheer volume and the diverse stakeholder needs throughout an entire enterprise, the Architecture Landscape is divided into three levels of granularity:
1. Strategic Architectures show a long-term summary view of the entire enterprise. Strategic Architectures provide an organizing framework for operational and change activity and allow for direction setting at an executive level.
2. Segment Architectures provide more detailed operating models for areas within an enterprise. Segment Architectures can be used at the program or portfolio level to organize and operationally align more detailed change activity.
3. Capability Architectures show in a more detailed fashion how the enterprise can support a particular unit of capability. Capability Architectures are used to provide an overview of current capability, target capability, and capability increments and allow for individual work packages and projects to be grouped within managed portfolios and programs.
(Syllabus Reference: Unit 5, Learning Outcome 15: You should be able to explain the purpose of the Standards Information Base within the Architecture Repository.)
The Standards Information Base is a repository area that can hold a set of specifications, to which architectures must conform.
Establishment of a Standards Information Base provides an unambiguous basis for architectural governance since:
• The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for.
• Standards are stated in a clear and unambiguous manner, so that compliance can be objectively as
To manage the content of the Enterprise Continuum we need tools in order to:
• Promote re-use
• Enable sharing of architecture information within an organization
• Facilitate easier maintenance of the architecture
• Ensure common terminology is used
• Provide stakeholders with relevant models
Using the models within the TOGAF standard, it is then possible to implement the Architecture Repository in a tool, thereby responding to stakeholder enquiries for models, views, and other queries.
The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures. It is also an aid to communication between all architects involved in building and procuring an architecture by providing a common language and terminology. This, in turn, enables efficiency in engineering and effective use of COTS products.
The Architecture Continuum is part of an organization’s Enterprise Continuum and is supported by the Solutions Continuum. It offers a consistent way to define and understand the generic rules, representations, and relationships in an information system, and it represents a conceptual structuring of re-usable architecture assets.
The Architecture Continuum shows the relationships among Foundation Architectures (such as the TOGAF Foundation Architecture), Common Systems Architectures (such as the III-RM), Industry Architectures, and Organization-Specific Architectures. It is also a useful method to discover commonality and eliminate unnecessary redundancy.
The Solutions Continuum is part of an organization’s Enterprise Continuum. It represents implementations of the architectures at the corresponding levels of the Architecture Continuum. At each level, the Solutions Continuum is a population of the architecture with reference building blocks – either purchased products or built components – that represent a solution to the enterprise’s business needs.
The Architecture Repository provides a structural framework for a physical repository for managing architectural work products and is a model of a physical instance of the Enterprise Continuum. The Architecture Repository defines six classes for architectural information held in the repository.
The TOGAF standard recognizes the need to manage the content of the Enterprise Continuum using tools, and includes high-level guidance on standardization of tools.
Q1: Which of the following statements does not apply to the Enterprise Continuum?
A. It is a repository of all known architecture assets and artifacts in the IT industry.
B. It is a view of the Architecture Repository.
C. It provides methods for classifying architecture and solution assets.
D. It is an important aid to communication for architects on both the buy and supply-side.
E. It is an aid to organization of re-usable and solution assets.
Q2: Which of the following in the Enterprise Continuum is an example of an internal architecture or solution artifact that is available for re-use?
A. Deliverables from previous architecture work
B. Industry reference models and patterns
C. The TOGAF TRM
D. The ARTS data model
Q3: Which of the following in the Enterprise Continuum is not an example of an external architecture or solution artifact?
A. The TOGAF TRM
B. IT-specific models, such as web services
C. The ARTS data model
D. Deliverables from previous architecture work
Q4: Which of the following best completes the next sentence: The Enterprise Continuum aids communication ___________
A. Within enterprises
B. Between enterprises
C. With vendor organizations
D. By providing a consistent language to communicate the differences between architectures
E. All of these
Q5: Which of the following are considered to be the constituent parts of the Enterprise Continuum?
A. Standards Information Base, Governance Log
B. TOGAF TRM, III-RM
C. Architecture Continuum, Solutions Continuum
D. Business Architecture, Application Architecture
Q6: Complete the sentence: The TOGAF Integrated Information Infrastructure Reference Model (III-RM) is classified in the Architecture Continuum as an example of a(n) _______
A. Common Systems Architecture
B. Industry Architecture
C. Enterprise Architecture
D. Foundation Architecture
Q7: Which of the following responses does not complete the next sentence? The Solutions Continuum ________________
A. Provides a way to understand the implementation of assets defined in the Architecture Continuum
B. Addresses the commonalities and differences among the products, systems, and services of an implemented system
C. Can be considered to have at each level a set of building blocks that represent a solution to the business requirements at that level
D. Contains a number of re-usable Architecture Building Blocks
E. Has a relationship to the Architecture Continuum that includes guidance, direction, and support
Q8: Which one of the following reference building blocks is not part of the Solutions Continuum?
A. Systems libraries
B. Organization-specific solutions
C. Foundation solutions
D. Common systems solutions
E. Industry solutions
Q9: Which of the following is considered a model for a physical instance of the Enterprise Continuum?
A. The Architecture Repository
B. The III-RM
C. The Standards Information Base
D. The TOGAF TRM
Q10: Which class of architectural information held within the Architecture Repository would contain adopted reference models?
A. Architecture Metamodel
B. Architecture Capability
C. Standards Information Base
D. Reference Library
Q11: Which level of the Architecture Landscape contains the most detail?
A. Capability Architectures
B. Segment Architectures
C. Strategic Architectures
Q12: Which of the following describes a purpose of a Standards Information Base?
A. To provide a method for architecture development
B. To provide a basis for architectural governance
C. To provide a record of governance activity
D. To show an architectural view of building blocks
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part V: Enterprise Continuum and Tools (Chapters 38-42)
_______________________
10 Go to www.opengroup.org/sib.
