Experiences with NetCentric Advocacy and Assessments Hans Polzer

Experiences with Net-Centric Advocacy and Assessments Hans Polzer, Lockheed Martin September 19, 2008

Outline § Net Centric Assessment Workshop Process Overview § SCOPE Model and Workshop Purpose § Top Level Model § SCOPE V 1. 0 Dimension Overview § Workshop Results and Experiences

Workshop Process Overview § Planning session with target program about 1 month prior to workshop – – § One-Two day SCOPE Workshop with identified stakeholders – – – § Orient proponents and identify domain stakeholders to be engaged Prepare strawman capability-specific net-centric criteria Mutual intro briefs and SCOPE model/purpose/process overview Structured interviews with stakeholder groupings using questionnaire as facilitating tool and data capture tool Outbrief to team on initial observations from workshop interviews and recommended follow-up interactions Formal report 2 -4 weeks after the workshop, usually in Powerpoint – – Follow-up actions identified during workshop Potential longer term relationship with target program team

SCOPE Purpose § Provide a measurement framework for describing to what degree a set of Systems supports a Capability, Operation, Program or Enterprise (SCOPE) over a network – Whether the set constitutes a family of systems, a system of systems, or just an ad hoc grouping is contextual and a matter of degree – Can involve multiple capabilities, programs, or enterprises – Helps define the scope and diversity of the systems in a given context • Highlights nature of issues affecting system interoperation – Helps identify how a given system could better support the larger context in a net-centric ecosystem (“scope creep”) How open are the systems to each other and to their environment and what purposes do they support?

SCOPE Model Features § Net Readiness Dimension set – Measures how open and adaptable component systems are to working with each other over the network § Capability/Operational Scope Dimension set – Measures how broad, deep, and diverse the operational architectures are that the systems are designed to support § Technical Feasibility Dimension set – Measures how feasible it is to achieve desired operational capabilities, given the systems and their information exchanges over the available network using established technical standards and infrastructure services Net-centricity is not free, adaptability is purpose-driven, and the network is only somewhat transparent

Relating Systems of Systems, Capabilities, Operations, Programs, and Enterprises (SCOPE) “Intergalactic Radiator” by Capt Yurchak For SCOPE illustration only Tactical C 2 MCP ISR MCP Enterprise Current Navy Warfare Sponsors EXW SUW USW AW N 75 N 76 N 77 N 78 Budgets allocated vertically Navigation MCP Individual Programs/Systems or System of Systems Missile Defense MCP ASW N 74 Time-Critical Strike MCP Systems of systems often aligned to these capabilities Operations (often in and out of page) Illustrates Complex Dependencies in Capability Acquisition

DODAF Architecture Views and SCOPE Capability Scope Dimensions Which Systems interact? About what? How much? And why? To what effect? Broad UJTLs Technical Feasibility Dimensions Operational View High Identifies Participant Relationships and Information Needs Battlespace Representation and Naming standards Narrow Data models, Process algorithms Net-Ready Dimensions Systems View Open Technical View Prescribes Standards and Conventions Relates Capabilities/Characteristics to Operational Requirements What do systems say to each other? How is this information represented? Data element standards, Protocols, Environments Low Can capability be achieved with current stds & technologies? Are new standards needed? Is the information obtainable, Accurate, timely? Technology readiness levels Closed How do systems interact? What standards are used?

Capability Scope Dimensions Value Broader Scope Narrower Scope Dimension Overall Scope and Types of Enterprise Single Unit Single Service or Agency Do. D-Wide World-Wide Capability Breadth Single Functional Domain/Service Multi-Domain, Multi. Service Multi-Dept, NGO, Industry Coalition, Multi. Enterprise Type Capability Depth Single Level Two Levels Three Echelons Four or More Echelons Organizational Model and Culture Rigid Hierarchy, Vertically Integrated Adaptive Hierarchy, Interact Horizontally Flat, Empowered, Open to Partnering Adaptive, Social, Interdependent Unity of Life Cycle Control/Alignment Single Do. D Acquis. Exec Multiple Do. D Acquis. Exec Do. D & US Syst. Owners Multi-National Syst. Owners Acquisition Congruence (SD) All Systems on Same Timeline within 2 years Timeline within 5 years Timelines >5 years apart Semantic Interoperability Single Domain Vocabulary Multi-Domain Vocabulary Single Language Multiple Languages Multiple Ops Contexts Future/Past Integration Hypothetical Entities Operational Context Single Ops Context (SD)

Program X Capability Scope Dimension Example Value Broader Scope Narrower Scope Dimension Overall Scope and Types of Enterprise Single Unit Single Service or Agency Do. D-Wide World-Wide Capability Breadth Single Functional Domain/Service Multi-Domain, Multi. Service Multi-Dept, NGO, Industry Coalition, Multi. Enterprise Type Capability Depth Single Level Two Levels Three Echelons Four or More Echelons Organizational Model and Culture Rigid Hierarchy, Vertically Integrated Adaptive Hierarchy, Interact Horizontally Flat, Empowered, Open to Partnering Adaptive, Social, Interdependent Unity of Life Cycle Control/Alignment Single Do. D Acquis. Exec Multiple Do. D Acquis. Exec Do. D & US Syst. Owners Multi-National Syst. Owners Acquisition Congruence (SD) All Systems on Same Timeline within 2 years Timeline within 5 years Timelines >5 years apart Semantic Interoperability Single Domain Vocabulary Multi-Domain Vocabulary Single Language Multiple Languages Multiple Ops Contexts Future/Past Integration Hypothetical Entities Operational Context Single Ops Context (SD)

One Possible Enterprise Breadth “Hypercube” Service Concepts Army Operating Concepts Marine Corps Strat 21 Naval Operating Concept Air Force CONOPS Joint Functional Concepts Enabling Concepts Joint Operating Concepts

Sample Capability-Specific Scope Dimensions Value Example Dimensions More Capability Less Capability Time to Target Engagement 1 Hour 30 Minutes 1 Minute Stryker Bde Deploy Time 30 Days 72 Hours 24 Hours Total Lift Capacity Single aircraft type Multiple aircraft Multiple lift types All lift types Target Detection Single sensor Multiple sensor types All source ISR Management Single Platform Multiple Platforms Multiple platform types All platform types Logistics Support Single Weapon System Type Fixed Wing Air Support Multi-Class Supply All Classes of Supply

Sample Functional Capability Profile Narrower Scope Broader Scope Current Proposed Key Improvement Areas C 7 C 6 C 8 • Tactical Nets • Local Gov Interface • Rail modes • Support for Cross Domain Services C 5 C 1 C 2 C 4 C 3 Actual MOP Threshold Capability Scope Measures Capability Specific Measures

Net Ready Dimensions and Levels Value Tighter Coupling / Less Net-Readiness Looser Coupling / More Net-Readiness Dimension Service Discovery Service specs pub at design Service specs pub run-time OWL spec for Services Comparative service select Information Discovery Static Indexes Metadata Navigation Relevance Measures Context-driven Search Info Model Pre. Agreement Complex data & doctrine Standard XML Schemas Business Object ASCII, URLs Information Assurance Link encrypt SSL Single sign-on support Do. D-Wide PKI support MSL, crossdomain spprt Autonomic Networking Design Time Configuration Run Time Re. Configuration Dynamic Net Management Adaptive Net Management Semantic Interoperability No Explicit Semantics Semantic Metadata for Interfaces Ontologybased interfaces Dynamic Ontology mapping

Technical Feasibility Dimensions Larger Risk Value Smaller Risk Dimension Inter-System Time Binding to Achieve Capability Strategic Tactical Transactional Real Time Run-Time Computing Resources Needed <1% of existing system resources 1 -10% 10 -50% >50% of existing system resources Service Mgmt. Resources Needed Negligible Within Current Net Service Capacity Within Planned Net Service Capacity Beyond Planned Net Service Capacity Net Resources Needed (FD) Negligible Within Current Net Capacity Within Planned Net Capacity Beyond Planned Net Capacity Interface Development Complexity <1% of system size 1 -10% 10 -50% >50% of system size Technology Readiness Level For Net Use TRL Levels 8 -9 TRL Levels 6 -7 TRL Levels 4 -5 TRL Levels 1 -3

SCOPE Model Summary § SCOPE is a comprehensive, balanced approach to assessing sets of systems from a net centric operations perspective – Evolved through application against real programs – Yet has an overarching perspective on the problem space, semiorthogonal to architecture frameworks (FEAF, Do. DAF, Zachman, etc. ) § SCOPE is a “Goldilocks” model – No preconceived value for any given degree of net-centricity – Value depends on operational objectives of target system sponsors • Desired degree of agility • Desired degree of operational/resource scope § SCOPE has potential to be a net-centric content-based complement to CMMI to characterize what is built vice how – But focused more on “best fit” to the problem domain rather than “maturity” or “level” based Helps position programs/systems in the larger ecosystem of institutional goals and capabilities; identifies interoperability gaps

Observations on SCOPE Workshops § Net Centricity is not just some set of requirements § Net Centricity is a state of mind, an attitude about how systems should behave with each other and with their users § System engineering and development program execution is about establishing system boundaries and constraining scope/risk § Net Centricity is about crossing system boundaries and embracing and accommodating diversity, change, and unanticipated users and uses § Net Centricity is about enabling reliance on systems/capabilities outside your system boundaries § Net Centricity means your system is potentially on someone else’s critical path § Net Centricity is a full-contact social sport You are promoting unnatural concepts and behavior – don’t expect a warm welcome

Observations on SCOPE Workshops • SCOPE is a kind of requirements elicitation tool designed to induce net centric thinking and perspectives on some set of systems vis-à-vis some capability set • Given the previous slide, it is also, therefore, provocative • You are serving as a change agent, an instigator, a facilitator • You can’t demand net-centric thinking – it has to be embraced by the program/capability team and made their own • Group interviews/discussion within the team is key to success • People being asked to interact with a questionnaire by themselves will have limited impact/utility • Group discussion exposes implicit assumptions and different perspectives within the team to each other You want the team to see for themselves where netcentricity can lead and explore what the benefits might be

Observations on SCOPE Workshops • The value of net-centricity has to be seen by the team as outweighing the cost/risk • Can be based on requirements compliance or “score” (weak) • Better to identify external dependencies that can bring value to the program as a program, or as a capability fragment provider • Reduce development cost/risk by using external system services • Establish program as a more central element in a capability area • Increase operational value by increased scope of accessibility to other systems, use of other systems, and increased agility • Focus on generating discussion within the team, prompted by the SCOPE dimensions and associated questions • Capture in the comments section for each question Goal is to find the “just right” level of net centricity for the team/systems – respect the risk/benefit balance they face

Observations on SCOPE Workshops • SCOPE doesn’t cover everything • E. g. , engineering process or specific architecture guidance • SCOPE covers too much for most program teams • Takes a lot of time to understand the implications of the dimensions and questions for a particular program • Not all of the dimensions are equally relevant to all programs • Usually some tailoring is required • May not have entire team available for all questions • The workshop team may not have sufficient domain expertise to generate even a “strawman” set of capability-specific SCOPE dimensions • Consider getting some domain SME help prior to the workshop Consider making SCOPE Workshops part of existing program review or “visioning” processes

SCOPE Workshop Follow-up § Engage Team Stakeholders regarding workshop results and recommendations – Aggregation of results require subjectivity/judgment – Graphic displays are useful, but need to be supported by specific recommendations and rationale § Look for and leverage specific areas where team has embraced increased net centricity to open other possible areas § Provide feedback on changes the team has adopted – “course corrections” § Identify any lessons learned for the SCOPE model – Changes to the model itself – Changes to the workshop process

Possible Output from SCOPE Workshops Specific recommendations for increased net-centricity along specific SCOPE dimensions and expected operational or programmatic benefit

Contact Information § NCOIC SCOPE Model – www. ncoic. org § SCOPE Working Group email: scope_wg@lists. ncoic. org § Hans Polzer – Email: hans. w. polzer@lmco. com – Phone: 703 251 -7303

Backup Slides

Capability Information Domains Strategy Development and Execution – Intention, Desired Effect Purpose, Situational Understanding Encyclopedic Information, Public Info Models, And Open Source Data People, Objectives, Perceptions, Intentions, Assessments Doctrine, OPCONS, Effects, Process Oplan Development and Execution Purpose, Situational Awareness Battlespace Information Models (S) Battlespace Information Models (O) Battlespace Information Models (T) “Sense-making” World Model Building Activities Data From Deployed/Tasked Data Collection Assets Phenomenology – Sensing the Real World

Net Enabling the Social and Cognitive Domains Through the Information Domain Social Domain Cultural Awareness Cognitive Domain Conveyed Commander’s Intent Cognitive Advantage Process Advantage Compressed Operations Network Centric Operations Shared Awareness Information Domain Information Advantage Precision Force Speed and Access Plan, Organize, Deploy, Employ and Sustain Cycle Physical Domain Force Advantage Position Advantage