Developing Enterprise Architecture TOGAF

Introduction In the previous presentation, we explored the Zachman Framework to identify that an enterprise architecture can be expressed in terms of perspective, metamodels, and components. While informative, the Zachman Framework does not describe how these concepts can be applied to the development of specific enterprise-based systems. To resolve this dilemma, we will be exploring The Open Group Architecture Framework (TOGAF).

TOGAF TOGAF provides a means of consistently developing, organizing, and managing multiple architectures used by an enterprise. In TOGAF, architecture is defined as: A formal description of a system A structure of components, their relationships, and governing principles and guidelines related to their design and use Given this context, an enterprise will typically be running multiple systems, each with distinct objectives to achieve. The development of an architecture for each system ensures that the system can be developed, implemented, and operated to meet those objectives consistently. Copyright: The Art of Service 2008

Architectures TOGAF recognizes four architecture domains: Business Architectures Data Architectures Application Architectures Technology Architectures The business architecture defines the strategies, governance, organization, and key business processes of the organization. In many respects, the business architecture represents the executive perspective of the Zachman Framework.   The data architecture defines the structure of the logical and physical data assets and resources for managing data within the organization. This answers the fundamental question of “What” in the Zachman Framework. The application architecture defines the various applications used in the organization, their interactions and relationships to the business processes. The Technology Architecture defines the logical software and hardware capabilities used to support business, data, and application services. This loosely represents the Technician Perspective of the Zachman Framework. The architectures are hierarchical, which means they build on each other. The data and application frameworks should be designed and developed to support the business architecture, while the technology architecture supports all the other architectures. Copyright: The Art of Service 2008

Key Concepts of TOGAF This presentation will briefly highlight the following TOGAF concepts: Architectural Artifacts Architecture Principles Enterprise Continuum Architecture Continuum Architecture Repository Architecture Content Framework Technical Reference Model (TRM) Architecture Development Method (ADM) Copyright: The Art of Service 2008

Artifacts Architectural artifacts are used to describe a solution’s or system’s architecture. They are the logical and physical components of the system. Artifacts can be classified into one of the following: Catalogs Matrices Diagrams TOGAF identifies 56 different core artifacts recommended for the Core Content Metamodel. Artifacts may be identified through the view one takes of a system; thus, they may not be visible from another view. An artifact is a building block of a system. A catalog is a list of those building blocks. A matrix shows the relationships between different building blocks, usually of a specific type. Diagrams provide a graphical representation of building blocks and their interconnections.   In the next slide, we will discuss stakeholders, concerns, and views. Copyright: The Art of Service 2008

Views Stakeholders are people who have an interest in a system. Concerns represent the communicated interests of a stakeholder. Requirements can be ascertained from stakeholder concerns. A view represents the system from a related set of concerns. A viewpoint is a reusable definition of a view. The definition includes the stakeholder, their concerns, and other relevant information. In the Zachman Framework, the enterprise could be described in terms of five (5) perspectives: executive, business management, architect, engineer, and technician. Each perspective has its own sets of concerns that must be addressed.   TOGAF expands this concept and suggests that a perspective or view can be established for each stakeholder of a system. In designing an architecture, each view or set of concerns is considered and addressed appropriately. In fact, TOGAF suggests that a view can be defined and reused across multiple architectures. Models and templates are simply tools from which an organization can address a set of related concerns consistently. In the previous slide, it was asserted that the artifacts of a system could be hidden from a view. We know that a cube, as displayed in this slide, has six (6) sides; however, our view of the cube only shows us three sides. If this cube represented a system, certain artifacts composing the system would be hidden from our view, but would still exist. If we were designing the system using only our current viewpoint, then some artifacts or components of the system would be missing. In this demonstration, it may be appropriate to design the cube using a minimum of six (6) viewpoints (one for each side). Copyright: The Art of Service 2008

Principles Architectural Principles are rules and guidelines used to support decision-making in creating, maintaining, and using an enterprise architecture. All principles have reason(s) for their existence (rationale), which is typically related to achieving business objectives and understanding impact (implication) for adopting the principle in system architectures. Principles are influenced by: Strategies and plans of the enterprise Constraints from markets, customers, and legislation Systems and technologies Industry and global trends The principles used to create an enterprise architecture are essentially the beliefs and values of the organization and are, therefore, unique. They are the basis for all decision making. They should be few in number, understood by all, robust to cover most situations, complete, consistent in practice, and enduring.   Principles are typically aligned with the four (4) core architectures: business, data, application, and technology. The recommended structure used to document a principle in TOGAF 9.1 is: Name Statement of principle Rationale Implication Copyright: The Art of Service 2008

Architecture Continuum The Architecture Continuum is used to define the rules, representations, and relationships within an architecture. Architectures evolve as they address needs and requirements. Foundation Common System Industry Organization Specific The Architecture Continuum is part of the Enterprise Continuum—a repository of all architecture assets found internally and externally to the organization. When an enterprise decides to create a system architecture, they are most likely going to leverage existing architectures. The Enterprise Continuum provides the means of establishing a common language.   In the diagram shown, the development of a system architecture will begin with basic components and building blocks of an existing architecture, which will be used and connected to meet the enterprise needs and business requirements of the organization. TOGAF recognizes four stages of evolving architectures: Foundation Architectures – They define the most generic form of components, relationships, and principles for an architecture. TOGAF defines a foundation architecture for enterprise architecture. Other such architectures include Cloud Computing, Storage Networks, Server/Client Applications, Customer Relationship Management, etc. Common System Architectures – They define architectures built on foundational principles to address a large majority of enterprises needs and business requirements. Some popular architectures which can fall into this category include SaaS (Software as a Service), RAID, Windows Directory, etc. Industry Architectures– They define architectures using common systems to address industry concerns, such as Finance, Health, or Manufacturing. Organization-Specific Architectures – They define the architectures used to explicitly address the needs and requirements of a specific organization and is usually not transferrable to another organization. The use of the Application Continuum in developing an organization-specific architecture is simple when put into context. For instance, consider the analogy of a financial company who is looking to develop an enterprise system for managing financial transactions. They decide that the application should follow the principles of Service-Oriented Architectures (Foundation) using Linux-based assets (Common Systems), but must follow legislative guidelines (Industry) to create a suitable application (Organization-Specific). While this example does not strictly adhere to the intent of the Application Continuum, it does demonstrate rather easily the different influences which may need to be addressed when developing an architecture. Architectural components Building Blocks Enterprise needs Business Requirements Copyright: The Art of Service 2008

Architecture Repository The development of an organizational-specific architecture requires the use of, and even generates, significant amount of information. This information can be stored in the Architecture Repository. The Architecture Repository will hold six classes of information: Architecture Metamodel Architecture Capability Architecture Landscape Standards Information Base Reference Library Governance Log The architecture repository provides an organization the means to govern modern and various architectures developed, used, and reused. The types of information found in the repository include: Architecture Metamodel – How the organization applies an architecture framework, including its defined method for development and a model for architecture content Architecture Capability – The parameters, structures, process, and skills required to support the repository’s governance Architecture Landscape – Provides the state of the enterprise and its architectural assets at different points in time Standards Information Base – Defines the industry standards, regulations, selected products and services from suppliers, and shared services which describe the compliance criteria for all developing architectures Reference Library – Any guidelines, templates, patterns, or materials which can be used to develop architectures faster and more effectively Governance Log – Records of all relevant governance activity within the organization   The information within the Architecture Repository can be used to support COBIT governance and management precepts or can aid in the design and development of services using ITIL. Copyright: The Art of Service 2008

Architecture Content Framework A content framework is a structural model which allows an architecture to define, structure, and present major work products in a consistent models. Architectural work products consist of: Deliverables – contractually required outputs of a process or project Artifacts – catalogs, matrices, and diagrams Building Blocks – reusable components of a business, IT, or architecture The Architecture Content Framework comprises a large portion of the Architecture Repository. From a TOGAF perspective, the Zachman Framework is a content framework; the Architecture Content Framework is therefore their version. The Architecture Content Framework provides much of the information found in the Architecture Landscape, Standards Information Base, and Reference Library of the Architecture Repository.   The work products are what a person can expect from the architecture. Often, the work products are organized based on a stakeholder’s view. Therefore, different stakeholders may be expecting a different set of work products. Copyright: The Art of Service 2008

Content Metamodel The number of building blocks used within an architecture can be massive. From a design perspective, building blocks can be specifications for components (Architecture Building Blocks) or the actual components (Solution Building Blocks).   The Content Metamodel shown in this slide is a graphical representation of all the types of building blocks possible within an architecture, as proposed through TOGAF 9.1. Every building block shares a set of generic characteristics: A building block defines a package of functionality meant to meet the organization’s needs. A building block is represented as a type within the Content Metamodel. A building block has a defined boundary and is recognizable within the proper context. A building block can interact with other building blocks. A building block is considered good when it: Considers implementation and usage Exploits technology and standards Can be assembled from other building blocks May be used to assemble other building blocks Is well specified Can be reused and replaced depending on the organization’s needs Copyright: The Art of Service 2008

Technical Reference Model The Technical Reference Model is a tool used when developing an architecture. The diagram above is provided by TOGAF to demonstrate the structure of the technical reference model, though some of the services identified in the TRM may not apply to all IT architectures.   The TRM consists of three entities and two interfaces: Infrastructure and business applications compose the Application Software entity. These applications provide functionality to the organization and are used to implement business processes. The services used to support the application create the application platform. In the diagram, these services are identified in green. The number and type of services can be extended out. Services, like Operating System and Network Services, allow for interoperability between services. The Application Platform Interface (API) connects the Application Software with the services within its Application Platform. The API will often define the level of portability available to an application. An application may utilize several APIs to gain access to its platform services. The Communication Infrastructure provides the means for connecting different systems or architectures. The Communication Infrastructure Interface is the interface between the Application Platform and the Communications Infrastructure. Many organizations have been looking at the Internet to fulfill their communications requirements. The Internet as a communication infrastructure presents itself with some unique and diverse challenges, simply because it is available to anyone. The interface with the Application Platform seeks to address these challenges and reduce the level of diversity for the organization. Copyright: The Art of Service 2008

Architecture Development Method The meat of TOGAF is the Architecture Development Method (ADM), a process for developing the architecture and relevant solutions for an organization.   The ADM comprises 10 phases, including a preliminary phase which occurs logically before architecture development and a requirements management phase which operates simultaneously with the other phases. The ADM cycle is intended to be iterative, that is, the organization can repeat the entire process, the interface between phases, or a single phase several times before obtaining the desired or improved result. With each iteration, the organization must define the: Scope or coverage of the architecture Level of detail to obtain in the architecture Time required to complete the iteration Architecture assets to be leveraged Because of the importance of the ADM, we will look briefly into each phase in the following slides. Copyright: The Art of Service 2008

ADM – Preliminary Objective: To determine and establish the organization’s capability to accept an architecture (Architecture Capability) Impact on Architecture: Defines the Architecture Principles for all architecture work done by the organization External Influences: Other management frameworks such as Business Planning, Project Management, IT Operations, and Solution Development (ITIL, COBIT, etc.) Outputs: Business principles, goals, and drivers Preliminary The preliminary phase is concerned with defining the fundamental questions related to the enterprise and its architecture: what, how, where, who, why. The purpose is to create a context for creating an architecture. In TOGAF, an enterprise may actually adopt multiple architectures, with the enterprise architecture being an “architecture of architectures”.   Within the preliminary phase, the organization will define (scope) the enterprise, and identify the business drivers and organization structures. In relation to architecture work, the requirements are defined; the frameworks are used, as well as the Architecture Principles. Lastly, the organization’s maturity to enterprise architecture will be evaluated. This is the phase where stakeholders in enterprise architecture are identified, their concerns are documented, and direction for any architecture work is established. The phase will provide: A model for enterprise architecture for the organization Requests for Architecture Work Framework for Architectures, including Architecture Principles Framework for Architecture Governance Framework content stored in Architecture Repository Copyright: The Art of Service 2008

ADM – Architecture Vision Objective: To develop a vision of the business value and capabilities to be delivered by the enterprise architecture Impact on Architecture: Defines the scope of the architecture effort External Influences: Stakeholders, their concerns and requirements Outputs: Approved statement of architecture work, architecture definition document, stakeholder maps, value chains, and solution concepts The Preliminary Phase will start the process with a Request for Architecture Work. In the Architecture Vision phase, this request is received and reviewed. The intention of this phase is to further define the architecture being requested, often determining what is in and out of scope for the request, as well as determining the current capabilities and resources available to support the architecture in the organization. Stakeholders for the specific architecture are identified.   When creating an Architecture Vision, the organization is attempting to align the developing architecture with the organization’s mission, vision, strategies, and goals, as well as to identify what steps are needed to develop the architecture effectively. The major steps in this phase include: Establishing a project and project team for the architecture work Identifying stakeholders’ concerns and requirements for the requested architecture Evaluating capabilities and resources of the organization, including assessing readiness for change Defining scope of architecture work Developing Architecture Vision within the defined scope Identifying target value propositions, key performance indicators, and risks Developing and approving Statement of Architecture Work Two key outputs result from this phase: Approved Statement of Architecture Work – defines what activities will be taken to fulfill the request Architecture Definition Document – identifies the baseline and target (before and after) architecture relevant to the request; highlighting the use and impact on the business, data, application, and technology architectures of the organization. This document will be used and refined throughout the entire ADM process. Copyright: The Art of Service 2008

ADM – Business Architecture Objective: To develop an appropriate business architecture Impact on Architecture: Demonstrates how business value is obtained from all architecture work Outputs: Business models, several catalogs, matrices and diagrams relevant to the Business Architecture Business Architecture is the foundation from which the Data, Application, and Technology Architectures are derived. Business Architecture The organization will develop a business architecture to support the architecture vision. The baseline and target architectures defined in the architecture definition document will identify the gaps in the organization’s current capabilities and what it needs to fulfill the vision. This phase will identify the architecture components needed to fill those gaps.   The business architecture focuses on the aspects of the business environment, such as organizational structure, functions, processes, information, and location, as well as the strategic direction for the organization’s products and services. In most cases, organizations will have devoted time on defining what they want to achieve—their goals, drivers, and metrics. However, in most cases, they have not completely defined how to get to their desired destination. This is the intent of developing a Business Architecture. In the Architecture Vision phase, business scenarios may be used to illustrate the architecture in action. In the Business Architecture phase, those scenarios can be transformed into business models to map requirements to business components. Several business models may be created in any aspect of the architecture: Business Process Models Use-Case Models Logical Data Models The major steps in the Business Architecture phase are: Selecting or creating relevant models, viewpoints, and tools Developing a description of the baseline business architecture Developing a description of the target business architecture Performing gap analysis Finalizing the business architecture Creating/updating the architecture definition document Copyright: The Art of Service 2008

ADM – Information System Architectures Objective: To develop appropriate data and application architectures Impact on Architecture: Defines the architecture capabilities for data management, data migration, data governance, and application-based functionality for the organization Outputs: several catalogs, matrices, and diagrams Information System Architecture The information system architectures are the data and application architectures of the organization. They must be developed to support the architecture vision and be aligned with the business architecture already defined. This phase is often seen as two separate activities—one for each architecture. The phase is similar in intent and function as the business architecture phase, though adopted to develop the relevant data and application architectures.   The data architecture focuses on how data is generated, captured, stored, used, and managed in relation to the scoped architecture. Data management, data migration, and data governance are key considerations to address in the data architecture. The application architecture focuses on providing the functionality required to meet the business and architecture vision. Frameworks established by programming languages or application development theories (Agile, SOA, etc.) are often leveraged at this point. The major steps in the Information System Architectures phase are: Selecting or creating relevant models, viewpoints, and tools Developing a description of the baseline data and application architecture Developing a description of the target data and application architecture Performing gap analysis Finalizing the data and application architecture Creating/updating the architecture definition document Copyright: The Art of Service 2008

ADM – Technology Architecture Objective: To develop an appropriate technology architecture Impact on Architecture: Utilizes any IT Service Catalog, the Technical Reference Model, and Technology Models to create a technology architecture capable of supporting the Business, Data, and Application architectures Outputs: several catalogs, matrices, and diagrams Technology Architecture The technology architecture focuses on enabling the physical and logical components of the data and application architectures to fulfill the Architecture Vision while maintaining alignment with the business architecture. In a loose coupling, the efforts of other frameworks, such as ITIL or COBIT, can provide the foundation required to define the technology architecture.   The major steps in the Information System Architectures phase are: Selecting or creating relevant models, viewpoints, and tools Developing a description of the baseline technology architecture Developing a description of the target technology architecture Performing gap analysis Finalizing the technology architecture Creating/updating the architecture definition document At the end of this phase, all the strict architecture considerations have been addressed. The subsequent phases will address the implementation considerations for the target architecture. Copyright: The Art of Service 2008

ADM – Opportunities and Solutions Objective: To realize the architectures and deliver business value Impact on Architecture: Transitions from concept to actuality through the development of an architecture roadmap, work packages, transition architectures, and implementation/migration planning External Influences: Project Management disciplines Outputs: Architecture Roadmap (project plan) The Opportunities and Solutions phase of the ADM is the first step after designing the architectures and focuses on implementation, namely identifying the best course of action to take. There are key contextual ideas to transitioning from design to implementation: Work Packages Architecture Roadmaps Transition Architectures Implementation and Migration Planning   The goal of ADM is to realize the target architecture. A work package is a set of changes needed to implement the architectures. Changes can be grouped into logical categories, such as technology, locations, services, etc. Architecture Roadmaps identify the various work packages and when they should be completed across a defined timeline. (Think in terms of project planning and deliverables if you are a project manager). Often in transitioning architectures, some middle ground must be temporarily established and supported until the target architecture has been realized. This middle ground is considered the Transition Architecture and has the elements of the old (still being supported) and new architecture. The management of the transition is done using project management and requires significant implementation and migration planning to support the transition architecture schedule and complete work products according to the roadmap, and to ensure that implementation of the target architecture is as effective and efficient as possible. The major steps in this phase are: Identifying the risks and constraints to implementation Translating gap analysis results from previous phases into manageable work packages Defining dependencies and schedules Identifying organizational and project readiness Identifying the transition architecture Creating implementation and migration plans Project Management is used heavily within this phase. If your organization has a dedicated project or program management function, they may have specific standards and requirements for project management, which must be met. Copyright: The Art of Service 2008

ADM – Migration Planning Objective: To create/finalize an implementation and migration plan Impact on Architecture: Defines how a target architecture will be realized from its current baseline Outputs: Finalized architecture documents, implementation and migration plan Migration Planning This is the final step in planning the architecture and is essential for ensuring that the implementation and migration of the architecture cause the least disruption to the business and IT infrastructure. Often, it requires that the plans be reviewed and approved in relation to several management frameworks existing in the organization, including: Business Planning/Resource Management Enterprise Architecture/Business and IT Alignment Portfolio/Project Management Service/Operations Management   Every work package must be defined clearly in terms of: Performance Criteria ROI Criteria Business Value Critical Success Factors Key Performance Indicators Strategic Fit in Organization An added responsibility within this phase is to understand and document the issues, mistakes, and successes of designing and developing the architectures. This information can be used to improve ADM for future iterations of the process. Copyright: The Art of Service 2008

ADM – Implementation Governance Objective: To ensure that all implementation projects conform with architecture requirements Impact on Architecture: Transfers knowledge from architecture to solution External Influences: Other management frameworks such as Solution Design, Application Development, Release and Deployment Management, Transition Planning and Support, Change Management Outputs: Assessments, change requests, and solutions complaint to the architecture Enterprises are constantly struggling with the differences between governance and management. For our purposes, governance is simply oversight over the implementation activities, while management provides active direction in ensuring that activities are completed according to plan.   Implementation governance ensures that the implementation and migration plans reflect the priorities and objectives of the business and that all standards adopted by the organization are in compliance throughout the transition. Implementation governance may be a function of the dedicated program management office, but several other governance frameworks may be engaged, specifically any architecture governance. The major steps in this phase are: Confirming scope and priorities for implementation Identifying the resources and skills needed for implementation Ensuring compliance to established standards Implementing operational state for business and IT Performing Post-Implementation Review Copyright: The Art of Service 2008

ADM – Architecture Change Management Objective: To manage changes to and resulting from an architecture Impact on Architecture: Ensures that the intended benefits and advantages of an architecture are realized Outputs: Changes, updates, new architecture work Even after implementation of the architecture, the organization must ensure that the architecture is still providing value to the business. Overtime, changes may need to be made to maintain this value. Architecture Change Management is a defined process for accepting, reviewing, and approving changes to existing architecture to ensure they’re aligned with the business priorities. The process may be supported in conjunction with other change management processes, specifically business and IT change management processes. However, architecture change management may have some key differences to consider (for example, there is no emergency change for architectures). Copyright: The Art of Service 2008

ADM – Requirements Management Objective: To manage architecture requirements throughout the ADM process Impact on Architecture: Defines and manages all functional and non-functional requirements Influences: Requirements can be generated from assumptions, constraints, principles, policies, standards, guidelines, or specifications Outputs: Requirements on the architecture Requirements Management is present in all phases of the ADM, as requirements are constantly being identified, evaluated, confirmed, approved, and integrated into the architecture. Requirements management is not unique to architectures, and your organization may have an established process for managing requirements. The key objective of the process is documenting requirements and assessing those requirements against business priorities. Copyright: The Art of Service 2008

Making TOGAF Work Be sure to consider all governance and management frameworks used by your organization. Align architectural work with IT service management, specifically any control processes (change, configuration, and release management). Ensure everyone is using the same language (i.e. what is an artifact?). Identify and classify all components of an architecture and a solution. Clearly establish and reuse viewpoints. TOGAF is a framework which provides a very comprehensive process for developing architectures. However, the process is useless without the foundation created by the repository, the technical reference model, and other resources from the organization. The ADM process focuses on creating organization-specific solutions using general architectural building blocks. Like constructing a house, the way the materials work together is just as important as the quality of the materials themselves. In Enterprise Architecture, the intent is to ensure that the architecture (house) is fit to serve its intended purpose for as long as possible. Copyright: The Art of Service 2008

The Toolkit To support the efforts of adopting enterprise architecture at this point, the Toolkit provides the following aids and templates: Customizable procedures for each ADM phase Architecture Definition Document Architecture Principles Copyright: The Art of Service 2008

Moving Forward Use the aids and templates to create an effective conversation for enterprise architecture in your organization. The template, Architecture Definition Document, is intended to provide a consistent method of identifying and documenting the existing and new architectures in your organization. Once the process for developing enterprise architecture has been established and your first working architecture is in place, the next presentation to view is ‘Managing Enterprise Architecture’. Copyright: The Art of Service 2008