Presentation on theme: "Introduction NAME 24 Sep 2009 Mr. Michael Wayson"— Presentation transcript:
1 Introduction NAME 24 Sep 2009 Mr. Michael Wayson Enterprise Architecture & Standards DirectorateOffice of the DoD Deputy Chief Information Officer(703)
2 DoDAF DefinitionDoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries.
3 DoDAF V2.0 Goals Support the Department’s core processes: Capabilities Integration and Development (JCIDS)Planning, Programming, Budgeting, and Execution (PPBE)Acquisition System (DAS)Systems Engineering (SE)Operations PlanningCapabilities Portfolio Management (CPM)Establish guidance for architecture content as a function of purpose – “fit for purpose”Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.
4 DoDAF V2.0 What has been delivered? Volume 1 – Manager’s GuideGuidance for Development, Use, and Management of ArchitecturesVolume 2 – Architect’s GuideDescribes construction of Architectures, the DODAF Meta-model, Data Exchange Requirements, and Development of the Architectural Models in technical detailVolume 3 – Developer’s GuideIntroduces the DoDAF Meta-Model Physical Exchange Specification
5 DKO DoDAF JournalWhat has been delivered in the DKO DoDAF Journal (https://www.us.army.mil/suite/page/454707)Models, Evaluation, ProcessOther Information (https://www.us.army.mil/suite/folder/ )Meta-Model Data Dictionary (Zip File)Physical Exchange Specification XSDs (Zip file)DoDAF Product Development Questionnaire Analysis Report (Capability and Project View examples and others are here)The DKO-S DoDAF Homepage isNeed a sponsored account if not Military or DoD Civilian
6 DoDAF V2.0 Promulgation Memo Version 2.0 is the prescribed framework for all Department architectures and represents a substantial shift in approach.Don’t redo current architectureArchitectures shall comply with Version 2.0 in their next major release.Update only in the next releaseDoes not prevent early adoption of DoDAF V2.0
7 VERSION 153/25/ :01Value of DoDAF V2.0DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs.Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers.Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA)-related techniques and toolsAdheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition GuideCan be used in conjunction with Lean Six Sigma and other Process Improvement methods7
8 DoDAF V2.0 FocusResults: Better ANALYSIS and Decisions.Focus: architecture DATA, not ProductsThe DoDAF Meta-model (DM2) supports the architecture content of the DoD Core ProcessesThe relationships captured in DM2 supports qualitative and quantitative analysisBy being able to relate architectural descriptions, with a common architecture vocabulary, better analysis across architectural description can be performed.Data allows better analytical results for the decision makers.8
9 Shift from Product-Centric to Data-Centric Focus Prior versions of DoDAF and earlier C4ISR versions of the Architecture Framework have emphasized reusable and interoperable data organized into ‘products’ (e.g., graphical representations or documents)DoDAF V2.0 emphasizes focus on data, and relationships among and between data rather than the presentations of productsEmphasizes on utilizing architectural data to support analysis and decision-making,Greatly expands the types of graphical representations that can be used to support decision-making activities.Supports innovative and flexible presentation of the architectural data in a meaningful, useful, and understandable mannerDoDAF 2.0 significantly refocuses the architectural concepts that have been in play for many years. First and foremost, the focus is on DATA, not architecture products. Data is needed for good analysis and better decisions. How these decisions are made within the culture of an organization should not artificially change just because we publish a Framework.Instead, this version discusses how to collect the data needed, validate that data, organize that data, and THEN form it into models, views, and viewpoints that graphically express the data. For those that have been happy with the older ‘DoDAF products’, please be assured that they are still being supported, along with many other views. The difference is that you can choose HOW to express your data in ways that better fit both your organizational preferences, and your specific project needs
10 DoDAF 2.0 focuses architecture development to ‘Fit for Purpose’ DoDAF 2.0 introduces ‘Fit-for-Purpose’ architecture as one that is appropriately focused on supporting the stated objectives‘Fit-for-Purpose’ architecturesRespond to the stated goals and objectives of a process ownerAre useful in the decision-making processRespond to internal and external stakeholder concerns‘Fit-for-Purpose’ enables the architect to focus on collecting data and creating views that are necessary for the decision-maker’s requirements, and focusing the architecture to align to the decision-maker’s needs10
11 Data-Centric: Original DoDAF Views have been expanded to better organize information, and reflect data that practitioners actually useModified ViewpointsThe original DoDAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practiceAll the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV)The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc)Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standardsThe All Viewpoint (AV) is essentially the same.New ViewpointsCapability Viewpoint (CV) focuses on Capability data in support of Capability development and to standardize the capture of capability dataProject Viewpoint (PV) focuses on the Portfolio Management/CPM information to explicitly tie architecture data to project efforts11
12 DoDAF Evolution To Support “Fit For Purpose” Architecture CADM SeparateBaseline For DoDAF 1.5Removed Essential & Supporting DesignationsExpanded audience to all of DoD(Published in 2003)DoDAF 1.5Addresses Net-CentricityVolume III is CADM &Architecture Data StrategyAddresses Architecture FederationBaseline for DoDAF 2.0Shifted away from DoDAF mandatinga set of products(Published in 2007)DoDAF 2.0Cover Enterprise andProgram ArchitectureEmphasize Data versusProductsTailored PresentationAV-1 to capture federationmetadataQuality Support to DecisionProcessesFEA & Allied/CoalitionSupportJournal- Errata & Interim ReleasesDoDAF2.0
13 DoDAF V2.0 DoDAF Metamodel (DM2) Fit ForPurposePresentationDashboardsGraphicalDepictionsReferenceModelsFusionProductsCompositeDoDAF V2.0DoDAF V1.5StandardsViewpointOperationalRest of OVsAll TVsAllAll AVsSystemsViewpointAll “Systems”Versions ofSV ProductsData &InformationViewpointOV-7ServicesSV-11All “Service”Versions ofSV ProductsDoDAF Metamodel (DM2)DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions.In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.).Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience.DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues.BUILD ONE:The original views (OV, SV,TV, AV) have had their content reorganized to better address their purposeThe Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementationsAll of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views.BUILD TWO:The new Systems view better accommodates our legacy system descriptions.The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services.The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective.BUILD THREE:The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both.Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View.There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker.CapabilityViewpointProjectNewUpdatedMoved
14 Perspectives: Viewpoints That Fit-the-Purpose RenamedNewNewNewOverarching aspects of architecture context that relate to all modelsAll ViewpointArticulate the data relationships and alignment structures in the architecture contentData and Information ViewpointArticulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecastsStandards ViewpointSystems ViewpointArticulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functionsServices ViewpointArticulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functionsOperational ViewpointArticulate operational scenarios, processes, activities & requirementsCapability ViewpointArticulate the capability requirement, delivery timing, and deployed capabilityDescribes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process.Project ViewpointNewDoDAF organizes the DoDAF-described Models into the following viewpoints:The All Viewpoint describes the overarching aspects of architecture context that relate to all viewpoints.The Capability Viewpoint articulates the capability requirements, the delivery timing, and the deployed capability.The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.The Operational Viewpoint includes the operational scenarios, activities, and requirements that support capabilities.The Project Viewpoint describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. An example is the Vcharts in Chapter 4 of the Defense Acquisition Guide.The Services Viewpoint is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.The Standards Viewpoint articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.Architecture viewpoints are composed of data that has been organized to facilitate understanding.14
15 DoDAF V2.0The logo indicates the change with DoDAF V2.0. With authoritative data, using a vocabulary for architects, a development method, and desired presentations, an architectural description can be ‘Fit-for-Purpose’ for the Decision-makers.15
16 “Fit for Purpose” Architecture Descriptions There are now 52 DoDAF-described Models --- as w/ past versions of DoDAF you only build the ones you need to get the information you need.It's the data behind the models that Decision-Makers really care about.ModelsBased on models and authoritative information (data), the architectural description can support desired presentations for multiple purposes.16
17 DoDAF V2.0 Focus: Terms DoDAF V1.5 DoDAF V2.0 Architecture Alignment with ISO and 15407DoDAF V1.5DoDAF V2.0ArchitectureArchitectural DescriptionArchitecture dataArchitectural dataProductModel (a template for collecting data)View (a model with data for an architecture)ViewViewpointModels are templates for organizing and displaying data in DoDAF 2.0Previous versions of DoDAF referred to these as ‘Products’An example of a Model is an OV-2, OV-5, SV-1, CV-5Views are the result of collecting and populating Models with data and then presenting itViews are a Model populated with specific dataAn example of a view is a MOC OV-2, MDA OV-6c, NAVFAC SV-1Viewpoints are a collection of models/viewsPrevious versions of DoDAF just referred to these as ‘Views’Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability Viewpoint (CV)The collection of information, specifically Views and/or Viewpoints, used to document the architecture is referred to as an Architectural DescriptionPrevious versions of DoDAF referred to these as just an ‘Architecture’A few words about terminology before we go very far. There is a lot of terminology in the presentation, and you will be faced with it each time you discuss an architecture. In addition, there are changes from previous versions of DoDAF that you might be familiar with, and normally use.In our part of the engineering world, everything starts will identifying a need, developing a plan for action, and collecting information about whatever it is that seems to need update or other types of change.Unfortunately, data or information is not easy to read or even pretty to look at. For that reason, people create presentations, such as this, to explain what they mean, seek further information, do analysis, and eventually gain concurrence.To do those things, we in the community look for ways to explain what we mean. Generally, for technical things, we use models—templates that look the way we usually express ourselves. When we ‘fill in’ the data, we have a view of the data. We used to call a view a ‘product’. A collection of these views is called a viewpoint, and becomes the architectural description.The difference is that you don’t have to use the examples contained in DoDAF—they are NOT required. You can create your own if you wish from the data collected. These are called User-created Views or Fit-for-Purpose Views. If you are comfortable with the older DoDAF ‘products’, then you can use the DoDAF-described Views—all of the old products are listed among the DoDAF-described products.DoDAF does describe a number of new views, as you will soon see. There is a lot of new material in DoDAF 2.0
18 Operational Model Example Architectural Description DoDAF V2.0 Focus: Architecture Models + Data = Architectural DescriptionOperational Model ExampleThingsIndividualsTypes or classes of individuals or thingsThe framework enables architecture content to be built that is “Fit for Purpose”, defined and described in Volume 1 as architecture, which is consistent with specific project or mission objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or use of architecture at each level will be different in content, structure, and level of detail. Pulling everything together that we know about an architecture—the viewpoints, requirements, and expected outcomes, we have an architectural description.In order to ensure that architectural descriptions meet program and mission objectives, the approach to architecture development must be tailored to address a specific, well-articulated, and understood purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, is undertaken, completed, and supportive of specific decisions or objectives.Architectural description: A collection of products to document an architecture. An architectural description generally contains one or more viewpoints to express the business, service, system and other elements of the overall project or program.Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.ArchitectureData + MetadataArchitectureModelsArchitectural DescriptionFit-for-Purpose (FFP)Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs.18
19 Methodology: DoDAF V2.0 Six-Step Architecture Development Process Determine theintended use ofthe architecture1Determinescope ofarchitecture2Determine datarequired tosupportdevelopment3Collect, organize,correlate, andstore architecturedata4Conductanalyses insupport ofobjectives5DocumentResults IAWDecision-Makerneeds6Provide list of dataneeded and usecases3.1Model toDM2 ConceptListReview list ofarchitecture dataand determine ifit meets the use3.2DM2 ConceptualData Model &Logical Data ModelAssist with theArchitect’sdata collectionprocesses4.1List ofPotentialCollectionMethodsSelectedVerify the datacollected meetsthe use cases5.1ExampleUsesFit-for-PurposeUseDetermine howdata needs to bepresented6.1LegacyProductsUserRequirementsPresentationsDetailedSteps forDecision-MakerIt is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience.If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts.There are six steps is the DoDAF methodology:1-Determine the intended use of the architecture2- Determine the scope of the architecture3- Determine data required to support architecture development4- Collect, organize, correlate and store data5- Conduct analysis in support of architecture objectives6- Document resultsManagers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed.With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.
20 Data: DoDAF Meta-Model (DM2) Purposes:The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usageSpecification for federated data exchange between:architecture development and analysis toolsarchitecture databasesother authoritative data sourcesSupport discovery and understandability tenants of NCDS:Discovery DM2 categories of informationUnderstandability thru precise semantics augmented with linguistic traceabilityCapture and express Architectural Descriptions in a common, understood language for the exchange of architecture information20
21 Data: Types of Data in DoDAF V2.0 (known as Conceptual Data) ProjectsGoalsRulesMeasuresLocationsActivitiesPerformersResource FlowsInformation and DataTraining, Skill, EducationCapabilitiesServicesThe new DoDAF meta-Model is much simpler and easier to understand than the old CADM Model from previous versions of DoDAF. There are twelve data groups, each of which collects some specific type of architecture data.[Go through groups]Internal [Project, Goals, Training, skill, education]Architectural [Rules, measures, Locations, Activities, Performers, Resource Flows, Capability, Services]Informational [Information and data]Data may be activity data, system or service data, or network data, or any of a number of data categories that contain appropriate data.21
22 The DoDAF Meta-model Improvements High-level conceptual model developed with easily understood terms and descriptionsSemantically correct without broken or obscure associations and relationshipsOnly that data related to architecture development in Departmental core processesExtensible and Scalable to support “Fit-for-Purpose” developmentsSmall and compact versus large, cumbersome, and difficult to read
23 DoDAF V2.0 ConformanceThe data in an architectural description is defined according to the DoDAF Meta-model (DM2) concepts, associations, and attributes.The information captured in an architecture tool is consistent with the DM2 concepts, association, and attributes.Architectural data should be stored in a recognized commercial architecture tool that conforms to industry standards.Tools, preferably data-driven, can be used for the PRESENTATION of architectural data, but it must be based on DATA.The architecture data is capable of transfer in accordance with the UPDM and PES
24 DoDAF Meta-model (DM2) and Unified Profile for DoDAF and MODAF (UPDM) DoDAF Meta-model (DM2)/Physical Exchange Specification (PES) – A data model that defines conceptual, logical, and physical views of the information requirements for DoD architectures.A language for the DoD architectA model for ALL tool vendorsAn exchange schema for interoperabilityUnified Profile for DoDAF and MODAF (UPDM) 1.0 – An Object Management Group specification for UML tool vendors to follow for consistent representations/exchanges of DoDAF V1.5/MODAF V1.2 architectures.A specification from which UML/SYSML tool vendors can implementUPDM 2.0 – A new effort by the Object Management Group to update UPDM for DoDAF V2.0 and MODAF V1.3.
25 DISR and MDRDoD Information Technology Standards and Profile Registry (DISR) – Registry of standards for the Department; UPDM is in DISR because it is a standard developed by a Voluntary Consensus Standards body.DoD Metadata Registry (MDR) – A registry of data models, vocabularies, and schemas to support COI collaboration
26 DoDAF V2.0 SummaryDoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.It is all about the decision-makers and the data!Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs.Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers.DoDAF V2.0 is available at:https://www.us.army.mil/suite/page/454707The DKO-S DoDAF Homepage is
Your consent to our cookies if you continue to use this website.