In agile projects, design ideally "emerges" over the course of development. However, if teams primarily focus on independent user stories, they risk losing sight of the product's vision and the integrity of well-thought-out architecture. Ken Kubo shares techniques he's used to improve the chances that a product's design will emerge into a cohesive and coherent architecture that serves its customers for many years. Join Ken to find out how you can incorporate contextual design principles and simple, visual techniques as part of his "A-Little-Before-Its-Time Design" framework. You can add these practices into your agile workflow to maintain a shared team understanding of your product's vision and the system's emerging design. Ken believes that you can only realize all the promises of agile development with a clearly and constantly communicated product vision and a set of architecture goals. Lack of these key principles leads to sub-optimizing system development-or much worse, failure.

1.
AW7
Concurrent Session
11/7/2012 2:15 PM
"Right-sized Architecture:
Integrity for Emerging Designs"
Presented by:
Ken Kubo
Northrop Grumman Corporation
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Ken Kubo
Northrop Grumman Electronic Systems
Ken Kubo is director of software engineering with twenty years of service at Northrop Grumman
Electronic Systems, Intelligence, Surveillance, Reconnaissance, and Targeting Systems
Division, Azusa campus. His work has focused on the development of satellite ground systems,
building the bigger picture from individual bits of data. Information radiators are Ken’s natural
focus in agile development. A certified Lean-Agile ScrumMaster and Certified ICAgile
Professional, he developed and teaches a Lean-Agile Development overview course for NGES.
Ken firmly believes that lean-agile and government acquisition processes are not completely
incompatible.

3. Right-Sized
Architecture
Integrity for Emerging Designs
AW7 - 7 November 2012 – 2:15 PM
Ken Kubo, James Yoshimori, Jason Liu
Agenda
• Software Engineering and Lean-Agile
• Right-Sized Architecture
Right Sized
• Collaborative Design
• Extending the Metaphor
• Retrospective

4. Acknowledgements
• The team gratefully acknowledges the support and interest of the
Sensor Exploitation Systems/SAIG business area leadership.
3
But First…A Word From Our Sponsor
• Northrop Grumman Corporation (NYSE: NOC) is a leading global security
company providing innovative systems, products and solutions in
aerospace, electronics, information systems, and technical services to
government and commercial customers worldwide The company has
worldwide.
over 120,000 employees in all 50 states and 25 countries around the
world.
• Our core competencies are aligned with the current and future needs of
our customers and address emerging global security challenges in key
areas, such as unmanned systems, cyber-security, C4ISR, and logistics
that are critical to the defense of the nation and its allies.
• Our Electronic Systems sector is a leader in airborne radar, navigation,
y
,
g
,
electronic countermeasures, precision weapons, airspace management,
space payloads, marine and naval systems, communications, biodefense,
and government systems.

5. The Need for Agility
Increase in Software in DoD Systems
Software Content of Sample Major DoD Weapon Systems 1960 - 2020
18
FCS
16
F-35 Aircraft
and Ground
ESLOC in Millions
14
12
10
DDX
8
6
Virginia SSN
4
Patriot
PAC-3
Aegis System
2
SBIRS
F-22
Polaris A3
0
1960
ACS
1970
1980
Sea Systems
1990
Missiles/Space
2000
Ground Systems
2010
2020
Aircraft
Sources: CARD Data, SEI, CSIS Analysis
5
The Need for Agility
• Defense Science Board Recommends More agile Acquisition Process
(March 2009)
“A new acquisition p ocess for information
ew acqu s t o process o
o at o
• National Defense Authorization Act should be Year 2010 (H.R.2647) on
technology for Fiscal developed—modeled
(Became Public Law No: 111-84 October 2009)
successful commercial practices, for the rapid
• AFEI Task Force 804 Report – June 2010
acquisition and continuous upgrade and
Recommended (Among Other Things):
improvement of IT
capabilities. The process
“Institute continuous, iterative, development,
should be agile and geared
test, and certification processes that drive the to delivering
commercial IT state of the art to deliver more capability in
meaningful increments of
trusted, standard, off-the-shelf building blocks”
approximately 18 months or less—increments
that are prioritized based on need and technical
readiness.”
6

6. Software Engineering (and other oxymorons)
• Definitions:
– Software: a set of instructions which define and enable the operation of a computer
system to perform a desired task
y
p
– Engineering: the discipline and profession of applying technical, scientific, and
mathematical knowledge to practical problems
• Historical endpoints
– 1968 NATO Software Engineering Conference
– Software Engineering Body of Knowledge (SWEBOK) (IEEE, 2004)
7
Software Engineering Practices
• Systemic view and development lifecycle (requirements analysis,
design, development, testing, deployment, maintenance)
• Risk analysis
• Best practices
– Lessons learned
– Design patterns
• Certification
– Certified Software Development Associate/Professional (CSDA/P)
– PMI-ACP, ICAgile Certified Agile Professional, role certification etc.
8

7. The Agile Transition
Predictive
Develop FS A
RA
HLD
DD
Develop FS B
I&T
V&V
PDS
Develop FS C
FS A,B,C
Adaptive
RA
…
HLD
PDS
FS A
FS B
FS D
FS C
9
Agile Execution
Analysis
A hit t
Architecture
“Desirement Analysis” with iteration planning
and backlog (work queue) grooming. Also
used for risk identification/mitigation.
Design
Development
I&T
10
Traditional engineering activities all still occur,
but note that they (mostly) happen
collaboratively, not sequentially.

8. When Engineering Goes Bad…
Traditional predictive practices and “ilities” can commit too early
• Lock-down architecture at the beginning of the project (Big Design Up
Lock down
Front)
• Only discuss design with customer prior to development
• Design for all possible customer
requests, enhancements, and
expandability
Wide focus can be uninformed
11
When Agile Goes Bad…
Agile methodology focus can incur technical debt
• Agile methodology impacts
– Iteration focus can emphasize coding activity – de-emphasizing others
– “Just in time” design can devalue architecture
• Technical debt
– Neglecting the “big picture”
– Decoupling architecture
– Losing sight of system
design integrity
Tight focus can prove short-sighted
12

9. Agile as a Philosophy
• Execute with lean agility
– Avoid waste
– Creating shared knowledge > creating documentation
• Leverage social interaction
– Use a common “information radiator”
• Artifacts and processes are open to view
• Artifacts are easily accessible
• Single source creates common understanding
– Build a social environment for development
p
• Encourage developers to work closely with one another
• Strengthen trust within the community
– Establish common understanding of artifacts being constructed
Shared understanding drives efficiency
13
Implementing Agile Architecture
• Avoid waste – just enough (George Fairbanks)
“You‘ll be smarter later”
• The Zen of “just enough”
–
–
–
–
–
Avoid big design up front (BDUF)
Decide on the vision for your framework
Pick your focal points (risk and ignorance)
Make design a convenient part of the workflow
Emphasize creating knowledge, not creating diagrams
• Encourage an open team dynamic so team members can say when they have
enough information to code
– Prefer the collaboration dynamic to automation tools
– Don’t force documentation of design sessions
– Be disciplined but not rigid
Just Enough Architecture A Little Before Its Time
14

10. Roles and Responsibilities
• Initial Design
Objective: identify interfaces, processing partitions/components, general system
sketch, build the framework for the developers
– Architect: maintains big picture, helps identify and define interfaces, keeps focus of
the meeting, controls documentation
– Product Owner: clarifies objectives and done-ness, fills in unstated (“wasn’t that
obvious?”) requirements
– Technical Lead(s): identify where development activity has to occur, help define
interfaces
• Delta Design
Objective: sanity check and impact analysis (not the search for the perfect design)
– Developer(s): present (proposed) solution, highlight any changes/detailing to
architecture
– Architect: helps perform impact analysis, verifies design integrity, controls
documentation
– Technical Lead(s): help perform impact analysis
15
Eyes on the Big Picture
• Apply Agile philosophy
– Understanding > documentation
• How?
– Using my Agile eyes …
• Inspiration
– CRC: class, responsibilities & collaborators (Ward Cunningham)
• Informal grouping of index cards (4”x6”)
• Simple, easily remembered rules
• Visual and collaborative
16

11. Color Map Affinity Diagrams
• Use colored index cards and push-pins – advanced developers may
use self-adhesive notes
• Assign colors to the various types of high level components you may
have (more details to follow)
• Find sufficient vertical space to place the index cards
• Have fun ☺
17
Example
• Project: Support processing, archive, and display of satellite wideband
data, substantial legacy code
• Team size: 5 members
• Platform: SGI and Linux
• Language: C/C++ and Java
18

12. Issues with Database to Display Interfaces
• Large amounts of data being transferred to displays on network
– Intermingled with smaller data packets
• Noticing network loading “uncomfortably” increased for single source
on a GigE network
– Anticipating load to increase by 4 times current loading in a year
– Load may increase by more than 18 times in 5 years
• Current display has noticeable lag in processing and rendering
– Display is just one executable so performance degradation is not unexpected
New capabilities have outgrown old paradigm
19
Just Enough Architecture
• Risk driven
• Focus on data stores and display
• Decouple display
– Do not directly attach to principal data stores
– Get away from single executable for display
– Create an infrastructure that supports “drop-in” views
• Find a smarter way to manage the data and their transmission over the
network
• Pay more attention to modularity and scalability qualities
Prioritize what to rearchitect/refactor
20

13. Color Assignments
• Specific colors do
not matter just be
consistent
• Edge components
that perform I/O
• Processing
components
• 4-5 is usually all I
need
• Persistent
component
• Coincidentally a
stack of colored
index cards have
5 colors
l
• Controller
component
• User Interface
21
High Level Tracking Architecture
Data Ingest
Signal
Processing
g
Tracking
Event
Detection
Pipeline
Wideband
Track Points
Display
22
Events
Simple approach
has issues

14. Current Display Architecture
Track
Point
View
Events
Data
Service
View
View
View
Wideband
23
Initial Update to Display Architecture
Track
Point
Track
Points
Service
View
View
Events
Wideband
24
Events
Service
Wideband
Service
View
View

15. Updated Display Architecture
Workstation
Blade
Track
Points
Track
Points
Service
View
View
Events
Events
Service
Wideband
Wideband
Service
View
View
We use blue painters
tape to identify
boundaries
25
Updated Display Architecture
Workstation
Blade
Track
Point
Track
Points
Service
Track
Points
Controller
View
View
Events
Events
Service
Events
Controller
View
View
Wideband
26
Wideband
Service
Wideband
Controller

16. Display Architecture
Workstation
Blade
Track
Point
Track
Points
Service
Track
Points
Controller
Events
Events
Service
Events
Controller
View
View
View
Exec
Wideband
Wideband
Controller
Wideband
Service
View
Setup
View
27
Display Architecture
Workstation
Blade
Track
Point
Track
Points
Service
Track
Points
Controller
Events
Events
Service
Events
Controller
Wideband
28
Wideband
Service
Wide
Wideband
Controller
View App
Cache
View App
View App
Exec
View App
View App
Setup

17. Display Architecture
Workstation
Blade
Track
Point
Track
Points
Service
Track
Points
Controller
Events
Events
Service
Events
Controller
Wideband
Wideband
Service
Wide
Wideband
Controller
Exec
View App
View App
View App
View App
View App
Events
Setup
Track
Point
Cache
Wideband
29
Display Architecture
Workstation
Blade
Track
Points
Events
Track Points
Service
Event
Service
Track
Points
P i t
Controller
View App
Vi
A
View App
Events
Controller
View App
Wideband
Controller
View App
View App
Exec
Wideband
30
Wideband
Service
Track
Points
Config
File
Wideband
Event

18. And Now For Something Different
• Story: As a mission operations monitor, I need an “always on” passive
display that shows wideband data from the satellite point of view
overlaid on map data to provide quick indication that data is flowing
and line of sight is good.
• Approach: Add a new view application which can be standalone or
“boxed” with the others which just provides a wideband data display.
31
Display Architecture
Workstation
Blade
Track
Points
Events
Track Points
Service
Event
Service
Track
Points
P i t
Controller
View App
Vi
A
View App
Events
Controller
View App
Wideband
Controller
View App
View App
Exec
Wideband
32
View App
Wideband
Service
Track
Points
Config
File
Wideband
Event

19. Information Radiator
250
16
200
14
12
150
10 Ideal
100
ETC
8
50
Committed
Completed
6
4
0
10
9
8
7
6
5
4
3
2
1
0
2
0
10
• Can be physical or virtual
• Must be current
33
Information Radiator
• Iteration goal/vision
• Current iteration task/story status (in play and backlogged), iteration metrics
• Schedule (IMS, Release Plan, milestone calendar)
• Product vision, roadmap, Release Backlog
• Project metrics (velocity, defects found in I&T, bug rates, customer feedback)
• High-level architecture/system overview
• Process/workflow team rules and standards
Process/workflow,
• Team member vacation/leave calendar
• Recognition/appreciation
Build shared knowledge and team direction
9
8
7
6
5
4
3
2
1
0

20. Extending the Metaphor
• Team-based metaphors (and better note stock)
• Visual design patterns
• Component abstraction
• UML, SysML, MBE, … tools where value-added
• For legacy systems, practical default may be to adopt legacy
standards
Team evolves “design language”
35
The Working System
• “My code works” is only a start; each developer
p
y
must own the performance of the system as a
whole
• “Responding to Change > Following a Plan”
does not mean “Don’t Plan”
36

21. Retrospective
• Lean-Agile and good engineering practices are not opposed!
• Visual design methodologies can strengthen role of architectural design in
Agile (and predictive!) methodologies
• Be creative (and Agile)
– Focus on goals
• Build shared system understanding
• Incorporate design into workflow
• Facilitate evolution of architecture over project life
• Reduce integration rework
– Right-sized = Do the minimum
– Create a variant or use another technique –
find what works better for your team
• Always keep looking for ways to do better
Keep an Agile eye on design
37
Useful References
• Scott L. Bain, Emergent Design: The Evolutionary Nature of
Professional Software Development (Addison-Wesley, 2008)
• Kent Beck, Ward Cunningham, “A Laboratory for Teaching ObjectOriented Thinking” (OOPSLA 1989)
• George Fairbanks, Just Enough Software Architecture: A Risk-Driven
Approach (Marshall & Brainerd, 2010)
38

22. Abstract
Lean-Agile development methodologies provide increased flexibility to
deliver a more rapid return on customer investment in the form of
working software. In Agile projects, system architecture ideally
emerges over the course of development. However, if teams primarily
focus on independent user stories, they risk losing sight of the Big
Picture – the product’s vision and the integrity of well-thought-out
architecture. This presentation shares techniques to improve the
chances that a product’s design will emerge into a cohesive and
coherent architecture that will support customer needs now and in the
future. Incorporating contextual design principles and simple, visual
techniques as part of “A Little Before Its Time (ALBeIT) Design”
maintains a focus on architectural integrity You can adopt these
integrity.
practices into your Agile workflow to maintain a shared team
understanding of your product’s vision and the system’s emerging
design.
40

23. Author Biography
• Ken Kubo is Director of Software Engineering at Northrop Grumman Electronic Systems,
Intelligence, Surveillance, Reconnaissance, and Targeting Systems Division, Azusa
campus with twenty years of service with NGES. His development work has focused on
the development of satellite ground systems, building the bigger picture from individual
bits of data Information radiators are thus his natural focus in Agile development He
data.
development.
holds an MS in Management Science from Cal State Fullerton and a BS in
Engineering/English from Harvey Mudd College. He is also a certified Lean-Agile Scrum
Master and a Certified ICAgile Professional.
• James Yoshimori has over 30 years of experience in software development. His work
has ranged from small embedded signal processing systems to very large radar imaging
and infrared processing systems. He has served in various roles from software engineer
to architect to program management. He currently serves as architect, team lead and
Agile process maven for the Situational Awareness and Global Exploitation (SAGE)
project. He holds an MS in Information and Computer Science and a BS in Civil
Engineering from the University of Hawaii Manoa
Hawaii, Manoa.
• Jason Liu is a Software Engineer currently associated with the SAGE project. He has
been with NGES at the Azusa campus since 2009. Jason holds an MS in Computer
Science from UCLA and a BS in Information Computer Science from the University of
California, Irvine.
41