The University is adopting a ‘light touch’ TOGAF approach to Enterprise Architecture (EA). TOGAF, which stands for The Open Group Architecture Framework, is an EA methodology and framework. It is designed to support the four commonly accepted domains of EA:

• Business architecture, which describes the University strategy, governance, organisation and processes.
• Data architecture, which describes the structure of the University’s logical and physical data assets and data management resources.
• Application architecture, which provides a blueprint for the individual application systems to be deployed, their interactions and their relationships to the core business processes of the University.
• Technology architecture, which provides the logical software and hardware capabilities that are required to support the deployment of the business, data and application services. This includes IT infrastructure, middleware, networks, communications processing and standards.

One of the most important aspects of TOGAF, and almost certainly the most widely recognised part, is the Architecture Development Model (ADM).

TOGAF Architecture Development Method (ADM)

The ADM is a step-by-step approach to developing an enterprise architecture, and a cycle of the ADM is essentially an EA project.  The ADM consists of a number of phases that are iteratively repeated with frequent validation against the organisation’s current requirements.  TOGAF defines the steps within each ADM phase are defined in detail.

During the Preliminary phase, which takes place before an organisation can begin its first EA project using TOGAF, the “where, what, why, who, and how we do architecture” in the enterprise is defined. During the Architecture Vision phase the scope of the cycle or project is determined, stakeholders identified and a high-level architecture vision created – is is essentially the project start-up. It is important to carefully define the scope in terms of breadth, depth and time period based on what is to be achieved and what resources are available. Trying to tackle too much will generate a huge architecture project that could well be impossible to complete, whereas a too small or too specific scope could provide something that does not consider wider architecture implications sufficiently. Phases B to D share common steps to establish the baseline and target architectures, and then an initial roadmap is developed in Phase E before being finalised in Phase F where more detailed work packages are defined. Phase G concentrates on ensuring conformance of solutions with the target architecture and Phase H is a continual process of maintaining and monitoring the enterprise architecture and initiating new cycles.

TOGAF Structure

The structure of the TOGAF standard is divided into seven parts:

• Part I: Introduction. A high-level introduction to the key concepts of EA and the TOGAF approach.
• Part II: Architecture Development Method. The core of TOGAF, explained above.
• Part III: ADM Guidelines and Techniques.  A collection of guidelines and techniques available for use in applying the ADM.
• Part IV: Architecture Content Framework. A description of the TOGAF content framework, including a structured meta-model for architectural artefacts, the use of re-usable Architecture Building Blocks (ABBs) and an overview of typical architecture deliverables.
• Part V: Enterprise Continuum and Tools. A discussion of appropriate taxonomies and tools to categorise and store the outputs of architecture activity within an enterprise.
• Part VI: TOGAF Reference Models. Provides two architectural reference models: the TOGAF Technical Reference Model (TRM) and the Integrated Information Infrastructure Model (III-RM).
• Part VIII: Architecture Capability Framework. A discussion of the organisation, processes, skills, roles and responsibilities required to establish and operate an architecture practice within an enterprise.

Other key aspects of TOGAF include the Architecture Repository and the Enterprise Continuum.  A lot of information is generated from doing EA, and the information needs to be effective managed in order for it to be useful and re-usable. The repository is where the information is stored and referenced.  It gets built up over time, and at the start might only contain reference models and material. The The Enterprise Continuum effectively provides contextual views of the Architecture Repository and a model for structuring and classifying those views.

The manual for all of the above is nearly 800 pages long, and you can imagine that used in its entirety TOGAF would be a very heavy weight framework. However, TOGAF is designed to be tailored and there are steps in the Preliminary phase to do just that. This tailoring aspect will be very important to the University’s start in using TOGAF effectively, and it is likely that it will need refinement over time as we all become more familiar with using the framework.