TOGAF and its relevance to building sound architectures

TOGAF and the Architecture ‘Continuum’

Definitions:

• TOGAF: The Open Group Architecture Framework
• Continuum: A continuous extent or succession from a starting point to a finishing point with only arbitrary divisions along the spectrum

The Open Group has a detailed set of frameworks and approaches for IT architecture (http://pubs.opengroup.org). These frameworks are for IT systems architecture design, development and deployment. They are not specific to Cloud Architectures, but can be used when building a de-novo Cloud solution, or migrating to a Cloud Platform and reforming your business and IT architectures. AWS’ CAF (Cloud Architecture Framework), is based on TOGAF for example.

TOGAF is a valuable tool for any architect, but given that it is a collaborative effort with 300 odd specialists contributing, you need to pick and choose what is relevant for your project. It should be added that many of the approaches and methods within TOGAF are unnecessarily opaque, academic and repetitive. In spite of that caveat, it is still a very useful tool for solution architects.

TOGAF’s Architecture Continuum

According to TOGAF every architecture (business, IS, technical), is a ‘Continuum’ from a beginning to the end. The main elements within the Continuum are:

1. Foundation Architectures,
2. Common Systems Architectures,
3. Industry Architectures, and a company’s own,
4. Organization-Specific Architecture.

This Continuum runs basically from ‘generic’ foundation principles and architectures, to the company-specific. Each one of the 4 elements mentioned above run within this Continuum.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap39.html#tag_39_04

For an architect looking to build an Organisation-specific architecture(s), the Continuum provides some useful ideas on how to achieve this:

1. Enterprise business requirements will be addressed in increasing detail as you move from left to right.
2. Generic components and architecture principles are formed on the left-hand side of the Continuum and become more specific as you move to the right.
3. Reusable components are sought early in the process and if not found, specific solution components can be either used, or developed as the detail of the architecture becomes more specific.
4. The process should move in a rationale manner including the following ‘layers’ as the architect proceeds from left to right:

• Conceptual architectures, then Logical and physical designs
• Horizontal (IT-focused) to vertical (business-focused) designs and flows
• Taxonomy of specific architecture artifacts and design details

 

Foundation Architecture

This phase uses generic components, inter-relationships, principles and concepts to provide a foundation on top of which more specific architectures will be built. Components would include hardware, software, integration concepts, applications, databases and platforms. The foundation will include the main elements of your target operation model (IT and Business). Note that you will have to understand your current model and gaps in moving from the current to the future target model.

 

Common Systems Architectures

The purpose of a Common Systems Architecture is to provide a common platform in which there are common, reusable solutions across many domains. This would include the integration of services from the Foundation Architecture to create a unified architectural view.

Some examples of CSA’s would include:

• security architecture,
• management architecture,
• network architecture,
• operations architecture

Each ‘sub’-architecture is incomplete if we look at overall system functionality, but within its own domain or scope, it should provide a complete solution to that specific problem domain (security, manageability, networking, operations, etc.). This will mean that solutions implementing re-usable building blocks for the creation of functionally to complete operating states of the enterprise.

Common Systems Architectures also include:

• Requirements specific to a generic problem domain
• Building blocks specific to a generic problem domain
• Business, data, application, or technology standards for implementing the building blocks
• Building blocks for easy re-use and lower costs

 

Industry Architectures

IA’s may be relevant to act as a guide for the integration of common system components with industry specific components (eg in Telecoms, Banking etc). IA’s exist for quite a few domains including and could contain the following:

• Requirements and standards specific to a vertical industry

• Building blocks specific to a generic problem domain
• Industry-specific logical data and process models
• Industry-specific applications and process models, as well as industry-specific business rules
• Guidelines for testing collections of systems (a system is defined as a set of IT components to support a business process and workflow)

 

Organization-Specific Architectures

Organization-Specific Architectures can help the architect with the final deployment of solution components for an enterprise or extended network of connected enterprises (a building block component is one component eg a DB; whilst a solution component is the combination of building block components eg a DB, Web app, Front End).

To build Organization-Specific Architecture which customise more generic and foundation-architectures, the following are true:

• OSA’s communicate and manage business operations across all four architectural domains
• They contain requirements specific to the enterprise
• They define building blocks specific to the enterprise
• They contain organization-specific business models, data, applications, and technologies
• They should encourage implementation of appropriate solutions to meet business needs
• OAS provides criteria to measure and select appropriate products, solutions, and services

==END