ES/SDOE 678
Reconfigurable Agile Systems and Enterprises
Fundamentals of Analysis, Synthesis, and Performance
Session 3 – Requirements Analysis: Response Types, Metrics, Values
Your Class web-page:
Support docs & links:
www.parshift.com/678/current.htm
www.parshift.com/678/support.htm
School of Systems and Enterprises
Stevens Institute of Technology, USA
rick.dove@stevens.edu, attributed copies permitted
3:1
Task
- Form into project teams
- Name your team
- Name your work file: Ex-teamname.ppt
- Write a descriptive statement of your
agile-system project
(uncertain environment, effective response)
- List strategic “response” objectives/values
Prepare two slides for brief out
FEEDBACK REVIEW
• The project MUST engage everyone's passion.
• Make sure the whole group is in favor of the choice, you will live with it all
week...perhaps for 10 weeks.
• You must see that this system is non-trivial, has a future, and is the subject
of further development, improvement, or increased understanding.
• Give time and care to producing your system statement,
as though your boss’s bosses would be interested and intrigued,
not only by your choice, but also by your statement.
rick.dove@stevens.edu, attributed copies permitted
3:2
Course Roadmap
Have You Signed The Attendance Roster?
Fundamentals
Analysis
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
Tools
Session 5 – Architecture and Design Principles
Synthesis
Session 6 – Design Exercise and Strategy Refinement
Integration
Session 7 – Quality: Principles, Reality, Strategy
Session 8 – Operations: Closure and Integrity Management
Perspective
Session 9 – Culture and Proficiency Development
Session 10 – The Edge of Knowledge, Projects
rick.dove@stevens.edu, attributed copies permitted
3:3
Response Requirements
Performance metrics of:
 Time
 Cost
 Predictability (Quality)
 Scope
Proactive/Reactive response dimensions
Requirements-development methods/issues
rick.dove@stevens.edu, attributed copies permitted
3:4
 Leadership: The ability to shape the operating environment and
set requirements of continued operation. Innovative. Marked by
followers.
 Agile: RA state marked by high competence at both proactive
and reactive change. Typically open minded, curious,
experimental, interactive, sharing, and listening.
 Resilient: RA state marked by good reactive change
competency, at least sufficient to be generally viable. Typically
follows best-in-class practices, listens to the customer,
responds well to competitive moves. Not good at leading.
 Innovative: RA state marked by good proactive change
competency, at least sufficient to be a market influencer.
Typically introduces new technologies, services, strategies, and
concepts that change the competitive rules. Not good at
following.
Proactive
Innovative/Composable
Creates Opportunity
Takes Preemptive Initiative
Proactive Proficiency
 Viability: The ability to meet minimum requirements of continued
operation. Resilience. Ability to seize opportunity and follow
another’s lead.
Innovative
(Composable)
Agile
Fragile
Resilient
Reactive Proficiency
 Fragile: RA state marked by small competency at change.
Reactive
Insufficiently reactive to shrug off adversity. Insufficiently
Resilient
proactive to influence the market. Typically doesn’t interact well,
poorly connected with the market, procedure driven,
Seizes Opportunity
unresponsive, afraid of failure, non-experimental, full of punchCopes with Adverse Events
clock people, and managed by administration.
rick.dove@stevens.edu, attributed copies permitted
3:5
Discussion
Where would you classify these enterprises, and why?
Proactive Proficiency
Microsoft
General Motors
Google
Intel
AMD
al Qaeda
Cyber security attackers
rick.dove@stevens.edu, attributed copies permitted
Innovative
(Composable)
Agile
Fragile
Resilient
Reactive Proficiency
3:6
Change Proficiency - The competency available for accomplishing a transformation.
Change Proficiency Metric - A four dimensional performance indicator that quantifies
a relative competency value for change proficiency:
a) Time [t]: A measure of elapsed time to complete a change. Fairly objective.
b)Cost [c]: A measure of monetary cost incurred in change. Somewhat objective.
c) Predictability [p]: A measure of prediction quality in meeting change time, cost,
and specification targets robustly. Somewhat subjective.
d) Scope [s]: A measure of the latitude or range of possible change, typically
bounded by mission or charter. Fairly subjective.
Change Proficiency Issue 1) A transformation considered of sufficient import to be included as an issue of
concern that must be considered and addressed;
2) A transformation with sufficiently inadequate change proficiency that it is an
issue of concern;
3) A transformation that the change proficiency metric is applied to, e.g., formation
of a partnership, expansion of production capacity, replacement of a faulty
supplier, changeover of a process, etc.
rick.dove@stevens.edu, attributed copies permitted
3:7
Scope Examples
Product
• Number of peripheral
devices possible on PC
Process
• Economic production
capacity, both upper and
lower limits
• Max load on pickup truck
while still offering good
• Order entry fast ramp-up
unloaded family ride
limits
• Web site hits/hr peak
• Variety of desktop
technology available on
the corporate network
• Working relationship
defined by a contract
• Minimum economic limit
on a service call
• Range in counter
customers serviceable
within 60 seconds
• Electricity available for
delivery in the summer
• Amount of learning
required to use a product • Recruitment and hiring
effectively
ramp-up rate limits
Practice
• Min/max economic
volume by salesperson
People
• Effective intercorporate
cultural interface range
• Min/max effective training • Vision and mission inclass size
tune with market
developments
• New knowledge and
thought leadership for
• Likelihood that a service
consulting practice
tech can fix whatever the
problem is
• Size of town required to
support retail chain
• Breadth of available
technology expertise to
• Business quantity needed product development
for local presence
• Breadth of alternate use
• Range of people
for employees already
productively applied to a
attuned to the culture
project
• Effective knowledge
reuse
rick.dove@stevens.edu, attributed copies permitted
3:8
Proactive (Leadership)
Agility is ...
Agile
Fragile
The ability to
respond effectively
at all times,
reactively and proactively
...within mission
Reactive (Viability)
... the ability to survive and thrive
in an unpredictable and uncertain environment
Agility is Risk Management:
decreasing vulnerability and risk by
increasing options and predictability
rick.dove@stevens.edu, attributed copies permitted
3:9
Agile Software Development is a family
of systems-engineering processes that we will
examine as an agile-system
…not a single approach to software development.
In 2001, 17 prominent figures in the field of agile
development (then called “light-weight
methodologies”) came together at the Snowbird ski
resort in Utah to discuss ways of creating software in
a lighter, faster, more people-centric way.
They created the Agile Manifesto, widely regarded as
the canonical definition of agile development, and
accompanying agile principles.
The publishing of the manifesto spawned a movement
in the software industry known as agile software
development.
In 2005, Alistair Cockburn and Jim Highsmith gathered
another group of people — management experts, this
time — and wrote an addendum, known as the
PM Declaration of Interdependence.
http://en.wikipedia.org/wiki/PM_Declaration_of_Interdependence
rick.dove@stevens.edu, attributed copies permitted
From Wikipedia 5/28/07
3:10
10
http://agilemanifesto.org/
Manifesto for Agile Software Development
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 tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form,
but rick.dove@stevens.edu,
only in its entirety
through this notice.
attributed copies permitted
3:11
11
http://agilemanifesto.org/principles.html
Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
rick.dove@stevens.edu, attributed copies permitted
3:12
12
Associated/Related Agile Development Processes
Spiral – Barry Boehm (1988)
Evo – (Evolutionary Project Management) – Tom Gilb (1988)
RAD (Rapid Application Development) – James Martin (1991)
DSDM (Dynamic Systems Development Method) – DSDM Consortium (1995)
SCRUM – Ken Schwaber (1996)
Most
RUP* (Rational Unified Process) – Booch/Jacobson/Rumbaugh (1998)
popular
XP (Extreme Programming) – Kent Beck (1999)
ASD (Adaptive Software Development) – Jim Highsmith (1999)
FDD (Feature Driven Development) – Jeff DeLuca (1999)
(Agile Manifesto – 2001)
Crystal Methodologies – Alistair Cockburn (2002)
Lean Software Development – Mary and Tom Poppendieck (2003)
AUP (Agile Unified Process) – Scott Ambler (20??)
Pipelining / Perpetual Beta – [Google is generally cited example]
Name shown is strongly associated with the concept and generally writes on its
employment extensively; often, not always, is considered the “inventor/founder”
rick.dove@stevens.edu, attributed copies permitted
3:13
How Designers Really Think
Waterfall Method
Actual Designer
Gather data
Shows what
the mind of
expert
designers
focus on
during
design
Analyze data
Problem
Solution
Formulate solution
Implement
Time Since Beginning of Design Session
Incremental and Iterative
Requirements influence solution evolution
Solutions influence requirements evolution
Wicked Problems: Naming the Pain in Organizations, E. Jeffrey Conklin & William Weil, http://kodu.ut.ee/~maarjakr/creative/wicked.pdf
rick.dove@stevens.edu, attributed copies permitted
3:14
Quick Review of Agile Software Scrum SE
File8.5
File2.0
This video is an introduction to the Scrum software
development methodology. By the end of this fastpaced video, you'll practically be a scrum master.
You'll know about burn down charts, team roles,
product backlogs, sprints, daily scrums and more.
Hamid Shojaee, Axosoft
www.youtube.com/watch?v=XU0llRltyFM
Patil Tatoulian, Pyxis
www.youtube.com/watch?v=WxiuE-1ujCM
rick.dove@stevens.edu, attributed copies permitted
3:15
The UURVE Environment Drives the Response Need
Agile systems are defined in counterpoint to their operating environments.
Words used to describe the general nature of the target environment often include
and combine dynamic, unpredictable, uncertain, risky, variable, and changing,
with little attention to clear distinction among them.
To design and develop a system that can deal effectively with changing
environments it is useful to articulate the nature of changes that should be
considered.
Agile systems have effective situational response options, within mission, under:
• Unpredictability: randomness among unknowable possibilities.
• Uncertainty: randomness among known possibilities with unknowable
probabilities.
• Risk: randomness among known possibilities with knowable probabilities.
• Variation: randomness among knowable variables and knowable variance
ranges.
• Evolution: gradual (relatively) successive developments.
The difference between risk and variation in this framework is that risk is viewed
as the possible occurrence of a discrete event (a strike keeps all employees
away), while variation is viewed as the intensity of a possible event (absenteeism
varies with the season).
rick.dove@stevens.edu, attributed copies permitted
3:16
UURVE High-Level Mission-Response Needs
Pro Forma Example: System Engineering Process





Unpredictability: unknowable situations
 Obsolescence of solution approach before completion
 Requirements additions and changes
Uncertainty: randomness with unknowable probabilities
 Feasibility of solution design
 Continuous political and funding support
Risk: randomness with knowable probabilities
 Unacceptable cost increases
 Failure to meet necessary schedule
Variation: knowable variables and variance range
 Critical test facility availability
 Multiple COTS-source performance differences
Evolution: gradual (relatively) successive developments
 Continuous incremental change in targeted operating environment
 Alternative technology improvement curves (Moore’s law effect)
rick.dove@stevens.edu, attributed copies permitted
3:17
Proactive and Reactive Response Types
Proactive response domains of:
 Creation
 Improvement
 Migration
 Modification
Reactive response domains:
 Correction
 Variation
 Expansion
 Reconfiguration
rick.dove@stevens.edu, attributed copies permitted
3:18
Change/Response Domains
Proactive
Creation
Proactive responses are generally triggered internally by
(and Elimination) the application of new knowledge to generate new value.
They are still proactive responses even if the values
generated are not positive and even if the knowledge
Improvement
applied is not new – self initiation is the distinguishing
feature here. A proactive change is usually one that has
effect rather than mere potential; thus, it is an application of
Migration
knowledge rather than the invention or possession of
unapplied knowledge. Proactive change proficiency is the
Modification
wellspring of leadership and innovation in system
(of Capability) capability.
Reactive
Change Domain
Reactive responses are generally triggered by events which
demand a response: problems that must be attended to or
fixed, opportunities that must be addressed. The
distinguishing feature is little choice in the matter – a
Variation
reaction is required. Reactive responses often address
threatening competitive or environmental dynamics, new
Expansion
customer demands, agility deterioration/failure, legal and
(of Capacity)
regulatory disasters, product failures, market restructuring,
and other non-competitor generated events. Reactive
Reconfiguration change proficiency is the foundation of resilience and
sustainability in system capability.
Correction
rick.dove@stevens.edu, attributed copies permitted
3:19
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?
The distinguishing feature is the creation of something new or reincarnated that is
not currently present. To note, this is not about the situation that calls for the
original creation of an agile system, but rather about the evolution of the agile
system during its operational period.
Situations to identify are those that require system configuration assemblies
during operation, and those that require new modules for employment in those
assemblies.
Agile Systems-Engineering (Process)
• project management strategy (t);
• project team (t, c); • system requirements (t, p);
• system architecture (t, s);
• system design (t, c, p);
• development activity plans (t);
• V&V/test plans (t);
• team collective understanding and learning (t, p);
• experiments (t, c, s).
rick.dove@stevens.edu, attributed copies permitted
3:20
Improvement
What improvements in system response performance will be expected over the
system’s operational life?
The distinguishing feature is performance of existing response capability, not the
addition of new capability.
Situations to identify are generally those involving competencies and
performance factors, and are often the focus of continual, open-ended campaigns.
Agile Systems-Engineering (Process)
• activity effort estimating (p);
• activity completion to plan (t, c, p);
• reducing uncertainty and risk (t, p, s);
• process effectiveness.
rick.dove@stevens.edu, attributed copies permitted
3:21
Migration
What evolving technologies and opportunities might require future changes to the
infrastructure?
The distinguishing feature is a need to change the nature of the plug-and-play
infrastructure, not the addition of new modules.
Situations to identify are generally those that enable the transition to possible and
potential next generation capabilities.
Agile Systems-Engineering (Process)
• compelling new technology availability (t, c, s);
• project scope change (s);
• lean process principles (p).
rick.dove@stevens.edu, attributed copies permitted
3:22
Modification (of capability)
What evolving technologies and opportunities might require modification of the
available modules and roster of module pools?
The distinguishing feature is a necessary change in available module capabilities.
Situations are generally those that require something unlike anything already
present, or the upgrade or change to something that does exist.
Agile Systems-Engineering (Process)
• new added team member unfamiliar/uncomfortable with management strategy (t);
• new environmental dynamics (t, c, p, s).
rick.dove@stevens.edu, attributed copies permitted
3:23
JIT Assembly Systems
(t = time of change, c = cost of change, p = predictability of change, s = scope of change)
Key Proactive Issues
Key Reactive Issues
Components
Creation
Weld Tips
Roller Tables
• Designing (50-100/year)
short-run assembly lines for
new parts that come with
long-run tooling [t]
Improvement
• Productivity of limited space
while increasing part variety
[s]
Racks
Hemmers
Standing
Platforms
Controllers
Production Team
Members (PTMs)
*Ctrl* Programs
****
Mastic
Tables
•••
Variation
Integrity Management
Module Evolution: Component team
Module Readiness: Component team
Assembly: Production teams
Infrastructure Evolution: Configuration team
P41 Deck Lid System
• High part production variety [s]
• Time available for new line
design [t]
• New parts to accommodate
with the JIT system [s]
* *
Expansion
• Production of non-GM parts
with non-GM tooling [ps]
Modification
• Absorb employees from
closed GM plants with
different union work rules into
cross-trained Production
Team Member positions [ts]
• Union refusals to
accommodate necessary work
rule changes [cs]
Assem Areas
System Examples
Migration
Correction
• Absorb growing part variety [s]
• Absorb growing inventory of
tooling [s]
• Area B
A47
Fender
System
• Area A
(Old-Form Agile Architecture Pattern)
rick.dove@stevens.edu, attributed copies permitted
Reconfiguration
• Short-run assembly line
construction/tear-down [t]
3:24
Change/Response Domains
Proactive
Creation
Proactive responses are generally triggered internally by
(and Elimination) the application of new knowledge to generate new value.
They are still proactive responses even if the values
generated are not positive and even if the knowledge
Improvement
applied is not new – self initiation is the distinguishing
feature here. A proactive change is usually one that has
effect rather than mere potential; thus, it is an application of
Migration
knowledge rather than the invention or possession of
unapplied knowledge. Proactive change proficiency is the
Modification
wellspring of leadership and innovation in system
(of Capability) capability.
Reactive
Change Domain
Reactive responses are generally triggered by events which
demand a response: problems that must be attended to or
fixed, opportunities that must be addressed. The
distinguishing feature is little choice in the matter – a
Variation
reaction is required. Reactive responses often address
threatening competitive or environmental dynamics, new
Expansion
customer demands, equipment malfunctions, legal and
(of Capacity)
regulatory disasters, product failures, market restructuring,
and other non-competitor generated events. Reactive
Reconfiguration change proficiency is the foundation of resilience and
sustainability in system capability.
Correction
rick.dove@stevens.edu, attributed copies permitted
3:25
Correction
What types of response activities might fail in operation and need correction?
The distinguishing feature is a dysfunction or inadequacy during attempted
response.
Situations to identify are those that require a recovery from response malfunction,
recovery from unacceptable side effects of a response, and inability to assemble
an effective response.
Agile Systems-Engineering (Process)
• wrong requirement (t);
• inadequate developer (t);
• failed V&V/test (t, c);
• non-compliant supplier (t, c).
rick.dove@stevens.edu, attributed copies permitted
3:26
Variation
What aspects of operational conditions and resources vary over what range when
response capabilities must be assembled?
The distinguishing feature is predictable but uncertain variance.
Situations to identify are those that manifest as variances in module availability,
module performance, and module interactions.
Agile Systems-Engineering (Process)
• expertise and skill levels among team members (p);
• grace period on schedule (t, c);
• deliverable performance range (p);
• availability, interaction, and expertise of customer involvement (s).
rick.dove@stevens.edu, attributed copies permitted
3:27
Expansion/Contraction
What are the upper and lower bounds of response capacity needs?
The distinguishing feature is capacity scalability.
Situations to identify are those that can be satisfied with planned capacity
bounds, as well as those that have indeterminate and unbounded capacity needs.
Agile Systems-Engineering (Process)
• 2x project scope change (t, c, p, s);
• team-size changes of x-y engineers distributed across n-m locations (t, s).
rick.dove@stevens.edu, attributed copies permitted
3:28
Reconfiguration
What types of situations will require system reconfiguration in order to respond
effectively?
The distinguishing feature is the configuration and employment of available
modules for new or reincarnated response needs.
Situations to identify are those that are within the system mission boundaries,
and that may require a reconfiguration of an existing system assembly, perhaps
augment with removal of modules or addition of available modules.
Agile Systems-Engineering (Process)
• unanticipated expertise requirement (t);
• development activity-sequence priority change (t);
• system/sub-system design change.
rick.dove@stevens.edu, attributed copies permitted
3:29
Production Cell
(t = time of change, c = cost of change, p = predictability of change, s = scope of change)
Key Proactive Issues
Creation
• Design/install new-part
production capability
frequently and quickly [tcp]
Improvement
Key Reactive Issues
Components
# #
# #
Work Setters
Correction
Rail Sections
Guided
Vehicles
Pallet
Changers
Work Setup Stations
Loader/
Unloaders
Flexible
Machines
• Cost of lost production due to
equipment malfunction and
repair time [tc]
Variation
Systems Integrity Management
• Customers are demanding a
reduction in short run costs [t]
Migration
• Moving from transfer line
technology to next generation
flexible machines brings
different concepts [cs]
Module Evolution: Operations manager
Module Readiness: Operations manager
Assembly: Customer account engineer
Infrastructure Evolution: General manager
• Prototype runs are more
frequent, and require more
varied machining options
[tcs]
System Examples
Expansion
3 Station Cell
6-8 Station Seasonal Cell
#
Modification
• Higher product change
frequency requires production
process modification rather
than replacement [tcs]
#
#
#
(Old-Form Agile Architecture Pattern)
rick.dove@stevens.edu, attributed copies permitted
• Expansion and contraction of
production capacity must
accommodate
unforecastable demand [tcs]
Reconfiguration
• Salvage and reuse old
production stages in new
production configurations [cs]
3:30
www.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf
www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf
Perceived
Effectiveness
100%
Did your Objectives recognize next generation migrations?
If they should have … correct that.
In-agile system
Development Operation
Time
Delivery
Agile system would continue ROI,
but does age, and
can suffer integrity failure
life-cycle end
Module Mix
Modifications
Perceived
Effectiveness
100%
Infrastructure
Migration
agile system
Development Gen 1 Operation
Time
Delivery
rick.dove@stevens.edu, attributed copies permitted
Gen 2 Operation
3:31
Wikispeed’s Modular Cars
File5
Detroit Auto Show, 11Jan2011
(Eight Modules)
Modular design – Development is
rapid because the design of the car
is modular.
The engine is able to be switched
from a gasoline to an electric engine
in about the time it takes to change
a tire. The car body can be switched
to a pickup truck.
Modular design enables Wikispeed
to make changes and develop
quickly.
Simplicity and modularity reduce
costs in making changes, in tooling,
in machinery and in complexity.
Accelerating the response to problems – Wikispeed has steadily increased its
velocity in resolving issues. For instance, on one occasion, within hours of
getting a video back from a side impact test, the team realized that there was four
inches of penetration into the cabin. It was still survivable, and still road-legal, but
it wasn’t the five star crash rating that the team wanted. So within hours, they had
a volunteer team update the side impact crash structure and bolt it onto the car.
The first time Wikispeed did a safety iteration like this, it took many weeks. Now
they are able to accomplish it within a seven day sprint cycle.
Video and text at: www.youtube.com/watch?v=tTDCQMjbc40
rick.dove@stevens.edu, attributed copies permitted
3:32
BREAK
rick.dove@stevens.edu, attributed copies permitted
3:33
Typical Integrated System Management
Art: Jamcracker
rick.dove@stevens.edu, attributed copies permitted
3:34
Case: Greenfield Semiconductor Foundry
Background
October 1999 (dot.com bubbling, semi-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
CEO has a vision for a preemptive modern-day competitor...
Goal: Build a uniquely superior foundry business
Strategy: Best practices + Agile IT infrastructure under logistics
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
rick.dove@stevens.edu, attributed copies permitted
3:35
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 IT support system
fit to the new and changing environment,
and focused on new values
rick.dove@stevens.edu, attributed copies permitted
3:36
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
rick.dove@stevens.edu, attributed copies permitted
3:37
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
is enabled rather than inhibited.
Integrating new plants, facilities, mergers, and acquisitions
is enabled rather than inhibited.
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 latest technology
rick.dove@stevens.edu, attributed copies permitted
3:38
Rules of Engagement
Get the best plans and designs and technologies possible,
wherever they may be found.
For implementation and evolution,
employ internal and local resources whenever possible,
else transfer responsibility to local resources as fast as possible.
Build internal spec/test/management/operating capability,
and outsource implementation projects (locally).
Make up the rules as you go along,
and refine them until they work.
rick.dove@stevens.edu, attributed copies permitted
3:39
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-requirements analysis
COTS Applications Only: No customization of purchased software
IT Internal Responsibilities – not to be outsourced:
 Infrastructure architecture design and evolution
 Management of integration projects
 Configuration of applications
rick.dove@stevens.edu, attributed copies permitted
3:40
Response Requirements – IT Infrastructure
Response Metrics: c=cost, t=time, p=predictability, s=scope
Proactive Dynamics
 Creating new customer/supplier/partner business net-link [t,p,s]
 Creating acquisition business net-link [t,p,s]
 Creating interface to a new application [t,c,s]
 Improvement of interface performance [t,s]
 Migration to NT and COM/DCOM [c,p]
 Addition of new foundry facility [p,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,p]
 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,p,s]
rick.dove@stevens.edu, attributed copies permitted
3:41
www.datacenterknowledge.com/inside-the-box-container-video-tours/
www.datacenterknowledge.com/archives/2010/08/11/the-blackbox-lives-or-at-least-is-not-dead/
www.zdnet.com/blog/datacenter/suns-datacenter-container-forgotten-but-not-gone/398
file
rick.dove@stevens.edu, attributed copies permitted
3:42
Modular Data Centers
Response Type
Response Situations
What must the system be creating or eliminating in the course of its operational activity?
Proactive
Creation
Improvement
• Create IT capacity anytime anywhere (p)
•?
What performance characteristics will the system be expected to improve during operational life cycle?
• Power efficiency (c)
• Processing box
• Processing capacity per volume
What major events coming down the road will require a change in the system infrastructure?
Migration
• Solar/hydrogen powered (s)
• Wireless
• Follow-the-sun power economics
• Distributed data center
Modification What modifications/evolutions in modules might be needed during the operational life cycle ?
• Interface options
(Capability) • Power generation modules
• Cross brand platforms (t, c, p, s)
What can go wrong that will need an automatic systemic detection and response?
Correction
• Damage and theft
• Hack attack
• Environmental exposure risk
• Remote component failure
Reactive
What process variables will range across what values and need accommodation?
Variation
Expansion
(Capacity)
Reconfiguration
• Ambient temperature/humidity
• Local power reliability and nature
•?
What are “quantity-based” elastic-capacity range needs on resources/output/activity/other?
• Infinite scalability of modules
• Internal storage
• Box size and amount of content
•What types of resource relationship configurations will need changed during operation?
• What box is where
•?
120315L3
Modular Data Systems Deployment and Operational Life Cycle
rick.dove@stevens.edu, attributed copies permitted
3:43
Tassimo Beverage System
Drag-and-Drop – Plug-and-Play
BRAUN
File
- http://www.tassimodirect.com/tassimo/
rick.dove@stevens.edu, attributed copies permitted
3:44
In-Class Tool Applications
Class Warm-ups
Team Trials
Team Project
Unit 2
AAP Analysis: Case
ConOps: Objectives
Unit 3
RS Analysis: Case
Reactive/Proactive
Unit 4
Unit 5
RS Analysis
RRS Analysis: Case
Unit 6
Unit 7
Unit 8
RS Analysis
Framework/Modules
RRS Analysis
Reality Factors
RRS + Integrity
Reality + Activities
Integrity
Closure
Unit 9
Unit 10
rick.dove@stevens.edu, attributed copies permitted
3:45
Tassimo Beverage System
Response Issues
Response
Situations
Response
Situations
(Amalgam)
What
must
the
system
be
creating
in
the
course
of
its
operational
“activities”?
x Pleasurable
user
experience
• Hot beverages to order
•
??
Creation
Creation
• New recipe creation
Overall system value ≠ system activity
• New T-disk creation
What performance characteristics will the system be expected to improve over time?
Improve- • Make better tasting stuff
x Battery for camping
migration or
Improve•
??
ment
• Faster
ment
maybe modification
• Easier cleaning
major
coming down the road will require a change in the system infrastructure?
• What
Sense
sizeevent
of cup
Migration
?? custom-recipes, remembered
Migration • •User
• Other mfg’ers disks
What modifications/evolutions in modules might be needed during the operational life cycle?
Modification • Other kinds of drinks (eg cocktails)
x Night light (these change framework,
Modification
•
??
(Capability) • Other kinds of stuff (eg soups)
x Wrong-size-cup detector not modules)
(Capability)
• Add features (eg Auto-start timer)
What can reader
go wrongfailure
that will
need anfall-back
automatic systemic detection and response?
• •Bar-code
manual
??
Correction • •Power
Correction
failure (graceful recovery)
• Cup overflow
variables will range across what values and need accommodation?
• What
Tasteprocess
preferences
??
Variation
Variation
• •Volume
variation per cup
• Seasonal changes in market tastes?
What
are “quantity-based”
elastic-capacity range needs on resources/output/activity/other?
•
Number
of
process
steps
Expansion
Expansion
• ??
(Capacity) • Two cups simultaneously
(Capacity)
• Small to large cup
• What types
of resource
steps
per diskrelationship configurations will need changed during operation?
Reconfig- • •Process
Reconfig??
• Homemade
disk inserts
uration
uration
• Multi-disk recipes
Reactive
Reactive
Proactive
Proactive
ResponseType
Type
Response
rick.dove@stevens.edu, attributed copies permitted
3:46
Getting it Right
Requirements shall statements define
exactly what must be accomplished.
If you miss even one you could have a dysfunctional result.
For Response Situation Analysis…
you do not need to develop a comprehensive list of shall statements,
but rather a sufficient list of response capabilities –
which if accomplished,
will stretch the envelope of agile response capability
to encompass all necessary response needs,
even if they were not on the list.
rick.dove@stevens.edu, attributed copies permitted
3:47
rick.dove@stevens.edu, attributed copies permitted
3:48
rick.dove@stevens.edu, attributed copies permitted
3:49
"When I am working on a problem,
I never think about beauty,
but when I have finished,
if the solution is not
Quality
beautiful,
Evaluation
I know it is wrong."
-- R. Buckminster Fuller
RAP
Tools &
Process
Projected
Operational
Story
Closure
Matrix
Design
Reality
Factors
Identified
“Quality is practical, and
factories and airlines and
hospital labs must be practical.
ConOps
But it is also moral and aesthetic.
Objectives
And it is also perceptual and subjective.”
& Activities
-- Tom Peters
rick.dove@stevens.edu, attributed copies permitted
Architectural
Concept
& Integrity
Response
Situation
Analysis
RRS
Principles
Synthesis
3:50
In-Class Tool Applications
Class Warm-ups
Team Trials
Team Project
Unit 2
AAP Analysis: Case
ConOps: Objectives
Unit 3
RS Analysis: Case
Reactive/Proactive
Unit 4
Unit 5
RS Analysis
RRS Analysis: Case
Unit 6
Unit 7
Unit 8
RS Analysis
Framework/Modules
RRS Analysis
Reality Factors
RRS + Integrity
Reality + Activities
Integrity
Closure
Unit 9
Unit 10
rick.dove@stevens.edu, attributed copies permitted
3:51
ProActive
ReActive
1. Assemble
Diverse Team
2. Define Edge
of Analysis Subject
EXERCISE
3. Brainstorm
General Issues
Prepare one new slide and update old slide for brief out
1. Incorporate review feedback into project (rewrite project statement)
2. Establish general reactive and proactive response requirements
(don’t break them down any finer into change domains)
Get Exercise Templates at:
www.parshift.com/678/support.htm (preferred)
or on the supplied CD
rick.dove@stevens.edu, attributed copies permitted
3:52
Proactive – Further Clarification
Proactive – Originally coined by the psychiatrist Victor Frankl in his 1946 book
Man's Search for Meaning to describe a person who took responsibility for his or
her life, rather than looking for causes in outside circumstances or other people.
The term was popularized in the business press in Stephen Covey's 7 Habits of
Highly Effective People. Though he used the word in Frankl's original sense, the
word has come to mean…
"to act before a situation becomes
a source of confrontation or crisis"
vs.
after the fact.
It is frequently misused to mean
simply “active” …the opposite of passive.
[Wikipedia – 070915]
rick.dove@stevens.edu, attributed copies permitted
3:53
System: __________________________
General Issues
Proactive
•
Reactive
•
rick.dove@stevens.edu, attributed copies permitted
3:54