Transcription
The Open GroupArchitecture Framework(TOGAF 9) and theUS Department of DefenseArchitecture Framework 2.0(DoDAF 2.0)A White Paper by:Terry Blevins, MITRE CorporationDr. Fatma Dandashi, MITRE CorporationMary Tolbert, MITRE CorporationJuly 2010
TOGAF 9 and DoDAF 2.0Copyright 2010 The Open GroupAll rights reserved. No part of this publication may be reproduced, stored in aretrieval system, or transmitted, in any form or by any means, electronic,mechanical, photocopying, recording, or otherwise, without the priorpermission of the copyright owners.This White Paper is an informational document and does not form part of theTOGAF documentation set. Readers should note that this document has notbeen approved through the formal Open Group Standards Process and doesnot represent the formal consensus of The Open Group Architecture Forum.Boundaryless Information Flow and TOGAF are trademarks and MakingStandards Work , The Open Group , UNIX , and the ―X‖ device areregistered trademarks of The Open Group in the United States and othercountries. All other trademarks are the property of their respective owners.The Open Group Architecture Framework (TOGAF 9) and theUS Department of Defense Architecture Framework 2.0 (DoDAF 2.0)1Document No.:W105Published by The Open Group, July 2010.Any comments relating to the material contained in this document may besubmitted to:The Open Group44 Montgomery St. #960San Francisco, CA 94104or by email to:ogpubs@opengroup.org1Approved for Public Release: 10-0515. Distribution Unlimited.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p2
TOGAF 9 and DoDAF 2.0Contentswww.opengroup.orgExecutive Summary4Introduction5The Open Group Architecture Framework Version 9 (TOGAF 9)8US Department of Defense Architecture Framework 2.0(DoDAF 2.0)11TOGAF 9 ADM with DoDAF 2.0 Models16DoDAF 2.0 within the TOGAF 9 ADM38Summary43References44Acronyms45About the Authors47About The Open Group48A W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p3
TOGAF 9 and DoDAF 2.0Boundaryless Information Flow achieved through global interoperabilityin a secure, reliable, and timely mannerExecutive SummaryNumerous architecture framework standards have been developed and matured over the past decade and thefocus of these frameworks is diverse. Many engineers believe there is an ―either or‖ decision to be maderegarding these frameworks; however, this is not always the case. Some of these standards address completelydifferent elements of the architecture development process, thus there may be a natural synergy that can beidentified and leveraged between architecture frameworks. The central part of TOGAF is the ArchitectureDevelopment Method (ADM), a prescriptive, step-by-step instruction guide for ―how to‖ architect, while the USDepartment of Defense Architecture Framework (DoDAF) has a primary focus on architecture description via aset of viewpoints. A MITRE working group was formed to analyze and document the relationships betweenthese two frameworks and identify complementary areas. This core group of representatives from MITRE wasalso supported by members of The Open Group Architecture Forum during this effort. The baseline versions ofthe documents used were TOGAF 9 and DoDAF 2.0.Previous analysis between TOGAF 8.1 and DoDAF 1.0 concluded that TOGAF and DoDAF were synergisticand complementary frameworks. This also holds true for the TOGAF 9 and DoDAF 2.0 releases. TOGAFcontinues to add depth to its method, while DoDAF has added depth and integrity to the types of data andviewpoints used to describe architectures. With all the improvements, it still remains beneficial to any DoDAFarchitect development effort to use the TOGAF ADM. Developing DoDAF models in conjunction with theADM allows an architect to produce an architecture description within a well-defined and repeatable process.A final note, given the synergy between these two frameworks it would appear that collaboration between thecommunities should be explored.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p4
TOGAF 9 and DoDAF 2.0IntroductionThis White Paper provides a comparative analysis of the two frameworks that describes where DoDAF products canbe employed throughout the TOGAF ADM phases to develop a visual, integrated model of an architecture.The intended audience is the DoD architect who can benefit from a formal methodology to guide architecture effortsand result in a quality architecture description in a DoD-compliant format, and the TOGAF architect who canbenefit by a formal set of defined models to capture output for each of the ADM phases. This document provides thearchitect with a map of the specific DoDAF 2.0 model that should be produced or consumed in a specific phase ofTOGAF 9 with enough context to understand the fundamental concepts of both DoDAF and TOGAF.Overview of Analysis ResultsPrevious analysis between TOGAF 8.1 and DoDAF 1.0 concluded that TOGAF and DoDAF were synergistic andcomplementary frameworks. This also holds true for the TOGAF 9 and DoDAF 2.0 releases. TOGAF continues toadd depth to its method, while DoDAF has added depth and integrity to the types of data and viewpoints used todescribe architectures. With all the improvements, it still remains beneficial to any DoDAF architect developmenteffort to use the TOGAF ADM.The following tables and graphics provide a summary of the results of this comparative analysis of TOGAF 9 andDoDAF 2.0. Detailed information between these standards is contained in the sections following.Notes to the reader: Some textual content from both TOGAF 9 and DoDAF 2.0 has been intentionally extracted and embedded in thisWhite Paper to provide better insight to the reader on both standards. Some minor edits of this text were made toclarify DoDAF 2.0/TOGAF 9 relationships. There are numerous detailed method steps in some TOGAF 9 phases. In these instances a subset of the completeTOGAF 9 step listing is presented, focusing on the steps that apply to DoDAF 2.0 tailoring comments.Table 1 provides a summary of DoDAF 2.0 architecture models mapped to specific sections within the TOGAF 9structure.Table 1: Summary Mapping of DoDAF 2.0 Models to TOGAF 9 StructureViewpointDoDAFModelDoDAF Model NameTOGAF 9 Structure ReferenceAll ViewpointAV-1Overview and Summary InformationPart II: Ch. 6 through 16,All PhasesAll ViewpointAV-2Integrated DictionaryPart II: Ch. 6 through 16,All PhasesCapability ViewpointCV-1VisionPart II: Ch. 7, 8, Phases A, BCapability ViewpointCV-2Capability TaxonomyPart II: Ch. 7, 8, Phases A, BCapability ViewpointCV-3Capability PhasingPart II: Ch. 7, 14, 16,Phases A, F, HCapability ViewpointCV-4Capability DependenciesPart II: Ch. 7, 8, Phases A, BCapability ViewpointCV-5Capability to Organizational DevelopmentMappingPart II: Ch. 13, Phase ECapability ViewpointCV-6Capability to Operational ActivitiesMappingPart II: Ch. 13, Phase Ewww.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p5
TOGAF 9 and DoDAF 2.0ViewpointDoDAFModelDoDAF Model NameTOGAF 9 Structure ReferenceCapability ViewpointCV-7Capability to Services MappingPart II: Ch. 13, Phase EData and InformationViewpointDIV-1Conceptual Data ModelPart II: Ch. 7, Phase AData and InformationViewpointDIV-2Logical Data ModelPart II: Ch. 8, Phases B, CData and InformationViewpointDIV-3Physical Data ModelPart II: Ch. 10, Phases COperational ViewpointOV-1High-Level Operational Concept GraphicPart II: 6, 7, Phases Prelim, AOperational ViewpointOV-2Operational Resource Flow DescriptionPart II: Ch. 8, Phase BOperational ViewpointOV-3Operational Resource Flow MatrixPart II: Ch. 8, Phase BOperational ViewpointOV-4Organizational Relationships ChartPart II: Ch. 8, Phase BOperational ViewpointOV-5aOperational Activity Decomposition TreePart II: Ch. 8, Phase BOperational ViewpointOV-5bOperational Activity ModelPart II: Ch. 8, 13, Phases B, EOperational ViewpointOV-6aOperational Rules ModelPart II: Ch. 8, Phase BOperational ViewpointOV-6bState Transition DescriptionPart II: Ch. 8, Phase BOperational ViewpointOV-6cEvent-Trace DescriptionPart II: Ch. 8, Phase BProject ViewpointPV-1Project Portfolio RelationshipsPart II: Ch. 7, 13, 14, 16,Phases A, E, F, HProject ViewpointPV-2Project TimelinesPart II: Ch. 7, 8, 13, 14, 16,Phases A, B, E, F, HProject ViewpointPV-3Project to Capability MappingPart II: Ch. 7, 8, 14, 16,Phases A, B, F, HServices ViewpointSvcV-1Services Context DescriptionPart II: Ch. 11, Phase CServices ViewpointSvcV-2Services Resource Flow DescriptionPart II: Ch. 11, Phase CServices ViewpointSvcV-3aSystems-Services MatrixPart II: Ch. 12, Phase DServices ViewpointSvcV-3bServices-Services MatrixPart II: Ch. 11, Phase CServices ViewpointSvcV-4Services Functionality DescriptionPart II: Ch. 11, Phase CServices ViewpointSvcV-5Operational Activity to ServicesTraceability MatrixPart II: Ch. 11, Phase CServices ViewpointSvcV-6Services Resource Flow MatrixPart II: Ch. 11, Phase CServices ViewpointSvcV-7Services Measures MatrixPart II: Ch. 11, Phase CServices ViewpointSvcV-8Services Evolution DescriptionPart II: Ch. 13, Phase EServices ViewpointSvcV-9Services Technology & Skills ForecastPart II: Ch. 13, 16, Phases E, HServices ViewpointSvcV-10aServices Rules ModelPart II: Ch. 11, Phase CServices ViewpointSvcV-10bServices State Transition DescriptionPart II: Ch. 11, Phase CServices ViewpointSvcV-10cServices Event-Trace DescriptionPart II: Ch. 11, Phase CSystems ViewpointSV-1Systems Interface DescriptionPart II: Ch. 12, Phase DSystems ViewpointSV-2Systems Resource Flow DescriptionPart II: Ch. 12, Phase DSystems ViewpointSV-3Systems-Systems MatrixPart II: Ch. 12, Phase DSystems ViewpointSV-4Systems Functionality DescriptionPart II: Ch. 12, Phase DSystems ViewpointSV-5aOperational Activity to Systems FunctionTraceability MatrixPart II: Ch. 12, Phase Dwww.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p6
TOGAF 9 and DoDAF 2.0ViewpointDoDAFModelSystems ViewpointDoDAF Model NameTOGAF 9 Structure ReferenceSV-5bOperational Activity to SystemsTraceability MatrixPart II: Ch. 12, Phase DSystems ViewpointSV-6Systems Resource Flow MatrixPart II: Ch. 12, Phase DSystems ViewpointSV-7Systems Measures MatrixPart II: Ch. 12, Phase DSystems ViewpointSV-8Systems Evolution DescriptionPart II: Ch. 13, Phase ESystems ViewpointSV-9Systems Technology & Skills ForecastPart II: Ch. 13, 16, Phases E, HSystems ViewpointSV-10aSystems Rules ModelPart II: Ch. 12, Phase DSystems ViewpointSV-10bSystems State Transition DescriptionPart II: Ch. 12, Phase DSystems ViewpointSV-10cSystems Event-TracePart II: Ch. 12, Phase DStandards ViewpointStdV-1Standards ProfilePart II: Ch. 12, Phase DStandards ViewpointStdV-2Standards ForecastPart II: Ch. 13, 16, Phases E, HFigure 1 is a visualization of the relationship between these frameworks from a TOGAF 9 to DoDAF 2.0 perspectiveusing the TOGAF 9 ADM Cycle diagram.AV-1, AV-2,OV-1AV-1, AV-2, OV-1,CV-1, 2, 3, 4, PV-1, 2, 3, DIV-1AV-1, AV-2, CV-3, PV-1, 2, & 3,SV-9, SvcV-9, StdV-2AV-1, AV-2, OV-s,CV-1, 2, 4, PV-2, 3, DIV-2AV-1, AV-2,Architecture ModelData Arch: AV-1, AV-2,DIV-2, DIV-3Apps Arch: AV-1, AV-2, CV-3, 7,SvcV-1, 4, 5, 7, 10c,AV-1, AV-2PV-1, 2, 3, CV-3AV-1, AV-2,SVs, StdV-1, 2Refined:AV-1, AV-2, OVs, DIVs, CVs, SvcV, & SVsNew: CV-5, 6 and 7 , PV-1, 2, SV-8, 9, SvcV-8, 9, StdV-2Figure 1: Summary of TOGAF 9 ADM with DoDAF 2.0 Models as the Architecture Descriptionwww.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p7
TOGAF 9 and DoDAF 2.0The Open Group Architecture Framework Version 9 (TOGAF 9)TOGAF is a ― detailed method and set of supporting tools—for developing enterprise architecture.‖ [TOGAF9-2009] In the early 1990s, the US Department of Defense (DoD) developed a series of architecture guidancedocuments known as the Technical Architecture Framework for Information Management (TAFIM). The purpose ofthese eight volumes was to provide: ― the services, standards, design concepts, components, and configurationsthat can be used to guide the development of technical architectures that meet specific mission requirements‖ toevolve the DoD technical infrastructure [TAFIM-1996]. TAFIM was matured to Version 3.0 and then provided toThe Open Group for its ongoing maturation and promulgation across the US Government and industry. TAFIMserved as the baseline for the development of TOGAF in 1995 and was subsequently retired.The US Defense Information Systems Agency (DISA) contributed heavily to the development of TOGAF 1.0,which primarily leveraged TAFIM Volume 2: Technical Reference Model for the TOGAF Technical ReferenceModel and TAFIM Volume 3: Architecture Concepts and Design Guidance for the TOGAF ArchitectureDevelopment Method (ADM). The ADM is a prescriptive, step-by-step instruction guide for ―how to‖ architect. It ispresented in a series of phases that guide the architect or architecture team through the architecting lifecycle ofsystem development. The first seven releases of the TOGAF ADM (1995-2001) focused on providing technicalarchitecture guidance. The 2002 release of TOGAF 8.0 extended the earlier technical focus with elements ofBusiness, Data, and Application Architectures. This ―collection‖ of architectures is commonly known as ―enterprisearchitecture‖.Table 2 below is an overview of the nine phases that guide the architect through the ADM.Table 2: TOGAF ADM Phase rk &PrinciplesIdentify additional framework(s) to use; define architecture principles toguide the architecture workAArchitecture VisionDefine scope; create vision; identify relevant stakeholders; definebusiness/mission requirements and constraints; obtain approvalsBBusinessArchitectureDevelop Baseline and Target Business Architectures, describing productand/or service strategy and organizational, functional, process, information,and geographic aspects of the business/mission environment, based onbusiness/mission principles, business/mission goals, and strategic driversCInformationSystemsArchitecture:Data ArchitectureDevelop Target Architecture(s) covering either the data chitectureDevelop Target Architecture(s) covering either the application or systemsdomainsDTechnologyArchitectureDevelop Technology Architecture to form the basis of the followingimplementation workEOpportunities andSolutionsEvaluate and select among the implementation options identified incandidate Target Architectures; identify strategic parameters for change andtop-level work packages or projects required to move from current state totarget stateFMigration PlanningAssess dependencies, costs, and benefits of the various migration projects;prioritize list of projects to form basis of detailed Implementation andMigration Planwww.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p8
TOGAF 9 and DoDAF ke recommendations for each implementation project; constructarchitecture contract to govern overall implementation and deploymentprocess; perform governance functions while system is implemented anddeployed; ensure conformance with defined architectureHChangeManagementProvide for the continual monitoring of new developments in technology andchanges in the business environment, and for determining whether toformally initiate a new architecture evolution cycleWith TOGAF 9 the reader is introduced to a new modular structure comprised of seven main parts: Part I: Introduction Part II: Architecture Development Method (ADM) Part III: ADM Guidelines and Techniques Part IV: Architecture Content Framework (ACF) Part V: Enterprise Continuum and Tools Part VI: TOGAF Reference Models Part VII: Architecture Capability FrameworkThe focus of this White Paper will remain on the use of DoDAF 2.0 models in conjunction with the TOGAF 9ADM; however, the TOGAF 9 ACF can serve as useful reference in the development of DoDAF 2.0 models.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p9
TOGAF 9 and DoDAF 2.0Figure 2: TOGAF 9 ADMNote: Although TOGAF 9 phases have alphabetic identifiers, there is an understanding that iteration within andbetween phases is required.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p10
TOGAF 9 and DoDAF 2.0US Department of Defense Architecture Framework 2.0 (DoDAF 2.0)In 1995, the US Deputy Secretary of Defense directed that work begin: ―.to define and develop better means andprocesses for ensuring that C4I capabilities meet the needs of warfighters‖. [CAF-1996] This initiative led to thedevelopment of the Command, Control, Communications, Computers, Intelligence, Reconnaissance, andSurveillance (C4ISR) Architecture Framework (CAF). CAF 1.0 was published in 1996 and was matured throughdeployment analyses and lessons learned. CAF 2.0 was released in December 1997. The US Department of Defensebroadened the scope of the CAF by its next release in February 2004, renaming it the Department of DefenseArchitecture Framework (DoDAF) to clarify its scope within the US Government. Additionally, its version numberwas reset to 1.0. DoDAF 2.0 was released in May 2009 with several significant changes.Version 2.0 focuses on architectural data (rather than individual products as described in previous versions), changesthe terminology for major concepts, adds new viewpoints (formerly known as views), and describes models(formerly known as products) for each viewpoint. DoDAF 2.0 also discusses ―fit-for-purpose‖ descriptions as userdefined presentations of a subset of architectural data created for some specific purpose.DoDAF 2.0 consists of three volumes: Volume 1: Introduction, Overview, and Concepts – Manager’s Guide Volume 2: Architectural Data and Models – Architect’s Guide Volume 3: DoDAF Meta-model: Physical Exchange Specification – Developer’s GuideThe DoDAF Journal2 is an electronic interface for DoDAF support. The DoDAF Journal provides a place forsubmitting future change requests to DoDAF, gives examples referenced in the various DoDAF volumes, andincludes descriptions of other best practices, lessons learned, and reference documents that supplement theinformation contained in the three volumes of DoDAF 2.0.The primary focus of DoDAF is architecture description – the architecture depiction consisting of several models(called products in [DoDAF-2004]) and reflecting the architecture from multiple viewpoints. Figure 3, extractedfrom DoDAF 2.0 Volume 1, Section 3.4.2, shows the All, Operational, Systems, and Standards viewpoints and thenewly defined Capability, Services, Data and Information, and Project viewpoints. [DoDAF-2009] Initially theprimary objective of DoDAF was to facilitate establishing interoperability between DoD systems, but that objectivehas been broadened to facilitate decision-making by DoD managers at all levels on issues relating to DOTMLPF(Doctrine, Organization, Training, Material, Leadership and Education, Personnel, and Facilities) as well as DoD ITsystems.2Refer to http://cio-nii.defense.gov/sites/dodaf20/journal exp3.html.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p11
TOGAF 9 and DoDAF 2.0Figure 3: Architecture Viewpoints in DoDAF 2.0Model descriptions in DoDAF 2.0 are provided as “predefined examples”. DoDAF does not prescribe any particularmodels. Instead it concentrates on the data required for architecture development. However, other regulations andinstructions from both the DoD and Chairman, Joint Chiefs of Staff (CJCS) have specific presentation requirements.These models are supported by DoDAF 2.0, and should be consulted for specific model requirements.A review of the DoDAF 2.0 models and descriptions in Table 3 reflects that these models are not unique to DoDarchitectures – many are traditional systems engineering modeling artifacts that have been in use for many years.Most are intrinsically useful beyond the DoD community. DoDAF 2.0 can be leveraged by many domains outside ofthe DoD community, providing a baseline for which architecture models the architect (or architecture team)considers when identifying which viewpoints will be addressed by their overall architecture description.Table 3: DoDAF 2.0 Listing of Architecture ModelsViewpointModelNameGeneral DescriptionAll ViewpointAV-1Overview andSummaryInformationDescribes a project's visions, goals, objectives, plans,activities, events, conditions, measures, effects (outcomes),and produced objects.All ViewpointAV-2IntegratedDictionaryAn architectural data repository with definitions of all termsused throughout the architectural data and presentations.CapabilityViewpointCV-1VisionThe overall vision for transformational endeavors, whichprovides a strategic context for the capabilities described and ahigh-level scope.CapabilityViewpointCV-2CapabilityTaxonomyA hierarchy of capabilities which specifies all the capabilitiesthat are referenced throughout one or more apabilityPhasingThe planned achievement of capability at different points intime or during specific periods of time. The CV-3 shows thecapability phasing in terms of the activities, conditions, desiredeffects, rules complied with, resource consumption andproduction, and measures, without regard to the performer andlocation solutions.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p12
TOGAF 9 and DoDAF 2.0ViewpointModelNameGeneral enciesThe dependencies between planned capabilities and thedefinition of logical groupings of capabilities.CapabilityViewpointCV-5Capability toOrganizationalDevelopmentMappingThe fulfillment of capability requirements shows the plannedcapability deployment and interconnection for a particularcapability phase. The CV-5 shows the planned solution for thephase in terms of performers and locations and theirassociated concepts.CapabilityViewpointCV-6Capability toOperationalActivities MappingA mapping between the capabilities required and theoperational activities that those capabilities support.CapabilityViewpointCV-7Capability toServices MappingA mapping between the capabilities and the services thatthese capabilities enable.Data andInformationViewpointDIV-1Conceptual DataModelThe required high-level data concepts and their relationships.Data andInformationViewpointDIV-2Logical DataModelThe documentation of the data requirements and structuralbusiness process (activity) rules. In DoDAF V1.5, this was OV7.Data andInformationViewpointDIV-3Physical DataModelThe physical implementation format of the Logical Data Modelentities; e.g., message formats, file structures, physicalschema. In DoDAF V1.5, this was lConcept GraphicThe high-level graphical/textual description of the onalResource FlowDescriptionA description of the resource flows exchanged betweenoperational urce FlowMatrixA description of the resources exchanged and the relevantattributes of the lationshipsChartThe organizational context, role, or other relationships ionalActivityDecompositionTreeThe capabilities and activities (operational activities) organizedin a hierarchal vity ModelThe context of capabilities and activities (operational activities)and their relationships among activities, inputs, and outputs;Additional data can show cost, performers, or other ational RulesModelOne of three models used to describe activity (operationalactivity). It identifies business rules that constrain operations.OperationalViewpointOV-6bState TransitionDescriptionOne of three models used to describe operational activity(activity). It identifies business process (activity) responses toevents (usually, very short scriptionOne of three models used to describe operational activity(activity). It traces actions in a scenario or sequence of events.ProjectViewpointPV-1Project PortfolioRelationshipsDescribes the dependency relationships between theorganizations and projects and the organizational structuresneeded to manage a portfolio of projects.www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p13
TOGAF 9 and DoDAF 2.0ViewpointModelNameGeneral DescriptionProjectViewpointPV-2Project TimelinesA timeline perspective on programs or projects, with the keymilestones and inter-dependencies.ProjectViewpointPV-3Project toCapabilityMappingA mapping of programs and projects to capabilities to showhow the specific projects and program elements help toachieve a capability.ServicesViewpointSvcV-1Services ContextDescriptionThe identification of services, service items, and cesResource FlowDescriptionA description of resource flows exchanged between atrixThe relationships among or between systems and services in agiven architectural cesMatrixThe relationships among services in a given architecturaldescription. It can be designed to show relationships ofinterest, (e.g., service-type interfaces, planned versus sFunctionalityDescriptionThe functions performed by services and the service dataflows among service functions ivity toServicesTraceability MatrixA mapping of services (activities) back to operational icesResource FlowMatrixProvides details of service resource flow elements beingexchanged between services and the attributes of es MatrixThe measures (metrics) of services model elements for theappropriate timeframe(s).ServicesViewpointSvcV-8Services EvolutionDescriptionThe planned incremental steps toward migrating a suite ofservices to a more efficient suite or toward evolving currentservices to a future nology &Skills ForecastThe emerging technologies, software/hardware products, andskills that are expected to be available in a given set oftimeframes and that will affect future service development.ServicesViewpointSvcV-10aServices RulesModelOne of three models used to describe service functionality. Itidentifies constraints that are imposed on systems functionalitydue to some aspect of system design or implementation.ServicesViewpointSvcV-10bServices StateTransitionDescriptionOne of three models used to describe service functionality. Itidentifies responses of services to events.ServicesViewpointSvcV-10cServices EventTrace DescriptionOne of three models used to describe service functionality. Itidentifies service-specific refinements of critical sequences ofevents described in the Operational Viewpoint.SystemsViewpointSV-1Systems InterfaceDescriptionThe identification of systems, system items, and esource FlowDescriptionA description of resource flows exchanged between he relationships among systems in a given architecturaldescription. It can be designed to show relationships of interest(e.g., system-type interfaces, planned versus existinginterfaces).www.opengroup.orgA W h i t e P a p e r P u b l i s h e d b y T h e O p e n Gr o u p14
TOGAF 9 and DoDAF 2.0ViewpointModelNameGeneral yDescriptionThe functions (activities) performed by systems and thesystem data flows among system functions ity toSystems FunctionTraceability MatrixA mapping of system functions (activities) back to operationalactivities ity toSystemsTraceability MatrixA mapping of systems back to capabilities or operationalactivities (activities).SystemsViewpointSV-6SystemsResource FlowMatrixProvides details of system resource flow elements beingexchanged between systems and the attributes of thatexchange.SystemsViewpointSV-7SystemsMeasures MatrixThe measures (metrics) of systems model elements for theappropriate timeframe(s).SystemsViewpointSV-8Systems EvolutionDescriptionThe planned incremental steps toward migrating a suite ofsystems to a more efficient suite, or toward evolving a currentsystem to a future gy &Skills ForecastThe emerging technologies, software/hardware products, andskills that are expected to be available in a given set oftimeframes and that will affect future system development.SystemsViewpointSV-10aSystems RulesModelOne of three models used to describe system functionality. Itidentifies constraints that are imposed on systems functionalitydue to some aspect of system design or implementation.SystemsViewpointSV-10bSystems StateTransitionDescriptionOne of three models used to describe system functionality. Itidentifies responses of systems to events.SystemsViewpointSV-10cSystems EventTraceOne of three models used to describe system functionality. Itidentifies system-specific refinements of critical sequences ofevents described in the Operational Viewpoint.StandardsViewpointStdV-1Standards ProfileThe listing of standards that apply to solution The description of emerging standards and potential impact oncurrent solution elements, within a set of timeframes.www.opengro
The Open Group Architecture Framework Version 9 (TOGAF 9) 8 US Department of Defense Architecture Framework 2.0 (DoDAF 2.0) 11 TOGAF 9 ADM with DoDAF 2.0 Models 16 DoDAF 2.0 within the TOGAF 9 ADM 38 Summary 43 References 44
