Agile Systems 101 Seminar and Tutorial/Workshop

Agile Systems 101
--------------
Active Systems-Engineering and Operational Management
of
Reconfigurable
Process and Product Architecture

Seminar and Tutorial/Workshop
Last Updated: 2 March 2012

Rick Dove
Taos County, New Mexico, dove@parshift.com, 575-586-1536
PI/CTO/CEO, Paradigm Shift International
Adjunct Professor, Stevens Institute of Technology

Download this seminar: www.parshift.com/s/AgileSystems-101.pdf
(updated asynchronously from time-to-time)
rick.dove@parshift.com, attributed copies permitted 1

Objective: System X-Ray Vision

http://awespendo.us/animemangacomics/kermit-at-the-doctor/


Please reserve questions until after the presentation.
Two moments of silence during the presentation will allow you
to write down questions for later discussion.
Slides are numbered if you want to reference them in your questions.

Content
Example: QRC Aircraft Refurb
Necessary & Sufficient Architectural Concept Pattern (ACP)
Examples: Architectural Concept Patterns in Many Domains

Case: Silterra Agile Enterprise-IT (ERP etc)
Case: Silterra Agile Project Mgmnt/Development Process

ACP echoed in biology and complex systems
Agility Defined, Metrics, and Wrap Up
References

When seminar opens a workshop, additional activity includes:
Full-Day Workshop Exercise (3-4 Hr + collaborative group brief out)
Half-Day Workshop Exercise (1-2 Hr + collaborative group brief out)

Some Problems Needing an Agile Architecture
QRC
Security as agile as the adversary
DOE wants a physical-security design strategy delivering value for 50 years
JTRS interoperability
SOA value and value-delivery understanding
DoD force transformation
Agile Systems-Engineering (the system development life-cycle)
Agile-Systems Engineering
Agile Software Development compatible with CMMI
Agile Software Development that produces agile software
Acquisition & contract policy that enables agile development processes
Getting there from here (reality factors that need harmoniously addressed)

• sustainable systems
• resilient/survivable systems
• evolving systems
• proactive/innovative systems
• dynamic systems of systems
• self organizing systems


Problem: Aircraft Refurb QRC
(Boss 2010) Agile Aircraft Installation Architecture In a Quick Reaction Capability Environment

 Mission system installation in military acquisition context
 Customer’s need for the latest technology
 Technology advances are creating new mission systems at
an increasing rate, driving the demand for QRC.
 Goal is to shorten the completion time without
compromising quality
 Mission requirements and “boxes” often change late
 Army wants QRC for intelligence surveillance
reconnaissance (ISR) to be robust, scalable, tailorable
 Air Force wants QRC challenges continually met as
success is measured by rapidly adapted EW


On the Capability Part of
Quick Reaction Capability
 This is about QRC, a misleading buzzword.
 Typical Strategy: get it faster by relaxing requirements,
reducing quality, working harder-not-smarter, costing
more, increasing risk of performance short-fall.
 You don’t get to do it over again.
An influx of compromised systems to the fleet
reduces the average system-population quality.

What is needed:
Agile Process Architecture (CAPABILITY)
for Quick Reaction
Narrow focus here: Installation of heating, cooling, power, & racks


Enabling Rapid, Low-Cost, Predictable Installation

Architectural Concept for
Reusable Installation Infrastructure

Enabling System & Process Agility The aircraft installation
infrastructure is
modified… once.
The SIL* has a duplicate
infrastructure.
“Everything” is fully
integrated and tested in
the SIL … before the
aircraft arrives.
Aircraft installation is a
simple relocation of
pluggable modules.
Minimizes aircraft
downtime and
eliminates custom
installation work.
Parameter Nature of Standard
Space Racks shall be designed in preset widths, depths and heights.
Power Each rack shall have a maximum kW equipment load rating. Racks with multiple
power types (e.g. 115 VAC 400 Hz and 28 VDC) limits should be set on each type.
Weight Each rack shall have a maximum equipment weight rating.
Cooling Each rack shall rate the kW cooling capacity at a specified exhaust temperature.
Physical Rack mounting provisions, cooling connections, and electrical connection interfaces
Interfaces shall have standard locations and configurations.
*SIL: System Integration Lab rick.dove@parshift.com, attributed copies permitted 8

Background: Agile vs. Traditional Power Distribution
Traditionally a breaker centralized panel distributes power to each
box. Each box typically requires its own circuit breaker creating an
interface for every box and many wire routing paths. Some aircraft contain over
1000 boxes, and wire routing becomes a large modification effort.
To reduce the number of interfaces, decrease wire routing effort, and allow rack
modularity, it is proposed that the secondary power distribution for rack mounted
boxes be moved from the aircraft to within the rack itself. A single breaker would
provide power to the rack, and a secondary breaker panel within the rack would
distribute power to each box. Using solid state power controllers, or SSPCs,
combines the function of a relay and a circuit breaker into a single device that is
controllable through a data bus. SSPCs be remotely operated, allow the power trip
point curve to be programmed rather than requiring a physical change to the
breaker wiring. This benefits a QRC program by simply re-programming an SSPC
instead of changing a breaker out and routing a new wire the entire length
between the breaker box and the rack.


Background: Modular Rack Cooling

Compared to wiring, air ducting is larger and more difficult to route effectively. For
this reason, the solution presented attempts to mitigate the rerouting effort of any
existing aircraft ductwork. The proposed cooling architecture is really a
combination of a cold air distribution subsystem that gets cold air from the
aircraft source to the boxes, and a hot air exhaust subsystem that must dispose
of the waste air. Although much more compact, this is similar to the hot aisle/cold
aisle method used in data center design.

Background: 10 RRS Principles (reusable/reconfigurable/scalable)
Self Contained Units. Racks are self contained units that can be inserted or
removed efficiently without affecting adjacent equipment or racks. Wiring and
cooling is part of the rack unit. Racks can be pre-built and tested in the shop without an
aircraft present.
Plug Compatibility. Standardized rack interfaces allow rack modules to be removed and re-
connected on multiple aircraft.
Facilitated Re-Use. Minimal standards facilitate reuse of boxes and racks by streamlining the
assembly and disassembly of rack configurations.
Flat Interaction. Rack structure, cooling, and power is provided in parallel allowing racks to
interface the aircraft resources directly rather than through a sequential dependence.
Failure or removal of one rack does not affect another.
Deferred Commitment. With adjustable cooling, programmable power, and reconfigurable
mounting, installation decisions can be deferred until maximum box definition is available.
Distributed Control and Information. Power and cooling control is localized within each
rack, minimizing wire runs, wiring effort, ducts, and ducting effort.
Self Organization. TBD, e.g., dynamic load balancing in response to cooling anomalies.
Evolving Standards. Rack interface standards can evolve to incorporate new interfaces like
liquid cooling, with a continuous job responsibility of process evolution management.
Redundancy and Diversity. Differences in box sizes and cooling-channel locations are
accommodated with a limited variety of standardized rack-assembly modules, which can be
configured to structurally accommodate multiple boxes of both similar and different sizes; and
to accommodate multiple boxes of both similar and different cooling entry and exhaust points.
Elastic Capacity. Racks are inserted/removed as needed, and mounting space, power
available, and cooling available scales proportionally. Rack cooling can be matched to head
load, and circuit trip points can be programmed for a range of power requirements.

Agile QRC Aircraft Installation Architecture
Modules

hardware boxes zones racks System Integration aircraft
Integrity Labs (SILs)
Management
Module pool & mix evolution system engineer
Module inventory condition material manager
Assembly in SIL production
Infrastructure evolution process engineer

Active

Infrastructure

Passive
small upgrade tech refresh large re-fit
Space use rules
Power distribution rules
Structural weight rules
Cooling standards
Physical Interfaces
Standards rick.dove@parshift.com, attributed copies permitted 12

Agile System: Class 1
Reconfigurable
necessary & sufficient architectural concept pattern:
actively managed drag-and-drop/plug-and-play
(Example: Unmanned Autonomous System Test - UAST)

Drag-and-Drop
Reusable
personnel tests sensors equipment DoD ranges Components


Reconfigurable

Drag-and-Drop
Reusable

Examples of Typical
Reconfigurable/Scalable
System Configurations

Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc


Reconfigurable

Drag-and-Drop
Reusable

Examples of Typical

Agile UAST Stds
High Level Arch
Test Procedures Plug-and-Play Evolving
Security Stds Passive Infrastructure
Safety Stds Rules/Standards/Principles



Reconfigurable

Drag-and-Drop
Reusable

Plug-and-Play
System assembly: Who? Evolving Active Infrastructure
Responsible-Party Designation

Examples of Typical

Agile UAST Stds
High Level Arch



Reconfigurable

Drag-and-Drop
Reusable

Component inventory: Who? Plug-and-Play

Examples of Typical

Agile UAST Stds
High Level Arch



Reconfigurable

Drag-and-Drop
Reusable

Component mix: Who?

Examples of Typical

Agile UAST Stds
High Level Arch



Reconfigurable

Drag-and-Drop
Reusable

Component mix: Who?
Infrastructure evolution: Who? Responsible-Party Designation

Examples of Typical

Agile UAST Stds
High Level Arch
VR Immersion Stds



Reconfiguring
(Example: Unmanned Autonomous Swarm System-of-System under Test)

Drag-and-Drop
Reusable
UAS mission coordination tasks sensors Components

Component mix: What?
Component inventory: What? Plug-and-Play
System assembly: What? Evolving Active Infrastructure
Infrastructure evolution: What? Systemic Regulation

Examples of Typical

Agile UASoS Stds
Engagement Stds
Cooperation Stds Plug-and-Play Evolving
Behavior Stds InterOp Passive Infrastructure
Comm Stds Rules/Standards/Principles
Ethical Stds



Multi-Range UAS Testing System
(highly stylized architectural concept diagram)
(Dove 2008b) Embedding Agile Security in Systems Architecture)

As an emergent property
security does not come
in a separate box, e.g.,
personnel are security trained,
sensors procedures tests personnel test equip ranges …et al.
equipment is self-secure.

1 component mix: UAST Program Manager Four active responsibilities,
2 component inventory: Range Master each with embedded security
3 test sys assembly: Test Manager personnel as integrated
4 infrastructure evolution: UAST Program Manager collaborative team members.
INFRASTRUCTURE
active

sub-sys test full system test swarm system test
Test system assembly is
constrained by
test configuration standards
passive

informed by security policy.

security policy 5 Security policy informs all
HLA interop stds other passive infrastructure
test config stds
safety stds standards, and evolves
UAS policy/stds simultaneously with each.

indicative configurations of test varieties
Security is embedded in architecture at points 1-5. Additionally, encapsulated
components have internal security distrustful of other components in general.


(Dove 2009) On How Agile Systems Gracefully Migrate Across Next-Generation Life Cycle Boundaries

Crossing Next-Generation Life Cycle Boundaries
for Home Entertainment Technology Migration
Modules

Integrity amplifiers speakers signal tuners playback units video displays content sources
(tape, CD, DVD) ) (TV, computer) (TIVO,P2P)
Management
Component mix: Mfgrs
Component inventory: Stores
System assembly: User/Owner
Infrastructure evolution: Industry Assocs

Active

Infrastructure

Passive
Audio tape Video media Net in/out

Physical connection
Analog interconnect
Power
Video/Surround
Digital/Internet
Rules/Standards
roughly… ‘40s/’50s ‘90s ‘00s

(Dove 2009) On How Agile Systems Gracefully Migrate Across Next-Generation Life Cycle Boundaries

Crossing Next-Generation Life Cycle Boundaries
for Internet Protocol Migration
Modules

filters appliances end points,
Integrity routers switches DNS Servers (eg IDS, Firewall) (eg, xml) NICs, NOMs
Management
Component mix: Vendor Community
Component inventory: Vendor Community
System assembly: Subnet Owners
Infrastructure evolution: Int. Eng. Task Force

Active

Infrastructure
NCP IPv4 IPv6
Passive era era era

NCP
Wire standards
TCP/IPv4
Wireless stds
Optical stds
Rules/Standards IPv6
rough operational start… ’70s ’80s/’90s ’00/’10s

(Dove 2008a) Relating Agile Development to Agile Operations

Agile Software- Development Process

Components

Integrity developers/ team leaders owners/users processes tests codes/
engineers designs
Management
Component mix Process mgr
Component inventory Team leaders
System assembly Team leaders
Infrastructure evolution Process manager

Active

Infrastructure

Passive
Iteration 1 Iteration 2 Iteration n

Emergent requirements
Iterative convergence
Incremental delivery
Self organizing
Rules/Standards Time
(key core practices detailed in
a process manual) 24
rick.dove@parshift.com, attributed copies permitted

(Dove 2008a) Relating Agile Development to Agile Operations

Agile Software Development-thru-Operations Process

Components

Integrity developers/ team leaders owners/users processes tests codes/
engineers designs
Management
Component mix Process mgr ???
Component inventory Team leaders ???
System assembly Team leaders ???
Infrastructure evolution Process manager ???

Active

Infrastructure

Passive
Development Migration Operation

Emergent requirements
Iterative convergence
Incremental delivery
Self organizing
Rules/Standards Time
(key core practices detailed in
a process manual) 25
rick.dove@parshift.com, attributed copies permitted

A Moment of Silence

Write down questions in your mind … so far


Case: Silterra
Background

October 1999 (dot.com bubbling, semiconductor slump ending)
Silterra is a start-up semiconductor foundry in Malaysia,
with interim USA top management and ex-pat process experts
Funded mainly by government designated sources
Mixed Cultures: 60% Malay, 30% Chinese, 10% Indian
Few employees have built or run such a company, and have little
idea about what they will need or want in business processes.
CEO has a vision for a preemptive modern-day competitor...
Goal: Build a uniquely superior foundry business
Strategy: Best practices + Agile IT infrastructure
CIO (interim exec) is writing book on systems agility...
Goal: Meet CEO's goals with Agile Systems design principles
Strategy: Design a differentiation strategy and apply principles

(Dove 2005) Fundamental Principles for Agile Systems Engineering.


Opportunity

New company:
No operating culture, performance metrics, or infrastructure legacy.
+
New technology:
Internet. Broadband. PDAs. XML. Enterprise IT. eBusiness.
+
New environment:
More uncertain, connected, knowledgeable. Faster. Always changing.
+
New customer expectations:
Personal attention. Immediate response. Self service.
Lots of information.

= New Opportunity
to design a company
fit to the new and changing environment,
and focused on new values


Guiding Concepts
Enterprise IT

Value: Must not dictate or limit corporate capability
Remove the ERP/Technology lock-in
Provide freedom to use best tools
Enable fast use of new technology in support of business strategy

Value: Must exploit new electronic connectivity opportunities
Real-time visibility of all enterprise activity and information
Everyone wired for immediate self-service
Dashboards and "agents" to bring focus on desired information
Assist and structure key management processes
Quick connections to information-sharing partners

Attitude: InfoTech shifts from financial reporting to enterprise infrastructure
View as a logistics service, not as a financial function
Distribute control and responsibility to the users

ERP: Enterprise Resource Planning

Refined Objectives
Supporting strategy with best-fit tools
is enabled rather than inhibited

Switching/upgrading to new technology and applications
is enabled rather than inhibited.

Accommodating custom electronic "partner" relationships

Integrating new plants, facilities, mergers, and acquisitions

All information is accessible electronically
to those authorized to see it.

Electronic "dashboards" will provide real-time vision and monitoring
of operational and strategic activities.

Provide competitive advantage through
enterprise visibility, adaptability, and technology


Response Situation Analysis – IT Infrastructure
Response Metrics: c=cost, t=time, q=quality, s=scope

Proactive Dynamics
 Creating new customer/supplier/partner business net-link [t,q,s]
 Creating acquisition business net-link [t,q,s]
 Creating interface to a new application [t,c,s]
 Improvement of interface performance [t,s]
 Migration to NT and COM/DCOM [c,q]
 Addition of new foundry facility [q,s]
 Addition of new customer/supplier/partner data interface [t,s]
 Addition of new industry data-standards [t,s]
 Replacing the bus vendor [c,t,s]

Reactive Dynamics
 Correcting an interface bug that surfaces later in time (original engineer gone) [t,q]
 Variation in quality of data from production MES system [t]
 Variation in competency/availability of infrastructure operating personnel [t,s]
 Variation in real-time on-line availability of applications [t,s].
 Expand the number of interfaced applications and business net-links [s]
 Reconfiguration of an interface for an application upgrade/change [t,c,q,s]


General Strategy
Business System Analyst (BSA) Group:
 Assigned to IT-assist dept managers (cross dept responsibilities)
 Business Process IT application configuration/evolution
 IT tool selection/acquisition

Strategic System Analyst (SSA) Group:
 Evolution of infrastructure framework
 Enforcing infrastructure usage rules

User Collaboration:
 Mandatory Response Situation Analysis (agility-tool)

COTS Applications: No customization of purchased software

IT Internal Responsibilities – not to be outsourced:
 Infrastructure architecture design and evolution
 Management of installation/integration projects
 Configuration of applications

Enterprise IT Infrastructure Design

MyFab Oracle Oracle Adexa People My Other Other
11i Apps ERP dB Planner Soft Apps Projects Apps dBases

XML Enterprise Bus
A&T =
Fab =
Assembly & Test Plant
Foundry Plant
Fab #1 Fab #n A&T #1 A&T #n

• = Bus Interface Module (BIM)
• = ETL Interface Modules
• MyProjects = Web-accessible strategic-project portfolio manager
• MyFab = Web-accessible operations transparency

www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf


Infrastructure – 10 RRS Principles Applied
Evolving Standards (Framework) - SSA group, XML, message data definitions, ETL-
interface specs, ETL template spec, BMI spec.
Encapsulated Modules - Applications, data bases, ETLs, bus-interface modules (BIMs),
bus, BSAs, SSAs.
Facilitated Plug Compatibility - XML, message-data definitions, BIM spec, ETL-interface
spec, rule on COTS.
Facilitated Module Reuse - BSA group, business process maps, ETL templates, mandatory
rule on COTS.
Redundancy and Diversity - Multiple app versions, multiple bus paths, replicated apps at
each physical locations, ERP multiple-vendor apps, rule on mandatory user collaboration,
cross-trained BSA departmental responsibilities.
Elastic Capacity - Virtually unlimited bus extension and capacity with compartmented
parallelism.
Distributed Control and Information - Separate apps and data bases at each physical
location, BSA independence and team collaboration, SSA/BSA separation, rule on mandatory
user collaboration.
Facilitated Deferred Commitment - Publish subscribe asynchronicity, ETL created after app
is stable, rule that response-requirements be developed before solutions considered.
Flat Interaction - Direct app-to-app dialog, BSA group user/management access and team
collaboration.
Self-Organization - BSA autonomy, BSA teaming, SSA autonomous control, publish-
subscribe options to pull information as needed.
ETL=extract/transform/load, BSA=business systems analyst, SSA=strategic systems analyst, BIM=bus interface module, COTS=common off the shelf.


Project Development Process – Strategy/Rules

- Vendor is responsible for total solution: HW and SW
- Requirements will not change during implementation
- No expedient customization allowed
- Three Phase Implementation Sequence:
P1: Out-of-box best-practice from vendor – supporting the company
Vendors configure the applications
P2: BSA-developed business process rules
Vendors + BSAs configure the applications
P3: Refined business processes
BSAs configure the applications
- No violation of infrastructure rules (repeatedly invoked)
- Don't say it can't be done, tell what is needed to do it (repeatedly invoked)


Encapsulated Development Process

Develop Develop Manage Conduct
Architecture Business Rules Outsourced Testing and
and Design and Specs Development User Training
3-Phases

Days Days Template
0-90
V2 …….. V2 60-90
V3 …….. V3
ssa bsa
120 days bsa 60 days bsa
91-180 150-180 Alpha
Prog. Proj. …….. V2
bsa V2 bsa …….. V3
IT V3 IT
bsa bsa
Mgr Mgr
ssa ssa 181-270 240-270
bsa bsa Beta
bsa ……..
bsa IT ……..IT
bsa V2 V2 V3 V3

- Designed to Accommodate Requirements Evolution -

www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf


Development Process – 10 RRS Principles Applied

Evolving Standards (Framework) – 3-phase implementation (out-of-box, desired, refined), 90-
day phases max, no spec/requirement changes once phase begins, internal total infrastructure
design responsibility, vendor total application responsibility (HW/SW).
Encapsulated Modules – Bus vendor (BEA), ERP app vendors (Oracle, PeopleSoft, Adexa),
database vendor (Oracle), app requirements (BSAs), infrastructure requirements (SSAs),
infrastructure imp (IT).
Facilitated Plug Compatibility – vendor rules clear, agreed in advance, and managed.
Facilitated Module Reuse - BSA group, business process development system.
Redundancy and Diversity - Cross-trained BSA dept responsibilities, mixed outsource/insource
resources and expertise.
Elastic Capacity – Outsource implementers managed by small internal group.
Distributed Control and Information - BSA business rule development autonomy, SSA
infrastructure rules/design autonomy, vendor implementation autonomy.
Facilitated Deferred Commitment – Implementation doesn't begin until requirements are firm.
Flat Interaction – All vendors are peers, BSAs have direct access to everyone.
Self-Organization - BSA team relationships and assignments.
ERP=enterprise resource planning, BSA=business systems analyst, SSA=strategic systems analyst, HW/SW=hardware/software


Effective Predictability

ERP on time, below budget, on spec
 3 months functional ERP "best practice" (Phase 1)
 3 months later preferred business processes (Phase 2)
 3 months later refined business processes (Phase 3)

HRM modularized and
added below time, on budget, on spec

Adexa planner
added on time/budget/spec

Existing Time and Attendance system
modularized and integrated on time/budget/spec


Wish Typical Imp Actual Imp
ERP in 12 mos total 24-36 mos 121,2
75% of license budget 200-300% 75%
$10 Million (5 + 5) $15-25 Million $9 Million

HRM in 6 mos 12-18 mos 5 mos

HOW??
 Principle-based installation/integration methodology and management
 Adherence to methodology (ie, effective management)
 BSAs utilizing MBW tool to develop and capture business processes
 BSAs taking responsibility for integrating ERP with users
 Bus architecture connecting ERP with HRM
 Experienced outsource to help integrate ERP/CIM2,3 (did it before)
 Expertise in agile system design and implementation
Notes: 1) 12 months = 3 mo concept design and vendor selection + 9 mo implementation,
time included infrastructure bus/ETL/BMI implementation, but not shop floor (CIM) integration (+6)
2) New Oracle 11i ERP with typical bugs and lack of documentation of new systems
3) Additional 6 mos due to independent CIM system shake out


Silterra Agile ERP System – Development Process

Components/Modules

Integrity BSAs SSAs Departments Contractors COTS ETLs & BIMs
Apps
Management
Module mix BSAs

Module inventory Proj Mgr

System assembly Dept User
Infrastructure evolution Prog Mgr

Active

Infrastructure

Passive
Phase 1: Out of Box Phase 2: Desired Phase 3: refined

Fixed reqs during phases
No change to COTS
Bus XML comm only
Internal integ. mgt.
Contractor peers
ETL Template
Rules/Standards

Silterra Agile ERP System – Operational
System examples are SOA-like instances of departmental needs

Components/Modules

Integrity COTS COTS Custom App Data Custom
ERP Apps Other Apps Other Apps ETLs Bases ERP Apps
Management
Module mix BSAs

Module inventory BSAs

System assembly Dept Users & BSAs
Infrastructure evolution SSAs

Active

Infrastructure

Passive
EOM Financial Rpt Customer MyFab Planning/Scheduling

Enterprise bus
BMI
XML protocol
ETL template
Rules/Standards


A Moment of Silence

Write down questions in your mind … so far


Bow Tie Process Echo from Science
Our work was based on observation of many real systems that exhibited agile
characteristics in a large variety of enterprise domains.
Since then, we have discovered a body of science behind the architecture,
with work carried out by collaborators:
• John Doyle, John G Braun Professor of Control & Dynamical Systems, Electrical
Engineering, and BioEngineering at Caltech
• Jean Carlson, Department of Physics, UC Santa Barbara
• Marie Csete, (now) Staff Physician at UC San Diego Anesthesiology

modules passive infrastructure system variety

http://en.wikipedia.org/wiki/Bow_tie_(biology)

Bow Tie Pattern in the Immune System
Millions of random infection detectors generated continuously by fixed rules and modules in the “knot”
(Dove 2010). Pattern Qualifications and Examples of Next-Generation Agile System-Security Strategies.

Speculative generation and mutation of detectors recognizes new attacks like a biological immune system
(Dove 2011a) Patterns of Self-Organizing Agile Security for Resilient Network Situational Awareness and Sensemaking

Adaptable Immune System
V--D--J V--J Bow-Tie Antigen-Detector Generator
Y detector
antibody
B-Cell

cell Modules

Integrity random
123 V segments 27 D segments 6 J segments nucleotides
Management
Module pools and mix evolution genetic evolution
Module inventory condition massive redundancy
Detector assembly bone marrow and thymus
Infrastructure evolution genetic evolution

Active long short long short long short
chain chain chain chain chain chain

Infrastructure

Passive
detector sequence n detector sequence n+1 detector sequence n+2

Use one each V-J
Use one each V-D-J
Add random nucleotides
Combine two assemblies
Assembly Rules
(Dove 2010) Pattern Qualifications and Examples of Next-Generation Agile System-Security Strategies

On Passive infrastructure
…protocols are far more important … than are modules
Marie E. Csete and John C. Doyle. 2002. Reverse Engineering of Biological Complexity. Vol 295 SCIENCE, 1 March.
www.cds.caltech.edu/~doyle/CmplxNets/CseteDoyle.pdf

Consider the ubiquitous Lego toy system. The signature feature of Lego is the
patented snap connection for easy but stable assembly of components. The snap
is the basic Lego protocol, and Lego bricks are its basic modules.
We claim that protocols are far more important to biologic complexity than are
modules. They are complementary and intertwined but are important to
distinguish. In everyday usage, protocols are rules designed to manage
relationships and processes smoothly and effectively.
If modules are ingredients, parts, components, subsystems, and players, then
protocols describe the corresponding recipes, architectures, rules, interfaces,
etiquettes, and codes of conduct.
Protocols here are rules that prescribe allowed interfaces between modules,
permitting system functions that could not be achieved by isolated modules.
Protocols also facilitate the addition of new protocols and organization into
collections of mutually supportive protocol suites.
Like modules, they simplify modeling and abstraction, and as such may often be
largely “in the eye of the beholder.”
A good protocol is one that supplies both robustness and evolvability.


Defining Agility
Agility is effective response to opportunity and problem,
within mission ... always … no matter what.

An effective response is one that is: Metric
 timely (fast enough to deliver value), time
 affordable (at a cost that leaves room for an ROI), cost
 predictable (can be counted on to meet expectations), quality
 comprehensive (anything/everything within mission boundary). scope

An ineffective response is failure - there is zero tolerance for failure today.
You can think of Agility as Requisite Variety.
You can think of Agility as Proactive Risk Management.
You can think of Agility as Innovative Response in unpredictable situations.
You can think of Agility as Life Cycle Extension.

The trick is understanding the nature of agile-enabling concepts, and
how they can be applied to any type of system.

Domain Independent

Project Management
A
QRC Management
Resilient Agile Mission Management
A

Resilient Agile
B
Resilient Agile

Fragile C Innovative B
C
B C

Fragile Innovative
Fragile Innovative
Comparing Companies A, B, C. A

Assessment/Evaluation
4
Response Proficiency Maturity Model
Metric Working Competitive Development
3 Stages Focus Knowledge Proactive Reactive
Reactive

0 Accidental Pass/Fail Examples Lucky None
2
1 Repeatable Time Concepts Creation Correction
2 Defined Cost Metrics Improvement Variation
1
3 Managed Quality Rules Migration Expansion
4 Mastered Scope Principles Modification Reconfig'tion
0
0 1 2 3 4 Maturity has been observed to progress sequentially
Proactive
(Dove 1996) An Agile Enterprise Reference Model – with a case study of Remmele Engineering

Eight principle tools are brought to bear when
designing or analyzing a system for agility
Projected
Operational
Story
Architectural This
Quality
Concept Presentation
Evaluation
& Integrity Focus

Closure Response with a
Matrix Situation bit of
Design Analysis this

Reality RRS and a
Factors Principles bit of
Identified Synthesis this
It is suggested that new ConOps
initiates begin at 12 o’clock Objectives
and move clockwise & Activities

Agile System and Project Management Design

Risk and Uncertainty Management Through:
 Creation of drag-and-drop response options
 Enabling effective plug-and-play use of options
 Agility management through active infrastructure responsibility
that constantly evolves the system and keeps it currently effective

Architecture here is Structure and Strategy…depicting ConOps
What are the pieces and what are their relationships
that enable and constrain response under uncertainty


References and Supportive Readings
(Boss 2010) Jason Boss and Rick Dove. Agile Aircraft Installation Architecture In a Quick Reaction Capability Environment. INCOSE International
Symposium 14Jul2010, Chicago. www.parshift.com/Files/PsiDocs/Pap100712IS10-AgileAircraftInstallationArchitecture.pdf
(Ballard 2000) Herman Ballard. The Last Planner System of Production Control. PhD Thesis at Birmingham University.
www.leanconstruction.org/pdf/ballard2000-dissertation.pdf
(Csete 2002) Marie E. Csete and John C. Doyle. Reverse Engineering of Biological Complexity. Vol 295 SCIENCE, 1 March.
www.cds.caltech.edu/~doyle2/wiki/images/7/7a/Science1664-2002.pdf
(Csete 2004) Marie Csete and John Doyle. Bow Ties, Metabolism and Disease. TRENDS in Biotechnology 22(9), September.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.173.3019&rep=rep1&type=pdf
(Dove 1996) Rick Dove, Sue Hartman and Steve Benson. An Agile Enterprise Reference Model – with a case study of Remmele Engineering.
Agility Forum, Report AR96-04. http://www.parshift.com/Files/PsiDocs/AerModAll.pdf
(Dove 2001a) Rick Dove. Response Ability – The Language, Structure and Culture of the Agile Enterprise. Wiley.
(Dove 2001b) Rick Dove. Design Principles for Highly Adaptable Business Systems, With Tangible Manufacturing Examples. Book chapter in
Maynard's Industrial Handbook, McGraw Hill. http://www.parshift.com/Files/PsiDocs/Rkd8Art3.pdf
(Dove 2005) Rick Dove. Fundamental Principles for Agile Systems Engineering. Conference on Systems Engineering Research (CSER), Stevens
Institute of Technology, Hoboken, NJ, March. http://www.parshift.com/Files/PsiDocs/Rkd05032
(Dove 2006) Rick Dove. Engineering Agile Systems: Creative-Guidance Frameworks for Requirements and Design. 4th Annual Conference on
Systems Engineering Research (CSER), Los Angeles, CA, Apr 7-8.
http://www.parshift.com/Files/PsiDocs/Rkd060407CserEngineeringAgileSystems.pdf
(Dove 2008a) Rick Dove and Garry Turkington. Relating Agile Development to Agile Operations. Conference on Systems Engineering Research
(CSER), Redondo Beach, CA, April. www.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf
(Dove 2008b). Rick Dove. Embedding Agile Security in Systems Architecture. INSIGHT 12(2):14-17, INCOSE.
www.parshift.com/Files/PsiDocs/Pap090701Incose-EmbeddingAgileSecurityInSystemArchitecture.pdf
(Dove 2009) Rick Dove and Garry Turkington. On How Agile Systems Gracefully Migrate Across Next-Generation Life Cycle Boundaries. Global
Journal of Flexible Systems Management, Vol 10, No 1, pp 17-26, 2009. www.parshift.com/Files/PsiDocs/Pap080614GloGift08-
LifeCycleMigration.pdf
(Dove 2010) Rick Dove. Pattern Qualifications and Examples of Next-Generation Agile System-Security Strategies. IEEE International Carnahan
Conference on Security Technology (ICCST), San Jose, CA, 5-8 Oct.
www.parshift.com/Files/PsiDocs/PatternQualificationsForAgileSecurity.pdf
(Dove 2011a) Rick Dove. Patterns of Self-Organizing Agile Security for Resilient Network Situational Awareness and Sensemaking. 2011 Eighth
International Conference on Information Technology: New Generations. www.parshift.com/s/110411PatternsForSORNS.pdf
(Dove 2011b) Rick Dove. Self-Organizing Resilient Network Sensing (SornS) with Very Large Scale Anomaly Detection. IEEE International
Conference on Technologies for Homeland Security, Waltham, MA, 15-17Nov.
www.parshift.com/s/111115VeryLargeScaleAnomalyDetection.pdf
(Schumacher 2011) Col. Ludwig J. Schumacher. Dual Status Command for No Notice Events Integrating Military Response to Domestic Disasters.
Homeland Security Affairs, Vol 7, Feb. www.hsaj.org/?download&mode=dl&h&w&drm=resources/volume7/issue1/pdfs/&f=7.1.4.pdf
(Wolf 2004) Gene Wolf. The Point-and-Click Substation Matures. Transmission and Distribution World. Nov 1.
http://tdworld.com/mag/power_pointandclick_substation_matures/index.html with companion agile-system analysis at
http://www.parshift.com/Files/Essays/Essay069.pdf

System X-Ray Vision
The bones are depicted in the Architectural Concept Pattern.
All truly agile systems have the same basic structure and strategy.
Knowing this will change the way you “see” and evaluate a system.

http://awespendo.us/animemangacomics/kermit-at-the-doctor/


Application Workshop Exercise

An excellent example of agile project management is
(Ballard 2000) The Last Planner System of Production Control
Creates options to fully employ all resources all of the time on necessary tasks
that advance complex-project completion – regardless of whether scheduled
events occur as originally planned.

Workshop
Exercise: Read (Ballard 2000), depict the Architectural Concept Pattern (ACP)
or
Exercise: Read (Schumacher 2011), depict ACP and write 1-2 page evaluation


Background


Today's Agility Interest – Origin
1991 – SecDef funded project at Lehigh University to identify
next manufacturing competitive focus beyond Lean
– 13 companies participated full-time in 3-month workshop
– 2 vol report: 21st Century Manufacturing Enterprise Strategy
– Problem/opportunity defined (for manufacturing enterprises)
1992 – Agile Manufacturing Enterprise Forum founded at Lehigh,
funded by Texas Instruments and General Motors
– Purpose: Identify nature of Agile solution
– Method: Industry collaborative workshop groups
1994 – DARPA/NSF establish $5 Million x 5 year funding
– Name changed to Agility Forum (any kind of enterprise)
– Research steering group and agenda established
– 250+ orgs, 1000+ participants in focused workshop groups
– Conferences, papers, reference base, tools, reference model
1998 – Mission accomplished, Agility Forum dissolved
– Agility pursuit by industry and IT vendors entrenched

Response Situation Analysis Domains
Change Domain General Characteristic

Creation (and Elimination)

Proactive
Proactive

Improvement
Innovative
Migration Creates Opportunity
Takes Preemptive Initiative
Modification (of Capability)

Correction

Reactive
Reactive

Variation
Resilient
Expansion (of Capacity) Seizes Opportunity
Copes with Adverse Events
Reconfiguration


Response Able System Principles – RRS

Self-Contained Units (Modules) Evolving Standards (Framework)

Reusable
Scalable
Plug Compatibility Redundancy and Diversity

Facilitated Reuse Elastic Capacity

Reconfigurable

Flat Interaction Distributed Control and Information

Deferred Commitment Self-Organization


Agile Systems 101 Seminar and Tutorial/Workshop

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (20)

Similar a Agile Systems 101 Seminar and Tutorial/Workshop

Similar a Agile Systems 101 Seminar and Tutorial/Workshop (20)

Agile Systems 101 Seminar and Tutorial/Workshop