Presentation is loading. Please wait.

Presentation is loading. Please wait.

Continuity Communications Working Group Status Report

Similar presentations


Presentation on theme: "Continuity Communications Working Group Status Report"— Presentation transcript:

1 Continuity Communications Working Group Status Report
Mr. Roy Roebuck Chief Architect Continuity Communications Enterprise Architecture Program Office August 5, 2005

2 Background… September 11th
Illustrated that the Federal Executive Branch (FEB) does not have the ability to quickly access and share information, collaborate among senior leaders, and make informed decisions. Enduring Constitutional Government Coordination Council (ECG CC) Report Review of the FEB’s COOP, COG, and ECG preparedness ECG CC Report Tasks include: Complete an evaluation of government-wide COOP communications capabilities Establish Minimum Communications Requirements for the Federal Executive Branch Create a Continuity Communications Enterprise Architecture (CC EA) to ensure execution of FEB Mission Essential Functions under all circumstances Tasked to the National Communications Systems (NCS) Committee of Principals (COP) Established the Continuity Communications Working Group (CCWG) ASD NII – Chair FEMA – Co-Chair Established the CC EA Program Office CCWG Terms of Reference (TOR) assigned tasking through August 2005 COOP = continuity of operations COG = continuity of government ECG = enduring constitutional government CC = continuity communications

3 Key Questions, Initial Round…
PMEF 5 PMEF 6 PMEF 1 PMEF 2 PMEF 3 Basic Communications Telephone Fax No VTC No Etc…. Department B Basic Communications Telephone Fax Etc…. Department A PMEF 4 Key Questions Can the D&A Priority Mission Essential Functions (PMEF) be performed at a COOP site? Can information about PMEFs be shared to support a common operational picture and collaborative planning by senior leadership? What are the Minimum COOP Communications Capabilities? What communications support execution of PMEFs Do systems used to execute PMEFs use common standards? D&A = FEB Departments and Agencies POINTS WITH THIS CHART – 1ST – SHOWS D&A PMEF RELATIONSHIPS D&A PMEF DATA RELATIOJNSHIPS – WIRING DIAGRAM SOME PMEFS ARE EXECUTED INTERNALLY – PMEF 1,2,6,7,8,9 SOME PMEFS REQUIRE SUPPORT FROM OTHER D/A’S - PMEF 3, 4, 5 WHMO DOCUMENTS IDENTIFY REPORTED COMMS CAPABILITIE\ MAY SUPPORT EXECUTION OF MEFS MAY NOT IF NOT – WHAT DOES ? – THE REASON FOR OUR DATA CALL 2ND – GREAT MANAGEMENT TOOL FEB WIDE VIEW – MEF’S AND COMMS CAPABILITIES CAN BE BROKEN DOWN BY DEPARTMENT – FOR EXAMPLE WE CAN PROVIDE STATE (EXAMPLE) AND STATE’S REPORTED DEPENDENCIES CAN TRACK MEFS (SHOW THOSE WITH INTERDEPENDENCIES) CAN SELECT MEFS (e.g., WHITE HOUSE IS VERY CONCERNED ABOUT MEFs X, Y, AND Z) CAN TRACK OUR PROGRESS ON IDENTIFYING MEF COMMS NEEDS/CAPABILITIES U.S. Government Basic Communications Telephone Fax SVTS…. Etc…. Department C PMEF 7 PMEF 8

4 Illustration of OMG FEA Reference Models (Taxonomies) For IT Investment Management
FEA, to Establish Federal IT Investment Governance Basic FEA metaschema with minimal D&A extension.

5 Typical D&A FEA Extension, For IT Investment Management
EA to Satisfy OMB Exhibit 300 and 53 Requirements and Facilitate IT Decisions OMB FEA with reasonable amount of D&A IT management activities needed to respond to FEA.

6 CC EA Requires Extension Of The OMB FEA Beyond Investment Management
1.0 ENTERPRISE CC EA CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING .01 .02 .03 .04 .05 .06 .07 LOCATION CATALOG ORGANIZATION CATALOG WORK UNIT (OFFICE/BILLET) CATALOG FUNCTION CATALOG (BRM+) PROCESS CATALOG (SRM+) RESOURCE CATALOG (DRM+/TRM+) MISSION CATALOG (PRM+) OMB FEA Extension of the OMB FEA reference models into FEB Enterprise Management Reference Catalogs (i.e., taxonomies) 5. TRM (Technology Catalog and Qualifying Products) 1. BRM (Assigned Functional Missions + Assumed Supporting Functions) 3. SRM (Best Practice, Re-usable Processes) 6.5.1 D&A Physical IT D&A Systems D&A Infrastructure 4. DRM (Metadata) 2 and 7. PRM (Strategic Mgmt, Ops & Invest. Strategies, Priorities)

7 CC EA Information Structure (Upper/Integrating Ontology)
1.0 ENTERPRISE CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING CONTAINING .01 .02 .03 .04 .05 .06 .07 LOCATION CATALOG ORGANIZATION CATALOG WORK UNIT (OFFICE/BILLET) CATALOG FUNCTION CATALOG (BRM+) PROCESS CATALOG (SRM+) RESOURCE CATALOG (DRM+/TRM+) MISSION CATALOG (PRM+) Location Contains Organization Billet Accomplishes Function Process Produces/Consumes Resource Organization Occupies Location Linking across the Reference Catalogs yields enterprise knowledge. Generalized links across catalog categories yields the ontology of a given semantic context, specific links across catalog category instances yields the knowledge-base of a given semantic/situational context. The aggregate of generalized and specified ontologies yields enterprise knowledge. This approach extends the OMB FEA and DODAF into an operational management capability. Must provide the discussion points of the CC EA 32 step process and alignment to each pearl HERE… from policy to data… etc etc.. This “View” will provide for the development of the knowledge base to not only provide for the assessment and implementation of IT Portfolio Management (Supported by the GEMINII Assessment) but provide for the view from the organization or command to include alignment to the desired Vision, Operational Objective, Organization Structure and Policies. …. Mission, Strategic Goals, Supporting Organizational Structure. Function Justifies Billet Resource Inputs-To/Results-From Process Organization Organizes Billets Function Applies Process Resource Satisfies Requirement Billets Perform Mission Process Achieves Function Requirements are Satisfied by Resource The CC EA approach extends the OMB FEA Enterprise operational management capability

8 CC EA Has An Extended OMB FEA Structure
Enterprise Architecture Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) 1. NEF/PMEF Service (e.g., Loosely Coupled, NetCentric) Capability Process Improvement and Solution Design Capability Implementation Operational Capability (Primary and Alternate Sites, Primary and Alternate Providers) 1. BRM (Assigned Functional Missions + Assumed Supporting Functions) 1.1 Policy 1.2 Assignment 1.3. Strategic Management 5. TRM (Technology Catalog of Standards and Qualifying Products) 6. Required Mission Resources over their life cycle. 6.1 People 6.2 Intelligence Functional Intelligence CC Intelligence 6.3 Funds 6.4 Skills CC Skills 6.5 Materiel 6.5.1 Physical IT Systems CC Systems Infrastructure CC Infrastructure 6.5.2 Goods 6.6 Facilities CC Facilities 6.7 Services CC Services 6.8 etc. 3. SRM (Best Practice, Re-usable Processes) 4. DRM (Metadata and Data) 1. OU Assigned Functional Responsibility 2. PRM (Strategic Mgmt, Ops & Invest. Strategies, Priorities) 7. PRM (Portfolios, Budgets) Normal and CC Capability Business Case and Budget Services, capabilities, SOA, ESB, etc. defined in terms of Reference Catalog content (categories/instances) and linkages (generalized, specific). 1. Parent Organization of OU Schema and Data Largely or Wholly Present in FEA 6. Organization Unit (OU) Assigned The Asset Schema and/or Data Added by CC EA 1. Location of OU (Physical and Virtual)

9 CCEA FEA Extension For Operations Management And Architecture Integration (FYO5 Plan)
EA as Whole-Enterprise System Analysis, Requirement Analysis, and Operational Model This diagram illustrates those things within enterprise-management-focused EA and IT environments that require configuration and change management. By governing the items going from left to right and top to bottom, the enterprise is able to dramatically reduce uncontrolled “requirements churn” at the IT implementation and operation levels. Balanced Scorecard efforts such as the President’s Management Agenda can be managed using the two Function and Mission taxonomies represented as diagonal structures on the left side, plus the minimized taxonomies for Location, Organization, and Organization Units. They deal with what, who, where, and why. The how aspect of strategic management is in the four rightmost taxonomies of process, resource (data), resource (technology), and implementations.

10 CC EA Framework Model Leverage BRM Leverage PRM Leverage SRM Leverage
Stage 1 of EA Process - Example Deliverables (Reference Catalogs 1 through 4 and their “primitive” associations) -- Enterprise Model (ISO 14258) -- Mission Management/Balanced Scorecard -- Enterprise Architecture (EA) Business Reference Model (BRM) -- Security Architecture (Functional Role-Based Access Control (RBAC) as foundation for Authentication and Authorization, i.e., for Single Sign-On (SSO) to Resources -- Government Performance and Results Act (GPRA) Support -- Organization, Missions, Functions, and Policy Directory -- Function Distribution/Location (Job/Office/Manager/Location) Stage 2 of EA Process - Example Deliverables (Reference Catalogs 1-5 and their associations) -- Reference Architecture (ISO 15704) of Policies, Processes, Procedures, Templates, Web Services, Standards, Tools, Data, Metadata, Schema, Metaschema, Models, and Metamodels for EA, CMM, CMMI, ISO 9000, IDEF, UML, XMI, CWM, ORM, OWL, MPEG/RL, etc.) -- Security Architecture (Refined Process RBAC, Data Classification, Access Rules and Methods, Digital and Physical Rights Management) -- EA Data/Information Reference Model (DRM) and Application/Service-Component Reference Model (SRM) -- Stakeholder Responsibility and Authority (Coordination/Collaboration Links) -- Activity Distribution/Location (Function/Billet/Office/Manager/Location) Stage 3 of EA Process - Example Deliverables (Reference Catalogs 1 through parts of 6 and their associations) -- EA SRM Refinement -- EA Technical Reference Model (TRM) -- Integrated MIS, Workflow, Business Rule, Data, Value-Chain, EDI, and Web Services Model -- Supplier/Customer Value Chain from Raw Material to Final Disposal (Product Flow, To Customers and From Suppliers) -- Security Architecture (Access Mechanisms and Provisioning, including Single Sign-On (SSO), based on User Identity and Role (RBAC) -- Duty Assignment and Training Requirements (Position/Person Knowledge, Skills, and Abilities Correlation) Stage 4 of EA Process - Example Deliverables (Reference Catalogs 1 through parts of 7 and their associations) -- Enterprise Program and Project Resource Requirements Life Cycle Management (Plan, Program, Budget, Execute, Assess, Review) -- Financial Analysis (Investment Portfolio Management (Clinger-Cohen Act (CCA) Compliance, Activity Based Costing, Functional Economic Analysis, Business Case, ROI) -- EA Performance Reference Model (PRM) -- Security Architecture (Resource Accountability) -- Transactional Context for Billing (Fee for Service) -- Performance Results, Review, and Assessment Stage 5 of EA Process - Example Deliverables (All Reference Catalogs and their associations, as enterprise knowledge-base) -- Enterprise Integrated Operations Management Stage 6 of EA Process - Example Deliverables (All Reference Catalogs and their associations, as enterprise operational-intelligence source supported by software agents providing dynamic situational awareness for all enterprise personnel and groups.) -- Enterprise Dynamic Intelligence and Operations Management Leverage BRM Leverage PRM Leverage SRM Leverage DRM/TRM

11 Contact Roy Roebuck roy.roebuck@commitent.com 703-598-2351
Questions? Contact Roy Roebuck

12 CC EA Supports NEF and PMEF Life Cycle Management, Including CC
5. D&A PMEF and CC Intelligence Refinement 4. NEF/PMEF Operation Management Enterprise Operations and CC CC EA Spiral Life Cycle Enterprise Intelligence 3. CC EA For Resource Distribution and Access Provisioning 1. D&A PMEF Intelligence Inventory (CC Portion of D&A EA Framework/Ontology and PMEF EA Content) 2. CC EA for Merged FEB NEF/PMEF Intelligence Structure and Operational Knowledge (Mapping of D&A EA Frameworks and EA Content to CC EA Integrating Framework, i.e., Upper Ontology)

13 CC EA Four Layer Model Continuity Communication Enterprise Architecture (CC EA), Providing GSA-Recommended EA Framework, Methodology, and Tools/Repository Layer Contents OMG MDA Layer Layer 1. Enterprise Architecture (EA) content, as KB or Filled Application/Template CC EA Data and Reports M0 Layer 2. EA Framework (Product Designs, Tools/Repository tailored Metaschema extension, as Ontology or Application/Template) CC EA application forms and additional data structure (or OMB FEA, D&A EA, C2, HR, SOA, other functional applications) as tailored variant of CC EA M1 Layer 3. Enterprise Model (i.e., Reference Models or Reference Catalogs, Enterprise Methodology, Foundation EA data-structure/Metaschema) Normalized/generalized enterprise management Methodology and Metaschema M2 Layer 4. Architecture Engine (i.e., Object Model and Object Database in SQL, XML, ISAM, etc.) Architecture/Object DB Application running on Data Store (e.g., ODBC, SQL, XML (RTF or OWL) M3 MDA is a method for documenting architectures.

14 CC EA Use of MDA Layers M1 Designs for Intended Information Products
M0 Information Requirements M1 Designs for Intended Information Products M0 Generated Information Products M0 Decision Support M0 Decision M1 Design for Required Data Structure (i.e., EA Metaschema) to Hold Information Product’s Data Content Enterprise Management Architecture Framework Architecture Technology M2 Model (i.e., EA metaschema) M3 Modeling Tools and Repository Enterprise Architecture Methodology

15 CC EA 4 Layer Metamodel for Model Driven Enterprise Management (e. g
CC EA 4 Layer Metamodel for Model Driven Enterprise Management (e.g., C2 Ontology Integration ) (Extending the OMG 4 Layer Metamodel’s MDA, SPEM, XMI, CIM, CWM Standards) MetaObject Facility (metadata repository) M3 MOF Architecture Model (Generalized Object (Metadata) Repository for Model Driven Architecture - MDA). Extended for GEM Context Schema (as Object Metaschema for Generalized Object Relationships – Category, Container, Sequence, Change, Equivalence, Variance, Reference) MOF Extension/Profile (Tool Standard) M2 GEM Metaschema UML (SPEM) UML (XMI) CWM Metaschema CIM Metaschema Enterprise Model (GEM Design Metamodel) SW Process Metamodel SW Design Metamodel Data Design Metamodel CIM Design Metamodel MOF-based Application Design (Specific Tool) M1 GEM Schema RUP RUP CWM Schema CIM Schema EA Framework (GEM Design Model) SW Process Model SW Design Model Data Design Model CIM Design Model The classical framework for metamodeling is based on an architecture with four meta-layers. These layers are conventionally described as follows: The information layer is comprised of the data that we wish to describe. The model layer is comprised of the metadata that describes data in the information layer. Metadata is informally aggregated as models. The metamodel layer is comprised of the descriptions (i.e., meta-metadata) that define the structure and semantics of metadata. Meta-metadata is informally aggregated as metamodels. A metamodel is an “abstract language” for describing different kinds of data; that is, a language without a concrete syntax or notation. The meta-metamodel layer is comprised of the description of the structure and semantics of meta-metadata. In other words, it is the “abstract language” for defining different kinds of metadata. This diagram provides a means of comparing the underlying structure of GEM to other “object” management standards. This diagram illustrates the Object Management Group (OMG) organization’s MOF (Meta Object Facility) repository, and its derived XMI (UML application model interchange) , CWM (data modeling), CIM (IT Management), and SPEM (software engineering process) standard metamodels (i.e., modeling-tool specifications) in relation to GEM. A MOF Repository is designed to support development and management environments (tools) such as these. A single MOF repository supports the multiple repositories of these environments, federated repositories, and versions of repositories, in a single storage mechanism. Technically, the MOF standard defines a MetaMetaModel (that is, it contains MetaMetaMetaData) that is stored in what is known as an M3 (count the number of "m"s) repository. This means that MOF is totally extensible. You can load any M2 metamodel into a MOF Repository, such as those above and also metamodels for UML, CORBA IDL, Java, Rational Rose. OWL, etc. UML designs from various object-oriented analysis and design tools can be imported into a MOF repository using the XMI metamodel format, which are then used to generate the resultant M2 repositories within the MOF M3. Finally, project specific M1 repositories (e.g., to support GEM-based enterprise architecture or situational awareness management projects) can be generated to hold project-specific data in M0 repositories for a specific set of data. M0 is data, M1 structures the data, M2 controls the M1 structure, and M3 governs the M2 controls. There is even an M4, called the Object Metaschema, established by OMG and The OpenGroup, which provides the structure/controls/governance for the M3 MOF. GEM actually starts from an extended form of this M4 Object Metaschema, which is now being approached by new standards such as the W3C Web Ontology Language (OWL). The importance of MOF is not just that you can bring all sorts of metadata together into a single place. You could, for example, define a metamodel that included all your corporate standards for software coding and development, or for management assertions such as concepts, semantics, and knowledge (i.e., ontologies), or for relationships between business objects such as organization, location, function, process, resource, etc. Constraint checks (i.e., data validation at the various M levels) would allow you to ensure that the contents of any M1 repositories created as instances of an M2 metamodel will automatically be checked for compliance to the defined M2 standard, etc. up to the M3 and M4 levels. This technology is seems highly abstract or “academic” to most people (e.g., puzzles within puzzles), although there are considerable savings to be made by having a coherent repository-based strategy to put all business, process, development, and operation information in a single place. Before GEM, the typical organization using MOF was a medium to large company seeking integrated management of IT and/or system/software engineering, and so most users will not need to know most of the underlying details. With GEM, the intent is for everyone to have some familiarity of these object layers, so that everyone can interact directly with the appropriate level of GEM, at the appropriate time. For most people, a graphical front-end tool that hides most of the underlying complexity is essential. The data for the collections of assertions held in these layered repositories is best represented in the form of basic Directed Labeled Graphs (DLG), showing two or more labeled components connected by one or more labeled arrows. MOF-based Application Instance (Tool Artifacts) M0 Implemented Project Implemented Project Implemented Project Data Management Repository IT Management Repository EA Instance (GEM EA Instance In Enterprise Or Aggregated GEM Capability) SW Process Performance Or Aggregated SW Design For System or Aggregated Design Data Model Or Aggregated Data Models CIM Instance On Device, or Aggregated IT Management

16 Standards and Products Supporting EA and EM via MDA
General Enterprise Management (GEM) Model Driven Enterprise Management - MDEM (EM Support) Via Model Driven Architecture (MDA)-M3/M2/M1/M0) GEM M3/M2 Schema Tools (Integrated Enterprise, Function, Process, Data, System, Software, Security, & Semantics, Knowledge Modeling And Management via OWL) M2 Open Standard Software Process Engineering Metaschema (SPEM/XMI) Standards and Tools M2 Enterprise Architecture Business, Data, Application, & Technical Schema (BEAM, FEA, DoDAF, TOGAF, etc.) Ontology EA Tools/Repositories (M3/M2/M1/M0) Agilense WebModeler Adaptive CASE EA Tools (M1/M0) Popkin SA PTech Computas Metis Other M3/M2/M1 IT Management Tools ITIL/ITSM/CMDB/CIM Schema (IT Models) (MOF) Troux (HW/SW/Net/EA) Isogon (SW) Tivoli TM1 MS SMS BMC Patrol HP OpenView Other WBEM Tools Standards Subsumed by CIM/MOF SNMP IP Tools (MIB) Desktop Mgmt Tools (MIF) HelpDesk Tools (SES/SIS) Others M2 CWM/XMI Schema (Data and Metadata Models) Data Modeling Metadata Management BI Tools OLAP Tools Data Warehouse Tools 3HT eSnap Schema Logic MetaMatrix ORM Tools (for Semantic and Data Modeling) MS Visio for EA MS VisioModeler M2 Open Standard Application Integration (EAI), Business Process Management (BPM) (WSDL, OWL-S), and Workflow (WfMC, UAN) Standards and Tools M2 XMI Schema (Application Models) UML Tool Examples Rational Poseidon ORM M2 Tools (Semantic/Data Models) MS Visio for EA MS VisioModeler BEAM and GEM Repository elements, showing enterprise management, enterprise architecture and IT operation management components. Standard are underlined. GEM-based M3/M2/M1 Identity, Operation, Asset, Vulnerability, and Security Management Tools OMG Managed Object Format (MOF) M3 Repository (XML + LDAP + XMI + Object Schema) OpenGroup and OMG Object Metaschema (M3) Used with Permission by CommIT Enterprise, Inc. and the U.S. Federal Executive Branch under the Creative Commons License at

17 CC EA Foundation Is Enterprise Engineering
Management Process Activities Roles Configuration Change Management Technology Insertion Product/Service Test and Evaluation Governance of Implementation Governance of Change Enterprise Engineering Business Architect (e.g., Enterprise Architect and Management Analyst) Enterprise Management Enterprise Architecture Strategic Management IT Portfolio Infrastructure Engineering Network Architect/Engineer System Engineering System Architect/Engineer Software Engineering Software Architect/Engineer Data Engineering / Management Data Architect/Engineer

18 CC EA Framework (i.e., ConOps or Ontology) Mapped to OMB FEA Reference Models and DoDAF Views
CC EA Methodology Steps Enterprise: AV1, OV4 Identify Enterprise: 0 Location: AV1, OV4 Identify Relevant Locations:1 Organization: AV1, OV2, OV4, SV1, SV2, SV3 Identify Relevant Organizations: 2 Organization Unit: AV1, OV4, SV1, SV2, SV3 Identify Relevant Organization Units: 3 Function:AV1, OV4, OV1, OV5, OV6b, SV1, SV2, SV3, SV5, SV6, SV7, SV8, SV9, SV10a, SV11 Identify Relevant Function: 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 30, 31 Process: AV2, OV3, OV4, OV5, OV6a, OV6c, OV6b, OV6c, OV7, SV4, SV5, SV10b, SV10c Identify Relevant Processes: 15, 16, 17, 18, 19, 20, 21 Resource: SV1, SV2, SV3, SV5, TV1, TV2 Identify Relevant Resources: 22, 23, 24, 24.1, 24.2, 24.3, 24.4, 24.5, 24.6, 24.7, 24.8, 24.9, 24.10 Requirement:SV3, SV5, SV8, SV9, SV10a Identify Relevant Requirements by Life Cycle Stage: 25, 26, 27, 27.1, 27.2, 27.3, 27.4, 27.5, 27.6, 27.7, 27.8, 27.8, 27.9, 27.10, 27.11, 27.12, 28, 29 CC EA Framework Stage 1 Example Deliverables (Used in EMM 1, 2, 3, 4, and 5) -- Enterprise Model (ISO 14258) -- Mission Management/Balanced Scorecard -- Enterprise Architecture (EA) Business Reference Model (BRM) -- Security Architecture (Functional Role-Based Access Control (RBAC) as foundation for Authentication and Authorization, i.e., for Single Sign-On (SSO) to Resources -- Government Performance and Results Act (GPRA) Support -- Organization, Missions, Functions, and Policy Directory -- Function Distribution/Location (Job/Office/Manager/Location) Stage 2. Example Deliverables (Used in EMM 1,2,3,4, and 5) -- Reference Architecture (ISO 15704) of Policies, Processes, Procedures, Templates, Web Services, Standards, Tools, Data, Metadata, Schema, Metaschema, Models, and Metamodels for EA, CMM, CMMI, ISO 9000, IDEF, UML, XMI, CWM, ORM, OWL, MPEG/RL, etc.) -- Security Architecture (Refined Process RBAC, Data Classification, Access Rules and Methods, Digital and Physical Rights Management) -- EA Data/Information Reference Model (DRM) and Application/Service-Component Reference Model (SRM) -- Stakeholder Responsibility and Authority (Coordination/Collaboration Links) -- Activity Distribution/Location (Function/Billet/Office/Manager/Location) Stage 3 Example Deliverables (Used in EMM 1,2, 3, 4, and 5) -- EA SRM Refinement -- EA Technical Reference Model (TRM) -- Integrated MIS, Workflow, Business Rule, Data, Value-Chain, EDI, and Web Services Model -- Supplier/Customer Value Chain from Raw Material to Final Disposal (Product Flow, To Customers and From Suppliers) -- Security Architecture (Access Mechanisms and Provisioning, including Single Sign-On (SSO), based on User Identity and Role (RBAC) -- Duty Assignment and Training Requirements (Position/Person Knowledge, Skills, and Abilities Correlation) Stage 4 Example Deliverables (Used in EMM 3, 4, and 5) -- Enterprise Program and Project Resource Requirements Life Cycle Management (Plan, Program, Budget, Execute, Assess, Review) -- Financial Analysis (Investment Portfolio Management (Clinger-Cohen Act (CCA) Compliance, Activity Based Costing, Functional Economic Analysis, Business Case, ROI) -- EA Performance Reference Model (PRM) -- Security Architecture (Resource Accountability) -- Transactional Context for Billing (Fee for Service) -- Performance Results, Review, and Assessment Stage 5 Example Deliverables (Used in EMM 4, and 5) -- Enterprise Integrated Operations Management Stage 6 Example Deliverables (Used in EMM 5) -- Enterprise Dynamic Intelligence and Operations Management


Download ppt "Continuity Communications Working Group Status Report"

Similar presentations


Ads by Google