Presentation is loading. Please wait.

Presentation is loading. Please wait.

ISA 201 Intermediate Information Systems Acquisition

Similar presentations


Presentation on theme: "ISA 201 Intermediate Information Systems Acquisition"— Presentation transcript:

1 ISA 201 Intermediate Information Systems Acquisition

2 Lesson 9 Architecture ISA 201 Architecture ELOs:
Lesson Point of Contact: Name: Kevin Corcoran Phone: Read Ahead: None Length of Presentation: 2.5 hours This lesson is broken into two 50 minute sessions. First hour: Slide 4–8: Build of the “So-What” for using architecture to help understand where enterprise to program understand where they are today, and manage the risk of moving into the future capability requirement. Slides 10-12: The key point to emphasis is how architecture in intended to help manage a program and/or manage the enterprise. Slide 13–29: Introduces the DoD Architecture Framework (DODAF) This includes Slide 19-24: Exercise to build an architecture product. Demonstrate relationship to CONOPS and identifying requirements and risks, then conclude with Focus on Standards Views and where DoD gets their standards. *Recommend: Put students on break – give them 15–20 minutes and have them read material for architecture exercise Slide 30–33: Introduces MOSA, DISR, and ISP as tools to help build interoperable system. Slide 35–43: Focus on “Other” Architecture words (DoD IEA, GIG, NR KPP, OSA, SOA, etc.) – what they are and why acquisition work force should care Slide 44-48: Walks through the Net Ready KPP requirements and how architecture products are used to describe Slide 49: Other CL courses that cover architecture related material in more detail. Slide 11: Lead in to help the rest of us sort through all the “architecture” words INSTRUCTOR NOTE: FOR MORE INFORMATION READ THE TRANSCRIBED NOTES THAT ACCOMPANY THIS SLIDE SET. ISA 201 Architecture ELOs:     ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. ARCHITECTURE Quiz Questions Which best describes the Joint Information Environment (JIE)? The JIE will be the trusted reference model and framework that will enable us to share information when needed, with any mission partner, regardless of location, device, or service provider. The body of standard design and engineering processes, tools, and best practices that leverage the modularity and composability of services to support objectives. The authoritative capstone architecture which provides a common, enterprise foundation to guide and inform IT planning, investment, acquisition and operational decisions. The set of information capabilities, and associated processes for collecting, processing, storing, disseminating, and managing information. Which of the following is NOT a benefit of the JIE? Cybersecurity Situational Awareness Reduced Cybersecurity Attack Surface (less places to attack and secure) Centralized Configuration Management Documented IT needs, objectives, and interface requirements ELO Recognize the application of a set of architectural data used within the acquisition process. Observed in Case Study (Practicum) Observed in Exercise ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). Which of the following is not a descriptive phrase for the “Modular Open Systems Approach”? Employs a modular design Strategic use of data rights Mandates interface standards for all interfaces Enables technology insertion ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance- Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). Which is an element of the DOD Information Technology Standards Registry (DISR)? Online repository of interoperable systems Mandatory list of standards that guarantees interoperability Describes current technical and emerging standards Used by program authorities to document IT needs, objectives, and interface requirements. ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter Will b a facilitated discussion for the October 2016 version. Intend to update into an exercise for the June 2017 version. ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). Which of the following is NOT one of the 5 Key Areas of the DODIN: Global Authentication, Access Control, and Directory Services Information and Services from the Edge Joint Infrastructure Common Policies and Standards The Information Support Plan (ISP) is used to: Document IT needs, objectives, and interface requirements Identify Joint Infrastructure Guarantee information and services from the edge D. Facilitate rapid delivery of IT systems

3 Today we will learn to: Describe the Joint Information Environment (JIE) Identify the benefits of the JIE Recognize the application of a set of architectural data is used within the acquisition process. Recognize the relationship between Enterprise Architecture and a Solution Architecture. Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). Describe the Modular Open Systems Approach (MOSA). From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). Recognize the benefits to the enterprise of the Information Support Plan.. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: An overview of the ELOs. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

4 ELO 8.1.1.8 Describe the Joint Information Environment (JIE)
Lesson Plan Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: An overview of the key parts of this lesson Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

5 The Winchester House Similarities
Construction of systems goes on continuously Vast budgets are allocated to the IT organization Collection of systems with odd features More interfaces and bridges than there are systems Major projects not completed Data: Redundant, inconsistent, and inaccessible SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: WIIFM *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Use Slides 4–8 to capture the students attention on importance of architecture Many of our IT infrastructures and projects resemble the Winchester House Transition: OK, so what is an Architecture… Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

6 Architecture SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: WIIFM *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Use this slide to emphasize how architecture includes all the drawings and are based on how something is intended to be used. (Note – can use a home example if needed to relate for students. E.g. can include added costs that occur when open walls) The structure is an instance of an architecture but it is not an architecture itself. When we refer to architecture we are given the system itself without the blueprints. The blueprints shown here are only one ‘view’ of the blueprints that would make-up the architecture referring to the ‘blue prints’ of the system and not the system itself. This is an important distinction since it is difficult to recreate a system when you are only f the structure there would actually be dozens. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: This provides a good lead into what do we do when we don’t have an architecture for a system and we want to modify it? Architecture

7 Question? What if we don’t have an Architecture for a existing system and want to make a modification? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: WIIFM *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: “What if we don’t have an Architecture for a existing system and want to make a modification? “ Let’s take the example of the baseball diamond shown here. If we were given a sizable amount of funds to increase the seating capacity of the stadium by 10%, how would be go about this without the architecture (blueprints)? Keep in mind that we don’t know what part of the structure we can modify without having negative effects on the current structure. What options do we have to meet this requirement without having the blue prints of the system? Here are 3. 1) Leave the old system and start from scratch. Just leave this stadium and build one across the street that meets the new requirement. (This is what was done with Comiskey Park, the Chicago Whitesox stadium). This seems to be the standard with IT. If we can’t “see” how the changes will affect the overall system we are unlikely to attempt the change. 2) Start tearing down walls We can start breaking down walls and see what effect it has on the structure. 3) Recreate the architecture. We can reverse engineer the architecture from the instance. This is costly and may take extensive domain expertise in the system being reverse engineered. It’s interesting that when constructing a building we assume there are detailed blueprints and this assumption is highly accurate; however, when constructing a software based system this assumption is less likely to hold. If our software system initially has accurate architectural diagrams do you feel we do a good job of maintaining them through the O&S phases? Why? Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

8 What is the Best Option? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: WIIFM *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Try to relate the images of IT systems to the trivial stadium example. Key Questions to Ask and Anticipated Answers: What do you think the best alternative is to fulfill the requirement of adding additional capacity to the network? Click to the image which shows a server room and then ask the question (what if you needed to expand server capacity by 10% and have no idea how the current servers are organized)? Now what is the best option? Then click to the final image to drive the point that it may be less cost effective to recreate the architecture. Another point is that it takes $$$ to maintain your architecture so ensure you figure that into your budget. I also like to bring out the point that architecture is great for communicating “What-if” scenarios. Terms \ Definitions \ Acronyms: NOTE: There are several images that are displayed which can only be seen in presentation mode. Architecture

9 ELO 8.1.1.8 Describe the Joint Information Environment (JIE)
Lesson Plan Status Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: An overview of the key parts of this lesson Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

10 Managing by Architecture
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the purpose of Enterprise Architecture (EA). ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The DoD intent is to get to the point where we can “Manage by Architecture” Architect is the technical expert who translates the decision-maker’s requirements into a set of data that can be used by engineers to design possible solutions. Working with the architect and team, the decision-maker has a critical role in ensuring that the architecture not only supports the creation of executable requirements that will achieve the desired outcome, but also that senior executives and managers can view the desired solution in an understandable and logical manner The architecture can then be used by the decision maker to see redundancy, opportunity, risk, and the impact of decisions on the enterprise MT 4.2 Enterprise architecture is one of the most powerful decision-making tools available to organization leadership at all levels. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

11 Architecture Products in Acquisition Process
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide shows the Acquisition Process and what views of our Architectures are needed throughout the life cycle. Note that the architecture products are recursive and iterative, as a program updates design the architecture must be updates. The ISP is updated prior to the JCIDS document, and should be a tool for the program office. A way to describe this process is: To discuss the process of building a house. The Architect does the initial drawings, then the builder will make required practical building changes as he/she builds the home, and the drawings will need to be updated as changes are approved by local “building code” engineers Note the Latest DODI 6212, March 2012 mandated significantly increases architecture requirements for each milestone. The new requirements is this document SHALL be used by all programs (6 months after instruction signed which is September 2012). Additionally, DODI , 7Jan2015 references using Open System Architectures (OSA), being compliant with cybersecurity architecture and DoD Information Enterprise Architecture (IEA), wtc Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: REFERENCES: DoDD , DoDI , DoDD , DoDI , CJCSI H, DoDAF 2.0 Architecture

12 DoDAF 2.0 Vision Views for Other Stakeholders
Structured Knowledge Base—Common Model Views for the Architect SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: DODAF 2.0 provides the framework for every level of architecture. DODAF views are primarily for the Architect. The Architect will use this framework to develop views which satisfy the customer requirements. Leaders and other users will pull data from the architecture to help them manage risk. Examples include: Allow resource managers at Service staff (PPBE process) to understand impact of canceling a program; Allow program offices to “discover” NDI systems to meet functional needs, etc. The architecture will be developed in a common data format (DM2 – DODAF Meta Model) to allow for a Common Modeling across the entire DoD enterprise. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: “Key process owners will decide what architectural data is required, generally through DoDAF-described Models or Fit-for-Purpose Views. However, other regulations and instructions from the DoD and the CJCS have particular presentation view requirements.” *DODAF 2.02 Architecture

13 Questions? Why do we need an architecture?
Tool in decision making (e.g., identify risk) What is the purpose of our architecture? “We” define the purpose—if you don’t know what you are going to use it for, there is a good chance it won’t be useful Identify and understand the different purposes of different stakeholders SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Self explanatory … meant to be a discussion of the value of architectures. The picture shows how the users would like the disconnected architectures to be seamless within the enterprise. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Some background information: Federated Architecture: A loosely coupled collection of information assets that accommodates the uniqueness and specific purpose of disparate architectures which allows for their autonomy and local governance while enabling the enterprise to benefit from their content. It provides an approach for aligning, locating, and linking disparate architectures and architecture information via information exchange standards to deliver a seamless outward appearance to users. (Global Information Grid Architecture Federation Strategy, Version 1.2, August 1, 2007). Integrated Architecture: An architecture where architectural data elements are uniquely identified and consistently used across all products and views within the architecture (DoDAF). Architectures can be expensive to build so it doesn’t make sense to build if you don’t plan to use it! Architecture

14 A View of the DoD Enterprise Architecture
Solution Architectures Guided and constrained by the architectures that make up the DoD EA SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide shows the levels of architecture. - The Enterprise Architecture (EA) provides the leadership vision. There can be several enterprises (e.g. DoD, Navy, Army, USAF, etc.), but every subordinate EA will tie into the higher level EA. - Segment Level Architectures provide the capability level (e.g. WMA, etc.) - Solution Architecture is lead by Programs to reflect the system or SOS that satisfy current capability needs/requirements. DoD Enterprise Architecture: Now, while the discipline of enterprise architecture was introduced largely in the area of IT, DoD EA provides guidance on a wide range of topics. Throughout the Department, enterprise architecture (and, thus, parts of the DoD EA) describes the enterprise rules for managing information, people, process, assets, and resources along with supporting IT and non-materiel solutions. Thus, DoD EA is used in many ways as an overall blueprint of DoD operations. This intertwining of IT and overall core process is not surprising in today’s world in which it is difficult to separate the functioning of core operations from managing the underlying information that supports them. The graphic shows that the DoD Enterprise Architecture (DoD EA) is a federation of architectures that provide context and rules for accomplishing the mission of the Department. These architectures are developed and maintained at the Department, capability area, and Component levels and collectively define:(a) the people, processes, and technology required in the current and target environments, and (b) the roadmap for transition to the target environment. A DoD CIO-approved architectural process identifies segments (and segment architectures) for major DoD mission areas and cross-cutting services. The EA-Segments align, as shown in the horizontal “swim lanes” with nine Joint Capability Areas. DoD Components, indicated by yellow tabs along the bottom represent enterprises unto themselves, operating within the scope of the larger DoD enterprise. Each Component has Enterprise Architecture(s), which align with that maintained by each of the other Components, to jointly support DoD missions. Solution Architectures Systems/solution architectures are governed by a set of enterprise architecture reference models. A Solution Architecture is a structure which depicts: the system’s elements, the externally visible properties of those elements, and the relationships among the elements. Solution Architectures are built and maintained by Program Managers, Program Executive Officers, or similar managers responsible for implementing a capability as a system, a service, a system-of-systems, or a family-of-systems. Each Solution Architecture describes a capability, system/service, and investment managed by the Department’s core decision-making processes (such JCIDS and the DAS). Solution architectures have been developed for hundreds of DoD systems over the last two decades. However, developing them in better alignment with a more complete DoD Enterprise Architecture will enable a marked improvement in interoperability, minimizing debilitating gaps and overlaps between solutions. Solution Architectures are not part of the DoD EA, but they are shown to the right of the diagram to indicate that solutions are guided and constrained by the architectures that make up the DoD EA. They play a key role in the DoD acquisition processes in that architecture-enabled solutions facilitate improved interoperability, better information sharing, stricter compliance, leaner processes, and result in reduced costs and more effective mission accomplishment. Solution Architecture viewpoints provide key components of the Capability Development Document (CDD) and Capability Production Document (CPD) to ensure DoD understands the linkages between capabilities and systems and can make appropriate acquisition decisions; and the performance attributes, including key performance parameters (KPPs) and key system attributes (KSAs), that define the most critical elements of performance for the systems under development.

15 DoD Business Enterprise Architecture
The BEA is the enterprise architecture for the DoD Business Mission Area Reflects DoD business transformation priorities; Business capabilities required to support those priorities; Enterprise systems and initiatives Supports use of information within an End-to-End (E2E) framework SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The DOD Business Enterprise Architecture is an EA example. Overview The BEA is the enterprise architecture for the DoD Business Mission Area and reflects DoD business transformation priorities; the business capabilities required to support those priorities; and the combinations of enterprise systems and initiatives that enable those capabilities. It also supports use of this information within an End-to-End (E2E) framework. The purpose of the BEA is to provide a blueprint for DoD business transformation that helps ensure the right capabilities, resources and materiel are rapidly delivered to our warfighters – what they need, when they need it, where they need it, anywhere in the world. The BEA guides and constrains implementation of interoperable defense business system solutions as required by the Section 2222 of Title 10 United States Code. It also guides information technology investment management to align with strategic business capabilities as required by the Clinger-Cohen Act, and supports Office of Management and Budget (OMB) and Government Accountability Office (GAO) policies. BEA 10.0 aligns with DoD Architecture Framework (DoDAF) 2.0 naming conventions and is comprised of a set of integrated viewpoint products. The viewpoints display capabilities, activities, processes, data, information exchanges, business rules, system functions, services, system data exchanges, technical standards, terms, and linkages to Laws, Regulations and Policies (LRP). The Strategic Management Plan (SMP), Functional Strategies as developed by the appropriate DoD Principal Staff Assistants and the Organizational Execution Plans (OEP) as developed by DoD Components are the drivers of BEA release content. The SMP sets the strategic direction for the department's business operations. The transformation effort guiding BEA development continues to focus on SMP alignment, providing tangible outcomes for a limited set of priorities, and developing architecture that is integrated, understandable and actionable.

16 Enterprise vs. Solution Architecture
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide shows the levels of architecture. And their relationships to Scope, Detail, Impact and Audience involved. Below is a Global Hawk article that talks about the goals for a future (“To-Be”) capability. The solution architecture will inform, guide, and constrain the vision to help the PM / PMO manage and achieve the capability. This discussion can be a good transition into the next slides that show how the architect with a team of users/warfighters, key PMO and technical people will build the architecture. New Global Hawk ground segment could enable greater commonality August 25, 2016 | Courtney Albon  Raytheon's plans to upgrade the Air Force's Global Hawk ground control segment with a more modular, open architecture could facilitate a more common ground architecture for unmanned air platforms across the services. The company this week won a contract worth $104 million to modernize the Global Hawk's ground control segment. The legacy system was built in the 1990s. Bob Dehnert, Raytheon's senior director of command, control and awareness, told Inside the Air Force this week that the system's replacement will have a smaller footprint, a more flexible design and a more robust cybersecurity framework. On flexibility, Dehnert said the company designed a service-oriented architecture for the new ground station that is very similar to the Navy's common control system. The design would allow the service to more easily integrate new sensors and capabilities -- a critical feature for the Global Hawk, which has a plan to integrate a number of new sensors over the next several years. Today, integrating and testing a new sensor can require an extensive flight plan, but that time line will be condensed with the new ground segment. "We're designing the system and building it such that it can relatively seamlessly take these new adds and integrate them into the new system," Dehnert said in an Aug. 25 interview. But beyond sensor integration, the system's open architecture could allow the service the flexibility to operate multiple types of unmanned aerial vehicles from a common ground system -- a concept the Navy is moving toward adopting with Raytheon as its contractor. The Air Force does not have a requirement under this contract for commonality, Dehnert said, but the possibility for a common system in the future is inherent in its open design. Dehnert said he thinks it is likely the Pentagon will pursue more commonality among UAV ground segments in the future, and while it's unclear whether the commercial or government world will lead the way, he thinks it's an eventuality -- both from a practical and technological point of view. "From a cost perspective, it is wise for the country to head that way," he said. "[The Office of the Secretary of Defense] talks about this as a desirable roadmap, and technically we're building that future. It's just a byproduct of having built an architecture for the Navy that has great commonality with the Air Force as well." Raytheon's new ground segment will also be much smaller than the legacy system, shrinking nine racks of processors down to two. Currently, pilots and crews operate the aircraft from trailers that are loud and large. The new stations will be housed inside of buildings, either new or existing, which Dehnert said will significantly improve the user experience. The program is currently working to develop a development schedule and a fielding plan, and Dehnert said that should be completed by the end of the year. The contract runs through 2019 and the plan is to deliver the new systems to operational units at Grand Forks Air Force Base, ND, and Beale Air Force Base, CA. Edwards Air Force Base, CA, will also receive a new system for testing. -- Courtney Albon If your architecture work is about cross-organizational and/or strategic integration and/or standardization, then it is Enterprise Architecture If your architecture work is aimed at addressing specific problems and requirements, usually through the design of specific systems or applications, then it’s Solution Architecture. Think of city planning vs. designing and building a skyscraper. Graphic adapted from Wikipedia at

17 Example Capability Management Questions
Required Data Types Viewpoints How do the capabilities relate to enterprise strategy and goals? Vision Goals Desired Effects Capabilities Relationship between capabilities and goals Capability Vision (CV-1) Are there dependencies among the capabilities? Relationships among capabilities, including dependencies Capability Dependencies (CV-4) How will capability performance be measured? Performance Measures Relationships of capabilities to performance measures Capability Taxonomy (CV-2) SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: These are example questions and where the architect would get the information to develop architecture regarding capabilities Key Questions to Ask and Anticipated Answers: What is the purpose of the Capability Viewpoint? Answer: Describe the capability vision, goals, desired effects and relationships with other capabilities. Terms \ Definitions \ Acronyms: Architecture

18 All Viewpoint (AV) Provide information pertinent to the entire Architectural Description rather than representing a distinct viewpoint Contains two models AV–1—Overview and Summary Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects AV–2—Integrated Dictionary Architectural data repository with definitions of all terms used throughout the architectural data and presentation SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the purpose of for the the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slides is part of taking a closer look at some of the DODAF views and their intended use All Views – AV1 – Leaders key view to outline vision, goals etc AV-2 – Dictionary to describe meaning of data. This is important for folks who may need to access data as different terms have different meanings. For Example: MDA MDA – Missile Defense Agency MDA – Maritime Domain Awareness MDA – Milestone Decision Authority MDA – Muscular Dystrophy Association Or Tank – For Army it is a armored, tracked vehicle Tank – for AF it is an airplane that provides gas to other airplanes. Tank – for Navy it is a void in the ship designed to hold water, fuel, ballast, etc. Key Questions to Ask and Anticipated Answers: What is the purpose of the AV? Answer: Provide information pertinent to the entire Architectural Description rather than representing a distinct viewpoint Terms \ Definitions \ Acronyms: Architecture

19 What information do they exchange (Operational IERs)?
Architectures To Document Mission Threads DoDAF Operational Viewpoints (OV) Who are the players? What information do they exchange (Operational IERs)? What they do with the information? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the purpose of for the the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This shows some of the operational views (or viewpoints or models) (NOTE: Architects will interchange viewpoint, view and model terms. For ease in instructing please be consistent and use viewpoint, however, if the question comes up … please just explain the terms are synonymous to an architect) commonly found in most architectural data bases. The operational models are used to define the operational requirements. For example: To understand and analyze a mission thread, you need a minimum amount of information describing the thread. This information includes: 1. Who are the players involved in the mission? (i.e. what commanders, units, platforms, etc.) 2. What information do the players need in order to accomplish the mission? 3. What actions do the players take in order to execute the mission? Mission architectures provide a convenient way to capture and display this data in a standardized format. Mission architectures have the additional benefit of making the data reusable for future efforts. If we look back at the pieces of data needed to describe the mission thread, they can be captured in the following architecture products: - The players in the mission thread can be captured in a OV-1 and OV-4. - The mission thread’s information exchanges can be captured in an OV-2 and OV-3. - And the actions needed to execute the mission can be captured in an OV-5 and OV-6c. Once the mission thread is described with this data, the mission can be analyzed to determine what services, applications, and hardware are required for mission completion. The mission can also be analyzed to determine the service, application, and system performance needed for mission success. This analysis can reveal gaps in current systems’ capabilities as well as overlaps in these capabilities. These gaps and overlaps can in turn be used to make program changes and investment decisions. Key Questions to Ask and Anticipated Answers: What viewpoint would be used to define the organization, what information the exchange and what they do with the information? Answer: Operational Viewpoint. Terms \ Definitions \ Acronyms: Architecture 19

20 Architectures to Describe Mission Threads DoDAF System Viewpoints (SV)
What system functions support the mission thread? How are the systems connected? How well do the systems perform? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the purpose of for the the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Once the user requirements are understood, the architect can begin to answer the questions related to systems. Key Questions to Ask and Anticipated Answers: What viewpoint would be used to map system functions to operational requirements, show how systems are /will be connected and document how well the systems perform? Answer: Systems Viewpoint Terms \ Definitions \ Acronyms: Architecture

21 Exercise to Build Architecture
Read Exercise 1 Material Develop Purpose for Architecture What architecture to be used for / Intent of architecture Develop OV-2 Performers (formerly Node) Based on scenario describe Information Needs between Operational Nodes Discuss how we can apply this information to decision making SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This exercise is used to develop an OV-2 model for JTAMS. Plan to lead a facilitated discussion with students how the model can be used to understand more about the user requirements and identify risks. At this point - Have the students read the exercise material, then work as a team to build the purpose for our architecture, then bring class together to build the operational performers on the white board and draw out the need lines. NOTE – these are exercise “answer” slides that the instructor can use to facilitate the students through to the solution Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Read JTAMS Overview Architecture

22 Stakeholder Issues Who are the Key Stakeholders for JTAMS?
What are some of the stakeholder issues from the scenario update? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This is meant to be a short instructor facilitated example of “Analysis” from the scenario update of how an architect would delve into what is essentially requirements analysis to build architecture. Understanding who are the stakeholders and what are their issues will help ensure we can describe the purpose of our architecture. Consider inserting the instructor solution slides here to help in your facilitated discussion. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Who are the Key Stakeholders for JTAMS?—Answer should include JCS, Army, Marine Corps, Air Force at a minimum … use your discretion for any others What are some of the key stakeholder issues (in the form of a question). There issues will be addressed in the CONOPS, use cases, etc. In the case of this exercise, we will draw on the scenario update. These questions below are some that I Will the new business processes and applications allows for the “just-in-time” logistics concept to be achieved? What types of logistics data are required? Who needs what data and who should provide the data? How do the new processes improve confidence in logistics? (Measures include speed, availability, and consistency of data) Lead short discussion on who are some of the stakeholders and could their issues / priorities differ. • Static Analyses – which could include capability audit, interoperability analysis, or functional analysis. These analyses are often performed using simple analysis tools such as paper-based comparisons and database queries. Architecture

23 What is the purpose of the architecture?
What questions need to be answered? Are there specific strategic objectives to be satisfied? Are there specific trade offs to be considered? What critical issues need to be addressed? How is the EA used to support key decision making processes? What types of analysis need to be supported? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Another key step for the architect is to understand the purpose of the intended architecture. In the students case, they are representatives of the JTAMS Program Office, so they will be building a solution architecture (build on the slide). Ask the students what they would like their architecture purpose to be. A program office would do analysis to determine the purpose of their architecture. At this point, they will need to conduct a Static Analysis—to capture Information Needs The graphic should help them focus on one of the aspects of the architecture is to develop a solution architecture (that aligns with higher level architecture) Remember they should challenge the Architect to develop architecture models to help them build a system that will serve the users and manage their program risk. DODI states: “A program’s solution architecture should define capability and interoperability requirements, establish and enforce standards, and guide security and cybersecurity requirements.” Schoolhouse answer is: The purpose should be to develop a solution architecture which will: Define logistics business processes for JRATS Define Capability Requirements Provide guidance for the acquisition of the set of applications and common database to support these upgraded business processes Supports decision making in key risk areas (e.g. cost, interfaces, immature technology, re-use, etc.) Manage LC Cost (e.g. Open System Architecture) Provide interoperable system Guide Security and cybersecurity requirements Use this as an opportunity for learning discussion: Ask student’s Why is purpose important? Architecture is a tool to support decision making If you don’t know what you are going to use it for, there is a good chance it won’t be useful You need to identify and understand the different purposes of different stakeholders Architectures can be expensive to build Doesn’t make sense to build one if you don’t plan to use it! Architecture

24 Example Solution Architecture Question
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Next couple of slides are intended to help students understand which architecture products are needed to meet our purpose. An architect will focus on answering key operational questions and data types through a series of Operational Views (OV) Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

25 JTAMS OV-1 SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This high level OV-1 is given in the scenario update. This is one of the most seen architecture viewpoints and is intended to give a “General Officer (G.O.)” level “picture” of the system; however this viewpoint is not a model. It is useful as a general overview on the concept of operations … Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

26 JTAMS OV-2 SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: - ***INSTRUCTOR SLIDE ONLY*** – Recommend building OV-2 on white board … have students find Operational Performers from scenario update. Then discuss information needs for each Need Line (NL) The OV-2 depicts the operational performers within JRATS program, with the JTAMS Operational (Joint Maintenance) performer as the focus. Army management is an external performer, depicted in burnt orange oval, while all other performers are internal to JRATS depicted by light green ovals. The Need Lines are used to describe the information needs to support operations between the operational performers / nodes. NL_1 and NL_2—Health of JUGV, Location of JUGV, etc. NL_3 and NL_4—Operational status (e.g. FMC, PMC, etc.) of JUGV, FUAV, parts, Estimated Time to Repair (ETR), etc. NL_5 and NL_6—Parts requisitions, parts status, maintenance records, etc NL_7 and NL_8—Health of FUAV, Location of FUAV, etc Once develop OV-2—Ask Students What risks can be identified from this model? E.g discuss the importance of using architecture to assess risks and define requirements. You could Ask students to describe what Engineers can learn from OV-2, potential answers: Define system requirements (e.g. bandwidth) Define interface requirements Refine IA requirements Define additional risks Etc. What is useful from this model for SE our system? System of systems? (Lead in to next slide discussion of systems views) Architecture

27 Example Solution Architecture Question
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide reflects the Architects questions and data types that will be documented in the service or system level views. The questions should be a natural lead in to the next slide and continued discussion of how the architect will build systems views from the operational views to help the program office manage risk. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

28 Relationships Between OV–2 and SV–1 (SvcV–1) Put IT in Context with Mission Operations
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This is a notional graphic, which should be used to show how the architect will relate operational views to systems views … in this case OV-2 to SV-1 This is a good slide to show how the operational performers host systems. So the work they did building the OV-2 (in the exercise just finished) is now used to build systems and interfaces. Point out interfaces between system locations as this shows how the architecture can be a tool to identify risk so we can manage it. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

29 Model: StdV–1 Name: Standards Profile Product Definition:
Rules that govern System Implementation and Operation Technical Standards that apply to the Architecture Additional Considerations: Time-phased to allow for: Emerging Technologies Technology Evolution Focus on relevant Services within Service Areas SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Technical standards that apply to the architecture. DoD Architecture is foundation for GIG?? Standards View is formerly called Technical View. It will appear as a spread sheet that outlines current and emerging standards. A good way to describe is by using Beta versus VHS … as commercial industry coalesced around VHS it became the standard. A more recent example would be HD-DVD versus Blue Ray. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

30 Standards Profile Identifies Implementation Criteria That Govern the Given Architecture
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the application of a set of architectural data used within the acquisition process. ELO Diagram one of the following: “All, Operational, System, and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Identify the purpose for the DoD Architecture Framework (DoDAF) “All, Operational, System, Services and Standards Views”. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Standards profiles are used to put “constraints” on system and Identifies Implementation Criteria That Govern the Given Architecture Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

31 “Fit for Purpose” Architecture Descriptions
SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the purpose of Enterprise Architecture (EA). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Use this slide to tie together why we are doing enterprise architectures is to provide data to allow decision makers to make better risk decisions … the architecture data could be used in PPBE to reduce redundancy, JCIDS Capability Based Assessments (CBA) to identify capability gaps, or Defense Acquisition System (DAS) to architect system. MT 4.2 Enterprise architecture is one of the most powerful decision-making tools available to organization leadership at all levels. MT 4.3 Enterprise Architecture Primary Purpose ‐ to inform, guide, and constrain the decisions for an enterprise, especially those related to Information Technology investments. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Additional Information: Fit-for-Purpose Views are user-defined views of a subset of architectural data created for some specific purpose (i.e., “Fit-for-Purpose”). While these views are not described or defined in DoDAF, they can be created, as needed, to ensure that presentation of architectural data is easily understood within an agency. This enables agencies to use their own established presentation preferences in their deliberations. Allows for a custom view of the system / product or enterprise Shifting from Product-Centric to Data-Centric Focus. Both the prior versions of DoDAF and earlier C4ISR versions of the Architecture Framework have emphasized reusable and interoperable data organized into ‘products’ (e.g., graphical representations or documents). DoDAF V2.0 places its emphasis on utilizing architectural data to support analysis and decision making, and greatly expands the types of graphical representations that can be used to support decision-making activities. (DoDAF 2.0 Volume 1, P 17) DoDAF-described Models (also referred to as Models) are created from the subset of data for a particular purpose and are fully explained in DoDAF V2.0, Volume 2. Once the DoDAF-described Models are populated with data, these “views” are useful as examples for presentation purposes, and can be used as described, modified, or tailored as needed. The Models described in DoDAF, including those that are legacy products from previous versions of the Framework, are provided as pre-defined examples that can be used when developing presentations of architectural data. DoDAF is prescribed for the use and development of Architectural Descriptions in the Department. Specific DoDAF-described Models for a particular purpose are prescribed by process-owners. All the DoDAF-described Models do not have to be created. DoDAF V2.0 is “Fit-for-Purpose”, based on the decision-maker needs. DoDAF concentrates on data as the necessary ingredient for architecture development. If an activity model is created, a necessary set of data for the activity model is required. Key process owners will decide what architectural data is required, generally through DoDAF-described Models or Fit-for-Purpose Views. However, other regulations and instructions from the DoD and the Chairman, Joint Chiefs of Staff (CJCS) have particular presentation view requirements. These views are supported by DoDAF V2.0, and should be consulted for specific view requirements. The architectural data described in DoDAF V2.0 can support many model and view requirements and the regulations and instructions should be consulted for those specific requirements. Architecture

32 Modular Open System Approach (MOSA)
DoD's definition of open systems is a system that has these 5 key principals: Employs modular design Enterprise investment strategies Lower development risk through transparency Transformation of the life cycle sustainment strategies — Technology Insertion Strategic use of data rights SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Modular Open Systems Approach (MOSA). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Open System Architecture (OSA) – The DoD intends that every program will apply a business analysis to the decision on open technical standards. In other words, we want to pay for data rights that we need to sustain a program, and not for ones we don’t need. OPPORTUNITY TO DOCUMENT THE OPEN SYSTEMS MOVING FORWARD --- RELATE TO MRES AND HOW IT APPLIES IN DESIGN LESSON DODI , 7Jan2015 says: “Program managers are responsible for applying open systems approaches in product designs where feasible and cost-effective. Open systems and modular architectures provide valuable mechanisms for continuing competition and incremental upgrades, and to facilitate reuse across the joint force. Program management will use open systems architecture design principles to support an open business model” Key Questions to Ask and Anticipated Answers: Name FIVE (5) CORE OSA IMPLEMENTING PRINCIPLES: BUSINESS (Culture of Competition) Strategic use of data rights to ensure a level competitive playing field and access to alternative solutions and sources, across the life cycle (Open Design Disclosure). Enterprise investment strategies, based on collaboration and trust, that maximize reuse of proven system designs and ensure we spend the least to get the best; (Analysis to determine which components will provide the best return on investment (ROI) to OSA, i.e., which components will change most often due to technology upgrades or parts obsolescence and have the highest associated cost over the life cycle) Dramatically lower development risk through transparency of system designs, continuous design disclosure, and Government, academia, and industry peer reviews; TECHNICAL Modular designs based on standards, with loose coupling and high cohesion, that allow for independent acquisition of system components; i.e., composability (independent modules) Transformation of the life cycle sustainment strategies for software intensive systems through proven technology insertion and product upgrade techniques Terms \ Definitions \ Acronyms: Architecture Architecture is the structural relationship between some set of elements. In OSA, the system architect and systems engineer uses architecture to manage elements called modules and their interfaces guide the design activity and assess a systems 'openness'. Architecture is not the same as an architecture description, which is the documentation representing a system's architecture at some point in time. Architecture descriptions form a portion of a system's technical baseline. From a systems engineering perspective, it is common to think in terms of two architectural baselines. • The design architecture which defines structural relationships between system components. • The functional architecture which defines the structural relationships between system functions, and Business models may also influence a system's architecture Modules A module defines a boundary around some portion of a system that needs to be isolated for some set of concerns. A module can: • Encompass an entire system or just a portion • Be simply a partition of some system functionality • Contain other modules (or sub-modules) to represent the hierarchy of the logical building blocks that form the system • Be described as 'composable' packages of functionality A module may represent either a physical system element or a logical partition. A physical module usually is directly associated with a particular component and its implementations. However, a logical module does not imply a particular type of implementation. The implementation details are not specified and may be hardware, software, human, or a composite of each. Architecture reference models generally describe a high-level design pattern or abstract design template for some class of systems. They define a common conceptual framework for some purpose and typically include: • Design constraints • Metrics for evaluating conforming products and implementations (reference ISO/IEC 9126), and • A vocabulary of related terms and concepts When reference models must permit some variation, such as is needed to support product-line approaches, they usually include both mandatory and optional constraints. Reference models are usually formalized on a consensus basis by a consortium or some other domain of interest. Reference models facilitate communication and collaboration between stakeholders of the domain. MOSA is a strategic “Business and Technical” acquisition approach that leverages the commercial market-place in a way to control and optimize design features to ensure that a level-field of competition provides the best valued product for our war-fighter. Architecture

33 Why How What Modular Open Systems Goals Approaches
Interoperability Approaches Modular Technical Design Approaches Design severable modules Define interfaces between modules Publish consensus-based standards Define, standardize & describe data models Open System Business Approaches Use open standards & specs for interfaces Recognize the relevant technical community Acquire necessary data & license rights Modular Design Tech Refresh Defined Interfaces Competition Standards Process SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Modular Open Systems Approach (MOSA). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: To be successful, here is a proposed implementation path for a modular, open systems approach that will ensure it is aligned with enterprise goals. First is the goal of interoperability. Adopting a modular technical design and possibly, an open system approach enables severable software and hardware modules to be changed independently of each other, and independently from the system in which they reside. Additionally, the focus on interoperability allows Components (and system stakeholders) to share & exchange technical data consistently using defined data exchange models. Interoperability also allows Systems (and software applications) to access & provide data and services using open interface definitions between components. Next, Technology Refresh. Adopting a modular technical design and possibly, an open system approach: Technical flexibility for rapid and effective technical upgrades of systems, effectively allowing our systems to maintain currency to the active threat in the area of interest. In this manner, delivery of new capabilities or replacement technology can be realized without rebuilding the entire system. Third is Competition. This has been one of the most cited reasons for an Open Systems approach. Adopting a modular technical design and possibly, an open system approach enables platform and vendor independence when hardware (and software) implement open industry standards; i.e., reduce vendor lock. Severable modules can be openly competed and portable components with open specifications or standards for interfaces, services, and supporting formats to be competed across a wide range of systems from one or more suppliers Innovation is also a goal of MOSA. Adopting a modular technical design and possibly, an open system approach enable Commercial flexibility to achieve value and innovation in procurement. As an example, 3rd party developers can now offer SW development kits (SDKs) and system development tools that include source code & documentation in order for the innovation to be accomplished organically, and provide operational flexibility to configure and reconfigure available assets to meet rapidly changing operational requirements Finally, Cost Avoidance/Cost Savings. Adopting a modular technical design and possibly, an open system approach can enable less expensive modifications, without redesigning hardware or software. Adoption of open approaches encourages the reuse of technology, modules and/or components from any supplier across multiple uses, across multiple platforms, at almost any point in the acquisition lifecycle. The Blue highlight in the “how” column indicates these are primarily business actions, vs. technical Accessible Data Innovation Open Interfaces IP Rights Cost Savings Supporting the goals for MOSA implementation are methods, processes and tools which underpin the approach

34 DoD Information Technology Standards Registry (DISR)
Online repository for a minimal set of primarily commercial IT standards. Describes current technical standards and emerging standards Can be used to populate the Standards Models (StdV–1 and StdV–2), conversely, the Standards Models can identify additional or new standards that need to be added to DISR. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). *Policy / Directive / Standard / DTM ID: DoDD , 21 May 2004 ********************************************************************************************************************************************************** Key Points: DISR is Online repository for a minimal set of primarily commercial IT standards. (NOTE: DISR Online is hosted on the GTG-F website – see link at the bottom of the slide) DISR describes current technical standards, as well as emerging standards. GTP (GIG Technical Profile) The DoD IT Standard Registry (DISR) module allows a user to search for standards and to submit date change requests. DISR will reduce cost, development and fielding time for DoD systems. Its use is mandatory for all system upgrades and emerging systems. DISR puts you on the road to interoperability, it does not guarantee interoperability. Key Questions to Ask and Anticipated Answers: What does it mean to have emerging standards for your program? E.g. Beta versus VHS were both emerging standards, eventually VHS became the standard Where would I use the DISR-online? If I was developing a systems that published information on terrorists I may go to the DISR-online and check if there is any existing standards for publishing terrorist information. It just so happens there is a “Terrorist Watchlist Person Data Exchange Standard (TWPDES)." After analyzing the standard, if it fits my data needs, I may use this standard vice developing a custom exchange standard. Terms \ Definitions \ Acronyms: DISR Puts you on the ROAD to Interoperability; DISR does NOT Guarantee interoperability! Architecture

35 Information Support Plan (ISP)
Purpose: used by program authorities to document IT needs, objectives, and interface requirements in sufficient detail to enable testing and verification of requirements. Enhanced Information Support Plan (EISP) “Tool”: Formats ISP. Captures the architecture data describing the critical Information Exchange Requirements (IER). Critical IERs need to be managed like any other aspect of a program. Identify and demonstrate the risk mitigation of those IERs. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the benefits to the enterprise of the Information Support Plan. ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide provides Background information on the ISP and EISP tool as an introduction for the Practicum MT 6.1. The Information Support Plan (ISP) is a tool to manage interoperability. MT 6.2. The DODAF view goals and content provide the ability for the program to manage risk and lead to interoperability. MT 15.2 GTG-F is the repository for the Information Support Plan (ISP) for every DoD program. MT15.4 The Program Manager’s Portal (PM-P) module allows a user to create, edit or view Information Support Plans (ISP) using the Enhance ISP (EISP) wizard, create, edit or view standard viewpoints using the StdV wizard and submit for a programs interoperability documentation (ISP, architecture products) for assessment. MT15.7 The Interoperability and Supportabiliy Assessment Module (IAM) allows users to conduct the ISP review process. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Below information is useful for understanding the purpose of the ISP Architecture: Purpose of ISP – The ISP is used by program authorities to document IT and NSS needs, objectives, and interface requirements in sufficient detail to enable testing and verification of requirements. The ISP also contains interface descriptions, infrastructure and support requirements, standards profiles, measures of performance, and interoperability shortfalls. The ISP is summarized in the Acquisition Strategy and reviewed at Milestones B and C. (DoDI and CJCSI F) (Source: DAU Glossary of Defense Acquisition Acronyms & Terms) The ISP shall describe system dependencies and interface requirements in sufficient detail to enable testing and verification of information technology (IT) and National Security Systems (NSS) interoperability and supportability requirements. The ISP shall also include IT and NSS systems interface descriptions, infrastructure and support requirements, standards profiles, measures of performance, and interoperability shortfalls. (Source: Manual for the Operation of the Joint Capabilities Integration and Development System, updated February 2009) ISP Review Process (a) The DoD Components shall lead the review of all ISPs regardless of ACAT level. If a program meets the criteria for a joint review listed below, the DoD Component shall coordinate the review with the joint community (including DISA). 1. For ACAT II and below programs, the owning DoD Component shall select the appropriate additional DoD Components for the joint review; however, the review shall include at a minimum the Joint Staff and DISA. 2. For all ACAT I and DoD CIO ISP Special Interest programs, the ISP shall be staffed to all DoD Components as part of a DoD-level joint review. The DoD CIO shall participate in ACAT I and DoD ISP Special Interest ISP reviews, and shall provide concurrence, concurrence with comment, or non-concurrence with the ISP for consideration by the DoD Component, MDA, or cognizant fielding authority for final approval. 3. The Joint Staff will no longer conduct Joint Interoperability and Supportability Certification for DoD Component IT and NSS. Final approval of an ISP undergoing joint review as outlined below satisfies the requirement for Joint Interoperability and Supportability Certification (paragraph of Reference (a)). DoD CIO shall participate in ACAT I and DoD ISP Special Interest ISP reviews, and shall provide concurrence, concurrence with comment, or non-concurrence with the ISP for consideration by the DoD Component, MDA, or cognizant fielding authority for final approval … Teresa Takai, DoD CIO Architecture

36 ELO 8.1.1.8 Describe the Joint Information Environment (JIE)
Lesson Plan Status Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: An overview of the key parts of this lesson Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

37 DoD Architectures SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: . *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Use this slide as a Lead in to the “head scratchers” (e.g. plethora of DoD architecture terms) “other” DoD Architectures and what do they mean to me?? The details will be covered during this lesson. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

38 Department of Defense Information Network (DODIN)
Department of Defense information network (DODIN) - The set of information capabilities, and associated processes for collecting, processing, storing, disseminating, and managing information on-demand to warfighters, policy makers, and support personnel, …, including owned and leased communications and computing systems and services, software (including applications), data, security services, other associated services, and national security systems. … JP 1-02 “The crossroad is now in our rearview mirror, and cyber security and defense and the DoD Information Network (DoDIN) are now a central part of our daily operations as the premier IT Combat Support Agency” … DISA Strategic Vision SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Department of Defense Information Network (DoDIN) is DISA’s new term for providing DoD Information Networks Key Questions to Ask and Anticipated Answers: There is some confusion about the GIG, DODIN and JIE. For now, the GIG remains policy and guides the technical architecture. The “JIE” is building toward its 5 major goals: Joint Network Identity Centric Architecture Data Center Consolidation Enterprise Services. , Collaboration and File Storage (i.e., Information Sharing) Joint Governance And DISA is still providing services through the DODIN. The first bullet is a link to an article on how DISA DISN services is now called DODIN. The 2nd bullets shows how DODIN is a central part of their strategic vision, and the picture is from a DISA press release on how they would like the GIG to be referred to as DODIN. NOTE: DAU should NOT get ahead of policy. Until the GIG instructions are superseded. The GIG remains the Technical Reference Architecture for the DoD Terms \ Definitions \ Acronyms: Architecture

39 Technical Architecture
GIG v2.0 Vision “… single coherent, secure, and consolidated information environment which represents a fundamental shift in how we design, implement, manage, operate, and maintain DoD information technology (IT) and network capabilities at all levels by focusing first on the technical, functional, and operational agility required by those at the tactical edge” (GIG 2.0 Operational Reference Architecture, V1.1, October 13, 2008) SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The DoD GIG ICD (see reference: JROCM , "Global Information Grid 2.0 Initial Capabilities document") is available on SIPRNET. The important point here is that the GIG is the Technical Architecture Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Technical Architecture Architecture

40 GIG v2.0 Provides a non-material solution to influence material solutions to transform the current federated GIG concept into a unified net–centric environment Developed incrementally over a period of years 5 Key Areas: Global Authentication, Access Control, and Directory Services Information and Services from the Edge Joint Infrastructure Common Policies and Standards Unity of Command SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The GIG Provides a non-material solution to influence material solutions… The GIG will be in a constant state of development. In layman terms, the GIG is the Department of Defenses internet which also serves and our enterprise architecture. We have a current state as well as a future state for the GIG. Mr. Dave Mihelcic (Chief Technology Officer and principal director, GIG Enterprise Services Engineering Directorate) said. “We want to expose information as broadly as possible. We want to move from this need to know to a right to know or need to share.” Key Questions to Ask and Anticipated Answers: What does the GIG provide? Answer: Provides a non-material solution to influence material solutions to transform the current federated GIG concept into a unified net-centric environment Terms \ Definitions \ Acronyms: Architecture

41 DoD Information Enterprise Architecture (DoD IEA) v 2.0
The DoD Information Enterprise Architecture (DoD IEA) is the authoritative capstone architecture that sets the operational context and vision of the Information Enterprise (IE) Provides a common, enterprise foundation to guide and inform IT planning, investment, acquisition and operational decisions Enables alignment of DoD architectures with the IE vision, drives enterprise solutions, promotes consistency and complements the IT Enterprise Strategy and Roadmap SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The Key Point is the DoD IEA is the DoD “Business Model” and it addresses a ―To Be vision 3–5 years in the future, and will influence the Program Objective Memorandum process DODI , 7Jan2015 states: “The DoD Information Enterprise Architecture will underpin all information architecture development to realize the Joint Information Environment. Program Managers must develop solution architectures that comply with the DoD Information Enterprise Architecture, applicable mission area and component architectures, and DoD Component architecture guidance. “ Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: “Provides a common DoD Information Enterprise foundation to support accelerated Department of Defense (DoD) transformation to net-centric operations. It presents the vision of net-centric operations and establishes near-term priorities to address critical barriers that must be overcome in order to achieve the vision.” ( DoD IEA unifies the concepts embedded in the Department’s net-centric strategies into a common vision, providing relevance and context to existing policy. DoD IEA highlights the key principles, rules, constraints and best practices drawn from collective policy to which applicable DoD programs, regardless of Component or portfolio, must adhere in order to enable agile, collaborative net-centric operations. In today’s information environment the DoD IEA rules apply within the persistently-connected Internet Protocol (IP) boundaries of the Global Information Grid (GIG). Outside of these boundaries, the principles still should be considered, but the rules of the DoD IEA must yield to the state of technology, and the needs and imperatives of the Department’s missions. From the DoDIEA V2.0, P I has five goals where increased attention and investment will bring the most immediate progress towards realizing net-centric goals: • Provide the basis for an IE that better enables Warfighting, Business, and Defense Intelligence domain operations • Provide a traceable line-of-sight from strategic guidance to solution architectures • Provide direction for proper planning for transforming the DoD IT landscape • Enable more informed acquisition of resources • Effectively operate the resulting IT environment DoD IEA enables DoD decision-makers to have informed discussions on key issues driving evolution of DoD’s information environment. DoD IEA empowers DoD decision-makers across all tiers and portfolios (including Investment Review Boards and Capability Portfolio Managers) in managing the overall DoD Information Technology (IT) portfolio. Components will use DoD IEA to strategically align their programs and architectures with the enterprise net-centric vision. DoD IEA addresses a ―To Be vision 3–5 years in the future, and will influence the Program Objective Memorandum process. DoD IEA enables DoD decision-makers to have informed discussions on key issues driving evolution of DoD’s information environment. —“Business Model” Architecture

42 DoD IEA Concept Map The Mission Areas (Warfighting, Business, Intelligence, and Enterprise Information Environment) provide warfighting Operational Requirements. The warfighting Operational Requirements are transformed into IE Requirements. CIO Vision shapes the content of the IE. Capabilities are described through Activities that are performed. The Activities are the basis for defining the scope of what Services need be implemented. An important activity for the CIO is to specify, based on common enterprise-wide services and improved. interoperability, Enterprise-wide Reference Architectures. The Solutions are developed to meet mission needs. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The DoD IEA is intended to keep the “solutions” (systems or services) aligned to the original Operational Requirements and the CIO (enabling) Vision. DoD IEA Concept Map The Mission Areas (Warfighting, Business, Intelligence, and Enterprise Information Environment) provide warfighting Operational Requirements. The fulfillment of successful operations is measured against those requirements. The warfighting Operational Requirements are transformed into IE Requirements that the Enterprise Information Environment Mission Area must provide in order to facilitate meeting warfighting Operational Requirements. The warfighting Operational Requirements are also the justification for the need for Capabilities from the IE. The consolidated set of IE Requirements becomes the driver for defining the IE and is the foundation of the DoD IEA. In addition, the vision for the future IE (the CIO Vision) shapes the content of the IE and the resultant documentation of that vision in the DoD IEA. The result is that the DoD IEA captures that vision and the evolution of the IE is managed through the DoD IEA. There are several ways of organizing the IE Requirements. Based on the desire to aggregate IE Requirements by separation of concerns and acquisition utility (i.e., alignment with the JCIDS Capabilities-Based Assessment [CBA] approach to acquisition), the organizing principle was to use Capabilities to define packages of IE Requirements. See Note1 for further discussion on the meaning of Capabilities in the context of the IE. Capabilities are described through Activities that are performed. The alignment of independent operational Activities to IE Capabilities provides users of the DoD IEA with an understanding of the Activities that need to be performed to enable that capability and the fact that some Activities are needed by multiple Capabilities. The Activities are the basis for defining the scope of what Services need be implemented to meet the IE Requirements. As noted previously, Activities are developed independently of Capabilities to optimize their use and reuse by one or more Capabilities. The alignment of Services to each IE capability provides users of the DoD IEA with a better understanding of the resources and associated processes needed to achieve each capability. This alignment is accomplished through associating Services with Activities that are required of, and implemented through, those Services. The alignment of principles and Rules to IE Capabilities provides users of the DoD IEA with a better understanding of constraints that have been imposed on achieving each capability. The alignment is accomplished through associating Rules with Activities and, subsequently, to Services. An important activity for the CIO is to specify, based on common enterprise-wide services and improved interoperability, Enterprise-wide Reference Architectures. CIO prescription or DoD Component Solution Provider needs for greater detail or guidance is the basis for the development of needed Enterprise-wide Reference Architectures that provide greater architectural detail for specific areas of the DoD IEA. Many times, Reference Architectures are organized around a capability or combination of Capabilities that are needed in the IE. Once the Reference Architecture is developed and approved it is considered a part of the DoD IEA and provides more detailed architectural content for application and compliance in relevant architectures. Under the direction of the DoD CIO, Strategic Plans for implementation of Capabilities are developed for evolution of the IE. Strategic Plans are the basis for Initiatives/Programs. In order to influence or prescribe how the IE Requirements are implemented in Solutions (i.e., constrain the capability specification), Reference Architectures may be directed as part of an Initiative/Program. The Initiative/Program, authorized by approved Plans, provides the programmatic direction for the development/production of Solutions. The Solutions are developed to meet mission needs in accordance with the IE guidance where applicable. “The DoD IEA will underpin all information architecture development to realize the JIE. Program Managers must develop solution architectures that comply with the DoD Information Enterprise Architecture, …“ DODI , 7Jan2015 Architecture

43 Service Oriented Architecture (SOA)
Definition—Service Oriented Architecture (SOA) is the body of standard design and engineering processes, tools, and best practices that leverage the modularity and composability of services to support objectives. Extends the EA and defines the implementation of the architecture in terms of its technical approach. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Service Oriented Architecture (SOA) – Services, like systems may be required to meet a requirement, and may be a cost effective and net-centric alternative to building another system (that must be sustained). What’s really great about SOA is it provides consistent access to any unit of work (yet it may not meet the requirements for all DoD users). Additional info: The key challenges of a cloud computing solution are security and quality aspects, including performance, latency, and availability. Integration, adaptation, agility, and the possible relocation of the solution play a major role during and after the implementation phase. These aspects can be addressed with an SOA-based architecture. (Indeed, some experts and analysts believe that SOA is a prerequisite for the cloud.) The National Institute of Standards and Technology (NIST) [REF-2] is the leading organization to define cloud standards. The integration challenge between clouds and how it can be addressed by SOA is one of the key areas. NIST defines the integration between the cloud and on-premise environments as cloud broker services DODI , 7Jan2015 states: “Cloud computing services can deliver more efficient IT than traditional acquisition approaches. Program managers will acquire DoD or non-DoD provided cloud computing services when the business case analysis determines that the approach meets affordability and security requirements.” Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Additional Information: The picture shows the Core Enterprise Services (CES). CES are a small set of capabilities whose use is mandated to enable interoperability and increased information sharing within and across Mission Area (Warfighter, Business, Defense Intelligence, and EIE) services. These services enable the secure enterprise-wide interactions between service consumers and providers, ensure that services and information are visible across the enterprise, and are instrumental in enabling SOA implementations to be constructed from services across the enterprise. CES provide SOA infrastructure capabilities such as service and metadata registries, service discovery, user authentication, machine-to-machine messaging, service management, orchestration, and service governance. In the target GIG, other notional examples of CES include candidates such as collaboration and policy services that enable new technologies, protocols and standards that are to be integrated into the existing environment. The CES also include definition and enforcement of the common service standards and rules that ensure networked joint capabilities and interoperability. The SOA Infrastructure includes a common, shared infrastructure for building services, including core services that enable the development of domain-specific and cross domain applications as SOAs, and enables services to be published and made visible, accessible, and consumable across the enterprise. The core services include IA services that support the necessary assurance capabilities to ensure the widest possible access is supported. These core services, within the common, shared infrastructure, allow users and information systems to find and bind relevant information, and expose the information they produce (post or publish) for others to discover. The common, shared infrastructure enables the exchange of information among information producers and consumers, while protecting the information from unauthorized access and use. Architecture

44 DoD IT Future: Joint Information Environment (JIE)
The JIE will be the trusted reference model and framework that will enable us to share information when needed, with any mission partner, regardless of location, device, or service provider. To achieve this goal: Transition from Network-Centric to Data-Centric solutions Rapid delivery and use of integrated cloud services accessible by all means from anywhere Interdependent information environment providing real time cyber situational awareness Scalable platform allowing flexibility and mission partnering Secure where it needs to be, resilient throughout, and appropriately consolidated JIE is not: Program of Record /Joint Program Office Turn key solutions Independent way of doing things SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: Use this slide as a transition. This slide is the beginning of a series of slides that will provide background to the latest DoD architecture related topics. JIE is comprised of shared Information Technology infrastructure, enterprise services and a single security architecture. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: The Joint Information Environment will be a secure, joint environment. The Link is a video of the DISA Commander discussing the JIE and the security architecture. It is 9 minutes long, but if there is time it provides a good reference for discussion. As the JIE Graphical illustration represents, it is comprised of shared Information Technology infrastructure, enterprise services and a single security architecture. It will help the DoD achieve full spectrum superiority, improve mission effectiveness, increase security, and realize IT efficiencies. The JIE will be operated and managed per the Unified Command Plan. This will be accomplished by using enforceable standards and specifications, and by following common tactics, techniques and procedures. JIE is not a program of record or a Joint Program Office and it will not deliver turn key solutions. Most importantly, as the JIE guiding principals will demonstrate, it is not an independent way of doing things. To realize a Joint Information Environment, we created a 7 step methodology to bring the Combatant Commanders, Services and Agencies together. JIE has 5 major goals: Joint Network Identity Centric Architecture Data Center Consolidation Enterprise Services. , Collaboration and File Storage (i.e., Information Sharing) Joint Governance JIE Graphical Illustration Architecture

45 Benefits of the JIE Provides Joint Force Commander a shared, secure information framework that delivers responsive, versatile and decisive actions on any device, anytime, from anywhere on the globe Provides near immediate communication with all Joint and Coalition partners on any device, anytime, from anywhere Cybersecurity Situational Awareness Reduced Cybersecurity Attack Surface (less places to attack and secure) Centralized Configuration Management A flexible, fused data-centric environment enabling access to information at the point of need (Smart Services) Ability to adapt and include new technology into the JIE easily, quickly and affordably SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Identify the benefits of the JIE *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: The Joint Information Environment will be a secure, joint environment. The Ocean Beach Pier sunset photo is a JIE video link discussing some of the JIE benefits including security architecture. It is 3 minutes long, but if there is time it provides a good reference for benefits discussion. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

46 NR-KPP Key Elements NR KPP process defined in 12 Feb 2015 JCIDS Manual
NR KPP certification defined in CJCSI G CJCSI F cancelled Still use the Wiki page: NR KPP Key Principals Defines three attributes focused on performance measures Incorporates MOE/MOP objective and threshold values No Tailored Information Support Plan (TISP) NR KPP architecture development methodology (copied DoDAF 6-step process). Requirement to align with DoD Information Enterprise Architecture, the current DoDAF, JIE and Joint Common System Function List (JCSFL) SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide is meant to show how the Net Ready Key Performance Parameters Key Elements are being addressed Compliant solution architecture – this s found within the context of the DODAF Architecture data. The requirement to comply with the Net Centric Data and Services Strategies remains, but is no longer part of the NR-KPP. For NR KPP purposes compliance verification information is provided by Data and Information Viewpoint (DIV)-3 (architecture product) submissions. GIG Technical Guidance (GTG) - exists in the ISP. DoD Cybersecurity requirement - exist as a AO responsibility. Supportability requirements - exists in the ISP but spectrum requirements compliance will continue to be analyzed within the refined NR KPP. The three key NR KPP attributes for certification are: IT must be able to support military operations. IT must be able to be entered and managed on the network. IT must effectively exchange information. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

47 NR KPP Attributes for Certification:
IT must be able to support military operations IT must be able to be entered and managed on the network IT must effectively exchange information SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide is meant to show how the Net Ready Key Performance Parameters Key Elements are being addressed Compliant solution architecture – this s found within the context of the DODAF Architecture data. The requirement to comply with the Net Centric Data and Services Strategies remains, but is no longer part of the NR-KPP. For NR KPP purposes compliance verification information is provided by Data and Information Viewpoint (DIV)-3 (architecture product) submissions. GIG Technical Guidance (GTG) - exists in the ISP. DoD Cybersecurity requirement - exist as a AO responsibility. Supportability requirements - exists in the ISP but spectrum requirements compliance will continue to be analyzed within the refined NR KPP. The three key NR KPP attributes for certification are: IT must be able to support military operations. IT must be able to be entered and managed on the network. IT must effectively exchange information. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: JMETL: Joint Mission Essential Task List JMT: Joint Mission Threads UJTL: Universal Joint Task List METL: Mission Essential Task List JCIDS Manual, 12 Feb 2015 , including errata as of 12 Jun 2015 Table D-E-1

48 CV-1, CV-2, CV-4, CV-6, OV-1, OV-5a OV-1, OV-2, OV-3, OV-5b
SV-7, SvcV-7 OV-5a&b OV-1, OV-2, OV-3, OV-5b CV-1, CV-2, CV-4, CV-6, OV-1, OV-5a AV-1, OV-6a SV-1 OV-2, OV-3, SV-6, SvcV-6 OV-2 32 SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This chart builds. Click #3 puts the circle around “Mission Analysis.” Ask the students which DoDAF products would document that. The next click reveals the box with the CVs in it. Do that sort of thing two more times. This slide is meant to show how the Net Ready Key Performance Parameters Key Elements are being addressed Compliant solution architecture – this s found within the context of the DODAF Architecture data. The requirement to comply with the Net Centric Data and Services Strategies remains, but is no longer part of the NR-KPP. For NR KPP purposes compliance verification information is provided by Data and Information Viewpoint (DIV)-3 (architecture product) submissions. GIG Technical Guidance (GTG) - exists in the ISP. DoD Cybersecurity requirement - exist as a AO responsibility. Supportability requirements - exists in the ISP but spectrum requirements compliance will continue to be analyzed within the refined NR KPP. The three key NR KPP attributes for certification are: IT must be able to support military operations. IT must be able to be entered and managed on the network. IT must effectively exchange information. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms:

49 Tell me how you fit in DoD.
Prove to me you’re in the JCA’s future plans. Prove to me you’ve thought out how we’ll operate this. Trace activities to capability fulfillment. Tell me how you’ll measure success or failure. Tell me how this system evolves (Evolutionary Acq). SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This chart builds. DODAF views supporting capability requirement documents. This slide is meant to show how the Net Ready Key Performance Parameters Key Elements are being addressed Compliant solution architecture – this s found within the context of the DODAF Architecture data. The requirement to comply with the Net Centric Data and Services Strategies remains, but is no longer part of the NR-KPP. For NR KPP purposes compliance verification information is provided by Data and Information Viewpoint (DIV)-3 (architecture product) submissions. GIG Technical Guidance (GTG) - exists in the ISP. DoD Cybersecurity requirement - exist as a AO responsibility. Supportability requirements - exists in the ISP but spectrum requirements compliance will continue to be analyzed within the refined NR KPP. The three key NR KPP attributes for certification are: IT must be able to support military operations. IT must be able to be entered and managed on the network. IT must effectively exchange information. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: JCIDS Manual, 12 Feb 2015, including errata as of 12 Jun 2015, Table D-1

50 What resources are flowing in/out of your system?
Teach me your language. Tie your business to its data. What are the key data and their important attributes? Prove to me you’re in someone’s portfolio. With who do you need interoperable interfaces? SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Given a scenario and determine which DoDAF views should be provided to support achieving Net-Ready Key Performance Parameter *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This chart builds. DODAF views supporting capability requirement documents. NR KPP Architecture Data and Associated Artifacts/Views This slide is meant to show how the Net Ready Key Performance Parameters Key Elements are being addressed Compliant solution architecture – this s found within the context of the DODAF Architecture data. The requirement to comply with the Net Centric Data and Services Strategies remains, but is no longer part of the NR-KPP. For NR KPP purposes compliance verification information is provided by Data and Information Viewpoint (DIV)-3 (architecture product) submissions. GIG Technical Guidance (GTG) - exists in the ISP. DoD Cybersecurity requirement - exist as a AO responsibility. Supportability requirements - exists in the ISP but spectrum requirements compliance will continue to be analyzed within the refined NR KPP. The three key NR KPP attributes for certification are: IT must be able to support military operations. IT must be able to be entered and managed on the network. IT must effectively exchange information. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: JCIDS Manual, 12 Feb 2015 , including errata as of 12 Jun 2015, Table D-E-4

51 CL Architecture-related Courses Include
CLE 012—DoD Open Systems Architecture CLE 041—Software Reuse CLE 068—Intellectual Property CLR 252 – Developing KPPs SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: These are CLE’s that the students can access for additional information about architectures. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

52 ELO 8.1.1.8 Describe the Joint Information Environment (JIE)
Today we learned to: Describe the Joint Information Environment (JIE) Identify the benefits of the JIE Recognize the application of a set of architectural data is used within the acquisition process. Recognize the relationship between Enterprise Architecture and a Solution Architecture. Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). Describe the Modular Open Systems Approach (MOSA). Describe the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F). Given a scenario and determine which DoDAF views should be provided to support achieving Net-Ready Key Performance Parameter Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). Recognize the importance to the enterprise of the Information Support Plan. SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Describe the Joint Information Environment (JIE) ELO Identify the benefits of the JIE ELO Recognize the application of a set of architectural data is used within the acquisition process. ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. ELO Diagram one of the following: “All, Operational, System and Standards Views” of the DoD Architecture Framework (DoDAF). ELO Describe the Modular Open Systems Approach (MOSA). ELO From a list identify the elements of the Global Information Grid (GIG) Technical Guidance-Federation (GTG-F)/DOD Information Technology Standards Registry (DISR). ELO Given a scenario, determine which DoDAF views support achieving Net-Ready Key Performance Parameter ELO Identify the five (5) key areas of the Global Information Grid (GIG) / DoD Information Network (DODIN). ELO Recognize the benefits to the enterprise of the Information Support Plan. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: An overview of the ELOs. Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Architecture

53 BACK UP SLIDES (TO BE REMOVED AFTER THE STUDENT PILOT)
Architecture

54 DODAF Flow from CBA to Capability Requirement Documents
JCIDS Manual, 12 Feb 2015, including errata as of 12 Jun 2015, Figure C-B-1

55 Solution Architectures
The term solution architecture refers to the architecture of the system (i.e., the "solution"). Solution architecture descriptions are the diagrams and data that describe the operational and technical requirements for the system and the design of the system. Solution architectural descriptions describe the system from various viewpoints. In DoD, programs are required to use DoDAF compliant solution architecture descriptions to document a system’s information exchange requirements and interoperability design. A system’s solution architecture is captured in its requirements documents, architecture views, and Information Support Plan (ISP) in textual, tabular, and graphical formats.

56 Viewpoints are models—not pictures.
DoD and Architecture Levels of Architecture DoDAF 2.0 Viewpoints SLIDE INFORMATION*************************************************************************************************************************** *Slide Type: Content (Content or Exercise) *Supporting ELOs ID: ELO Recognize the relationship between Enterprise Architecture and a Solution Architecture. *Policy / Directive / Standard / DTM ID: ********************************************************************************************************************************************************** Key Points: This slide shows the levels of architecture. - The Enterprise Architecture (EA) provides the leadership vision. There can be several enterprises (e.g. DoD, Navy, Army, USAF, etc.), but every subordinate EA will tie into the higher level EA. - Segment Level Architectures provide the capability level (e.g. WMA, etc.) - Solution Architecture is lead by Programs to reflect the system or SOS that satisfy current capability needs/requirements. DoDAF 2.0: is the latest DoD architecture framework … the key takeaway is DODAF 2.0 is the new framework that allows DoD to meet the Federal Architecture (Title 40 – formerly CCA) requirement, describe the who, what, how, etc for our enterprise / system. Views are models … not pictures is intended to illustrate the intent is to use the architectural data Models a semantic interpretation have standard – Rules for correctness and consistency Most DoDAF described models/views have a graphic template The graphic is backed up with dictionary entries (based on data entities and relationships from DM2): Data elements provide definitions and descriptions of items in the graphic plus Additional supporting information and relationships to other architecture elements The data elements integrate the set of views Views share data Architectural data described in DoDAF is not all-inclusive. Architectures may require additional data, and it is expected that architecture developers at all levels will extend the set of architectural data as necessary.(DoDAF 2.0 Volume 1, P 17) The DoDAF 2.0 has increased / changed the viewpoints to relate to a more specific collection of architecture related data. Architecture constructs originally described in the UK Ministry of Defense Architecture Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group Architecture Framework (TOGAF) are adopted for use within DoDAF 2.0 thus increasing international data exchange. Approaches to SOA development are described and discussed within DoDAF 2.0 . Key Questions to Ask and Anticipated Answers: Terms \ Definitions \ Acronyms: Viewpoints are models—not pictures. Architecture

57 Net-Ready KPP Development Process
Defense Acquisition Process Combat Developer (JCIDS Process) Step 1: Mission Analysis Step 2: Information Analysis Step 3: Systems Engineering Mission threads Operational activities Performance measures Networks Information Exchanges Performance measures System functions System architecture design Performance measures Document Architectural views Specifications Verification plans Architectural views are key to understanding, developing, documenting, and verifying interoperability requirements.

58 Open Systems Architecture
External Systems Employ modular design Loose coupling, tight cohesion Designate key interfaces Which interfaces will frequently need to change? Which interfaces impact future re-procurement/ competition? Use Open Standards Widely supported, consensus based standards Certify Conformance Develop verification & validation plans to confirm “openness” (plug ‘n’ play, etc.) System Limited use of proprietary standards


Download ppt "ISA 201 Intermediate Information Systems Acquisition"

Similar presentations


Ads by Google