ISA 201 Intermediate Information Systems Acquisition

1. ISA 201Intermediate Information Systems Acquisition

2. Lesson 9Architecture

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.. Architecture

4. Lesson Plan Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures 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 Architecture

6. Architecture Architecture

7. Question? What if we don’t have an Architecture for a existing system and want to make a modification? Architecture

8. What is the Best Option? Architecture

9. Lesson Plan Status Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures Architecture

10. Managing by Architecture Architecture

11. Architecture Products in Acquisition Process REFERENCES: DoDD 5000.1, DoDI 5000.02, DoDD 4630.5, DoDI 4630.8, CJCSI 3170.01H, DoDAF 2.0 Architecture

12. DoDAF 2.0 Vision • Views for Other Stakeholders • Structured Knowledge Base—Common Model • Views for the Architect “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? Architectures can be expensive to build so it doesn’t make sense to build if you don’t plan to use it! Architecture • 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

14. A View of the DoD Enterprise Architecture https://www.intelink.gov/wiki/DoD_CIO/DoD_EA Solution Architectures Guided and constrained by the architectures that make up the DoD EA

15. Enterprise vs. Solution Architecture • 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 http://en.wikipedia.org/wiki/File:Architectural_Levels_and_Attributes.jpg

16. Example Capability Management Questions Architecture

17. 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 architecturaldata and presentation Architecture

18. 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? Architecture

19. Architectures to Describe Mission ThreadsDoDAF System Viewpoints (SV) What system functions support the mission thread? How are the systems connected? How well do the systems perform? Architecture

20. Exercise to Build Architecture Read JTAMS Overview 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

21. Stakeholder Issues Who are the Key Stakeholders for JTAMS? What are some of the stakeholder issues from the scenario update? Architecture

22. 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? Architecture

23. Example Solution Architecture Question Architecture

24. JTAMS OV-1 Architecture

25. JTAMS OV-2 Architecture

26. Example Solution Architecture Question Architecture

27. Relationships Between OV–2 and SV–1 (SvcV–1)Put IT in Context with Mission Operations Architecture

28. 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 Architecture

29. Standards Profile Identifies ImplementationCriteria That Govern the Given Architecture Architecture

30. “Fit for Purpose” Architecture Descriptions Architecture

31. Modular Open System Approach (MOSA) 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 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

32. Modular Open Systems Why How What Goals Approaches Interoperability • 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 Defined Interfaces Tech Refresh Standards Process Competition Accessible Data Innovation Open Interfaces IP Rights Cost Savings Supporting the goals for MOSA implementation are methods, processes and tools which underpin the approach

33. DoD Information Technology Standards Registry (DISR) DISR Puts you on the ROAD to Interoperability; DISR does NOT Guarantee interoperability! https://gtg.csd.disa.mil/disr/dashboard.html Architecture 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.

34. Information Support Plan (ISP) 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 • 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.

35. Lesson Plan Status Architecture Basics (Video Homework) Enterprise Architecture in IT Acquisitions DoD Architectures Architecture

36. DoD Architectures Architecture

37. 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 Architecture

38. GIG v2.0 Vision Technical Architecture Architecture “… 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)

39. 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 Architecture

40. DoD Information Enterprise Architecture (DoD IEA) v 2.0 DoD IEA enables DoD decision-makers to have informed discussions on key issues driving evolution of DoD’s information environment. —“Business Model” http://dodcio.defense.gov/Portals/0/Documents/DIEA/DoD%20IEA%20v2%200_Volume%20II_Description%20Document_Final_20120806.pdf Architecture 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

41. DoD IEA Concept Map “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 5000.02, 7Jan2015 Architecture 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.

42. 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. Architecture

43. DoD IT Future: Joint Information Environment (JIE) • JIE is not: • Program of Record /Joint Program Office • Turn key solutions • Independent way of doing things JIE Graphical Illustration Architecture 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

44. 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 Architecture

45. NR-KPP Key Elements • NR KPP process defined in 12 Feb 2015 JCIDS Manual • NR KPP certification defined in CJCSI 5123.01G • CJCSI 6212.01F cancelled • Still use the Wiki page: https://www.intelink.gov/wiki/Net_Ready_Key_Performance_Parameter_(NR_KPP)_Manual • 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) Architecture

46. 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 JCIDS Manual, 12 Feb 2015 , including errata as of 12 Jun 2015 Table D-E-1

47. 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 AV-1, OV-6a 32 SV-1 OV-2, OV-3, SV-6, SvcV-6 OV-2

48. Prove to me you’re in the JCA’s future plans. Tell me how you fit in DoD. Trace activities to capability fulfillment. Prove to me you’ve thought out how we’ll operate this. Tell me how you’ll measure success or failure. Tell me how this system evolves (Evolutionary Acq). JCIDS Manual, 12 Feb 2015, including errata as of 12 Jun 2015, Table D-1

49. Teach me your language. What resources are flowing in/out of your system? Prove to me you’re in someone’s portfolio. Tie your business to its data. With who do you need interoperable interfaces? What are the key data and their important attributes? JCIDS Manual, 12 Feb 2015 , including errata as of 12 Jun 2015, Table D-E-4

50. CL Architecture-related Courses Include CLE 012—DoD Open Systems Architecture CLE 041—Software Reuse CLE 068—Intellectual Property CLR 252 – Developing KPPs Architecture