This action might not be possible to undo. Are you sure you want to continue?
A Quick Look on TOGAF
By: Agung Ariwibowo
ABSTRACT One of the reasons of implementing enterprise architecture is to create balance between business and IT for the needs of organizations. The enterprise architecture implementation is always related to how an enterprise plans and designs the enterprise architecture. To do so, they need a methodology, a framework that is complete and easy to use, and TOGAF is the one to come in mind. It is complete, but not many understand how to use well. So we will take a look at TOGAF which is actually one of the best architecture frameworks available. Keywords: enterprise architecture, TOGAF, methodology, architecture framework 1. INTRODUCTION The field of enterprise architecture essentially started in 1987 with the publication in the IBM System Journal of an article titled, “A framework for information system architecture,” by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architecture that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. Zachman said that the cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. Zachman became a major influence to the Department of Defense of the United States Government to create enterprise architecture. This EA was known as the Technical Architecture Framework for Information Management (TAFIM). TAFIM was introduced in 1994. In 1995 the first version of TOGAF was presented, which was based on the TAFIM. The US Department of Defense gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM. TOGAF 7 (“Technical Edition”) was published in December 2001. TOGAF 8 (“Enterprise Edition”) was first published in December 2002 and republished in updated form as TOGAF 8.1 in December 2003, which was updated in November 2006 as TOGAF 8.1.1. The latest version is TOGAF 9, launched on 2 February 2009. As an evolutionary development from TOGAF 8, TOGAF 9 includes many new features including • Increased rigor including a formal Meta Model that links the artifacts of TOGAF together Elimination of unnecessary differences More examples and templates
Additional guidelines and techniques include • • • A formal business-driven approach to architecture scoping and segmentation Business capability-based planning Guidance on how to use TOGAF to develop Security Architecture and SOAs
2. TOGAF ENTERPRISE ARCHITECTURE DOMAINS TOGAF is based on four pillars, called architecture domains:
identifying the stakeholders. including the definition of an Organization-Specific Architecture Specific framework and the definition of principles. communications. The ADM includes establishing an architecture framework. organization. ganization. other and their relationships to the core business processes of the organization. transitioning. and obtaining approvals. The TOGAF ADM . IDEF.A Quick Look on TOGAF Business Architecture – Describes the processes the business uses to meet its goals. In this phase. and key business processes of the organization. . and the associated data management resources. . and UML can be used to build the models needed. Applications Architecture – Describes how specific applications are designed and how they interact with each other. and governing the realization of architectures. processing. Data Architecture – Describes how the enterprise data assets are organized and accessed. software. network. many modeling notations such as BPMN. provides a tested and repeatable process for pro developing architectures. • • • The Preliminary Phase The preliminary phase d reliminary describes the preparation and initiation activities initiat et required to prepare to meet the business directive for a new enterprise architecture. but the most important part of TOGAF is the t Architecture Development Method. as seen on Figure 1. 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. Technology Architecture – Describes the hardware. middleware. It includes information about defining the scope. are . ARCHITECTURE DEVELOPMENT METHOD TOGAF describes itself as a framework. Phase B: Business Architecture This phase describes the development of escribes a Business Architecture to support an agreed Architecture Vision. It defines the business strategy. as well as the data structure . creating the Architecture Vision. In this phase. Phase A: Architecture Vision This phase describes the initial phase of ibes an architecture development cycle. • • • • Figure 1 TOGAF Architecture Development Cycle Phases within the ADM are as follows: 3. 2 . governance. The TOGAF ADM is a flexible method since it can be tailored to suit the changes of needs ilored during the design phase. and standards that support applica applications and their interactions. All of these activities. there are questions which are used to get the ideal architecture. developing architecture content. better known as TOGAF ADM.
Techniques that can be used on this phase are Environment and Location Diagram. In the content metamodel. Class Diagram. stored. processes. etc. as well as decides if another cycle of architecture development will be done. etc. Usually. • • • . which defines a set of entities that allow architectural concepts to be captured. queried. Requirements Management This is actually a phase that is done on every phases. And in the associated viewpoints. Techniques to be used are ERDiagram.A Quick Look on TOGAF Phase C: Information Systems Architectures This phase describes the development of Information Systems Architectures for an architecture project. Furthermore. requirement management is included. To model this phase on the design. the content metamodel has viewpoints associated with them. and service function. Techniques that can be used are Application Communication Diagram. The viewpoints associated with the content metamodel can be seen on Figure 3. it examines the process of managing architecture requirements throughout the ADM. It also emphasize on the application models to be designed. completeness. The information system architecture phase is even divided into data and application architecture. Network Computing Diagram. and diagrams. Phase E: Opportunities & Solutions This phase conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. The detailed representation of the content metamodel can be seen on Figure 2. • • • • Each of the phases mentioned above have their own content metamodel. Phase G: Implementation Governance This phase provides an architectural oversight of the implementation. Data architecture focuses on how data are used for the needs of business. Phase F: Migration Planning This phase addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. and represented in a way that supports consistency. filtered. These viewpoints come in form of catalogs. and traceability. The application architecture is more focused on how the requirements of application planned using the Application Portfolio Catalog. Phase H: Architecture Change Management This phase establishes procedures for managing change to the new architecture. but the migration planning. implementation governance. which is used in order to aid in re-use and consistency. The 3 mapping on this phase can be integrated with other management framework such as COBITS from IT Governance Institute (ITGI). Their purpose is mainly to identify stakeholders concerns. and Object Diagram. Phase D: Technology Architecture This phase describes the development of the Technology Architecture for an architecture project. matrices. Application and User Location Diagram. You may realize that not all of the phases in TOGAF Architecture Development Cycle included in the content metamodel and the viewpoints associated with it. architecture change management and requirement management are not included. we can use the Project Context Diagram and the Benefit Diagram. and architecture change management phases are not included. the modeling on this phase uses valuation and decision matrices for the organization needs for the implementation of a system. including the development of Data and Application Architectures.
A Quick Look on TOGAF Figure 2 Detailed Representation of the Content Metamodel Figure 3 Viewpoints Associated with the Core Content Metamodel and Extension 4 .
Principles Catalog Architecture Vision: . The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts. ENTERPRISE CONTINUUM It is usually impossible to create a single unified architecture that meets all requirements of all stakeholders for all time.Application Interaction Matrix .Role Catalog . the enterprise architect will need to deal not just with a single enterprise architecture.Requirements Catalog 4.Technology Standards Catalog . Without an understanding of "where in the continuum you are".Functional Decomposition Diagram .System/Technology Matrix .Interface Catalog .System/Function Matrix . both within individual enterprises.Data Dissemination Diagram Information Systems (Application Architecture): . as they evolve from generic Foundation Architectures to Organization-Specific Architectures.Value Chain Diagram .Business Service/Information Diagram .Solution Concept Diagram Business Architecture: .Stakeholder Map Matrix . The Enterprise Continuum not only represent an aid to communication.System Use-Case Diagram Technology Architecture: . Therefore. • • • • 5 .Role/ System Matrix .Business Footprint Diagram . Effectively bounding the scope of an architecture is therefore a critical success factor in allowing architects to break down a complex problem space into manageable components that can be individually addressed.Business Service/Function Catalog . they are as follows: • • Preliminary: .Application and User Location Diagram . The Enterprise Continuum in general can be seen on Figure 4. people discussing architecture can often talk at cross-purposes because they are referencing different points in the continuum at the same time.Actor/Role Matrix . without realizing it. it represents an aid to organizing re-usable architecture and solution assets.Product Lifecycle Diagram Information Systems (Data Architecture): . Each architecture will have a different purpose and architectures will relate to one another.Class Diagram . but with many related enterprise architectures.Data Entity/Business Function Diagram .A Quick Look on TOGAF The viewpoints associated with the content metamodel on each phase are called artifacts.System/Data Matrix .Environments and Locations Diagram • • Opportunities and Solutions: .Benefits Diagram Requirements Management: .Project Context Diagram .Application Communication Diagram .Technology Portfolio Catalog .Business Interaction Matrix .System/Organization Matrix . The Enterprise Continuum is an important aid to communication and understanding.Application Portfolio Catalog .Organizational/Actor Catalog .Data Entity/Data Component Diagram . both internal and external to the Architecture Repository. and as can be seen on figure 3. and between customer enterprises and vendor organizations.
A Quick Look on TOGAF Figure 4 Enterprise Continuum Figure 5 Relationships between Architecture and Solution Continua 6 .
For example. standards. the Enterprise Continuum contains two specializations. systems.g. which now become an important factor in an organization success. but are not directly used during the ADM architecture development. strategic initiatives. 5. organizational structures. It provides a tested and repeatable process for developing architectures. The Foundation Solutions also support the Foundation Architecture by helping to realize the architecture defined in the Architecture Continuum. • • . The Solutions Continuum provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum. The Solutions Continuum addresses the commonalities and differences among the products. Finally. The Enterprise Continuum classifies contextual assets used to develop architectures. The similar relationship also exists between the other elements of the Enterprise Continuum. The Enterprise Continuum classes of assets may influence architectures. direction. The solutions are the results of agreements between customers and business partners that implement the rules and relationships defined in the architecture space. The TOGAF Architecture domains are the four pillars that become the base of TOGAF.A Quick Look on TOGAF The Enterprise Continuum is partitioned into three distinct continua as follows: • The Enterprise Continuum is the outermost continuum and classifies assets related to the context of the overall enterprise architecture. thus helps in communication and organizing re-useable architecture and solution assets. namely the Architecture and Solutions Continua. and support. ABBs evolve through their development lifecycle from abstract and generic entities to fully expressed Organization-Specific Architecture assets. common system architectures (such as the III-RM). It can provide a thorough enterprise architecture analysis and design. industry architectures. especially one that depends on IT. representations. and enterprise-level capabilities. including traceability and derivation relationships (e. TOGAF ADM might be the most important part of TOGAF itself. The main TOGAF topics are the TOGAF Enterprise Architecture domains. to show that an Organization-Specific Architecture is based on an industry or generic standard). and enterprise architectures. The Architecture Continuum represents a structuring of Architecture Building Blocks (ABBs) which are re-usable architecture assets. the Foundation Architectures defined in Architecture Continua guide the creation or selection of Foundation Solutions defined in Solution Continua. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy. and relationships in an architecture. CLOSURE The TOGAF is a complete architecture framework. such as policies. The Enterprise Continuum can also classify solutions. the TOGAF ADM. The Architecture and Solutions Continua have relationships in form of guidance. These relationships can be seen on Figure 5. and services of implemented systems. The Architecture Continuum assets will be used to guide and select the elements in the Solutions Continuum. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts. The Architecture Continuum shows the relationships among foundational frameworks (such as TOGAF). and the Enterprise Continuum. The Solutions Continuum defines what is available in the 7 organizational environment as re-usable Solution Building Blocks (SBBs).. The Architecture Continuum offers a consistent way to define and understand the generic rules.
since it would not be possible without the help provided by CIMBNiaga Karawaci. K. Open Group. (2007). (2010). R. Seminar Nasional Aplikasi Teknologi Informasi 2009 (SNATI 2009). 8 . 2010. Accessed on July 21. TOGAF V9 Sample Catalogs Matrices Diagrams v2. Inc. It is not just a matter of choosing the best framework. ACKNOWLEDGEMENT Writer would thank CIMBNiaga Karawaci for providing the necessary material and resources to write this document. The Open Group Architecture Framework http://www. Comparison of the Top Four Enterprise Architecture Methodologies. TOGAF Standard Courseware V9 Edition. Sessions. REFERENCES Open Group. ObjectWatch.A Quick Look on TOGAF Even though TOGAF is a complete framework and may even be the best framework available. 6. Perancangan Model Enterprise Architecture dengan TOGAF Architecture Development Method. ISSN: 1907-5022. R. to create good enterprise architectures. organization will still need skilled architect..org/architecture/togaf9doc/arch/. (2009). Surendro. (2009). Yunis.opengroup.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.