School of Systems and Enterprises Stevens Institute of Technology, USA

1. File5.5 ES/SDOE 678Reconfigurable Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and PerformanceSession 9 – Perspectives: Developing Proficiency and Culture School of Systems and Enterprises Stevens Institute of Technology, USA Your Class web-page: <ask instructor> Support docs & links: www.parshift.com/678/support.htm File File

2. FEEDBACK REVIEW • Closure Matrix

3. start thinking…later, in a short while EXERCISE 1) Describe the general responsibilities you have 2) Categorize them: software, electronics, process, management, proposals, architecture, …. whatever 3) Provide a brief example of where/how Response Ability concepts should be employed. Do this on 1 PowerPoint slide – with your name on it Add it at the end of your team’s group exercise file NEXT TO YOUR PREVIOUS SLIDE

4. Guest Speaker – SugataMitraThe child-driven education (File17) • Education scientist SugataMitra tackles one of the greatest problems of education -- the best teachers and schools don't exist where they're needed most. In a series of real-life experiments from New Delhi to South Africa to Italy, he gave kids self-supervised access to the web and saw results that • could revolutionize how we think about teaching. • SugataMitra's "Hole in the Wall" experiments have shown that, in the absence of supervision or formal teaching, children can teach themselves and each other, if they're motivated by curiosity and peer interest. • In 1999, SugataMitra and his colleagues dug a hole in a wall bordering an urban slum in New Delhi, installed an Internet-connected PC, and left it there (with a hidden camera filming the area). What they saw was kids from the slum playing around with the computer and in the process learning how to use it and how to go online, and then teaching each other. In the following years they replicated the experiment in other parts of India, urban and rural, with similar results, challenging some of the key assumptions of formal education. The "Hole in the Wall" project demonstrates that, even in the absence of any direct input from a teacher, an environment that stimulates curiosity can cause learning through self-instruction and peer-shared knowledge. Mitra, who's now a professor of educational technology at Newcastle University (UK), calls it "minimally invasive education." Video and text above at: http://www.ted.com/talks/sugata_mitra_the_child_driven_education.html

5. BREAK

6. Review • Quality principles • Requisite Variety • Parsimony • Harmony • Reality recognition • Agile-Strategy ConOps • Operational/Integrity Management • Framework evolution • Module Evolution • Module inventory management • System response management • Closure: Integrating analysis, principles, activities

7. Course Roadmap Have You Signed The Attendance Roster? Session 1 – Overview and Introduction to Agile Systems Session 2 – Problem Space and Solution Space Session 3 – Response Types, Metrics, Values Session 4 – Situational Analysis and Strategy Exercise Session 5 – Architecture and Design Principles Session 6 – Design Exercise and Strategy Refinement Session 7 – Quality: Principles, Reality, Strategy Session 8 – Operations: Closure and Integrity Management Session 9 – Culture and Proficiency Development Session 10 – The Edge of Knowledge, Projects Fundamentals Analysis Tools Synthesis Integration Perspective

8. Culture and Proficiency Development • Operational models • Maturity stages • Quick Review • Process Sequence

9. Sometimes They Just Build It Like You Designed It • Thinking (a conscious activity) about your engineering tools and your engineering processes and the goals of your piece of the project is necessary – but not sufficient . • You must also think about the context – its intent and its values. • “We are not constructing a tunnel – we are creating a transportation system.” [Allen Fairbairn, System Engineer on the Chunnel Project] Thought frameworks introduced in this course expose the context for whatever piece of the work is your responsibility. Your contribution will fit harmoniously with need.

10. Project Yourself Into Your Design Feel What It’s Liketo Be There Walk Around Look Around Interact

11. Future Casting with StoriesScientific American, May 2012, “Professional Seer”, Brian David Johnson Interview by Larry Greenemeier • Intel , the worlds largest computer chipmaker employs a corporate futurist, Brian David Johnson, to guess what gadgetry and computing will look like in 2020 and beyond. • Q: How does your role as future caster fit with what the company is doing? • A: I sit in front of the company’s development road map. … I create models of what the experience will be like, what it will feel like to use a computer in 2020. Intel is an engineering company, so I turn that into requirements and capabilities for our chips. I’m working on 2019 right now. • Q: Does the act of engaging in imaginative writing help you with your day job? • Writing science fiction has been an integral part of my future-casting process for years. Often these stories or science-fiction prototypes are used as part of the final product specification – this is the requirements document that explains to the engineers and development team what needs to be built. Some of the greatest scientific minds, such as Albert Einstein and Richard Feynman, used creativity and their imagination as part of their scientific method. When I write science fiction based on science fact, it gives me a really powerful tool to innovate and create technologies that are better designed for humans. Also, engineers love science fiction, so it’s a great way to get across my 10- to 15-year future casts. Brian David Johnson. (Credit: Intel)

13. Neat Ideas – But I Can’t Use Them Here! (or Can I?) • No matter how little or how low-level your piece of the total project puzzle, you have de facto design and architectural responsibility for that piece. • Whatever you do has users and user-needs that will change. Some of those users are the people who will maintain and modify what you’ve done when the system needs improved or overhauled. • The ideas exposed here work beneficially at all levels. • The total system will not be agile as a whole if it is not agile throughout – but any parts of it that are agile are parts that contribute to bottom-line system response ability. • In any enterprise or system that are many pieces that make contribution to bottom-line objectives. Some pieces deliver more value than others. • Software: the lexical analysis subroutine of a compiler can be done many ways. Table driven methods structured for transparency are easy to debug, easy and safe to extend with new language constructs, easy and safe for someone else to learn and maintain. The table structure and processing rules are the infrastructure, the table rows and table entries are the modules. • Electronics: Encapsulated decomposition. Firmware over circuitry. … • Process: what will facilitate lessons-learned becoming part of the process next cycle?

14. EXERCISE 1) Describe the general responsibilities you have 2) Categorize them: software, electronics, process, management, proposals, architecture, …. whatever 3) Provide a brief example of where/how Response Ability concepts should be employed. Do this on 1 PowerPoint slide – with your name on it Add it at the end of your team’s group exercise file NEXT TO YOUR PREVIOUS SLIDE

15. Guest Speaker – Jeff HawkinsBrain science is about to fundamentally change computing (21 min) Jeff Hawkins pioneered the development of PDAs such as the Palm and Treo. Now he's trying to understand how the human brain really works, and adapt its method -- which he describes as a deep system for storing memory -- to create new kinds of computers and tools. Jeff Hawkins' Palm PDA became such a widely used productivity tool during the 1990s that some fanatical users claimed it replaced their brains. But Hawkins' deepest interest was in the brain itself. So after the success of the Palm and Treo, which he brought to market at Handspring, Hawkins delved into brain research at the Redwood Center for Theoretical Neuroscience in Berkeley, Calif., and a new company called Numenta. Hawkins' dual goal is to achieve an understanding of how the human brain actually works -- and then develop software to mimic its functionality, delivering true artificial intelligence. In his book On Intelligence (2004) he lays out his compelling, controversial theory: Contrary to popular AI wisdom, the human neocortex doesn't work like a processor; rather, it relies on a memory system that stores and plays back experiences to help us predict, intelligently, what will happen next. He thinks that "hierarchical temporal memory" computer platforms, which mimic this functionality (and which Numenta might pioneer), could enable groundbreaking new applications that could powerfully extend human intelligence. Video and text above at: www.ted.com/index.php/speakers/jeff_hawkins.html

16. Resilient Agile Resilient Agile Resilient Agile A A B B C Fragile Innovative Fragile Innovative Fragile Innovative C B C A Maturity Modeling Customer Responsiveness Outage Management Competency Development Assessment and Competitive Evaluation Comparing Companies A, B, CResponse Proficiency Maturity Model 4 3 2 1 0 Metric Working Competitive Development Stages Focus Knowledge Proactive Reactive 0 Accidental Pass/Fail Examples Lucky None 1 Repeatable Time Concepts Creation Correction 2 Defined Cost Metrics Improvement Variation 3 Managed Quality Rules Migration Expansion 4 Mastered Scope Principles Modification Reconfig'tion Agile Resilient Reactive Innovative Fragile www.parshift.com/docs/MaturityModel00.htm 0 1 2 3 4 Proactive

17. Enterprise Change Proficiency Profile Analytical Guide for EstablishingCompetitive StrategyandImprovement Targets Could show where your company and/or its processes are agile! • Maturity Working Metric Change Competencies Stage Knowledge Focus Proactive Reactive • 0 Accidental Examples Pass/Fail None None • 1 Repeatable Concepts Time Creation Correction • 2 Defined Metrics Cost Improvement Variation • 3 Managed Responsibilities Quality Migration Expansion • 4 Mastered Principles Scope Modification Reconfiguration www.parshift.com/docs/MaturityModel00.htm

18. Change Proficiency Maturity Stages Stage 0 - Accidental - Characterized by: • The lack of any change-process recognition, yet change manages to occur. • The process is ad hoc: exhibiting false starts and retries, unpredictable completion dates and costs, surprising results and side effects, and undesirable reactions from, and effects on, the personnel involved. • Examples: Downsizing, management fad-of-the-day, grueling overtime, fire-fighting, multiple reengineering attempts, expediting. Stage 1 - Repeatable - Characterized by: • Anecdotal “lessons learned” from past change activities. • The time it takes to make a change is under control. • Specific individuals and teams are recognized for repeatable success with effective change projects. Stage 2 - Defined - Characterized by: • The emergence of formal change processes with documented procedures. • The base of practitioners is broadened as process rather than intuitive talent becomes appreciated. • Metrics for the change process are identified, cost of change is under control, and predictability becomes a known but elusive desire. • Typically procedures at this stage are rigid and based on studied experience and analysis. Stage 3 - Managed - Characterized by: • The appointment of change managers (business engineers) with established responsibilities, though they may neither be called such nor recognized as such. • An evolving knowledge base of change process fundamentals and rules begins to emerge. • Rigid procedures are loosened, and predictable change processes are the norm. • Appreciation for and participation in the corporate change process is widespread. Stage 4 - Mastered - Characterized by: • A principle-based, deep appreciation of adaptability. • An understanding that process alone is not sufficient. • A conscious engineering and manipulation of the business practice structures and organizational infrastructures. • Like a flock of birds swooping and turning as a unit, corporate change loses its event status and takes on a constant fluid motion. www.parshift.com/docs/MaturityModel00.htm

19. Change Proficiency Maturity Stages Stage 0 - Accidental - Characterized by: • The lack of any change-process recognition, yet change manages to occur. • The process is ad hoc: exhibiting false starts and retries, unpredictable completion dates and costs, surprising results and side effects, and undesirable reactions from, and effects on, the personnel involved. • Examples: Downsizing, management fad-of-the-day, grueling overtime, fire-fighting, multiple reengineering attempts, expediting. www.parshift.com/docs/MaturityModel00.htm

20. Change Proficiency Maturity Stages Stage 1 - Repeatable - Characterized by: • Anecdotal “lessons learned” from past change activities. • The time it takes to make a change is under control. • Specific individuals and teams are recognized for repeatable success with effective change projects. www.parshift.com/docs/MaturityModel00.htm

21. Change Proficiency Maturity Stages Stage 2 - Defined - Characterized by: • The emergence of formal change processes with documented procedures. • The base of practitioners is broadened as process rather than intuitive talent becomes appreciated. • Metrics for the change process are identified, cost of change is under control, and predictability becomes a known but elusive desire. • Typically procedures at this stage are rigid and based on studied experience and analysis. www.parshift.com/docs/MaturityModel00.htm

22. Change Proficiency Maturity Stages Stage 3 - Managed - Characterized by: • The appointment of change managers (business engineers) with established responsibilities, though they may neither be called such nor recognized as such. • An evolving knowledge base of change process fundamentals and rules begins to emerge. • Rigid procedures are loosened, and predictable change processes are the norm. • Appreciation for and participation in the corporate change process is widespread. www.parshift.com/docs/MaturityModel00.htm

23. Change Proficiency Maturity Stages Stage 4 - Mastered - Characterized by: • A principle-based, deep appreciation of adaptability. • An understanding that process alone is not sufficient. • A conscious engineering and manipulation of the business practice structures and organizational infrastructures. • Like a flock of birds swooping and turning as a unit, corporate change loses its event status and takes on a constant fluid motion. www.parshift.com/docs/MaturityModel00.htm

24. Change-Proficiency Maturity Stages Stages General Maturity-Stage Characteristics Example: Maintaining Skilled Resources 0: Accidental Stumble through change, no awareness Hire what’s available, hope they are good 1: Repeatable A set of rules for change become understood Common hiring ritual to obtain new skills 2: Defined Rules broadened, with performance metrics Knowledge-based screening & testing 3: Managed Objectives clarified, rules refined, accountability Individual employee development program 4: Mastered No longer rule based - principles guide action Enables/encourages self development Key Human-Relationship Issues (Remmele Engineering, 1996) Proactive Change Proficiency Issues 1: Creation • Obtaining top quality people; creating a sense of team, ownership, responsibility. 2: Improvement • Improving personnel skills. 3: Migration • Workforce diversity; top management succession. 4: Modification • Gaining new skills; guarding against insularity. Reactive Change Proficiency Issues 1: Correction • Correcting mismatches between people and their tasks. 2: Variation • Filling critical slots when a key employee is absent. 3: Expansion • Finding more high-quality machinists; handling surge requirements. 4: Reconfigure • Reassigning tasks and responsibilities to meet special needs. Proforma Example Case-study results from assessment at Remmele Engineering, 1996 www.parshift.com/docs/MaturityModel00.htm

25. 2 24 4 23 8 10 22 11 21 15 20 18 19 17 1 16 3 14 5 13 6 12 7 9 Maturity Fit to the Times/Needs Industry Priority FutureCurrent 4.00 4.00 4.00 3.00 3.00 3.50 2.50 4.00 0.00 1.00 3.00 0.50 2.00 4.00 4.00 4.00 4.00 4.00 3.00 2.00 4.00 3.00 1.50 3.00 MaturityCritical Business Practice 4.0 1 Strategic Plan Vision 4.0 2 Strategic Plan Dissemination 4.0 3 Strategic Plan Buy-In 3.0 4 Capital Investment Justification 3.0 5 Infrastructure Investment Just. 3.5 6 Business Eng. Investment Just. 2.5 7 Business Unit Relationships 4.0 8 Employee Relationships 0.0 9 Partner Relationships 1.0 10 Supplier Relationships 3.0 11 Customer Relationships 0.5 12 Information Sys. Unit Relationships 2.0 13 Production Unit Relationships 4.0 14 Product Innovation Management 4.0 15 Process Innovation Management 4.0 16 Procedure Innovation Mgmnt. 4.0 17 Strategy Innovation Management. 4.0 18 Knowledge-Portfolio Strategy 3.0 19 Knowledge Generation 2.0 20 Knowledge Capture 4.0 21 Knowledge Mobilization 3.0 22 Leading Indicator Metrics 1.5 23 Operating Metrics 3.0 24 Valuation Metrics Grouped by Industry Priority Future Current 72% 79% Remmele www.parshift.com/docs/aermodA0.htm www.parshift.com/docs/MaturityModel00.htm

26. Art: Andersen Consulting • Agility • A = RA + KM + VP • RA = RRS + CP • The Hard Facts… • RA is enabled with RRS engineering principles • RA is quantifiable with CP metrics • About a Soft Concept… • KM is about learning • CP is about competency and culture • VP is about decision making • A = Agility • RA = Response ability • KM = Knowledge management • RRS = Reusable, reconfigurable, scalable • CP = Change proficiency • VP = Value Propositioning

27. Part 1: Concepts That Form the Core of Value Propositioning 1 On The Nature of Value and Value Propositions 2 On The Nature of Decision Makers and Champions 3 On The Nature of Problems and Solutions 4 On The Nature of Knowledge and Context 5 On the Nature of Trust and Risk 6 On The Nature and Effect of Competition 7 On The Nature of Competency and Talent Part 2: Logic That Structures Core Concepts and Drives Decision Making 8 The Logic of Core Concepts 9 The Logic of Misperception  (pdf-file) 10 The Logic of Individual Decision Making 11 The Logic of Group Decision Making 12 The Logic of Perception Formation 13 The Logic of Multi-Benefit Valuation 14 Confusion With Technology and ROI Chapter 9 PDF download: www.parshift.com/ValueProp/VPBook1/VP1Chap09.pdf

28. Concepts That Enable Agility Agility consists of practices and processes for Knowledge Management Value Propositioning Response Ability by to have awareness to enable response Decision Champion Decision Maker www.parshift.com/ValueProp/VPBook1.htm needs skills of needs skills of Knowledge Development Knowledge Development Focused Learning Focused Learning as as Perception Influencing Perception Influencing Focused Educating Focused Educating as as ROI Development ROI Development push-pull cross links Business Math Business Math as as Communi- cation Communi-cation Focused Clarity Focused Clarity as as Trust Building Trust Building Risk Reduction Risk Reduction as as

29. File8 .5 Guest Speaker: Dave SnowdenIntroduction to the Cynefin Framework David John Snowden (born April 1, 1954) is a Welsh academic, consultant, and researcher in the field of knowledge management. He is the founder and Chief Scientific Officer of Cognitive Edge, a research network focusing on complexity theory in sensemaking. Snowden, a thought leader on the application of complexity theory to organizations, tacit knowledge and an observer in the way knowledge is used in organizations; has written articles and scholarly works on leadership, knowledge management, strategic thinking, strategic planning, conflict resolution, weak signal detection, decision support, and organisational development. He holds an MBA from Middlesex University, and a BA in Philosophy from Lancaster University; and started his active career life with Data Sciences Ltd (formerly Thorn EMI software), acquired by IBM in 1996. He was the Director of IBM's Institute for Knowledge Management, and the founder of the Cynefin Center for Organizational Complexity. Snowden developed the Cynefin (Ken-ev-in) framework, a practical application of complexity theory to management science. Video: http://cognitive-edge.com/library/more/video/introduction-to-the-cynefin-framework/ Text: Dave Snowden (Wikipedia) 70 minute full theory Video & Slides: www.infoq.com/presentations/Agile-Theory

30. The Cynefin Framework (Ken-ev-in) David J. Snowden and Mary E. Boone. 2007. A Leader’s Framework for Decision Making. Harvard Business Review. November. • The Cynefin framework helps leaders determine the prevailing operative [project] context so that they can make appropriate choices. Each domain requires different actions. • Simple and complicated contexts assume an ordered universe, where cause-and-effect relationships are perceptible, and right answers can be determined based on the facts. • Complex and chaotic contexts are unordered—there is no immediately apparent relationship between cause and effect, and the way forward is determined based on emerging patterns. • The ordered world is the world of fact-based management; the unordered world represents pattern-based management. • The very nature of the fifth context—disorder—makes it particularly difficult to recognize when one is in it. Here, multiple perspectives jostle for prominence, factional leaders argue with one another, and cacophony rules. The way out of this realm is to break down the situation into constituent parts and assign each to one of the other four realms. Leaders can then make decisions and intervene in contextually appropriate ways.

31. Project Context Defines the Necessary Approach David J. Snowden and Mary E. Boone. 2007. A Leader’s Framework for Decision Making. Harvard Business Review. November. • Effective leaders shift their styles to match changing environments. Simple, complicated, complex, and chaotic contexts each call for different managerial responses. • Simple: The Domain of Best Practice – Simple contexts are characterized by stability and clear cause-and-effect relationships that are easily discernible by everyone. Often, the right answer is self-evident and undisputed. Decisions are unquestioned because all parties share an understanding. Leaders in a simple context must sense, categorize, and respond to a situation. • Complicated: The Domain of Experts – Complicated contexts, unlike simple ones, may contain multiple right answers, and though there is a clear relationship between cause and effect, not everyone can see it. Leaders in a complicated context mustsense, analyze, and respond. This approach is not easy and often requires expertise. Because the complicated context calls for investigating several options—many of which may be excellent—good practice, as opposed to best practice, is more appropriate. • Complex: The Domain of Emergence – In a complicated context, at least one right answer exists. In a complex context, however, right answers can’t be ferreted out. In this domain, we can understand why things happen only in retrospect. Instructive patterns, however, can emerge if the leader conducts experiments that are safe to fail. That is why, instead of attempting to impose a course of action, leaders must patiently allow the path forward to reveal itself. They need to probe first, then sense, and then respond. • Chaotic: The Domain of Rapid Response – In a chaotic context, searching for right answers would be pointless: The relationships between cause and effect are impossible to determine because they shift constantly and no manageable patterns exist—only turbulence. A leader’s immediate job is not to discover patterns but to stanch the bleeding. A leader must first act to establish order, then sense where stability is present and from where it is absent, and then respond by working to transform the situation from chaos to complexity, where the identification of emerging patterns can both help prevent future crises and discern new opportunities. Communication of the most direct top-down or broadcast kind is imperative; there’s simply no time to ask for input.

32. Agile-Systems Engineering1/7 • This section focuses first on fundamental needs, definitions, and necessary and sufficient enabling concepts for agile systems of any kind – including processes, major systems, products, organizations, and human endeavors [1, 2]. A brief recognition of some current confusion about agile concepts concludes the section. • Need – A cross-industry study for the US Office of Naval Research in 1991 [3] observed that technology and the environment in which it is deployed were co-evolving at an increasing rate, outpacing the adaptation capabilities of most organized human endeavors. Agility, as a systemic characteristic, was identified as a new need generally missing in systems we call enterprise, the systems supporting enterprise, and the systems produced by enterprise. Decreasing relevance and life expectancy for traditional systems of all kinds create the counterbalancing need for agility. • Definition – Agility is the ability of a system to thrive in an unpredictably evolving environment; deploying effective response to both opportunity and threat, within mission. • Metrics – effective response has four metrics: timely (fast enough to deliver value), affordable (at a cost that delivers ROI and allows successive new responses), predictable (can be counted on to meet the need), and comprehensive (anything and everything within the mission boundary). • Value Proposition – Risk management in an evolving unpredictable environment is the value proposition for agile systems. An agile system is constructed to enable and facilitate augmentation, reconfiguration and scalability of reusable assets in response to unpredictable situations, and agility is sustained with active management of responsibilities that constantly evolve the agility enabling capabilities.

33. Agile-Systems Engineering2/7: Architecture • Architecture – Achieving good agile response metrics is enabled or hindered by architecture. One fundamental Agile Architecture Pattern has emerged from extensive investigation and appears both necessary and sufficient. It will be recognized in a simple sense as a drag-and-drop plug-and-play architecture, with some critical aspects not generally called to mind with the general thoughts of a modular architecture. There are three critical elements in the architecture: a catalog of drag-and-drop encapsulated modules and the module pools in which they belong, a catalog of the passive infrastructure rules and standards that enable and constrain plug-and-play operation, and the designation of the active infrastructure of four specific responsibilities that sustain agile operation. • Modules – Modules are self contained encapsulated units complete with interfaces which conform to the plug-and-play passive infrastructure. They can be dragged-and-dropped into a system of response capability with relationship to other modules connected through the passive infrastructure, and not connected directly module-to-module. Modules are encapsulated so that their interfaces conform to the passive infrastructure but their methods of functionality are opaque to other modules. New modules can be added to module pools and new pools of modules can be added, asynchronously. Module pools provide variation and diversity among modules - often with duplicate versions of modules in a pool to enable increased functional capacity of like-module deployment. • Passive Infrastructure – The passive infrastructure provides drag-and-drop connectivity between modules. Its value is in isolating the encapsulated modules so that unexpected side effects are minimized and new operational functionality is rapid. Selecting passive infrastructure elements is a critical balance between requisite variety and parsimony – just enough in standards and rules to facilitate module connectivity but not so much to overly constrain innovative system configurations. Passive infrastructure typically evolves, but slowly, generally when migration to next generation capability is appropriate.

34. Agile-Systems Engineering3/7: Architecture • Active Infrastructure– An agile system is not something designed and deployed in a fixed event and then left alone. Agility is most active as responsible parties assemble new system configurations in response to new requirements – something which may happen very frequently, even daily in some cases. But in order for new configurations to be enabled, three more responsibilities are required: the collection of available modules must evolve to be always what is needed, the modules that are available must always be in deployable condition, and the passive infrastructure must have evolved when new configurations require new standards and rules. Four responsibilities must be designated with responsible parties or processes that ensure effective response capability is possible at unpredictable times. • Module Mix/Evolution – Who (or what process) is responsible for ensuring that new modules are added to the pools, modules in the pools are upgraded, and new module pools are created, in time to satisfy response needs? • Module Readiness – Modules in module pools must be ready for deployment at unpredictable times. Designated parties internal to the system or external in the environment must be responsible for ensuring that sufficient modules are ready for deployment. • System Assembly – Who assembles new system configurations when new situations require something different in capability? Are they trained and knowledgeable in resource deployment and system configuration methods? • Infrastructure Evolution – No fixed infrastructure of standards and rules is appropriate for prolonged periods of time – witness the evolving infrastructure of standards that has enabled home entertainment systems to accommodate new technologies such as video and Internet connectivity, while sustaining effectiveness of legacy assets.

35. Agile-Systems Engineering4/7: Principles • Principles – Ten Reusable-Reconfigurable-Scalable design principles add the flesh to the bones of the architecture, and are briefly itemized here. • Reusable Principles • Encapsulated Modules – Modules are distinct, separable, loosely-coupled, self-sufficient units cooperating toward a shared common purpose. • Facilitated Interfacing (Plug Compatibility) – Modules share defined interaction and interface standards; and are easily inserted or removed. • Facilitated Reuse – Modules are reusable and replicable; and responsibilities are specifically designated for module inventory management, maintenance, and upgrade. • Reconfigurable Principles • Peer-Peer Interaction – modules communicate directly on a peer-to-peer relationship; and parallel rather than sequential relationships are favored. • Distributed Control and Information – Modules are directed by objective rather than method; decisions are made at point of maximum knowledge; information is associated locally, accessible globally. • Deferred Commitment – Situations can change rapidly and continue to evolve. Deferring commitment of response assembly and deployment to the last responsible moment avoids costly wasted effort that may also preclude a subsequent effective response. • Self-Organization – Module relationships are self-determined where possible; and module interaction is self-adjusting or self-negotiated. • Scalable Principles • Evolving Standards – Passive infrastructure standardizes inter-module communication and interaction; defines module compatibility; and is evolved by designated responsibilities for maintaining current and emerging relevance. • Redundancy and Diversity – Duplicate modules provide capacity right-sizing options and fail-soft tolerance; diversity among similar modules employing different methods is exploited. • Elastic Capacity – Modules may be combined in responsive assemblies to increased and decreased functional capacity within the current architecture.

36. Agile-Systems Engineering5/7: Requirements • Requirements – In addition to the system functional requirements, response situation analysis helps identify response requirements that inform the design of architecture, indicating the necessary nature of modules and modules pools, which in turn help identify the necessary nature of both passive and active infrastructure. Requirements arising from response situational analysis may not be directly present in customer requirements, but are necessary for effective architecture design. Unlike functional requirements typically captured in all-encompassing specific shall statements, response requirements need only enumerate sufficient diversity to result in a capability that can respond to un-enumerated situations. An effective framework for structuring response situational analysis drives analytical thinking in four reactive and four proactive domains. For brevity the framework below provides abstractions without examples. Detailed examples can be found in [1, 2] with case-making general coverage in [4]. Note that response requirements are system-operational time requirements, not system-design time requirements; and should be stated as operational needs independent of possible solution strategies which will evolve with time. • Proactive domains • Creation/Elimination – what range of opportunistic situations will need modules assembled into responsive system configurations; what elements must the system create during operation that can be facilitated by modules and module pools; what situational evolution will cause obsolesce of modules which should be removed? • Improvement – what improvements in system response performance will be expected over the system operational life? • Migration – what evolving technologies and opportunities might require future changes to the infrastructure? • Modification – what evolving technologies, opportunities, and situations might require future modifications to modules? • Reactive domains • Correction – what types of response activities might fail and need correction? • Variation – what operational conditions and resources vary over what range when response capabilities must be assembled? • Expansion/Contraction – what are the upper and lower bounds of response capacity needs? • Reconfiguration – what types of situations will require modular system reconfiguration to react effectively?

37. Agile-Systems Engineering6/7: Confusions • Confusions to Understand • Definitions for system agility proliferate in the literature, with varying sub-characteristics and sometimes with parallel system characteristics called out separately, such as adaptability, robustness, flexibility, resilience and others. At core agility is a capability that enables and facilitates effective response to unpredictable situations – including all of these characteristics. • Agile Systems-Engineering and Agile-Systems Engineeringboth obtain agility by addressing uncertainty with the same common fundamentals. Agile Systems-Engineering is a process that obtains its agility from a design based on Agile-Systems Engineering fundamentals. • Agile Software Developmentas agile systems engineering is not a general systems engineering approach, but rather a variety of many differing software-system engineering practices. Nevertheless, agile software development practices rely on agile-system engineering fundamentals as their core source of agility. • Lean and agilesystem/process concepts are different. The former is focused on efficient system operation and the later is focused on efficient system transformation. Neither encompasses the other, but there is some overlap of common best-practice in each.

38. Agile-Systems Engineering7/7: References • References (last few pages) • [1] Dove, R. 2001. The Language, Structure, and Culture of Agile Enterprise. Wiley. • [2] Dove, R. 2012. Agile Systems and Processes: Necessary and Sufficient Fundamental Architecture (Agile 101). INCOSE Webinar, 19 September. www.parshift.com/s/AgileSystems-101.pdf. • [3] Nagel, R. N. 21st Century Manufacturing Enterprise Strategy Report. AMEF N0001-92 Prepared for the Office of Naval Research. www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA25703 2 • [4] Sillitto, H. G. 2013. Composable Capability – Principles, Strategies and Methods for Capability Systems Engineering. International Symposium of IS13 (submitted), INCOSE, Jacksonville, FL, 24-27 June.

39. First Pass: 12 O'clock Clockwise (if comfortable)Then Think-Across Until Consistent & Complete Projected Operational Story "When I am working on a problem, I never think about beauty, but when I have finished, if the solution is not beautiful, I know it is wrong." -- R. Buckminster Fuller Quality Evaluation Architectural Concept & Integrity Closure Matrix (Design) Response Situation Analysis Response AbilityTools & Process Reality Factors Identified RRS Principles Synthesis “Quality is practical, and factories and airlines and hospital labs must be practical. But it is also moral and aesthetic. And it is also perceptual and subjective.” -- Tom Peters ConOps Objectives & Activities