relating agile development to agile operations › files › psidocs › pap080404cser2008... ·...
TRANSCRIPT
Relating Agile Development to Agile OperationsRick Dove and Garry Turkington
initiating research into life cycle migration issueswithin and across system generations
an investigation ofan investigation ofResponse Ability Principles (RAP)
and their ability to illuminate agile system issues and enablers
Rick Dove, Stevens Institute of TechnologyCSER 2008, Redondo Beach, CA
April 4 2008
[email protected], attributed copies permitted 1
April 4, 2008
Engineering of Agile Systems and EnterprisesEngineering of Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and PerformanceFundamentals of Analysis, Synthesis, and Performance
SDOE 678SDOE 6781/4 of Graduate Certificate in Agile Systems and Enterprise
Based on research funded by OSD/DARPA managed by NSF/Navy 1991-1997
Class 1 Agility: Reconfigurable Systems
y g y yPurpose: Identify and understand the next competitive paradigmLehigh University, Agility Forum, and ~1000 people from ~250 organizations
Purpose: Lay a Foundation for Student Project Research(establishing efficacy and promise of RAP* tools)
Agile Enterprise and Agile Software Development (ASD): concepts with considerable exposure in the language.
Agility in the enterprise context – usually refers to system operation.Agility in the software context usually refers to system developmentAgility in the software context – usually refers to system development. Both are concerned with systems that must
deliver satisfaction in an environment of uncertainty and change.
This initial work began with the observation that ASD processes
generally ignore the agility of the resultant system.
The investigation:1) established commonalities across ASD processes 2) cast these common concepts in the domain independent
Response Ability architecture that grew from work at the Agility Forum 3) modeled how this development characterization could be extended into the
operational phase consistent with observed operational agility
[email protected], attributed copies permitted 3
operational phase consistent with observed operational agility
*RAP: Response Ability Principles*ASD: Agile Software Development
Observations
ASD is focused on brand-specific procedural gnits & gnats
Many people are trying to reach “accommodation” between CMMI and ASD
CMMI is measured by repeatability of the processCMMI is measured by repeatability of the process
ASD is measured by customer satisfaction
How to migrate toward ASD is a major & critical issue for many
Reality:
Requirements uncertainty on the increase?q y
Deadlines coming sooner?
Systems complexity on the increase?
Management wants plan-driven predictability, needs agile-driven quality?
Govt customers want plan-driven predictability, need agile-driven quality?
[email protected], attributed copies permitted 4
PerceivedEffectiveness100%
In-agile systemiteration
DeliveryTime
life-cycle end
OperationDevelopment
[email protected], attributed copies permitted 5
PerceivedEffectiveness
Agile system would continue ROI,but does age and can
100%
iteration In-agile system
DeliveryTime
life-cycle end
but does age, and cansuffer integrity failureOperationDevelopment
[email protected], attributed copies permitted 6
Response requirements categories (4 reactive and 4 proactive elements):R ti ti i ti i fi ti
RAP: Seven Thought-Guiding Frameworks
Reactive: correction, variation, expansion, reconfigurationProactive: creation, improvement, migration, modification
Response performance metrics (4 elements):Response cost time q alit scopeResponse: cost, time, quality, scope
Response-enabling design principles (10 elements):
Encapsulation Compatibility Reusability Redundancy/Diversity ScalabilityEncapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability,Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards
Design quality principles (3 elements):Requisite Variety Parsimony HarmonyRequisite Variety, Parsimony, Harmony
An overarching architectural philosophy (3 elements):Reusable modules Reconfigurable in a Scalable architecture (RRS)
System integrity responsibilities (4 elements):Module Inventory, System Re-configurationModule Evolution, Infrastructure Evolution
[email protected], attributed copies permitted 7
An architectural conceptual pattern:Drag-and drop modules in a plug-and-play infrastructure
Response requirements categories (4 reactive and 4 proactive elements):R ti ti i ti i fi ti
RAP: Seven Thought-Guiding Frameworks
Reactive: correction, variation, expansion, reconfigurationProactive: creation, improvement, migration, modification
Response performance metrics (4 elements):Response cost time q alit scopeResponse: cost, time, quality, scope
Response-enabling design principles (10 elements):
Encapsulation Compatibility Reusability Redundancy/Diversity Scalability
This paper’s focus
Encapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability,Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards
Design quality principles (3 elements):Requisite Variety Parsimony HarmonyRequisite Variety, Parsimony, Harmony
An overarching architectural philosophy (3 elements):Reusable modules Reconfigurable in a Scalable architecture (RRS)
System integrity responsibilities (4 elements):Module Inventory, System Re-configurationModule Evolution, Infrastructure Evolution
[email protected], attributed copies permitted 8
An architectural conceptual pattern:Drag-and drop modules in a plug-and-play infrastructure
Proactive Change Domains
Domain Definition and General Issues General CharacteristicsDomain Definition and General Issues
Proactive changes are generally triggered internally by the application of new k l d t t
Make or eliminate something. Issues are generally involved with the development of something new where nothing was before or the elimination of
General Characteristics
Creation(and
Elimination) knowledge to generate new value. They are still proactive changes even if the values generated are not positive and
nothing was before, or the elimination of something in use.
Incremental improvement. Issues are generally involved with competencies
Elimination)
activ
e
g peven if the knowledge applied is not new – self initiation is the distinguishing feature here. A proactive change is usually one
g y pand performance factors, and are often the focus of continual, open-ended campaigns.
F t l d f d t l
Improvement
Proa proactive change is usually one
that has effect rather than mere potential; thus, it is an application of knowledge rather than the invention or
Foreseen, eventual, and fundamental change. Issues are generally associated with changes to supporting infrastructure, or transitions to next
ti l t
Migration
than the invention or possession of unapplied knowledge. Proactive change proficiency is the wellspring of l d hi d i ti
generation replacements.Addition or subtraction of unique capability. Issues are generally involved with the inclusion of Modification
(Add/Sub
[email protected], attributed copies permitted 9
leadership and innovative activity.
something unlike anything already present, or the removal of something unique.
(Add/Sub Capability)
Agile System: Class 1Reconfigurable
Drag-and-DropReusable
Plug-and-Play Evolving Active Infrastructure
Components
System assembly: Who?
Component mix: Who?Component inventory: Who?
Examples of TypicalReconfigurable/ScalableSystem Configurations
Responsible-Party Designation Infrastructure evolution: Who?System assembly: Who?
System Configurations
Plug-and-Play EvolvingPassive InfrastructureRules/Standards/Principles
[email protected], attributed copies permitted 10
Rules/Standards/Principles
Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc
Agile System: Class 2Reconfiguring
Drag-and-DropReusable
Plug-and-Play Evolving Active InfrastructureSystem assembly: What?
Component mix: What?Component inventory: What?
Components
Systemic RegulationInfrastructure evolution: What?System assembly: What?
Examples of TypicalReconfigurable/ScalableSystem Configurations
Plug-and-Play EvolvingPassive InfrastructureRules/Standards/Principles
System Configurations
[email protected], attributed copies permitted 11
Rules/Standards/Principles
Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc
4 Integrity Responsibility ElementsThe “active” part of the infrastructure
maintaining sufficient inventory of modules ready for use (development people, team leaders, engagement procedures, reusable code modules, reusable test suites, etc), , , ),
new module addition and upgrade as new capabilities are needed (new developer skills, newly developed code modules, new test suites for new code new procedures as indicated by a changing situation usernew code, new procedures as indicated by a changing situation, user representatives intimate with next stage feature development needs, etc),
infrastructure evolution (improvements to existing rules and standardsinfrastructure evolution (improvements to existing rules and standards, new rules and standards, etc), and
assembly of modules into on-demand system configurations suitable for changing response needs (successive iterations in the development process).
[email protected], attributed copies permitted 12
Questions
Q1: Can domain dependent ASD* concepts be cast as domain independent RAP* architecture?
Q2: Could ASD cast as RAP architecture help reveal useful values and concepts?
Q3: Could ASD cast as RAP architecture provide a migration path for extending development-phase agility into the operational phase?
*ASD: Agile Software Development
[email protected], attributed copies permitted 13
RAP: Response Ability Principles
Manifesto for Agile Software DevelopmentW i b tt f d l i
http://agilemanifesto.org/
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, gwe value the items on the left more.
Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve MellorMike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
[email protected], attributed copies permitted 14
Martin Fowler Brian Marick
© 2001, the above authorsthis declaration may be freely copied in any form,
but only in its entirety through this notice. 14
Agility is the ability to both create and respond to change in order to profit in a
Quote From the Preface
respond to change in order to profit in a turbulent business environment.Rather than shrink from change, Agile organizations harness or embrace change b b i b tt th tit tby being better than competitors at responding to changing conditions and by creating change that competitors can’t respond to adequately. However, companies
t d t i h t l l f ilit thmust determine what level of agility they require to remain competitive, Agility is only an advantage relative to competitors – a copper mining company doesn’t need to be
il bi t h l fias agile as a biotechnology firm.Other aspects of agility are also important: nimbleness or flexibility on the one hand, and balance on the other. Agile gorganizations are nimble (able to change
directions quickly) and flexible (able to see how things that worked last week may not work as well next week). An Agile organization also knows how to balance structure and flexibility If
[email protected], attributed copies permitted 15
An Agile organization also knows how to balance structure and flexibility. If everything changes all the time, forward motion becomes problematic. Agile organizations understand that balancing on the edge between order and chaos determines success.
Agile Software Development Process(casting ASD as RAP architecture)
Drag & Drop Modules
developers owners/usersteam leaders processes tests codes
Module maintenance
IntegrityManagement
Infrastructure evolution
System assembly
Module inventory
PM PM PM
Infrastructure
Active
I t l d liIterative convergence
Emergent requirements
Iteration 2 Iteration nIteration 1Passive
[email protected], attributed copies permitted 16
Self organizingIncremental delivery
Plug & Play Rules Time
Agile Software Development Process(casting ASD as RAP architecture)
Drag & Drop Modules
developers owners/usersteam leaders processes tests codes
Module maintenance
IntegrityManagement
Infrastructure evolution
System assembly
Module inventory
PM PM PM
Infrastructure
Active
I t l d liIterative convergence
Emergent requirements
Iteration 2 Iteration nIteration 1Passive
[email protected], attributed copies permitted 17
Self organizingIncremental delivery
Plug & Play Rules Time
Agile Software Development ProcessQ1: Can domain dependent ASD concepts
Drag & Drop Modules
p pbe cast as domain independent RAP architecture? = Yes
developers owners/usersteam leaders processes tests codes
Module maintenance
IntegrityManagement
Infrastructure evolution
System assembly
Module inventory
PM PM PM
Infrastructure
Active
I t l d liIterative convergence
Emergent requirements
Iteration 2 Iteration nIteration 1Passive
[email protected], attributed copies permitted 18
Self organizingIncremental delivery
Plug & Play Rules Time
Agile Development-thru-Operations Process(moving responsibilities to operating personnel)
Drag & Drop Modules
Module maintenance
developers owners/usersteam leaders processes tests codesIntegrityManagement
PMPMPMInfrastructure evolution
System assembly
Module inventory
PM
Active
Infrastructure
MigrationDevelopment OperationPassive
I t l d liIterative convergence
Emergent requirements
[email protected], attributed copies permitted 19
TimePlug & Play RulesSelf organizing
Incremental delivery
Agile Development-thru-Operations ProcessQ2: Could ASD cast as RAP architecture help reveal useful values and concepts?St bilit f hit t d l it f h i t bl th t b
Drag & Drop Modules
Stability of architecture and perplexity of choice are two problems that may be mitigated with this RAP view.
Module maintenance
developers owners/usersteam leaders processes tests codesIntegrityManagement
PMPMPMInfrastructure evolution
System assembly
Module inventory
PM
Active
Infrastructure
MigrationDevelopment OperationPassive
I t l d liIterative convergence
Emergent requirements
[email protected], attributed copies permitted 20
TimePlug & Play RulesSelf organizing
Incremental delivery
Q3: Could ASD cast as RAP architecture provide a migration path for extending development-phase agility into the operational phase?
N thi f d t ll h ith d li d l t b b ilt hNothing fundamentally changes with delivery: new modules must be built when new requirements surface, and existing modules must be upgraded when they cease to perform effectively due to requirements change.
It matters not if the modules in question are people with certain skills, code that executes on a computer, tests that verify a new addition doesn’t cripple prior capability, procedures that discipline the system sustainment activity, and so on.
What does change is a lessening of development intensity, and an adjustment in who carries out the responsibilities for maintaining and sustaining system integrity.teg ty
[email protected], attributed copies permitted 21
Encapsulated Implementation ProcessSilterra Semiconductor Fabrication Facility, circa 2000
actual example
Develop Develop Manage Conduct
actual example
3-Phases
DevelopArchitectureand Design
DevelopBusiness Rules
and Specs
ManageOutsourced
Development
ConductTesting and
User Training
D D Template
Alpha
V2V2 …….. V3V3 ……..
60 days
Days0-90
91-180
Days60-90
150-180bsa
bsa
bsa120 daysssa
p
Beta……..
……..bsabsa V2V2
……..
……..ITIT V3V3
181-270 240-270
bsa bsa
bsa bsa
Proj.Mgr
Prog.Mgr
bsabsa ITITssassa
D si n d t Acc mm d t R quir m nts Ev luti n
V3V3bsa V2V2bsabsa IT
[email protected], attributed copies permitted 22
- Designed to Accommodate Requirements Evolution -
www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf bsa: business system analystssa: strategic system analystVn: vendor
Effective Predictability
this approach has worked
ERP on time, below budget, on spec3 months: functional ERP "best practice" (Phase 1)
this approach has worked
3 months later: preferred business processes (Phase 2)3 months later: refined business processes (Phase 3)
Wish Typical Imp Actual ImpERP in 12 mos total 24-36 mos 121,2ERP in 12 mos total 24 36 mos 12
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
[email protected], attributed copies permitted 23
www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf
Concluding RemarksRAP includes a design ethos that a “good” system satisfies three quality
i i l R i it V i t P i d Hprinciples: Requisite Variety, Parsimony, and Harmony. • Requisite variety would seem to be the driving force behind ASD: the
development process must be able to respond to requirements as they become evident and as they change – and it must be proactive in discovery, reactive in y g p y,accommodation.
• Parsimony is seen throughout the ASD varieties, especially in minimal documentation, deferring action on “possible” future needs, and “lean” avoidance of anything that doesn’t add immediate valueavoidance of anything that doesn t add immediate value.
• Harmony has been the rub: ASD appears in contradiction with acceptable best management practices as measured by plan-driven values.
Common disharmonious pronouncements: • No stability, as the architecture is vague and subject to whimsical change. • No way to measure progress, as the goals keep changing. o ay to easu e p og ess, as t e goa s eep c a g g
The RAP view depicted here provides a solid unchanging basis to the ASDprocesses that should counter the lack-of-stability perception.
[email protected], attributed copies permitted 24
As to the need for visible progress measurement, the core metric can only be the nature and speed of convergence on customer satisfaction – an issue we’ve not addressed, as yet.
The drag-and-drop/plug-and-play reconfigurable patterns depicted here are consistent with actual ASD practice and do not represent additional project cost to realize the long term continuation benefit in theproject cost to realize the long term continuation benefit in the operational phase.
Realizing the benefit is a matter of selection criteria in choosingRealizing the benefit is a matter of selection criteria in choosing appropriate user/owners for development-phase participation.
It is suggested that a strategy for continuing the ASD approach pattern asIt is suggested that a strategy for continuing the ASD approach pattern as depicted here, into operations, will lower the barriers for gaining ASD acceptance.
ROI in the operating phase is a requirement of all systems, whether explicitly recognized in system requirement “shall” statements or not, and savvy management responds to value propositions that provide y g p p p preasons for believing ROI will occur.
At today’s technology pace, a system that cannot incorporate new
[email protected], attributed copies permitted 25
At today s technology pace, a system that cannot incorporate new technology or respond to new competitive needs and customer demands becomes a liability, often before ROI is realized.
With Respect…
Boehm and Turner (2004) state on page 1: “Agility is the counterpart of discipline.”
We hold that agility is obtained and (especially) sustained only throughWe hold that agility is obtained and (especially) sustained only through discipline, and is a fleeting competency if that discipline is not vigilantly maintained by the four integrity responsibilities.
Highsmith (2002) states on page xxxi“Agility means balancing between structure and flexibility, so rigor is a vital part of any development process Agility focuses on thea vital part of any development process. Agility focuses on the flexibility side of the definition and rigor focuses on the structured side.”
We suggest the “focus” is a temporary artifact of introducing ASD into a e suggest t e ocus s a te po a y a t act o t oduc g S to aplan-driven world, and that ASD as espoused by its leaders is extremely rigorous.
[email protected], attributed copies permitted 26
It is time for ASD 2.0
Perceived
CSER Paper (April 2008)
PerceivedEffectiveness100%
TimeDevelopment
Agile system would continue ROI,but does age, and can suffer
strategy-lapse integrity failure
In-agile system
Operation
DeliveryTime
life-cycle end
GLOGIFT Paper (July 2008)PerceivedEffectiveness100%
InfrastructureMigration
Module MixModifications
p ( y )
agile system
[email protected], attributed copies permitted 27
DeliveryTime
Development Gen 2 OperationGen 1 Operation
Hi-Fi Migrates to 2nd Gen Home Entertainment Systems
Drag & Drop Components
amplifiers playback units(tape, CD, DVD) )
speakers video displays(TV, computer)
content sources(TIVO,P2P)
Component Mix:
IntegrityManagement
Mfgrs
signal tuners
Infrastructure evolution:
System assembly:
Component inventory:
Industry Assoc
User/Owner
Stores
Infrastructure
Active
PAnalog interconnect Physical connection
Video media Net in/outAudio tapePassive
[email protected], attributed copies permitted 28
Power
Plug & Play Standards‘90s
Video/Surround Digital/Internet
‘50s ‘00sroughly…
Internet Protocol Migration
Drag & Drop Components
routers DNS Serversswitches end points,NICs, NOMs
appliances(eg, xml)
Component Mix:
IntegrityManagement
Vendor Community
filters(eg IDS, Firewall)
Infrastructure evolution:
System assembly:
Component inventory:
IETF
Subnet Owners
Vendor Community
Infrastructure
Active
Wire standards NCP
IPv6eraPassive
TCP/IP 4
IPv4era
NCPera
[email protected], attributed copies permitted 29
Plug & Play Standards’80s/’90s
TCP/IPv4
IPv6 ’60s/’60s ’00/’10srough operational start…
Optical stds Wireless stds
Class 1 Agile Systems are Reconfigurableg y g
Useful Metaphors:
atyr
osad
o.co
m/
p
Plug-and-Play – Drag-and-Drop
Nat
y R
osad
o, h
ttp://
na
Class 2 Agile Systems are ReconfiguringClass 2 Agile Systems are Reconfiguring
htm
l?l=
w&
p=6
Useful Metaphors:
Ecologies and Evolution
ls, w
ww
.yes
sy.c
om/a
rtis
ts.h
[email protected], attributed copies permitted 30
Hel
en W
ell
SDOE 675 SDOE 678 SDOE 679 SDOE 683
678Engineering
679Architecting
683Designing
675Thinking
[email protected], attributed copies permitted 31