Presentation on theme: "Continuity Communications Working Group Status Report"— Presentation transcript:
1 Continuity Communications Working Group Status Report Mr. Roy RoebuckChief ArchitectContinuity Communications Enterprise Architecture Program OfficeAugust 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) ReportReview of the FEB’s COOP, COG, and ECG preparednessECG CC Report Tasks include:Complete an evaluation of government-wide COOP communications capabilitiesEstablish Minimum Communications Requirements for the Federal Executive BranchCreate a Continuity Communications Enterprise Architecture (CC EA) to ensure execution of FEB Mission Essential Functions under all circumstancesTasked to the National Communications Systems (NCS) Committee of Principals (COP)Established the Continuity Communications Working Group (CCWG)ASD NII – ChairFEMA – Co-ChairEstablished the CC EA Program OfficeCCWG Terms of Reference (TOR) assigned tasking through August 2005COOP = continuity of operationsCOG = continuity of governmentECG = enduring constitutional governmentCC = continuity communications
3 Key Questions, Initial Round… PMEF 5PMEF 6PMEF 1PMEF 2PMEF 3Basic CommunicationsTelephoneFaxNo VTCNoEtc….Department BBasic CommunicationsTelephoneFaxEtc….Department APMEF 4Key QuestionsCan the D&A Priority Mission Essential Functions (PMEF) be performed at a COOP site?Can information about PMEFs be shared to support a commonoperational picture and collaborative planning by seniorleadership?What are the Minimum COOP Communications Capabilities?What communications support execution of PMEFsDo systems used to execute PMEFs use common standards?D&A = FEB Departments and AgenciesPOINTS WITH THIS CHART –1ST – SHOWS D&A PMEF RELATIONSHIPSD&A PMEF DATA RELATIOJNSHIPS – WIRING DIAGRAMSOME PMEFS ARE EXECUTED INTERNALLY – PMEF 1,2,6,7,8,9SOME PMEFS REQUIRE SUPPORT FROM OTHER D/A’S - PMEF 3, 4, 5WHMO DOCUMENTS IDENTIFY REPORTED COMMS CAPABILITIE\MAY SUPPORT EXECUTION OF MEFSMAY NOTIF NOT – WHAT DOES ? – THE REASON FOR OUR DATA CALL2ND – GREAT MANAGEMENT TOOLFEB WIDE VIEW – MEF’S AND COMMS CAPABILITIESCAN BE BROKEN DOWN BY DEPARTMENT – FOR EXAMPLE WE CAN PROVIDESTATE (EXAMPLE) AND STATE’S REPORTED DEPENDENCIESCAN 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/CAPABILITIESU.S. GovernmentBasic CommunicationsTelephoneFaxSVTS….Etc….Department CPMEF 7PMEF 8
4 Illustration of OMG FEA Reference Models (Taxonomies) For IT Investment Management FEA, to Establish Federal IT Investment GovernanceBasic 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 DecisionsOMB 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.0ENTERPRISECC EACONTAININGCONTAININGCONTAININGCONTAININGCONTAININGCONTAININGCONTAINING.01.02.03.04.05.06.07LOCATIONCATALOGORGANIZATIONCATALOGWORK UNIT(OFFICE/BILLET)CATALOGFUNCTIONCATALOG(BRM+)PROCESSCATALOG(SRM+)RESOURCECATALOG(DRM+/TRM+)MISSIONCATALOG(PRM+)OMB FEAExtension 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 ITD&A SystemsD&A Infrastructure4. DRM(Metadata)2 and 7. PRM(Strategic Mgmt, Ops & Invest. Strategies, Priorities)
7 CC EA Information Structure (Upper/Integrating Ontology) 1.0ENTERPRISECONTAININGCONTAININGCONTAININGCONTAININGCONTAININGCONTAININGCONTAINING.01.02.03.04.05.06.07LOCATIONCATALOGORGANIZATIONCATALOGWORK UNIT(OFFICE/BILLET)CATALOGFUNCTIONCATALOG(BRM+)PROCESSCATALOG(SRM+)RESOURCECATALOG(DRM+/TRM+)MISSIONCATALOG(PRM+)Location Contains OrganizationBillet Accomplishes FunctionProcess Produces/Consumes ResourceOrganization Occupies LocationLinking 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 BilletResource Inputs-To/Results-From ProcessOrganization Organizes BilletsFunction Applies ProcessResource Satisfies RequirementBillets Perform MissionProcess Achieves FunctionRequirements are Satisfied by ResourceThe CC EA approach extends the OMB FEAEnterprise operational management capability
8 CC EA Has An Extended OMB FEA Structure Enterprise ArchitectureService Oriented Architecture (SOA)Enterprise Service Bus (ESB)1. NEF/PMEFService (e.g., Loosely Coupled, NetCentric)Capability Process Improvement and Solution DesignCapability ImplementationOperational Capability (Primary and Alternate Sites, Primary and Alternate Providers)1. BRM(Assigned Functional Missions + Assumed Supporting Functions)1.1 Policy1.2 Assignment1.3. Strategic Management5. TRM(Technology Catalog of Standards and Qualifying Products)6. Required Mission Resources over their life cycle.6.1 People6.2 IntelligenceFunctional IntelligenceCC Intelligence6.3 Funds6.4 SkillsCC Skills6.5 Materiel6.5.1 Physical ITSystemsCC SystemsInfrastructureCC Infrastructure6.5.2 Goods6.6 FacilitiesCC Facilities6.7 ServicesCC Services6.8 etc.3. SRM(Best Practice, Re-usable Processes)4. DRM(Metadata and Data)1. OU Assigned Functional Responsibility2. PRM(Strategic Mgmt, Ops & Invest. Strategies, Priorities)7. PRM (Portfolios, Budgets)Normal and CC Capability Business Case and BudgetServices, capabilities, SOA, ESB, etc. defined in terms of Reference Catalog content (categories/instances) and linkages (generalized, specific).1. Parent Organization of OUSchema and Data Largely or Wholly Present in FEA6. Organization Unit (OU) Assigned The AssetSchema and/or Data Added by CC EA1. 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 ModelThis 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 AssessmentStage 5 of EA Process - Example Deliverables (All Reference Catalogs and their associations, as enterprise knowledge-base)-- Enterprise Integrated Operations ManagementStage 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 ManagementLeverageBRMLeveragePRMLeverageSRMLeverageDRM/TRM
11 Contact Roy Roebuck email@example.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 IntelligenceRefinement4. NEF/PMEF OperationManagementEnterprise Operations and CCCC EASpiralLife CycleEnterprise Intelligence3. CC EAFor ResourceDistribution and AccessProvisioning1. D&A PMEF IntelligenceInventory (CC Portion of D&A EA Framework/Ontology and PMEF EA Content)2. CC EA for Merged FEB NEF/PMEF IntelligenceStructure 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 ModelContinuity Communication Enterprise Architecture (CC EA), Providing GSA-Recommended EA Framework, Methodology, and Tools/RepositoryLayer ContentsOMG MDA LayerLayer 1. Enterprise Architecture (EA) content, as KB or Filled Application/TemplateCC EA Data and ReportsM0Layer 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 EAM1Layer 3. Enterprise Model (i.e., Reference Models or Reference Catalogs, Enterprise Methodology, Foundation EA data-structure/Metaschema)Normalized/generalized enterprise management Methodology and MetaschemaM2Layer 4. Architecture Engine (i.e., Object Model and Object Database in SQL, XML, ISAM, etc.)Architecture/Object DB Application running onData Store (e.g., ODBC, SQL, XML (RTF or OWL)M3MDA is a method for documenting architectures.
14 CC EA Use of MDA Layers M1 Designs for Intended Information Products M0 InformationRequirementsM1 Designs for Intended Information ProductsM0 GeneratedInformationProductsM0 DecisionSupportM0 DecisionM1 Design for Required Data Structure (i.e., EA Metaschema) to Hold Information Product’s Data ContentEnterpriseManagementArchitectureFrameworkArchitectureTechnologyM2 Model (i.e., EA metaschema)M3 Modeling Tools and RepositoryEnterpriseArchitectureMethodology
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)M3MOFArchitecture 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)MOFExtension/Profile(Tool Standard)M2GEM MetaschemaUML (SPEM)UML (XMI)CWM MetaschemaCIM MetaschemaEnterprise Model(GEM DesignMetamodel)SW ProcessMetamodelSW DesignMetamodelData DesignMetamodelCIM DesignMetamodelMOF-basedApplication Design(Specific Tool)M1GEM SchemaRUPRUPCWM SchemaCIM SchemaEA Framework(GEM DesignModel)SW ProcessModelSW DesignModelData DesignModelCIM DesignModelThe 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-basedApplication Instance(Tool Artifacts)M0ImplementedProjectImplementedProjectImplementedProjectData ManagementRepositoryIT ManagementRepositoryEA Instance(GEM EAInstance InEnterpriseOr AggregatedGEM Capability)SW ProcessPerformanceOr AggregatedSW DesignFor System orAggregatedDesignData ModelOr AggregatedData ModelsCIM InstanceOn Device, orAggregatedIT 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/M2Schema Tools(IntegratedEnterprise,Function,Process, Data,System,Software,Security, &Semantics,KnowledgeModeling AndManagementvia OWL)M2 Open StandardSoftware Process Engineering Metaschema (SPEM/XMI) Standards and ToolsM2 Enterprise Architecture Business, Data, Application, & Technical Schema(BEAM, FEA, DoDAF, TOGAF, etc.)Ontology EA Tools/Repositories (M3/M2/M1/M0)Agilense WebModelerAdaptiveCASE EA Tools (M1/M0)Popkin SAPTechComputas MetisOtherM3/M2/M1 IT Management ToolsITIL/ITSM/CMDB/CIM Schema (IT Models)(MOF)Troux (HW/SW/Net/EA)Isogon (SW)Tivoli TM1MS SMSBMC PatrolHP OpenViewOther WBEM ToolsStandards Subsumed by CIM/MOFSNMP IP Tools (MIB)Desktop Mgmt Tools (MIF)HelpDesk Tools (SES/SIS)OthersM2 CWM/XMI Schema (Data and Metadata Models)Data ModelingMetadata ManagementBI ToolsOLAP ToolsData Warehouse Tools3HT eSnapSchema LogicMetaMatrixORM Tools (for Semantic and Data Modeling)MS Visio for EAMS VisioModelerM2 Open Standard Application Integration (EAI), Business Process Management (BPM) (WSDL, OWL-S), and Workflow (WfMC, UAN) Standards and ToolsM2 XMI Schema (Application Models)UML Tool ExamplesRationalPoseidonORM M2 Tools (Semantic/Data Models)MS Visio for EAMS VisioModelerBEAM 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 ToolsOMG 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 ProcessActivitiesRolesConfiguration Change ManagementTechnology InsertionProduct/Service Test and EvaluationGovernance of ImplementationGovernance of ChangeEnterprise EngineeringBusiness Architect(e.g., Enterprise Architect and Management Analyst)Enterprise ManagementEnterprise ArchitectureStrategic ManagementIT PortfolioInfrastructure EngineeringNetwork Architect/EngineerSystem EngineeringSystem Architect/EngineerSoftware EngineeringSoftware Architect/EngineerData Engineering / ManagementData Architect/Engineer
18 CC EA Framework (i.e., ConOps or Ontology) Mapped to OMB FEA Reference Models and DoDAF Views CC EA Methodology StepsEnterprise: AV1, OV4Identify Enterprise: 0Location: AV1, OV4Identify Relevant Locations:1Organization: AV1, OV2, OV4, SV1, SV2, SV3Identify Relevant Organizations: 2Organization Unit: AV1, OV4, SV1, SV2, SV3Identify Relevant Organization Units: 3Function:AV1, OV4, OV1, OV5, OV6b, SV1, SV2, SV3, SV5, SV6, SV7, SV8, SV9, SV10a, SV11Identify Relevant Function: 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 30, 31Process: AV2, OV3, OV4, OV5, OV6a, OV6c, OV6b, OV6c, OV7, SV4, SV5, SV10b, SV10cIdentify Relevant Processes: 15, 16, 17, 18, 19, 20, 21Resource: SV1, SV2, SV3, SV5, TV1, TV2Identify Relevant Resources: 22, 23, 24, 24.1, 24.2, 24.3, 24.4, 24.5, 24.6, 24.7, 24.8, 24.9, 24.10Requirement:SV3, SV5, SV8, SV9, SV10aIdentify 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, 29CC EA FrameworkStage 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 AssessmentStage 5 Example Deliverables (Used in EMM 4, and 5)-- Enterprise Integrated Operations ManagementStage 6 Example Deliverables (Used in EMM 5)-- Enterprise Dynamic Intelligence and Operations Management