Garrison GeoBase Enterprise Architecture Workshop

Transcription

1 Headquarters U.S. Air Force Garrison GeoBase Enterprise Architecture Workshop 2004 Compass Conference San Antonio, TX 15 August 2004 Laura Silsbee, Garrison GeoBase Architect (with thanks to Stacey Tyley, CE Chief Architect) AF/ILEI

2 Agenda 1:30 2:15 pm - Enterprise Architecture Overview Enterprise Architecture 101 Portfolio Management and Enterprise Architecture 2:15 3:00 pm - DoDAF Architecture Products Operational, System, and Technical Standards Views Introduction to required and supplementary products 3:00 3:30 pm Break 3:30 4:30 pm Specifics on Requested Products 4:30 5:00 pm Next steps: Garrison GeoBase Enterprise Architecture (Version 1.1)

3 What is Enterprise Architecture? Enterprise Architecture (EA) is: A strategic plan for business vision and activities. A method for linking information technology to business processes. A blueprint that explains how all the IT management and infrastructure elements work together as a whole. A tool for enabling intelligent decisions on how an organization spends money. A legislated requirement for federal departments and agencies

4 Why Enterprise Architecture? Purpose: Align IT investments with business needs AF/CE Business Priorities, Goals, and Outcomes Strategic Plan Business Functions Data Requirements AF/CE IT Investments Major Development System Modernization Infrastructure Upgrades EA bridges business and IT providing basis for executive decision making and capital planning and investment control guidance.

5 Enterprise Architecture Goal CLEARLY link an organization s mission, strategic plan, and business processes to Enterprise Architecture to Capital IT Investment Planning and Decision Making - Portfolio Management Strategic Plan MISSION Road Map Business Processes Enterprise Architecture Justifiable IT Funding Decisions

6 How Did We Get to This Point? OMB CIRCULAR A-130 The policies in this Circular apply to the information activities of all agencies of the executive branch of the Federal government. PL The transition plan developed under subsection (a) shall contain specific time-phased milestones for modifying or eliminating existing systems and for acquiring new systems necessary to implement the proposed enterprise architecture. FY ? CLINGER-COHEN ACT of 1996 Agencies must document and submit their initial EA to OMB. Agencies must submit updates when significant changes to the Enterprise Architecture occur. BUSINESS MANAGEMENT MODERNIZATION PROGRAM (BMMP): Required by OMB, DoD, and AF; identifies requirements justification; makes USD(C) accountable for releasing IT funds AF/IL PfM, EA, and GCSS Compliance SAF Policy on EA 6 Aug 02 EAIC Charter 20 Dec 02 SECAF &CSAF AFOSMP 20 Jan 04 Commander s IPT 3 Mar 04 TODAY!

7 A Common Sense Approach Perspective Illustrates functional and integrated needs holistically Communication Provides clear documentation of your enterprise so that it can be understood by all concerned Analysis of Problem Areas Helps uncover and flag problems before it s too late Budget Helps organizations make reasonable investment decisions Efficiency Helps ensure business processes are working optimally Use of Technology Helps ensure that IT solutions are the right ones Training Helps new personnel understand the enterprise and the tools available to them

8 Collaboration is a Prerequisite Federal EA DoD EA USA EA USN EA USAF EA Warfighter Mission Area Financial Mgmt Domain Health Services Domain Acquisition Domain SVS LOG (Lead) CE Personnel Domain COMM IL Domain Operational Support Mission Area Infrastructure Environment

9 Additional Collaboration OSD Enterprise Architecture MISSION AREAS WARFIGHTER (Lead: CJCS) BUSINESS MANAGEMENT (Lead: USD(C)) ENTERPRISE INFORMATION ENVIRONMENT (Lead: ASD(NII)/DoD CIO) NATIONAL FOREIGN INTELLIGENCE (Lead: USD(I)) DOMAINS TBD Acquisition (Lead: USD(AT&L)) TBD TBD Installations & Environment (Lead: USD(AT&L)) Logistics (Lead: USD(AT&L)) Strategic Planning/Budgeting (Lead: USD(C)) Civil Engineering Accounting & Finance (Lead: USD(C)) Human Resources Mgmt (Lead: USD(P&R)) Logistics Business Enterprise Architecture (BEA) AF Enterprise Architecture ARCHITECTURES WARFIGHTING OPERATIONS SUPPORT INFRASTRUCTURE ENTERPRISE MISSION AREAS Combat Ops (Lead: ACC) Installations & Logistics (Lead: AF/IL) Modeling & Simulation (Lead: AF/XI) Space Ops (Lead: AFSPC) Health Services (Lead: AF/SG) Infostructure (Lead: AF/XI) Mobility Ops (Lead: AMC) Personnel (Lead: AF/DP) Special Ops (Lead: AFSOC) Acquisition (Lead: SAF/AQ) Weather (Lead: AF/XOW) Air Traffic Management (Lead: AFFSA) Financial Management (Lead: SAF/FM) Operations Support Enterprise Architecture (OSEA) Notes: 1. Civil Engineer EA must respond to many forces. 2. Logistics EA and Civil Engineer EA are in different domains in OSD, but in same mission area within AF, with AF/IL as lead 3. Civil Engineer should work with Combat Ops 4. Civil Engineer should work with Modeling & Simulation cross-cutting area 5. AF-CIO owns technology aspects of AF EA; AF CIPT owns business process aspects of AF EA

10 What s the Payback? INTEGRATING ENTERPRISE ARCHITECTURE AND PORTFOLIO MANAGEMENT PROVIDES OPPORTUNITIES TO: Reshape strategic vision for organization Reduce or remove information and/or process stovepipes Revamp decision-making policies Implement improved organizational governance and structure Increase synergy between business and IT personnel Increase communications about business and supporting IT Visualize impacts of change on business and supporting IT Increase objectivity in decision-making Analyze rate of return for long-term solutions

11 Enterprise Architecture Drivers Legislation and policy have a hammer IT initiatives with total funding > $1M will not be approved without a completed Enterprise Architecture and transition plan after 30 Sep 05 Continued lack of enterprise architecture is causing Congress to lose faith in DoD IT management, resulting in reduced IT funding across appropriations Services losing control of IT to OSD domains, including investment decisions

12 Enterprise Architecture Basic User Needs Understand Enterprise Architecture well enough to: Support Civil Engineer EA (CEEA) development Recognize and understand products Understand Portfolio Management Intertwined with Enterprise Architecture Understand Governance Understand how to fit into IL s, AF s, and OSD I&E s governance structure Change ILE s governance structure to accommodate strategic nature of enterprise architecture and portfolio management

13 Upcoming Suspenses AF/IL Requirements per policy memos: By 30 Sep 04, must: Identify EA project management office and chief architect Identify small headquarters working group Define the scope, vision, and objectives Adapt a methodology Determine framework and toolset Define working group(s) for BPR Produce a concept of operations Acquire development support By 30 Sep 05 must: Hold larger corporate working group(s) Produce framework products for as-is, to-be, and transition enterprise architectures Conduct public relations activities (i.e., education, organization change) DoD has been directed by OMB and Congress to complete by 30 Sep 05 PLUS Periodic Checks with ILE for Mid-Course Corrections and Affirmation

14 EA First Step: Adopt Methodology Provide a common set of procedures for developing architecture products to help ensure consistency across the organization for developing and maintaining the enterprise architecture Must be documented, understood, and consistently applied Prescribed standards, steps, tools, techniques, and measures to be used to provide reasonable assurance for product quality Options Multiple approaches possible CE will use Spewak s enterprise architecture planning (EAP) methodology Used by predominance of federal agencies that have selected a methodology (ref: GAO Enterprise Architecture) Can be viewed as a cyclical wheel

15 Next Step: Determine Framework EA framework (or model) provides formal structure for representing the architecture and serves as basis for nature and content of the specific products Ensures consistent representation of information Decreases difficulty of maintenance Framework has been determined by DoD and AF Department of Defense Architectural Framework (DoDAF) Includes 3 layers of architectural views: Operational System Technical Standards

16 Third Step: Define Toolset Automated EA tool serves as the repository of architecture artifacts, which are work products that are produced and used to capture and convey architectural information Who s using what? Predominance of federal agencies: System Architect, Microsoft Office OSD I&E: Metis (a visual modeling tool) AF-CIO: Metis and System Architect AF/IL: ARIS (but has requested sub-domains use System Architect) Tools of ILE Choice? System Architect and DOORS System Architect is configure to build DoDAF products DOORS captures business requirements Supplemented with Microsoft Office files Garrison GeoBase will use System Architect to interface with larger ILE requirements Field submittals expected to be in common Microsoft Office format such as Word, Excel, Access, Visio, and Project

17 Conceptual Approach to Enterprise Architecture START HERE! 1. Define Vision, Scope, Objectives 6. Implement 2. Map Business Processes for To-Be Architecture Continuously Review and Update 5. Build Transition Plan 3. Document High Level As-Is Architecture 4. Analyze Gaps and Opportunities

18 Define Scope, Vision, and Objectives Carefully define the scope of the specific enterprise architecture Include all areas that need to share data, internal and external Realistically bound the extents of your architecture Garrsion GeoBase architecture will take a tiered approach Installation/DRU MAJCOM/FOA AF/ILEI Strategic vision should look about 10 years ahead Objectives should identify what is to be accomplished, with focus on business benefits

19 Tiered Architectures Different organizational levels will have different levels of specific detail in their Enterprise Architectures Installation architectures represent finest detail Day to day operations and processes Widest variety of specific requirements MAJCOM/FOA will represent next level of abstraction, but still specific to individual mission requirements Garrison GeoBase EA will be most general to encompass all geospatial processes, technologies, data, organizations, etc. INSTALLATION/DRU MAJCOM/FOA AF/ILEI, etc. SPECIFIC TECHNICAL DETAIL ABSTRACTED VIEWS

20 Scoping the Enterprise Architecture Federal EA DoD EA USA EA USN EA USAF EA Warfighter Mission Area Financial Mgmt Domain Health Services Domain Acquisition Domain SVS LOG (Lead) CE Personnel Domain COMM IL Domain Operational Support Mission Area Infrastructure Environment

21 Scope of CEEA Red lines identify supporting roles Garrison GeoBase EA Perform DoD I&E Processes Blue line identifies CEEA scope Perform AF I&L Processes Activities may not be completely identified Perform HAF CE Processes Expeditionary activities are based on MCL Connection with AF I&L and DoD I&E reinforces need to forward data to the larger enterprises Perform Readiness Activities Perform Explosive Ordnance Activities Perform Real Property Activities Perform Operations Activities Perform MAJCOM CE Processes Perform Garrison CE Processes Perform Administration Activities Perform Personnel and Training Related Activities Perform Military Family Housing Activities Perform Furnishings Management Activities Perform FOA Processes MAJCOM Support for AEF Perform COCOM CE Processes Perform Expeditionary (Forward Ops) CE Processes Perform Capability Activities (Intelligence) Perform Capability Activities (Command & Control) Perform Capability Activities (Protect: Deny and Respond) Perform Capability Activities (Protect: Recover) Perform Fire Department Activities Perform Environmental Activities Perform Project Management Activities Perform Capability Activities (Prepare & Sustain)

22 Vision Civil Engineer Enterprise Architecture (CEEA) vision begins with the Air Force Civil Engineer Mission Provide, operate, and maintain installations, infrastructure, and facilities necessary to create and sustain responsive, persistent, and effective combat operations Garrison GeoBase EA vision is one installation one map A sub-architecture to the CEEA, but still part of the larger CE vision Supports CE activities in a cross-cutting fashion through focus on installation mapping and visualization capabilities

23 CEEA Objectives Objectives begin with the AF/CE Strategic Plan Right Expeditionary Engineering Right Installation Size and Place Right Installation, Environment, and Base Services Quality Right Installation Safety and Security Right Installation Resources Right Tools and Metrics Determine if these objectives hold true for the 10-year vision

24 Garrison GeoBase EA Objectives Support basing mission safety, efficiency and effectiveness through improved geospatial information resources Ensure long-term adoption and tight integration of geospatial capabilities into the AF enterprise Effectively manage geospatial information resources and related information technology investments Use strategic planning to: Secure fiscal accountability Reduce investment risk Guide and monitor long-term geospatial resource development Implement standardized geospatial data architectures and quality assurance procedures Assure protection of geospatial information resources

25 Tie to mission requirements Map To Be Business Processes Seek guidance from DoD and AF resources, such as Directives, Architectures, Policies AF/CIO, AF/ILEI, GCSS-AF Outreach Team Conduct business process engineering sessions to map future processes in sufficient detail to: Make investment decisions Satisfy the scope, vision, and objectives Define methods to measure success Consult subject matter experts, particularly for mission data set development Develop appropriate DoDAF products

26 Document As-Is Architecture Review and map existing processes Develop appropriate DoDAF products Document as is so as to comparable to the to be state Conduct business process engineering sessions to map future processes in sufficient detail to: Make investment decisions Satisfy the scope, vision, and objectives Define methods to measure success

27 Analyze Gaps and Opportunities Compare existing and future processes Define requirements Identify all existing functional capabilities related to perceived gaps across the enterprise (may be in a different organization or functional area) GeoBase Capabilities Registry designed to help at this stage Perform gap analysis Identify opportunities to enhance basic capabilities

28 Build Transition Plan Document plan ahead in the transition road map How will you get from where you are to where you want to be? May include a third transitional phase between the as is and to be states Identify milestones and metrics Identify funding streams

29 Review steps ahead with: Enterprise Architect(s) Portfolio Managers Network Administrators Internal hierarchy (as appropriate): Installation/DRU MAJCOM/Related Centers of Excellence AF/ILEI IM&V Council AF/ILE ILDAC/EAIC AF/CIO Implement Transition Plan

30 Start the Next Round 1. Define Vision, Scope, Objectives 6. Implement 2. Map Business Processes for To-Be Architecture Continuously Review and Update 5. Build Transition Plan 3. Document High Level As-Is Architecture 4. Analyze Gaps and Opportunities

31 Portfolio Management and Enterprise Architecture Investment Evaluation Strategic Planning (i.e., EA) Priorities Portfolio Management (PfM) Value Proposition Resource Allocation Investment Analysis & Selection Policy and Process Legislation Based on DoD/AF Strat Plans ILE Operational Goals Ties to Master Capabilities List Policy, Process, Control Existing IT Systems Sustainment Enhancement Concepts for New Systems Investment Control Investments Program Management Day-to-Day Operations Existing IT Systems Sustainment Enhancement Development of New Systems

32 What s Happening With PfM? New Policy Memo Reasserts 6 Aug 03 ILE-2 memo regarding PfM Delineates new roles and responsibilities for AF/ILE-I and AFCESA/CEOI (related to EA and PfM) Directs MAJCOMs and FOAs to identify portfolio manager as single point of contact Identifies upcoming data call for system information Now anticipated for late July OSD I&E Domain and AF I&L Domain are both formulating data requirements; will try to use their requirements in developing call Broadens scope of what systems should be identified (e.g., administrative systems at MAJCOMs/FOAs/HAF, energy control management systems) New AF/ILE Portfolio Manager

33 What s Happening With PfM? (cont.) New Processes from OSD I&E and AF I&L Domains Have specifically held back in defining governance processes to meet OSD and AF domain requirements OSD domain will likely take lead IL Registry no longer used! Data migrated to new system ILE portfolio includes 55 systems ILE has own registry to get arms around capabilities Reports to AF/IL, AF CIPT (Operational Support EA), OSD I&E Not ALL systems must be reported to these organizations OSD(C) certification process and worksheet being developed for systems requiring >$1M fund expenditures PfM is adding Certification and Accreditation as a professional expertise

34 Roles/Responsibilities AF/ILE-I Focus shifting from GeoBase only to CE information resource management Responsible for strategic perspective and policy Enterprise Architecture and Portfolio Management considered strategic activities AFCESA/CEOI Focus shifting from strategic and tactical information resource management to program management

35 Understand Governance What is meant by governance as it pertains to EA and PfM? It is the set of processes and organizations by which we make investment (i.e., information technology) decisions AF Civil Engineer is subject to the governance of others; must address internal governance to conform and work with those

36 Existing Governance Structure SAF/IEE AF/IL Panel EAIC Automation Steering Group ILE-2 Chair ILDAC Meets every 3 months EESOH CCB Meets every 3 months CE Investments Only Configuration Control Board AFCESA/CEOI Chair Meets every 3 months CE Investments Only Installation Mapping & Visualization Council Meets every 3 months GeoBase IPT Inputs ACES Environmental IPT Inputs Focused Working Groups 9 ACES Integrated Process Teams Garrison Site Mapping Panel Expeditionary Site Mapping Panel

37 Changing Governance Structure Must demonstrate through organization how both enterprise architecture and portfolio management will be governed within CE Need to implement for EA Enterprise Architecture Executive Steering Committee Need to implement for PfM Capital Investment Council Technical Review Committee Concept / Business Case Functional Review Boards New structure would require new or modified processes, new form(s), and different mindset Goal is to have new structure and processes in place by Jan 05 IM&V Council Charter must be approved by 15 Oct 04

38 Steps Ahead Understand Enterprise Architecture Support Civil Engineer EA (CEEA) development Support Garrison GeoBase Enterprise Architecture development Recognize and understand DoDAF architecture products Understand Portfolio Management Establish an active working relationship with your organization s PfM Provide input when data call is made Request clarification and assistance when requests are unclear or issues appear Understand Governance Understand how to fit into IL s, AF s, and OSD I&E s governance structure Support changes to ILE s governance structure to accommodate strategic nature of enterprise architecture and portfolio management (such as 04 AUG Memo signed by Maj Gen Fox, the AF Civil Engineer)

39 Top Management Involvement Every successful EA has cited Top Management awareness, recognition, and acceptance as the single most important factor in its success! Top Management refers to executives in the business area being planned AND in information systems Awareness means the executives know about the EA process, its benefits, and its products Executives must recognize the reason for developing architectures and their importance to the organization Acceptance means that management understands the rationale for EA and accepts their role and responsibility to the EA process for successfully achieving its objectives SOLUTION: Institute an education process to bring management on board. GAO-04-40: Agencies continue to face the same management challenges that we identified 2 yrs ago that is, obtaining top management support and commitment, overcoming parochialism, and having the requisite resources (financial and human capital) to get the job done.

40 Commitment to EA Commitment means that sufficient personnel, funds, time, and material are allocated to do EA properly and in a timely manner Without commitment, EA cannot succeed. Part of the FY05 GeoBase program management reviews will be to put forth a plan to complete the requisite DoDAF architecture products for each MAJCOM/FOA/DRU. In that plan: Identify timeline to complete products 1 st drafts due in March 05 2 nd drafts June 05 Will be incorporated into CEEA due Sep 05 Realistically evaluate existing capabilities and potential shortfalls in personnel, expertise, or other resources **More discussion to follow in session after the break**

41 Enterprise Architecture Department of Defense Architecture Framework (DoDAF) Version 1.0, August 2003

42 Definitions Architecture.the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. --C4ISR Architecture Framework, Version 2.0 (evolved into DoDAF, Version 1.0) Framework common, pragmatic guidelines for describing an architecture to enable comparisons and integration. architectural discipline for examining processes and system alternatives in context with mission operations and information requirements. --Kathie Sowell, FEAC Institute DoDAF The architecture framework that the Department of Defense has chosen to use

43 DoDAF Views The DoDAF uses three different data perspectives (views) that logically combine to describe an architecture. Operational View (OV): describes required tasks, activities, operational elements, and information exchanges What has to be done? Who does it? Who needs to get the information? Systems View (SV): describes systems and interconnections What is the material solution by which operational nodes interact with each other and with the outside world? Technical Standards View (TV): describe technical system rules that govern the arrangement, interaction, and interdependence of system elements What technical standards must be met (i.e. J2EE or SDSFIE)? What performance criteria must be met (i.e. minimum response time)?

44 DoDAF Architectural Views Activities Activity Relationships Business Processes Needed Information Information Relationships Node Locations Information Exchanges Source of Information OPERATIONAL VIEW System Interfaces Information Exchanges System Laydown System Components Links to Nodes Links to Activities SYSTEMS VIEW Standards Technical Implementation GIG Standards Exchange Criteria JTA Compliance TECHNICAL VIEW

45 Links Between Views Operational View (Identifies Players, Relationships and Information Needs) Base technology supportability and new capabilities Processing and levels of infoexchange requirements Systems associations to nodes, activities, needlines, and rqmts Processing and inter-nodal levels of information exchange rqmts Systems View (Relates Capabilities & Characteristics to Operational Requirements) Technical criteria governing interop implementation of selected system Specific capabilities to satisfy infoexchange levels & other ops rqmts Technical View (Prescribes Standards and Conventions)

46 Associated Products 26 products across views Color coding AV Black OV Blue SV Brown TV Red Products are highly integrated Core products are those most commonly used, and, until recently, required - still highly recommended View Abbrev Product Core? All Views (Context) AV-1 Overview and Summary Information Yes All Views (Terms) AV-2 Integrated Dictionary Yes Operational OV-1 High-Level Operational Concept Description Yes Operational OV-2 Operational Node Connectivity Description Yes Operational OV-3 Operational Information Exchange Matrix Yes Operational OV-4 Organizational Relationships Chart Operational OV-5 Activity Model Yes Operational OV-6a Operational Rules Model Operational OV-6b Operational State Transition Description Operational OV-6c Operational Event/Trace Description Operational OV-7 Logical Data Model Systems SV-1 System Interface Description Yes Systems SV-2 Systems Communications Description Systems SV-3 Systems - Systems Matrix Systems SV-4 Systems Functionality Description Systems SV-5 Operational Activity to System Function Traceability Matrix Systems SV-6 System Data Exchange Matrix Systems SV-7 System Performance Parameters Matrix Systems SV-8 System Evolution Description Systems SV-9 System Technology Forecast Systems SV-10a Systems Rules Model Systems SV-10b Systems State Transition Description Systems SV-10c System Event/Trace Description Systems SV-11 Physical Schema Technical TV-1 Technical Standards Profile Yes Technical TV-2 Standards Technology Forecast

47 DoDAF Views The DoDAF also describes a fourth view that is related to all of the other three (OV, SV, TV): All Views (AV): describes pertinent to the architecture but does not describe a distinct view Overarching perspective, such as the scope of the architecture Common terminology used throughout the architecture Usually in document format **Although enterprise architecture is aimed at managing Information Technology, the concepts apply to any process you might want to map. The next example looks at architecting a manufacturing process that manages physical goods rather than electronic information

48 DoDAF Views The Margarita Example You want to architect making and serving the perfect margarita What considerations would go into each of the views? All View (scope and definitions) Operational View (activities) System View (material solutions to support activities) Technical View (standards and rules) What would change if: You needed to serve a non-alcoholic version? You decided to patent your recipe? You wanted to sell your margaritas? You want to enable your drinks to be made around the world? You wanted to have them made and sold worldwide?

49 Break Something to think about on the break: Enterprise Architecture can apply to any process, from washing your car to colonizing Mars. It can certainly apply to mapping out how you would approach creating the architecture product plan that will be required during the FY05 GeoBase PMRs. Ponder the following, and we ll see if we can incorporate these ideas as we discuss the individual required products What is the scope of this assignment? What do these terms actually mean? Who will be involved? What information will I need? What standards do I need to follow? What activities will need to be done? What technology will I need to create and deliver the products?

50 Conceptual Approach to Enterprise Architecture START HERE! 1. Define Vision, Scope, Objectives 6. Implement 2. Map Business Processes for To-Be Architecture Continuously Review and Update 5. Build Transition Plan 3. Document High Level As-Is Architecture 4. Analyze Gaps and Opportunities

51 The Six Step Process in DoDAF The DoDAF provides some high-level guidance on how to proceed. Determine the intended use of the architecture Purpose Critical Issues Target Objectives Determine the architecture scope Geographic Timephase(s) Functional Bounds Technology Constraints Determine the characteristics to be captured Depth of Detail Performance Measures

52 The Six Step Process in DoDAF Determine the views and products to be built Not all architectures require all products None are strictly required at this point, but seven are highly recommended Requesting seven out of the eight core products for Garrison GeoBase Enterprise Architecture Build the requisite products For Garrison GeoBase, submit using Microsoft Office software Will be incorporated into larger CE Enterprise Architecture at AF/ILEI using Popkin System Architect Build additional DoDAF products if they will helpful Use architecture for intended purpose Product investments Business process improvement Increased interoperability

53 Core DoDAF Products All Views (AV) AV-1: Overview and Summary Information (context ) AV-2: Integrated Dictionary (terms) Operational View (OV) OV-1: High Level Operational Concept Description OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Activity Model Systems View (SV) SV-1: System Interface Description Technical Standards View (TV) TV-1: Technical Standards Profile

54 Core All Views (AV) AV-1: Overview and Summary Information (context ) Definition Executive level summary Assumptions, constraints, limitations Purpose Serves as planning guide in early stages Provides summary upon completion Architecture Project Identification Scope Purpose and viewpoint Context Tools and File Formats Used Findings

55 Notional AV-1 Example

56 Core All Views (AV) AV-2: Integrated Dictionary Definition Definition of terms used in an architecture a glossary Purpose Includes taxonomies Common terms linked to common definitions Used consistently throughout all architecture products Metadata regarding architecture data types used Central repository for architecture s data and metadata Provides unambiguous definitions Allows architecture to stand alone, to be understood with minimal reference to external sources

57 Key AV-2 Taxonomies

58 Core Operational Views OV-1: High-level Operational Concept Description Definition Describes business process or mission Highlights main operational nodes Can represent geographic distribution of assets Depicts interaction of architecture subject with external entities Purpose Visual depiction of what the architecture covers Primarily graphic representation of mission and activities, supported by textual content where needed Focused towards high-level decision makers **Not being requested from field for Garrison GeoBase enterprise architecture at this time**

59 Sample OV-1 (Tricare)

60 OV-1 Example Navy

61 Core Operational Views OV-2: Operational Node Connectivity Description Definition Graphically depicts nodes where activities occur. A node is an element that produces, consumes or processes information generally a person, an organization, or a functional area Shows needlines for information exchange between nodes Does not detail physical or organizational connectivity between nodes Includes internal and external nodes Purpose Track the need for information exchange between nodes Integrates directly with the OV-5 Activity Model

62 OV-2 Template

63 OV-2 Example

64 Core Operational Views OV-3: Operational Information Exchange Matrix Definition Identifies who exchanges what information with whom Shows why information is necessary Depicts how information exchange must occur One OV-2 needline may have many individual information exchanges on the OV-3 Purpose Information exchange: the act of exchanging information between two nodes, including characteristics of the exchange Information element: what is exchanged Express relationships across operational activities, nodes, and information flow Focus on key exchanges, minimal detail don t overdo it!

65 Notional OV-3

66 Core Operational Views OV-5: Activity Model Definition Describes operations normally conducted to achieve a mission or a business goal Describes capabilities, activities, and input/output flow between activities Depicts internal and external activities Purpose Key product for describing capabilities and ties to mission success Delineates operational node responsibilities for activities (OV-2) Pinpoints redundant or missing activities Integrates tightly with information exchange matrix (OV-3)

67 OV-5 UML Template

68 Sample OV-5 (Tricare) Military Health System Access to Care Provision of Health Services Population Health Management Manage the Business Deliver Worldwide Logistics Manage Human Resources Perform Medical Management Support Contracting Manage Finances 4.2 Patient Financial Management 4.4 Review/Improve Business Mgmt 4.6

69 Conduct Combat Assessment OV-5 Example

70 Core System Views SV-1: System Interface Description Definition Depicts system nodes and the systems at those nodes Demonstrates how operational nodes (OV-2) are supported by systems Can identify cross-organizational system interfaces One information needline may have many system interfaces Purpose Links systems to operations by assigning systems and system nodes to information exchange needlines Documents systems, subsystems, and hardware/software Physical modes of system communication (routers, switches, etc.) are not documented here, but in the SV-2, System Communication Description

71 Core System Views SV-1: System Interface Description (continued) Key Interfaces have one of the following characteristics, and should be identified on the SV-1: Spans organizational boundaries Mission critical Difficult or complex to manage Capability, interoperability, or efficiency issues The SV-1 can be shown in different ways: Internodal Node-Edge-to-Node-Edge Internodal System-to-System Intranodal Intrasystem

72 Notional SV-1 Internodal Node-Edge-to-Node-Edge

73 Notional SV-1 Internodal System-to-System

74 Notional SV-1 Intranodal

75 Notional SV-1 Intrasystem

76 SV-1 Example

77 Core System Views TV-1: Technical Standards Profile Definition Define systems standards rules, i.e. Data formats Communication protocols Approved hardware/software Outline constraints Ties to Joint Technical Architecture (JTA) at service level Purpose Apply standards for architecture implementation across an enterprise Identify technical standards utilized when evaluating interoperability Governs hardware/software and data format choices

78 TV-1 Template (JTA)

79 Enterprise Architecture Next Steps for Garrison GeoBase Enterprise Architecture

80 Garrison GeoBase Enterprise Architecture Current version completed in January 03 Primary focus on as-is and transitional states Based on C4ISR Architecture Plan Includes following products: OV-1: High-leOvel Operational Concept Description OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-4: Organizational Relationship Chart OV-7: Logical Data Model SV-1: Systems Interface Description TV-1: Technical Standards Profile Version 1.1 expected to be completed December 04 Will update existing products and add AV-1, AV-2, and OV-5

81 Garrison GeoBase Enterprise Architecture Version 2.0 will include information to be integrated into the Civil Engineer Enterprise Architecture (September 05) Will draw from information provided by MAJCOM/FOA/DRU products Should be flexible and more easily maintained due to use of automated enterprise architecture software Will evaluate value of additional supplementary architecture products, such as the SV-11, Physical Schema, and the TV-2, Standards Technology Forecast Will incorporate policy and guidance changes since last version Will either incorporate requirements, or serve as basis for, separate Expeditionary Site Mapping Enterprise Architecture Will also provide support for continued development of installation mapping and visualization as an AF web service