Towards a Formalism for System Architecture From Value to Architecture

1. Towards a Formalism forSystem ArchitectureFrom Value to Architecture Prof. Ed Crawley and Willard Simmons October 20, 2006

2. Outline of Today • The challenge • A bit of theory • Architecting for value delivery • Architecting for value, a new way

3. The Challenge • We conceive, design, implement and operate really complex and sometimes unprecedented systems • Are they architected well? • Do they meet stakeholder needs? • How do we better define interfaces for more reliable integration? • How do we adapt to new environments? • How do we evaluate the value of commonality?

4. Architecture • Architecture • The embodiment of concept, and the allocation of physical/informational function to elements of form, and definition of interfaces among the elements and with the surrounding context. • Consists of: • Function • Related by Concept • To Form Form Function Concept

5. Concept? Function? Form? Interfaces? Context? Architecture – Mechanical Cable-stayed bridge Suspension Bridge Source - www.bridgepro.com

6. Concept? Function? Form? Interfaces? Context? Architecture - Communications Insert scanned image of cannon camera system

7. Are these Good Architectures? • Do these architectures: • Respond to stakeholder needs and deliver value? • Rely on creative solutions? • Provide leverage within one project? • Good interface control? • Cross project standardization? • Architecture is the primary link between benefit and cost! • Early = high leverage on an organization’s activities • Source of competitive advantage • Alignment with the role many of our organizations do in development - architecting is what we do!

8. Key Questions in Architecture • How can we represent architectures? • How can we rigorously search the option space? • How can we select an architecture that has desirable value delivery? • How can we identify the decisions that lead to the selection of a preferred architecture?

9. Objects Object • Defined: An object is that which has the potential of stable, unconditional existence for some positive duration of time • Can be physical: visible or tangible and stable in form • Can be informational: anything that can be apprehended intellectually • Objects have states (which can be changed by processes) • Objects are linked to nouns

10. The Whole Product System • We usually architect form which is both a product and a system, and which we designate the product/system • Often for the product/system to deliver value, it must be joined and supported by other supporting systems • Together, the product, plus these other supporting systems, constitute the whole product system. Whole Product System Product/ System Supporting Systems

11. Operand • The product/system almost always operates on an operand • It is the change in the state of an operand that is associated with the delivered value of the product system • Focus the analysis or synthesis of an architecture on the operand in order to understand the delivery of value Whole Product System Product/ System Supporting Systems Operand

12. Boundaries • The product/system is separated from other supporting systems and the operand by a boundary • The boundary is vital to the definition of architecture, because it defines: • What you architect, eventually deliver and are responsible for • What is “fixed” or “constrained” at the boundaries • Everything that crosses a boundary must be facilitated by an interface • Interfaces tend to be the most stable aspect of an architecture

13. Product System Questions? • What is the value related operand? • What is the product system? • What are the supporting systems? • What are the interfaces? • What is the use context?

14. Product - Whole Product - Context Kitchen Counters Other appliances Whole Refrigerator System Cabinets Etc. Outside Air Inside Air Food Refrigerator Operator Outlet Floor Product/system boundary Whole product system Usage context

15. Form = Objects + Structure Object 3 • Defined: The relationship among the elements of form, which we call the objects • Can be physical: visible or tangible and stable in form • Can be informational: anything that can be apprehended intellectually • NB: does not imply contact, but only interrelationship • Can represent ‘formal’ relationships: • Topological (within, touching) • Spatial (aligned with, distant from) • Connectivity (bolted to, wired to) • Good practice is to specify what a connection or matrix entry means Object 1 Object 2

16. Processes Processing • Defined: A process is the pattern of transformation applied to one or more objects • Cannot hold or touch a process - it is fleeting • Generally creation, change, or destruction • A process relies on at least one object in the pre-process set • A process transforms at least one object in the pre-process set • A process takes place along a time line • A process is associated with a verb

17. Process is Associate with Form • Change voltage proportional to current • Change voltage proportional to charge • React translation forces • Carry moment and shear Resistor Capacitor Pin Support Beam

18. Emergence • As elements of form are brought together, new processes emerge • Processes do not combine in any “linear” way - it is often difficult or impossible, a priori, to predict the emergent process • In design, the expected process function may appear, may fail to appear, or an unintended process may appear • It is exactly this property of emergence that gives systems their “power”- definition of ‘system’: • A set of interrelated elements that perform a function, whose functionality is greater than the sum of the parts

19. External Function Produces Benefit • The project/system always executes externally delivered functions = process + operand • TransportOil • PowerEquipment • Support Platform • Sort Array • It is the external function that delivers benefit, and therefore value, of the project system • The form generally is an instrument of delivering benefit, but is not unique to the benefit delivery • If a competitor delivers the same function with another object which is superior, they will displace you 610

20. Semantically Exact Representation with OPM Operand Instrument Object Processing • Architecture is made up of operands + processes (functions) plus instrument object (form) • Examples: • Material is transported by ship • Oil is transported with a pump • Equipment is powered by an electric generating plant • Platform is supported by a spar • Array is sorted by bublesort routine Form Function 610

21. Architecting “Up and Down” Stakeholder - Needs Value - Intent Synthetic Process Concept Architecture Operations

22. Need Beneficiary Needs of Stakeholders • Need is a product attribute • Need is defined as: • an overall desire or want • a necessity • a wish for something which is lacking • Can also include opportunities to fill unexpressed or unrecognized needs

23. Need Value Identification -Goals on Externally Delivered Process • Next examine the operand associated with value • Identify the attribute of the operand whose change is associated with value • Define the transformation of the attribute associated with value, in solution neutral form and its attributes Beneficiary Operand Other Attribute Beneficial Attribute Solution neutral transforming Attribute of transforming Intent Need This will lead you to a value focused solution neutral statement of intent on process

24. “food rots too fast” Food spoilage rate slowing Decomposes to Specializes to Has attribute of Value Identification - Refrigerator Value Identification • Beneficiary = kitchen worker • Need “my food rots too fast” • Operand = food • Value attribute = spoilage rate • Transformation = slowing Kitchen worker Food Spoilage rate Slowing How much? Identifying/ Incorporating 610

25. Need Decomposes to Specializes to Has attribute of Solution Neutral to Specific Function Operand Beneficiary • Next identify the specific operand (if not the same as the generic operand), and its specific beneficial attribute • Then choose a the process part of the concept which specializes the solution neutral process • Define attributes of the process Specific Operand Beneficial Attribute Beneficial Attribute Solution neutral transforming Specific system Operating Attribute of transforming Attribute of operating Intent Need Function 610

26. Form Function Concept Concept - Definition • A product or system vision, idea, notion, or mental image which maps Function to Form • Embodies principle of operation • Includes an abstraction of form • Establishes the solution-specific vocabulary - it is the solution Is not a product/system attribute, but a mapping

27. Concept - Formal Definition Solution neutral process • The combination of: • The specific system operating process… • enabled by the generic form object… • specialized as a specific system form. Specific system Operating Generic Concept form Specific System form Concept Specializes Agent Link

28. Concepts - Preserving Food • Solution neutral statement is: ‘preserving food’ • Solution specific processes: chilling, freezing, etc. • Solution specific form for chilling: refrigerator, cooler, etc. • Concept is chilling with a refrigerator Food Selected Concept Preserving Chilling Chiller Refrigerator Freezing Cooler ??? Irradiating ????

29. Need Specific Function to Specific Form Operand Beneficiary Specific Operand • Next choose the generic and specific form part of the concept to execute the specific process • Define the attributes of the form Beneficial Attribute Beneficial Attribute Solution neutral transforming Specific system Operating Attribute of transforming Generic Concept form Attribute of operating Intent Need Function Specific System form Attribute of form Form

30. “food rots too fast” Decomposes to Specializes to Has attribute of Complete Value Template - Refrigerator Food Kitchen worker Spoilage rate Slowing Chilling By 90% Chiller Efficiently At 40˚ Refrigerator Need Intent Function 16 ft3 Form 610

31. Need Value - A Formal Definition Value is delivered when the external process(es) acts on the operand in such a way that the needs of the beneficiary are satisfied at a desirable cost. ?? Beneficiary Operand Note that in operations, intent ‘vanishes’ unless recorded Beneficial Attribute Value Delivery Specific system Operating Specific System form The relation between the beneficiary and the operand in undefined (the beneficiary could be the operand, own the operand, love/hate the operand, etc.) 610

32. Value related internal processes Operands Supporting processes Supporting objects and interfaces Value related Instrument Objects Operations Wheels Floor Conducting, Convecting Cabinet Circulating Load carrying Structurally interfacing Outside Air Condenser Fan Refrigerating Frame Refrigerator Wiring Sensing, Feeding back Controller Power carrying Power interfacing Inside Air Circulating Evaporator Fan Plug/chord Outlet Conducting, Convecting Transferring load Food Shelves Illuminating Light Insulated door Grasping, moving Operator Mixing Refrigerator Opening, closing project/system boundary

33. Wheels Floor Conducting, Convecting Cabinet Circulating Load carrying Structurally interfacing Outside Air Condenser Fan Refrigerating Frame Refrigerator Wiring Sensing, Feeding back Controller Power carrying Power interfacing Inside Air Circulating Evaporator Fan Plug/chord Outlet Conducting, Convecting Transferring load Food Shelves Illuminating Light Insulated door Grasping, moving Operator Mixing Refrigerator Opening, closing project/system boundary

34. Floor Conducting, Convecting Box Circulating Load carrying Structurally interfacing Outside Air Refrigerating Regulating Powering Melting Inside Air Circulating Ice Conducting, Convecting Transferring load Food Illuminating Light Insulated top Grasping, moving Operator Mixing Cooler! Opening, closing project/system boundary

35. Our Effort:Systems Architecture Research • Mission: • Develop formal methods and tools for Systems Architecting. • Methodology: • Apply these ideas to current projects from Government and Industry. • Tools: • Object-Process Network (OPN), a computable graphical language for systems architecting.

36. OPN Project Objectives • To improve the thoroughness and efficiency of system architecting, • By automating the mechanical tasks in architectural reasoning and model construction, • Using an executable meta-language: “Object-Process Network” (OPN). • OPN supports architecture evaluation by: • Functioning as a declarative language to describe the feasible space of architectures. • Functioning as an imperative language to automatically generate large sets of models of feasible system configurations. • Functioning as a simulation language to evaluate and sort system concepts using customized metrics.

37. What is OPN? • OPN is a visual and computable meta-language that assists with systems architecting tasks. • OPN is used to: • Describe and Partition the space of architectural alternatives. • Generate and Enumerate the set of instances of feasible system models. • Simulate and Order the performance metrics of the generated models. • OPN is a network (a directed graph) of objects and processes connected by relationships • An OPN model can be created, edited, and executed using the OPN IDE Software

38. Generated Model List Meta-Model OPN View Generated Model OPN View Meta-Model Tree View Generated Model Matrix View Meta-Model Matrix View Generated Model Data View OPN IDE Screenshot

39. OPN Applications (so far) • Published Space-related Applications: • Retrospective study of the Apollo decision process. • Support the Moon/Mars architecture selection for the Draper/MIT CE&R project • Evaluation of the Shuttle Derived Heavy Launch Vehicle architectures for Draper/MIT CE&R Project. • NASA Value Flow / Policy Network analysis. • Study of Decisions in NASA Lunar Lander Project • Other Applications • Oil Exploration of Sakhalin Island for (Supporting BP) • Electronics Pod Selection for Aircraft (support Draper) • Proposed • Study of Earth Observation Satellites for NASA Goddard

40. MIT/Draper CE&R Project • Goal: To help NASA identify sustainable system of system architectures for exploration • Approach: • Define measures of sustainability for design • Comprehensively search the architectural space(s) • Identify key policy, technology and operational decision points • Project the resulting functionality onto the CEV, to determine the robustness of its requirements to further downstream decisions • September 15, 2004 – September 14, 2005 • Draper / MIT team was one of 11 industry teams for Phase I, one of 2 for Phase II • Involved about 50 people from Draper Labs and MIT Holistic Sustainable Mars-Back Modular, Accretive, and Minimal

41. Exploration Architecture Approach

42. policy money workforce technology systems knowledge Main Value Flows

43. What are the Value Driven Objectives? Auxiliary columns Auxiliary columns • Identify stakeholder, their needs and derived objectives • Translate objectives into metrics, proximate measure and indicators • Proximate indicators drive exploration architecture

44. Transportation Architecture Approach Questions Addressed • Where should the CEV go? • What other vehicles are needed? • What propulsion should be used? • Should in-situ resources be used? • What size of HLLV is needed? Requirements and Indicators • Requirements • Crew size • Cargo mass • Mars mission duration • Metrics • Initial mass in Low Earth Orbit (IMLEO) • Dry mass of unique elements • Overall safety and risk metric (OSRM) • Available contingency plans • Software development cost Constraints and Assumptions • Fast-Conjunction Mars Missions • Aerocapture used for Mars orbit insertion • Propulsion Technology • LH2/LOx for Earth departure with chemical • LCH4/LOx for other maneuvers with chemical • ISPP (if used) • Each Mars mission carries plant • Single base/production facility for Lunar missions Approach – Moon and Mars • Generate all feasible Lunar and Mars architectures • Analyze architectures • Screen architectures • Commonality analysis for promising Lunar and Mars architectures • Size TMI/TLI stages • Select launch vehicle size(s)

45. Defining the Architecture • Architecture is a representation of the Stable Properties of the system. • It is the embodiment of a concept, and the allocation of physical/informational functions to elements of form, and definition of interfaces among the elements and with the surrounding context. • Stable properties of a the Exploration architecture: • The Mission Mode: the number, types, destinations and interactions of the exploration vehicles Number and Types of Vehicles Vehicle Interactions Destinations of Vehicles John C. Houbolt explains the mission mode Lunar Orbit Rendezvous (LOR) (NASA Photo)

46. Moon-Mars Architecture Generator • Constructed using OPN • Produces 1162 unique transportation architectures. • This model describes the set containing the entire space of alternatives. • Relatively easy to add new options or behaviors, if necessary.

47. Instance of a Transportation Architecture • Mass Metrics can be calculated for different configurations: • Examples: • #567 of 1162 generated mission modes • This Architecture is representative of the 1993 NASA Mars Design Reference Mission

48. Comprehensive Study of Feasible Options • Metrics were calculated for various configurations of all 1162 architectures • Example: Total Initial Mass in Low Earth Orbit (IMLEO) Moon Mars • MOON: • Crew=5, ISRU=no, Propulsion=Chemical • MARS: • Crew=5, ISRU=no, Propulsion=Chemical

49. Results: Modular, Accretive and Minimal LEO / ISS Mission Hardware Short Lunar Mission Hardware Common in-space propulsion stage (LCH4 / LOX): Core propulsion stage XL strap-on tanks XXL strap-on tanks (ERV) LAT for CEV capsule: CEV + IPU (27 m3 ): Lunar landing gear & exoskeleton: LEO propulsion stage: Engine 1 (LCH4 / LOX) Restartable, non-throttleable: CEV power pack: CEV launch vehicle: Engine 2 (LCH4 / LOX) Throttleable: Design Philosophy: Maximize hardware commonality to minimize gap between lunar and Mars missions and overall development and production costs Common Earthdeparture stage(LH2 / LOX) Heavy Lift Launch Vehicle: (“2 stages”, 100 mt to LEO) Mars Mission Hardware SDLV upper stage (125 mt to LEO), potentially EDS-derived: Mars landing gear & exoskeleton: Long Lunar Mission Hardware Habitat core and inflatablepressurized tent forplanetary surfaces: Integrated aeroshell Note: Block upgrades across phases are not depicted

50. Base Moon-Mars Exploration System Commonality Concept Lunar Transportation Architecture Mars Transportation Architecture • With Mars-Back approach, most of the elements from the Lunar Mission are also useable for the Mars mission. • Principle: Keep costs low by planning in commonality and extensibility from the beginning