Slides that Jean-Louis Marechaux and I presented at Innovate last Wednesday. Got some interesting feedback to include in the future.

1. Design on a Diet! A Lightweight Design
Process
Jean-Louis (JL) Marechaux
Worldwide Technical Enablement and CoP Leader – Collaborative Lifecycle Management
jl.marechaux@ca.ibm.com
Daniel Leroux
IBM Distinguished Engineer – Architecture, Design and Engineering Lifecycle Management
dleroux@ca.ibm.com
ADSN-2131
© 2013 IBM Corporation

2. Please note the following
IBM’s statements regarding its plans, directions, and intent are subject to change or
withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment,
promise, or legal obligation to deliver any material, code or functionality. Information
about potential future products may not be incorporated into any contract. The
development, release, and timing of any future features or functionality described for our
products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance that any
user will experience will vary depending upon many factors, including considerations
such as the amount of multiprogramming in the user’s job stream, the I/O configuration,
the storage configuration, and the workload processed. Therefore, no assurance can be
given that an individual user will achieve results similar to those stated here.

3. Agenda

Agility at scale, ALM, and Architecture & Design

Design and Backlog management

Design and Sprint planning

Design and Iterative development

4. 4
Your work environment - Raise your hand if….
1. You work on an agile project
2. You team size is over 10 resources
3. Your team use tools for planning, requirements management, tests, or change requests
4. Your team is distributed
5. Some team members work from home on a regular basis
6. You have never raised your hand so far

5. 5
Agile scaling factors: needs for a more disciplined approach

6. 6
Quick poll
According to agile best practices, there is no architecture in Agile
projects.
True
False
Would you develop a software-intensive system without thinking?
Yes
No

7. 7
Architecture and Agile: a contradiction?
 No architecture role does not mean no
architectural tasks
– Architecture & design is the responsibility of the
whole team
 Design activities does not necessarily imply
models or documentation
– Brainstorming
– Creative thinking
– Problem solving
 Agile thought leaders recommend agile
architecture
– « Continuous attention to technical excellence
and good design enhances agility. » - Agile Manifesto,
principle #9
– « The best architectures, requirements, and designs
emerge from self-organizing teams. » - Agile Manifesto,
principle #11

8. 8
<
Typical agile development lifecycle (Scrum)
Feedback
Backlog Sprint Backlog
Tasks
Working increment
Test
Code
Refactor
Production
Incidents
Continuous
Delivery
Continuous
Integration
Many teams have adopted a similar development lifecycle, including our Jazz
Design Management development team.

9. 9
Agile Architecture and Design in ALM:
A team approach to design management
 Design management is a team effort
– Everyone contributes to design information
– Everyone leverages information in designs
– Design needs to be integrated in lifecycle, not external
 Design information is useful throughout
the ALM cycle
– Backlog
– Planning
– Sprint
– Change request
– Defect / incidents
– Reduce technical debt
– Continuous delivery
– And more……
 Lifecycle traceability
– Requirements, design, quality, and change management
– Focus on activities useful for the whole lifecycle
Requirements
Architecture &
Design
Quality
Change &
Configuration
Code

10. Architecture in Agile projects
Some key architectural activities your team can’t ignore, whether you are “Agile” or not:
 Define the approach for developing the system
– Identify key best practices & patterns to leverage
– Drive technical decisions
 Identify the appropriate technical components too meet:
– Functional requirements
– Non-functional requirements (availability, security, performance…)
 Define the structure of the system (runtime and deployment)
 Continuously validate architectural consistency
 Continuously communicate with all stakeholders (wherever they may be located)
 Continuously validate against (possibly volatile) requirements
10
Agile architecture is about finding the right balance between “anticipation” and “adaptation”
 Initial envisioning
 Evolving and emergent design
Source: Succeeding with Agile, M. Cohn, 2007Source: Succeeding with Agile, M. Cohn, 2007
Agile architecture is about finding the right balance between “anticipation” and “adaptation”
 Initial envisioning
 Evolving and emergent design

11. Agenda

Agility at scale, ALM, and Architecture & Design

Design and Backlog management

Design and Sprint planning

Design and Iterative development

12. Design information for backlog ranking
Backlog ranking – Why design helps?
 Experimented Product Owners know that business value is
not the only factor
 Take into account design information for ranking based on:
– Risks
– Dependencies
– Complexity
 Design information helps uncover technical risks and
dependencies
 Complex items sometimes require a design feature team to
be assigned to design scenarios and break down features

13. Design Management supports working as a Team
 Increase team knowledge through
an enterprise-wide software design
repository
 Scenario designers, analysts,
architects, developers, testers, and
other extended team members can
access designs through a Web
client
13
Threaded discussions on
scenarios and early
designs
Rich hovers provide quick
access to information to
determine if additional details
are required!

14. Everyone stays connected
 Dashboards
provide an easy
way to stay
connected with
design activities
 Design
comments,
recent links,
most active,
design reviews,
design changes
 Create mashup
dashboards with
viewlets from
across the
application
lifecycle
14

15. Some of the architectural and design expressions we use
for architecture envisioning/backlog
prioritization/understanding
15
Component Architecture
Tactic/Scenario Model
Deployment Architecture
Live Architecture
Documents
FreeForm Diagrams

16. Agenda

Agility at scale, ALM, and Architecture & Design

Design and Backlog management

Design and Sprint planning

Design and Iterative development

17. Design information for Sprint planning
Sprint planning – Why design helps?
 Assess technical feasibility of requirements
– Explore design alternatives
– Leverage guidance and past decisions when possible
 Identify tasks to implement stories
 Evaluate development effort based on:
– Lessons learned from the previous sprints or projects
– Potentially reusable assets
– Technical complexity Planning

18. Learn from the past
 Quickly search across all of your organizations designs on the server for learning, review,
analysis, or to identify potential reuse
 Search directly on the server; no need to load designs into a client first
 Simple full text search over model content (name, description, type)
 Powerful query based searching
18

19. New* Architecture Decision Knowledge
 Architecture Decision support (ADK)
 Simple way to manage information about
architecture/design issues and decisions
 Other users can benefit from the decision making
process
 Leverage past decisions, understand
rationale
 Impact analysis helps to identify decisions for
specific issues

20. Some of the expressions we use for sprint planning – our
distributed whiteboard for reasoning around tasks
20
Capability/Block diagrams
Conceptual Data/Resource Model
Deployment Architecture
Live Architecture
Documents
FreeForm Diagrams

21. Agenda

Agility at scale, ALM, and Architecture & Design

Design and Backlog management

Design and Sprint planning

Design and Iterative development

22. Design to support iterative development
Development & testing – Why design helps?
 Sketches for ideation and problem solving
– “A picture is worth a thousand words”
 Design tasks for complex user stories
– Design “in a flash”
– Communicate design to team
 Design activities intertwined with development activities
– Look at design for code development
– Look at design for test scripting
– Various levels of automation possible
 Reduce technical debt
– Capture design decisions for reuse, revisiting, …
– Understand impact of change
22

23. Live Design Documents
 Create living
design
documents
 Rich text
documents
with embedded
design links
 Add to any
design project
 Keep current
as designs
change
23

24. Decision

25. Generating or creating formal models from the informal
expressions
25
Informal expressions can
seed the content for formal
models
Can convert individual shapes
and connections into formal
model elements

26. Automation: e.g. Model RESTful Services and Generate
JAX-RS Based Web Services
26
Generate JAX-RS based
Web Service from Model
Deployed on
Application Server
Generate Model from
JAX-RS based Web Service
Model RESTful Service in RSA

27. Teams have visibility into coverage & completeness
27
 Proactively respond to gaps as they surface throughout the project
 Issues are quickly highlighted and resolved
 Different views available

28. Some of the expressions we use during sprint feature
development – our distributed whiteboard
28
Flow/Activity diagrams
Resource/ontology models
Component diagrams
Live Architecture
Documents
Use case diagrams

29. Summary: Lightweight design process for agile teams
 Simplicity is essential
– Design Management provides simple tools
 Light design supports agile teams
– Backlog management
– Sprint planning
– Iterative development during Sprints
 Everyone in the team creates and uses design
information
 Design evolves over time
– Emergent design (done incrementally)
– Intentional design (decision making process)
– Some design aspects may be anticipated
(envisioning)
 Balance between anticipation and adaptation

30. 30

31. 31
Daily Apple TV giveaway
 Complete your session surveys online each day at a conference kiosk or on
your Innovate 2013 Portal!
 Each day that you complete all of that day’s session surveys, your name will
be entered to win the daily Apple TV!
 On Wednesday be sure to complete your full conference evaluation to receive
your free conference t-shirt!

32. 32
Acknowledgements and disclaimers
© Copyright IBM Corporation 2013. All rights reserved.
– U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
IBM, the IBM logo, ibm.com, Rational, the Rational logo, Telelogic, the Telelogic logo, Green Hat, the Green Hat logo, and other IBM products
and services are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or
both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these
symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may
also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and
trademark information” at www.ibm.com/legal/copytrade.shtml
If you have mentioned trademarks that are not from IBM, please update and add the following lines:
[Insert any special third-party trademark names/attributions here]
Other company, product, or service names may be trademarks or service marks of others.
Availability: References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries
in which IBM operates.
The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided
for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any
participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided
AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise
related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating
any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license
agreement governing the use of IBM software.
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may
have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is
intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue
growth or other results.

33. 33
© Copyright IBM Corporation 2013. All rights reserved. The information
contained in these materials is provided for informational purposes only, and is
provided AS IS without warranty of any kind, express or implied. IBM shall not be
responsible for any damages arising out of the use of, or otherwise related to,
these materials. Nothing contained in these materials is intended to, nor shall
have the effect of, creating any warranties or representations from IBM or its
suppliers or licensors, or altering the terms and conditions of the applicable license
agreement governing the use of IBM software. References in these materials to
IBM products, programs, or services do not imply that they will be available in all
countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion
based on market opportunities or other factors, and are not intended to be a
commitment to future product or feature availability in any way. IBM, the IBM logo,
Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products
and services are trademarks of the International Business Machines Corporation,
in the United States, other countries or both. Other company, product, or service
names may be trademarks or service marks of others.

34. “Just Enough” Expressions and Traceability within Agile
Architecture and Design
34