This chapter provides an introduction to the guidelines and techniques provided in Part III: ADM Guidelines & Techniques.¹

17.1 Guidelines for Adapting the ADM Process

The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Guidelines included within this part are as follows:

• Applying Iteration to the ADM (see 18. Applying Iteration to the ADM) discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM
• Applying the ADM across the Architecture Landscape (see 19. Applying the ADM Across the Architecture Landscape) discusses the different types of architecture engagement that may occur at different levels of the enterprise - this section then also discusses how the ADM process can be focused to support different types of engagement

17.2 Techniques for Architecture Development

The following techniques are described within Part III: ADM Guidelines & Techniques to support specific tasks within the ADM:

• Architecture Principles (see 20. Architecture Principles) - principles for the use and deployment of IT resources across the enterprise - describes how to develop the set of general rules and guidelines for the architecture being developed
• Stakeholder Management (see 21. Stakeholder Management) describes stakeholder management, an important discipline that successful architecture practitioners can use to win support for their projects
• Architecture Patterns (see 22. Architecture Patterns) provides guidance on using architectural patterns
• Gap Analysis (see 23. Gap Analysis) describes the technique known as gap analysis; it is widely used in the TOGAF ADM to validate an architecture that is being developed
• Migration Planning Techniques (see 24. Migration Planning Techniques) describes a number of techniques to support migration planning in Phases E and F
• Interoperability Requirements (see 25. Interoperability Requirements) describes a technique for determining interoperability requirements
• Business Transformation Readiness Assessment (see 26. Business Transformation Readiness Assessment) describes a technique for identifying business transformation issues
• Risk Management (see 27. Risk Management) describes a technique for managing risk during an architecture/business transformation project
• Capability-Based Planning (see 28. Capability-Based Planning) describes the technique of capability-based planning

17.3 Using the TOGAF Framework with Different Architectural Styles

The TOGAF framework is designed to be flexible and it can be used with various architectural styles. Further information can be found in the following Guides:

• Integrating Risk and Security within a TOGAF® Enterprise Architecture
• TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures

Architectural styles differ in terms of focus, form, techniques, materials, subject, and time period. Some styles can be considered as fashionable, others focused on particular aspects of Enterprise Architecture. The TOGAF standard is a generic framework intended to be used in a wide variety of environments. It is a flexible and extensible framework that can be readily adapted to a number of architectural styles.

An organization's Architecture Landscape can be expected to contain architecture work that is developed in many architectural styles. The TOGAF standard ensures that the needs of each stakeholder are appropriately addressed in the context of other stakeholders and the Baseline Architecture.

When using the TOGAF standard to support a specific architectural style the practitioner must take into account the combination of distinctive features in which architecture is performed or expressed. As a first step, the distinctive features of a style must be identified.

For example, The Open Group definition for SOA identifies the following distinctive features:

• It is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter-enterprise) business processes
• Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration
• It places unique requirements on the infrastructure - it is recommended that implementations use open standards to realize interoperability and location transparency
• Implementations are environment-specific - they are constrained or enabled by context and must be described within that context

The second step is determining how these distinctive features will be addressed. Addressing a distinctive style should not call for significant changes to the TOGAF framework; instead it should adjust the models, viewpoints, and tools used by the practitioner.

In Phase B, Phase C, and Phase D the practitioner is expected to select the relevant architecture resources, including models, viewpoints, and tools, to properly describe the architecture domain and demonstrate that stakeholder concerns are addressed (see Part II, 7.3.1 Select Reference Models, Viewpoints, and Tools , 9.3.1 Select Reference Models, Viewpoints, and Tools , 10.3.1 Select Reference Models, Viewpoints, and Tools , and 11.3.1 Select Reference Models, Viewpoints, and Tools). Depending upon the distinctive features, different architectural styles will add new elements that must be described, highlight existing elements, adjust the notation used to describe the architecture, and focus the architect on some stakeholders or stakeholder concerns.

Addressing the distinctive features will usually include extensions to the Architecture Content Metamodel and the use of specific notation or modeling techniques and the identification of viewpoints. Whether the style is dominant will determine whether it is necessary to revisit the Preliminary Phase and make changes to the Architecture Capability or whether support for the distinctive feature is possible within the scope of selection expected within a single ADM cycle.

Style-specific reference models and maturity models are commonly used tools that support a practitioner.

During the lifetime of the TOGAF framework many architectural styles have been developed to address key problems facing practitioners and to demonstrate how the TOGAF framework can be made more relevant within defined contexts.

Some of these have been developed by The Open Group Forums and Work Groups working in specific areas and have been published in Guides, White Papers, and Standards. Examples include:

• TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures
• Integrating Risk and Security within a TOGAF® Enterprise Architecture

Some of these have been developed collaboratively between The Open Group and other bodies. Examples include:

• TOGAF® and SABSA® Integration
• Integrating the TOGAF® Standard with the BIAN Service Landscape
• Exploring Synergies between TOGAF® and Frameworx
• TOGAF® 9 and DoDAF 2.0

The TOGAF Library (see https://publications.opengroup.org/togaf-library) includes an evolving list of documents providing advice and guidance for the application of the TOGAF framework within specific contexts.

Footnotes

1.

Additional guidelines and techniques are available in the TOGAF Library.

return to top of page