Presentation is loading. Please wait.

Presentation is loading. Please wait.

9:1 attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

Similar presentations


Presentation on theme: "9:1 attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,"— Presentation transcript:

1 9:1 attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis, Synthesis, and Performance ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis, Synthesis, and Performance Session 9 – Perspectives: Developing Proficiency and Culture School of Systems and Enterprises Stevens Institute of Technology, USA File5.5 Your Class web-page:www.parshift.com/678/ L3.htmwww.parshift.com/678/ L3.htm Support docs & links:www.parshift.com/678/support.htmwww.parshift.com/678/support.htm File

2 9:2 attributed copies permitted FEEDBACK REVIEW Closure Matrix + Personal Term Project ConOps Web

3 9:3 attributed copies permitted 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 start thinking…later, in a short while EXERCISE

4 9:4 attributed copies permitted Education scientist Sugata Mitra 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. Sugata Mitra'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, Sugata Mitra 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." Guest Speaker – Sugata Mitra The child-driven education (File17)File17) Video and text above at:

5 9:5 attributed copies permitted 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

6 9:6 attributed copies permitted Integration Fundamentals Tools Perspective Analysis Synthesis 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

7 9:7 attributed copies permitted Culture and Proficiency Development Operational models Maturity stages Quick Review Process Sequence

8 9:8 attributed copies permitted 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] Sometimes They Just Build It Like You Designed It 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.

9 9:9 attributed copies permitted Project Yourself Into Your Design Feel What It’s Like to Be There Walk Around Look Around Interact

10 9:10 attributed copies permitted Future Casting with Stories Scientific 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 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)

11 9:11 attributed copies permitted

12 9:12 attributed copies permitted 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?

13 9:13 attributed copies permitted 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 EXERCISE

14 9:14 attributed copies permitted BREAK

15 9:15 attributed copies permitted 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. Redwood Center for Theoretical NeuroscienceNumenta 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.On Intelligence Guest Speaker – Jeff Hawkins Brain science is about to fundamentally change computing (21 min)21 min Video and text above at:

16 9:16 attributed copies permitted Outage ManagementCompetency Development Proactive Assessment and Competitive Evaluation Innovative Agile ResilientFragile A C B Innovative Agile ResilientFragile A C B Customer Responsiveness Innovative Agile ResilientFragile A C B Comparing Companies A, B, C Response Proficiency Maturity Model Metric WorkingCompetitive Development StagesFocusKnowledgeProactiveReactive 0 AccidentalPass/FailExamplesLuckyNone 1 RepeatableTimeConceptsCreationCorrection 2 DefinedCostMetricsImprovementVariation 3 ManagedQualityRulesMigrationExpansion 4 MasteredScopePrinciplesModificationReconfig'tion Metric WorkingCompetitive Development StagesFocusKnowledgeProactiveReactive 0 AccidentalPass/FailExamplesLuckyNone 1 RepeatableTimeConceptsCreationCorrection 2 DefinedCostMetricsImprovementVariation 3 ManagedQualityRulesMigrationExpansion 4 MasteredScopePrinciplesModificationReconfig'tion Resilient Agile Innovative Fragile Reactive Maturity Modeling

17 9:17 attributed copies permitted Enterprise Change Proficiency Profile Maturity Working Metric Change Competencies Stage Knowledge Focus Proactive Reactive 0 AccidentalExamplesPass/FailNoneNone 1 RepeatableConceptsTimeCreationCorrection 2 DefinedMetricsCostImprovementVariation 3 ManagedResponsibilitiesQualityMigrationExpansion 4 Mastered PrinciplesScopeModificationReconfiguration Analytical Guide for Establishing Competitive Strategy and Improvement Targets Could show where your company and/or its processes are agile!

18 9:18 attributed copies permitted 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. Change Proficiency Maturity Stages

19 9:19 attributed copies permitted 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. Change Proficiency Maturity Stages

20 9:20 attributed copies permitted 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. Change Proficiency Maturity Stages

21 9:21 attributed copies permitted 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. Change Proficiency Maturity Stages

22 9:22 attributed copies permitted 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. Change Proficiency Maturity Stages

23 9:23 attributed copies permitted 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. Change Proficiency Maturity Stages

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

25 9:25 attributed copies permitted Maturity Fit to the Times/Needs Grouped by Industry Priority FutureCurrent 72%79% Remmele FutureCurrent Industry Priority Maturity Critical Business Practice 4.01Strategic Plan Vision 4.02Strategic Plan Dissemination 4.03Strategic Plan Buy-In 3.04Capital Investment Justification 3.05Infrastructure Investment Just. 3.56Business Eng. Investment Just. 2.57Business Unit Relationships 4.08Employee Relationships 0.09Partner Relationships 1.010Supplier Relationships 3.011Customer Relationships 0.512Information Sys. Unit Relationships 2.013Production Unit Relationships 4.014Product Innovation Management 4.015Process Innovation Management 4.016Procedure Innovation Mgmnt Strategy Innovation Management Knowledge-Portfolio Strategy 3.019Knowledge Generation 2.020Knowledge Capture 4.021Knowledge Mobilization 3.022Leading Indicator Metrics 1.523Operating Metrics 3.024Valuation Metrics

26 9:26 attributed copies permitted 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 9:27 attributed copies permitted Part 1: Concepts That Form the Core of Value Propositioning 1On The Nature of Value and Value Propositions 2On The Nature of Decision Makers and Champions 3On The Nature of Problems and Solutions 4On The Nature of Knowledge and Context 5On the Nature of Trust and Risk 6On The Nature and Effect of Competition 7On The Nature of Competency and Talent Part 2: Logic That Structures Core Concepts and Drives Decision Making 8The Logic of Core Concepts 9The Logic of Misperception (pdf-file) 10The Logic of Individual Decision Making 11The Logic of Group Decision Making 12The Logic of Perception Formation 13The Logic of Multi-Benefit Valuation 14Confusion With Technology and ROI Chapter 9 PDF download:

28 9:28 attributed copies permitted Concepts That Enable Agility by as needs skills of Decision Champion ROI Development Perception Influencing Communi- cation Trust Building Focused Educating Focused Learning Business Math Focused Clarity Risk Reduction as Knowledge Development as Decision Maker ROI Development Perception Influencing Communi- cation Trust Building Focused Educating Focused Learning Business Math Focused Clarity Risk Reduction as Knowledge Development push-pull cross links needs skills of Agility Knowledge Management consists of practices and processes for Response Ability Value Propositioning to enable response to have awareness

29 9:29 attributed copies permitted Guest Speaker: Dave Snowden Introduction to the Cynefin Framework Video: Text: Dave Snowden (Wikipedia) File8.5 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 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. 70 minute full theory Video & Slides:

30 9:30 attributed copies permitted The Cynefin Framework (Ken-ev-in) 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. David J. Snowden and Mary E. Boone A Leader’s Framework for Decision Making. Harvard Business Review. November.

31 9:31 attributed copies permitted Project Context Defines the Necessary Approach 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 must sense, 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. David J. Snowden and Mary E. Boone A Leader’s Framework for Decision Making. Harvard Business Review. November.

32 9:32 attributed copies permitted Agile-Systems Engineering 1/6 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. INCOSE SE Handbook V4: New Agile Systems Engineering section content

33 9:33 attributed copies permitted Agile-Systems Engineering 2/6 : 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 9:34 attributed copies permitted 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. Agile-Systems Engineering 3/6 : Architecture

35 9:35 attributed copies permitted 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. Agile-Systems Engineering 4/6 : Principles

36 9:36 attributed copies permitted 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? Agile-Systems Engineering 5/6 : Requirements

37 9:37 attributed copies permitted 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 Engineering both 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 Development as 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 agile system/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. Agile-Systems Engineering 6/6 : Confusions

38 9:38 attributed copies permitted "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 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 First Pass: 12 O'clock Clockwise (if comfortable) Then Think-Across Until Consistent & Complete Projected Operational Story Architectural Concept & Integrity Response Situation Analysis RRS Principles Synthesis ConOps Objectives & Activities Reality Factors Identified Closure Matrix (Design) Quality Evaluation Response Ability Tools & Process


Download ppt "9:1 attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,"

Similar presentations


Ads by Google