TOGAF

TOGAF is an architecture framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

SO/IEC 42010:2007 defines “architecture” as:

“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”

TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In TOGAF, “architecture” has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 – ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership.

There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

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

Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

Phases within the ADM are as follows:

  • The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles.
  • Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
  • Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
  • Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision.
  • Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision.
  • Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.
  • Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
  • Phase G: Implementation Governance provides an architectural oversight of the implementation.
  • Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
  • Requirements Management examines the process of managing architecture requirements throughout the ADM.

Deliverables, Artifacts, and Building Blocks

Architects executing the ADM will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The TOGAF Architecture Content Framework   provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented.

The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:

  • A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
  • An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.
  • A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to “architectures” or “solutions”.
    • Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.
    • Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise.

The relationships between deliverables, artifacts, and building blocks are shown in Figure 1.

Figure -1: Relationships between Deliverables, Artifacts, and Building Blocks

For example, an Architecture Definition Document is a deliverable that documents an architecture description. This document will contain a number of complementary artifacts that are views of the building blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target call handling process (a building block). This artifact may also describe other building blocks, such as the actors involved in the process (e.g., a Customer Services Representative). An example of the relationships between deliverables, artifacts, and building blocks is illustrated in Figure 2

Figure 2: Example – Architecture Definition Document

Enterprise Continuum

TOGAF includes the concept of the Enterprise Continuum, which sets the broader context for an architect and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual organization. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

An overview of the structure and context for the Enterprise Continuum is shown in Figure 3.

Figure -3: Enterprise Continuum


Architecture Repository

Supporting the Enterprise Continuum is the concept of an Architecture Repository which can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels.

By means of the Enterprise Continuum and Architecture Repository, architects are encouraged to leverage all other relevant architectural resources and assets in developing an Organization-Specific Architecture.

In this context, the TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository. The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and their relationships to each other, and the constraints and requirements on a cycle of architecture development.

The structure of the TOGAF Architecture Repository is shown in Figure  4.

Figure 4: TOGAF Architecture Repository StructureThe major components within an Architecture Repository are as follows:

  • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
  • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
  • The Architecture Landscape is the architectural representation of assets deployed within the operating enterprise at a particular point in time. The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.
  • The Standards Information Base (SIB) 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 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.

Establishing and Maintaining an Enterprise Architecture Capability

In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. An overview of the TOGAF Architecture Capability is shown in Figure 5.

Figure 5: TOGAF Architecture Capability Overview


Establishing the Architecture Capability as an Operational Entity

Barring architecture capabilities set up to purely support change delivery programs, it is increasingly recognized that a successful enterprise architecture practice must sit on a firm operational footing. In effect, an enterprise architecture practice must be run like any other operational unit within a business; i.e., it should be treated like a business. To this end, and over and above the core processes defined within the ADM, an enterprise architecture practice should establish capabilities in the following areas:

  • Financial Management
  • Performance Management
  • Service Management
  • Risk Management
  • Resource Management
  • Communications and Stakeholder Management
  • Quality Management
  • Supplier Management
  • Configuration Management
  • Environment Management

Central to the notion of operating an ongoing architecture is the execution of well-defined and effective governance, whereby all architecturally significant activity is controlled and aligned within a single framework.

As governance has become an increasingly visible requirement for organizational management, the inclusion of governance within TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.

The benefits of architecture governance include:

  • Increased transparency of accountability, and informed delegation of authority
  • Controlled risk management
  • Protection of the existing asset base through maximizing re-use of existing architectural components
  • Proactive control, monitoring, and management mechanisms
  • Process, concept, and component re-use across all organizational business units
  • Value creation through monitoring, measuring, evaluation, and feedback
  • Increased visibility supporting internal processes and external parties’ requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
  • Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise – studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
  • Integrates with existing processes and methodologies and complements functionality by adding control capabilities

Using TOGAF with Other Frameworks

Two of the key elements of any enterprise architecture framework are:

  • A definition of the deliverables that the architecting activity should produce
  • A description of the method by which this should be done

With some exceptions, the majority of enterprise architecture frameworks focus on the first of these – the specific set of deliverables – and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).

Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.

In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP. Guidelines for adapting the TOGAF ADM

As a generic framework and method for enterprise architecture, TOGAF provides the capability and the collaborative environment to integrate with other frameworks. Organizations are able to fully utilize vertical business domains, horizontal technology areas (such as security or manageability), or application areas (such as e-Commerce) to produce a competitive enterprise architecture framework which maximizes their business opportunities.


Advertisements

COBIT

COBIT 5 is the only business framework for the governance and management of enterprise IT. This evolutionary version incorporates the latest thinking in enterprise governance and management techniques, and provides globally accepted principles, practices, analytical tools and models to help increase the trust in, and value from, information systems. COBIT 5 builds and expands on COBIT 4.1 by integrating other major frameworks, standards and resources, including ISACA’s Val IT and Risk IT, Information Technology Infrastructure Library (ITIL®) and related standards from the International Organization for Standardization (ISO).

Control Objectives for Information and Related Technology (COBIT) is a framework created by ISACA for information technology (IT) management and IT governance. It is a supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks.

Overview

COBIT was first released in 1996; the current version, COBIT 5, was published in 2012. Its mission is “to research, develop, publish and promote an authoritative, up-to-date, international set of generally accepted information technology control objectives for day-to-day use by business managers, IT professionals and assurance professionals.”.

COBIT, initially an acronym for ‘Control objectives for information and related technology’, defines a set of generic processes to manage IT. Each process is defined together with process inputs and outputs, key process activities, process objectives, performance measures and an elementary maturity model. The framework supports governance of IT by defining and aligning business goals with IT goals and IT processes.

The COBIT framework

The framework provides good practices across a domain and process framework.

The business orientation of COBIT consists of linking business goals to IT goals, providing metrics and maturity models to measure their achievement, and identifying the associated responsibilities of business and IT process owners.

The process focus of COBIT 4.1 is illustrated by a process model that subdivides IT into four domains (Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate) and 34 processes in line with the responsibility areas of plan, build, run and monitor. It is positioned at a high level and has been aligned and harmonized with other, more detailed, IT standards and good practices such as COSO, ITIL, ISO 27000, CMMI, TOGAF and PMBOK. COBIT acts as an integrator of these different guidance materials, summarizing key objectives under one umbrella framework that link the good practice models with governance and business requirements.

The COBIT 4.1 framework specification can be obtained as a complimentary PDF at the ISACA download website. (Free self-registration may be required.)

COBIT 5 was released in June 2012.COBIT 5 consolidates and integrates the COBIT 4.1, Val IT 2.0 and Risk IT frameworks, and draws from ISACA’s IT Assurance Framework (ITAF) and the Business Model for Information Security (BMIS). It aligns with frameworks and standards such as Information Technology Infrastructure Library (ITIL), International Organization for Standardization (ISO), Project Management Body of Knowledge (PMBOK), PRINCE2 and The Open Group Architecture Framework (TOGAF).

Releases

COBIT has had five major releases:

  • In 1996, the first edition of COBIT was released.
  • In 1998, the second edition added “Management Guidelines”.
  • In 2000, the third edition was released.
    • In 2003, an on-line version became available.
  • In December 2005, the fourth edition was initially released.
    • In May 2007, the current 4.1 revision was released.
  • COBIT 5 was released in June 2012. It consolidates and integrates the COBIT 4.1, Val IT 2.0 and Risk IT frameworks, and also draws significantly from the Business Model for Information Security (BMIS) and ITAF.

Components

The COBIT components include:

  • Framework: Organize IT governance objectives and good practices by IT domains and processes, and links them to business requirements
  • Process descriptions: A reference process model and common language for everyone in an organization. The processes map to responsibility areas of plan, build, run and monitor.
  • Control objectives: Provide a complete set of high-level requirements to be considered by management for effective control of each IT process.
  • Management guidelines: Help assign responsibility, agree on objectives, measure performance, and illustrate interrelationship with other processes
  • Maturity models: Assess maturity and capability per process and helps to address gaps.

Other ISACA Publications based on the COBIT framework include:

  • Board Briefing for IT Governances, 2nd Edition
  • COBIT and Application Controls
  • COBIT Control Practices, 2nd Edition
  • IT Assurance Guide: Using COBIT
  • Implementing and Continually Improving IT Governance
  • COBIT Quickstart, 2nd Edition
  • COBIT Security Baseline, 2nd Edition
  • IT Control Objectives for Sarbanes-Oxley, 2nd Edition
  • IT Control Objectives for Basel II
  • COBIT User Guide for Service Managers
  • COBIT Mappings (to ISO/IEC 27002, CMMI, ITIL, TOGAF, PMBOK etc.)
  • COBIT Online

COBIT and Sarbanes-Oxley

Companies that are publicly traded in the US are subject to the Sarbanes-Oxley Act of 2002. According to the IIA, COBIT is one of the most commonly used frameworks to comply with Sarbanes-Oxley.

Benefits

COBIT 5 helps enterprises of all sizes:

  • Maintain high-quality information to support business decisions
  • Achieve strategic goals and realize business benefits through the effective and innovative use of IT
  • Achieve operational excellence through reliable, efficient application of technology
  • Maintain IT-related risk at an acceptable level
  • Optimize the cost of IT services and technology
  • Support compliance with relevant laws, regulations, contractual agreements and policies

Simply stated, COBIT 5 helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use.

COBIT 5 enables information and related technology to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and functional areas of responsibility, considering the IT-related interests of internal and external stakeholders.

The COBIT 5 principles and enablers are generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector.

Governance ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against agreed-on direction and objectives (EDM).

Managementplans, builds, runs and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives (PBRM).

The five COBIT 5 principles:

1.Meeting Stakeholder Needs

2.Covering the Enterprise End-to-end

3.Applying a Single Integrated Framework

4.Enabling a Holistic Approach

5.Separating Governance From Management

 Enablers

COBIT is a framework developed for IT process management with a strong focus on control. These scales need to be practical to apply and reasonably easy to understand. The topic of IT process management is inherently complex and subjective and, therefore, is best approached through facilitated assessments that raise awareness, capture broad consensus and motivate improvement. These assessments can be performed either against the maturity level descriptions as a whole or with more rigour against each of the individual statements of the descriptions. Either way, expertise in the enterprise’s process under review is required.

The advantage of a maturity model approach is that it is relatively easy for management to place itself on the scale and appreciate what is involved if improved performance is needed. The scale includes 0 because it is quite possible that no process exists at all. The 0-5 scale is based on a simple maturity scale showing how a process evolves from a non-existent capability to an optimised capability.

However, process management capability is not the same as process performance. The required capability, as determined by business and IT goals, may not need to be applied to the same level across the entire IT environment, e.g., not consistently or to only a limited number of systems or units. Performance measurement,  is essential in determining what the enterprise’s actual performance is for its IT processes.

Although a properly applied capability already reduces risks, an enterprise still needs to analyse the controls necessary to ensure that risk is mitigated and value is obtained in line with the risk appetite and business objectives. These controls are guided by COBIT’s control objectives.

Although it is difficult to imagine today, there was a time in the not-too-distant past the term “governance” was not used so often or so freely. Based on Latin and Greek words referring to the steering of a ship, governance was a concept primarily restricted to the CEO’s office and the boardroom.

But several global business catastrophes over the last few decades brought the term to the forefront of business thinking. Massive trader fraud at Barings Bank and Société Générale uncovered a breakdown in the monitoring of internal processes. Enron’s phenomenal success was revealed to be due, in some measure, to systematic, long-term, organized accounting fraud. WorldCom, Global Crossing and Tyco followed, and soon there was a clear and widely accepted need for more rigorous governance over companies’ systems of internal control. Increasingly, legislation is being passed to address this need. Worldwide, regulations such as Basel II, the Canadian Privacy Act, HIPAA, Australia’s Corporate Law Economic Reform Program and the Sarbanes-Oxley Act have moved governance to the top of agendas at all layers within enterprises.

This demonstrates that, although the highly publicized enterprise meltdowns may have focused more attention on formalized systems of governance, considerable thought and exploration had already gone into the basic concepts. As stakeholder issues, corporate social responsibility, enterprise risk management and alliances became an increasingly critical component of enterprise success, many astute enterprise leaders realized the need for effective and efficient governance around these issues.

The various legislative acts mentioned above may have reinforced the already existing focus on governance, but they did not necessarily bring clarity to the topic. Different views of governance have arisen, leading to confusion on the relationships among them. How does corporate governance relate to enterprise governance? What about the differing views brought about by increased dependency on intellectual capital, people, information technology—isn’t there a need for governance of these as well? What governance principles apply to open collaboration (“wiki”) sites, whose multiple authors and shared intellectual property create muddied ownership issues? As governance issues have become increasingly complex and critical to the business, those who need to understand and apply these concepts often find themselves wishing “if only someone would put all this on a page, so I could see how it fits together.”

Governance—Beyond Compliance
Although compliance is a powerful driver, there are more profound reasons to implement effective and efficient governance. Enterprise complexity, corporate responsibility, transparency—all these facets of the current business environment bring challenges that governance can address. Among the other drivers for efficient and effective governance:

  • Transparency, as stakeholders wish to be aware of the decisions, mechanisms and results of the enterprises in which they have an interest
  • Enterprises’ need to practice and demonstrate corporate responsibility
  • Creation of the extended enterprise, as enterprises’ growing appreciation of the benefits of collaboration has led to an increasingly large and complex network of relationships and strategic partners (joint ventures, wiki partners, etc.), among which delegation of accountability and decision-making rights  must be accomplished
  • Multiple stakeholders’ varying understanding and acceptance of value and risk
  • Enterprises’ increased dependence on strategic assets (e.g., people, knowledge, communications infrastructure, energy infrastructure, intellectual capital, information technology, information) or on external parties (e.g., outsourcing, strategic alliances) and the critical need for 24/7 access to them.
  • Data and information are especially important assets, as they form the basis for informed business decisions; bad data can lead to bad decisions.

The end result is an increasingly complex web, characterized by multiple layers of detail, requirements and interdependencies. This initiative has been undertaken to help clarify and provide ways to maneuver through the governance maze.

The governance mapping initiative was undertaken for many reasons. In addition to gaining a better understanding of the governance space and how the many components fit together, the intent is to populate the resulting maps in ways that will help all organizations dealing with these topics gain a better comprehension of what and who are operating in the governance space. Ultimately, it is hoped that the final product will encourage and assist enterprises to apply effective and efficient governance concepts within their own structures.

The mapping will therefore provide enterprises with guidance on existing standards, frameworks and methodologies that can assist them in implementing effective governance quickly and efficiently, and that incorporate the best practices appropriate to them. Information plays a vital role in the space and fosters good communication among related parties for better governance.

Therefore, the long-term plan is to populate the map—starting with the version that features IT governance (since that is ITGI’s area of expertise)—with four basic types of information:

  1. The leading international guidance, standards and frameworks relating to the disciplines reflected on the map. It is not intended to include all the guidance documents that exist, at this stage. The first iterations of the map will focus on what are considered the “top” guidance documents.Many frameworks can apply to many areas on the map; this map places them where their primary focus lies.
    In addition to showing just the “alphabet soup” of acronyms, each listing will be linked to further information describing the issuing body, the general purpose of the guidance, and the ways in which it specifically addresses the space in the governance map to which it has been assigned. ITGI’s worldwide cadre of experts will make inroads into this, but ultimately external assistance will be requested.
  2. The people involved in each view of governance—specifically the roles, responsibilities, credentials and qualifications of each
  3. The organizations that offer complementary products or services in each area
  4. ITGI’s own products and service offerings. Other organizations may wish to do the same for their own portfolio.

The mapping and description of the relevant frameworks, standards and methodologies will provide enterprises with practical guidance on governance implementation by clarifying aspects such as:

  • The scope of the framework, standard or methodology (e.g., COBIT’s positioning as a comprehensive process and control framework covering all IT processes vis-à-vis The Open Group Architecture Framework’s [TOGAF] positioning within the enterprise architecture domain)
  • Particular suitability to specific industries (where these exist)
  • Expected benefits from the application of the relevant framework, standard or methodology
  • Current uptake and reach (e.g., global reach for Committee of Sponsoring Organizations of the Treadway Commission [COSO])