Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations

1. Lifecycle Modeling on the Cloud:An Approach to Simplified, Rapid Development, Operations, and Support Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations.com May 14, 2012

2. Overview • What is Cloud Computing? • Cloud Computing Implications for Systems Engineering • Lifecycle Modeling Language Overview • Suggested LML Processes • LML Tool Needs • Use of LML for Architecture • Use of LML for Systems Design • Use of LML for Software Development • Use of LML in Test and Evaluation • Use of LML in Operations and Support • Summary

3. What is Cloud Computing? Hint: It’s not just a website

4. What is cloud computing? • Definition from NIST: • Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012

5. Five Essential Characteristics • On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider. • Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). • Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. • Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time. • Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service. From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012

6. Three Service Models • Software as a Service (SaaS): The end user system • Platform as a Service (PaaS): Tools and services to create a SaaS Application • Infrastructure as a Service (IaaS): Full control of the software stack and services

7. Four Deployment Models • Private cloud • Operated solely for an organization • May be managed by the organization or a third party • Community cloud • Shared by several organizations • Managed by the organizations or a third party • Public cloud • Available to the general public or a large industry group • Owned by an organization selling cloud services • Hybrid cloud • composition of two or more clouds that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability

8. Normal Server Deployment App App App App Hardware 1) Two applications running under normal conditions 2) One application’s demand increased 3) Server crashed, both applications down

9. Virtualized Server Deployment 3) Added third server, extended virtual server App App 1) Two applications running under normal conditions App App 2) One application’s demand increased 4) Application’s demand increased 5) Application’s demand decreased 6) Hardware server crashes, virtualization continues Hardware Virtualization Hardware Virtualization Hardware Hardware Hardware

10. Net Cloud Virtualized Servers Disk Box 0 (Controller) App App App App Hardware Virtualization Layer Hardware Hardware Hardware

11. “Cloud-First” Policy “The Federal Government’s current Information Technology (IT) environment is characterized by low asset utilization, a fragmented demand for resources, duplicative systems, environments which are difficult to manage, and long procurement lead times. These inefficiencies negatively impact the Federal Government’s ability to serve the American public.” “Cloud computing has the potential to play a major part in addressing these inefficiencies and improving government service delivery. The cloud computing model can significantly help agencies grappling with the need to provide highly reliable, innovative services quickly despite resource constraints.”

12. From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012 13

13. Security must be addressed at each layer From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012 14

14. From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012 15

15. USG Approach to Cloud Authorization – Risk Based FedRAMP provides a means to ensure government use of the cloud is secure and minimizes costs to cloud providers IOC – June 2012 See http://www.gsa.gov/portal/category/102371

16. How Secure is the Cloud? • We are using Google App Engine for SaaS application development: • Proven Reliability: Google App Engine is one of the most secure enterprise services in the world • Multiple layers of physical and virtual security • Safer than most internal networks: With multiple layers of firewalls, sandboxed code, and software protection Google App Engine is more secure than most company networks

17. Advantages • Reduce the total number of independent servers • Individual applications are secured from one another (“Sandboxed”) • Servers stored at secure locations • Only accessible on the secure network • Inexpensive • Scalable

18. Disadvantages • Scalability means “no-SQL” out of the box • SQL Databases are designed for single servers or small clusters • Caching data in memory becomes more important as it is inefficient (and expensive) for applications to read the database for common queries • Requires understanding use cases ahead of time • Software development cost is typically higher • Bleeding edge technology (changing everyday) • Requires significant new code – cannot just port old code

19. Cloud Computing Bottom-Line • Enhances scalability • Enhances capability for large collaborations on design and development throughout the lifecycle • Upside: We can design more complex systems • Downside: We will have to manage more complex systems development

20. Cloud Computing Implications for Systems Engineering Complexity of the problem can not be masked by the complexity of the systems engineering

21. Cloud Computing Implications for Systems Engineering • Larger, more complex systems development implies: • A need for larger, distributed teams • A need for a clear concise way to express the system design (clear, logically consistent semantics) • New tools to enable collaboration across the entire lifecycle Complexity has been identified by many as a critical problem facing system engineers

22. Complexity • With the growth of the Internet and daily changes in IT, systems have become more complex and change more rapid than ever before • Cloud computing gives us new tools to deal with these larger systems • Systems engineering methods have not kept up with these changes • SE has been relegated to the beginning of the lifecycle From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011

23. How Does SE Typically Respond to Complexity? • Focus on “architecture” • More complex languages • More complex procedures • More layers of abstraction • “Systems of Systems” • “Family of Systems” • “Portfolio Management” • Need more time and money!

24. More Money Is a Problem • Calls for doing more with less continue • Need for lower labor and tool costs essential for acceptance of SE across the lifecycle From a presentation by Dr. Michael Ryschkewitsch, NASA Chief Engineer, at CSER Conference 15 April 2011 How can we simplify things enable “quicker/ cheaper”? Let’s start with the language we use

25. State of Current “Languages” • In the past decade, the Unified Modeling Language (UML) and now the profile Systems Modeling Language (SySML) have dominated the discussion • Why? • Perception that software is “the problem” • Hence need for an “object” approach • SysML was designed to relate systems thinking to software development, thus improving communication between systems engineers (SE) and software developers

26. Why Objects Are Not the Answer • Although SysMLmay improve the communication of design between SEs and the software developers it does not communicate well to anyone else • No other discipline in the lifecycle uses object oriented design and analysis extensively • Users in particular have little interest/acceptance of this technique • Software developers who have adopted Agile programming techniques want functional requirements (and resent SEs trying to write software) • Many software languages are hybrid object and functional

27. Popular Software Languages From http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html accessed 4/6/2012 Trend to hybrid functional and object

28. So What Do We Do? • Recognize that our primary job as SEs is to communicate between all stakeholders in the lifecycle • Be prepared to translate between all the disciplines • Reduce complexity in our language to facilitate communication

29. What We Did • In preparing for the cloud computing world of SE we: • Researched the variety of languages (ontologies) in common use (DM2, SysML, BPMN, IDEF, SREM, etc.) • Researched the variety of representations (FFBDs, N2, Behavior Diagrams, Class Diagrams, Electrical Engineering Diagrams, etc.) • Took the best of each of these languages and representations and distilled them down to the essential elements, relationships, attributes, and diagrams The result: Lifecycle Modeling Language

30. LIFECYCLE MODELING LANGUAGE (LML) OVERVIEW A language to simplify system design description for the cloud

31. The Lifecycle Current Operations and Maintenance Future Operations and Maintenance Demolition and Disposal Operational T&E and Transition Architecture Development Integration and Test System Design Integration & Verification Design & Analysis Hardware/Software Acquisition Program Management

32. Lifecycle Modeling Language (LML) • LML combines the logical constructs with an ontology to capture information • SysML – mainly constructs – limited ontology • DoDAFMetamodel 2.0 (DM2) ontology only • LML simplifies both the “constructs” and ontology to make them more complete, yet easier to use • Goal: A language that works across the full lifecycle

33. LML Ontology* Overview *Ontology = Taxonomy + relationships among terms and concepts ** Taxonomy = Collection of standardized, defined terms or concepts • Taxonomy**: • 12 primary element classes • Many types of each element class • Action (types = Function, Activity, Task, etc.) • Relationships: almost all classes related to each other and themselves with consistent words • Asset performs Action/Action performed by Asset • Hierarchies: decomposed by/decomposes • Peer-to-Peer: related to/relates

34. LML Taxonomy Simplifies and Enhances the Semantic Schema Elements • Technical • Action • Artifact • Asset • Resource • Characteristic • Measure • Input/Output • Link • Statement • Requirement • Programmatic/Technical • Cost • Decision • Location • Physical, Orbital, Virtual • Risk • Time

35. LML Sequencing SELECTION Action B Condition 1 SEQUENTIAL Action A OR Action A Action B Action C Condition 2 PARALLEL LOOP 1 to n (iterate) Until r < z (loop) Range (e.g.) Action A Range Action C Coordinated by Asset C SYNC Action B Action C (Exit Criteria) Action A LOOP No constructs – only special types of Actions – ones that enable the modeling of command and control/ information assurance to capture the critical decisions in your model

36. LML Action Diagram Captures Behavior 1.4 Optional Action 1 External Output Input/Output 1 1.2 Which path? OR 1.5 Exit Criteria 1.6 LOOP Optional Action 2 in Loop 1.7 End 1.1 Start Synchronize Information Action Input/Output 2 SYNC Trigger Input/Output 3 1.3 Action in ParallelAction External Input

37. LML Physical Block Diagram* Asset (Human) Asset (System) Sensor Systems Operator Sensor Platform P.5.2.1 P.5.2.2 I.1.3 Operator-Sensor Platform Interface connected with/connects used by/uses • capacity (10 Mbits/sec) • Latency (100 millisec) Asset (Resource) Sensor System Memory • maximum quantity (6 Gbytes) • minimum quantity (10 Kbytes) R.5.2.2.1 *Note: Work in progress

38. LML Combined Physical Behavior Diagram* Enables Instances and Clones Asset (System) Sensor Platform A(3) Asset (Resource) P.5.2.2 Asset (Human) Sensor Systems Operator P.5.2.1 Asset (System) Sensor Platform A(2) Clones provide multiple instances of an Asset for use in simulation Asset (Resource) P.5.2.2 I.1.3 Operator-Sensor Platform Interface A.3.1 Deploy Sensor connected with/connects A.3.1 Action (System Function) Asset (System) Sensor Platform A(1) Asset (Resource) P.5.2.2 input to/input from A.3.2 Sense Targets Deploy Command A.3.1 Action (System Function) input to/input from *Note: Work in progress

39. LML Translation • Two types of mapping for tailoring: • Map names of classes to enable other “schema” models to be used • Map symbols used (e.g., change from LML Logic to Electrical Engineering symbols) • Enable diagram translations (e.g., Action Diagram to IDEF 0) AND

40. Other Diagrams • Physical Block Diagrams • With option for icon substitution • Interface Diagrams • N2 (Assets or Actions) • Hierarchy Diagrams • Automatically color coded by class • Time Diagrams • Gantt Charts • Timeline Diagram • Location Diagrams • Maps for Earth • Orbital charts • Risk Chart • Standard risk/opportunity chart • Organization Charts • Showing lines of communication, as well as lines of authority • Pie/Bar/Line Charts • For cost and performance • Combined Physical and Functional Diagram (?)

41. LML Relationships Provide Linkage Needed Between the Classes • decomposed by/decomposes • orbited by/orbits • related to/relates

42. Reducing Complexity by Association Picture Action Programmatic Other Resources Key Relationships Name Parents (decomposes) Number Description Children (decomposed by) trigger? Inputs (receives/triggers) Yes No Outputs (generates) Type Statement (based on) Select Icon Icon Asset (performed by) Duration (takes)

43. Reducing Complexity by Association Action Programmatic Other Picture Resources Name Relations for Risk Analysis Number causes: Issue or Risk incurs: Cost List of Issues or Risks or None List of Costs or None resolves: Issue or Risk located at: Location List of Issues or Risks or None Map It List of Locations or None mitigates: Risk occurs: Time (TimeFrame or PointInTime) List of Risks or None List of Times or None

44. Reducing Complexity by Association Action Programmatic Other Picture Resources references: Artifact Name List of Artifacts or None Number specified by: Characteristic List of Characteristics or None Peer-to-Peer Relationships related to: Action List of Actions or None Context relates: Action List of Actions or None Context

45. Reducing Complexity by Association Action Programmatic Other Picture Resources Name Number Relations for Resource Modeling captures: Resource (Asset subclass) List of Resources or None consumed by: Resource (Asset subclass) List of Resources or None produces: Resource (Asset subclass) Amount List of Resources or None

46. LML Summary • LML provides the fundamental foundation for a tool to support SE in the cloud • LML contains the basic technical and programmatic classes needed for the lifecycle • LML defines the Action Diagram to enable better definition of logic as functional requirements • LML uses Physical Diagram to provide for abstraction, instances, and clones, thus simplifying physical models • LML provides the “80% solution” • It can be extended to meet specific needs (e.g. adding Question and Answer classes for a survey tool that feeds information into the modeling)

47. Break

48. SUGGESTED LML PROCESSES The cloud will require us to be more disciplined

49. Processes are key to success on the cloud • Cloud computing enables participation in design across the planet • Hence, common processes are needed to enable different practitioners to contribute to the design in a coherent manner • The following processes are offered as a starting point for such development

50. Systems Engineering During Design Phase System Analysis and Control Requirements Analysis Top Down Note: On the cloud the customer participate in the requirements development process and as such may want to focus on a scenario-based approach Functional Analysis and Allocation Best Use: “Classical SE” Middle Out Best Use: Architecture Development (To-Be) Synthesis Adapted from EIA-632 Bottom Up Best Use: Reverse Engineering (As-Is)