Agile Strategies for Enterprise Architects

1
Agile Strategies for Enterprise Architects

• Scott W. Ambler
• Practice Leader Agile Development
• IBM Rational

2
My Background

• Practice Leader Agile Development, IBM Rational
• Senior Contributing Editor, Dr. Dobbs Journal
• Fellow, IASA
• www-306.ibm.com/software/rational/bios/ambler.html

3
Agenda

• Warning!
• Examining Traditional Architecture
• Agile Software Development
• Agile Strategies for Enterprise Architecture
• Beyond Architecture

4
Warning!

• Im spectacularly blunt at times
• Many new ideas will be presented
• Some may not fit well into your existing
  environment
• Some will challenge your existing notions about
  software development
• Some will confirm your unvoiced suspicions
• Dont make any career-ending moves
• Be skeptical but open minded

5
Agenda

• Warning!
• Examining Traditional Architecture
• Questioning Project Level Architecture
• Questioning Enterprise Level Architecture
• Why Architecture Goes Wrong
• Agile Software Development
• Agile Strategies for Enterprise Architecture
• Beyond Architecture

6
Questioning Project-Level Architecture

• Have you ever developed a system architecture,
  only to discover
• The developers ignored it?
• It didnt work very well in practice?
• The team built great foundational frameworks,
  only to have the project cancelled anyway?
• The underlying technology changed during the
  project, requiring a rearchitecting effort?

7
Questioning Enterprise-Level Architecture

• Has your enterprise architecture efforts
• Never really gotten off the ground?
• Produced great ideas, which were then ignored by
  the development teams?
• Provided nothing more than a parking lot for
  bright people (your EAs)?

8
Why Architecture Goes Wrong

• Poor tooling
• Many architects are too far removed from actual
  development
• Thinking things through up front is inefficient
• Too much modeling removes the joy from
  development
• Hand-offs increase risk through injection of
  communication errors (e.g. Chinese whisper)

9
Agenda

• Warning!
• Examining Traditional Architecture
• Agile Software Development
• Agile Software Development (ASD)
• Adoption Rates
• Success Rates
• Going Beyond the Mainstream
• Agile is Relative
• Agile Strategies for Enterprise Architecture
• Beyond Architecture

10
Agile Software Development

• An iterative and incremental (evolutionary)
  approach
• performed in a highly collaborative and
  self-organizing manner
• with just the right amount of ceremony
• to frequently produce high quality software
• in a cost effective and timely manner
• which meets the changing needs of its
  stakeholders.

11
Has Your Organization Adopted One or More Agile
Techniques?
Source DDJ 2007 Agile Adoption Survey, August
2007 issue
12
Project Success Rate ()
Source DDJ 2007 Project Success Survey, December
2007 issue
13
Challenges with Agile in the Mainstream
Compliance requirement
Critical, Audited
Low risk
Geographical distribution
Entrenched process, people, and policy
Co-located
Global
Minimal
Significant
Agile Development
Organization distribution (outsourcing,
partnerships)
Application complexity
Simple, single platform
Complex, multi-platform
In-house
Third party
Team size
Degree of Governance
Under 10 developers
100s of developers
Informal
Formal
14
Agility is Relative
15
Agenda

• Warning!
• Examining Traditional Architecture
• Agile Software Development
• Agile Strategies for Enterprise Architecture
• Look Beyond Technology
• Working Software Over Comprehensive Documentation
• Agile Modeling Strategies
• Agile Modeling at the Enterprise Level
• Agile Modeling at the Project Level
• Beyond Architecture

16
Look Beyond Technology

• You need to understand the business
• Architecture must be based on requirements,
  otherwise you are hacking
• There are two aspects to architecture, business
  and technical
• Individuals and interactions
• Supplying models and documents isnt sufficient
• Support project teams
• Roll up your sleeves and work closely with the
  teams
• Architecture comes from teams, not individuals

17
Working Software over Comprehensive Documentation

• Prove it with code
• Working code samples (reference architectures)
  are far more valuable than whitepapers or models
• Build an end-to-end skeleton as soon as possible
• The longer you go without the concrete feedback
  of working code the greater at risk you are
• Refactoring and test-first approaches are
  critical to your success

18
Agile Modeling Strategies

• Think about the future, just wait to act
• Look at the whole picture
• Make architecture attractive to your customers
• Multiple views
• Active stakeholder participation
• Model with others
• Just good enough is the most efficient

19
Agile Enterprise Architecture

• Create slim models at first
• Get actively involved with teams
• Mentor them
• Lead the technical effort
• Work with stakeholders
• Evolve enterprise architecture artifacts over time

20
Agile Project Architecture

• Create slim models at first
• Model the details just in time (JIT)
• Travel light
• You need good modeling tools

21
Agenda

• Warning!
• Examining Traditional Architecture
• Agile Software Development
• Agile Strategies for Enterprise Architecture
• Beyond Architecture
• Agile Process Continuum
• Lean Development Governance

22
The Agile Process Continuum
Rational Unified Process
Eclipse Way
XP, Scrum, OpenUP, DSDM
23
Lean Development Governancewww.ibm.com/developerw
orks/

• Pragmatic Governance Body
• Staged Program Delivery
• Business-Driven Project Pipeline
• Scenario-Driven Development

• Iterative Development
• Adapt The Process
• Risk-Based Milestones
• Continuous Improvement
• Embedded Compliance

• Simple And Relevant Metrics
• Continuous Project Monitoring

Organization
Processes
Mission Principles
Measures
Roles Responsibilities
Policies Standards

• Integrated Lifecycle Environment
• Valued Corporate Assets
• Flexible Architectures

• Promote Self-Organizing Teams
• Align Team Structure With Architecture

24
Thank You

• Scott W. Ambler
• www-306.ibm.com/software/rational/bios/ambler.html
  

25
References and Recommended Reading

• www.agilealliance.com
• www.agilemodeling.com
• www.agiledata.org
• www.enterpriseunifiedprocess.com
• www.ibm.com/developerworks
• Ambler, S.W. (2002). Agile Modeling Effective
  Practices for XP and the UP. New York John Wiley
  Sons.
• Ambler, S.W. (2003). Agile Database Techniques.
  New York John Wiley Sons.
• Ambler, S.W. (2004). The Object Primer 3rd
  Edition AMDD with UML 2. New York Cambridge
  University Press.
• Ambler, S.W. and Sadalage, P.J. (2006).
  Refactoring Databases Evolutionary Database
  Design. Reading, MA Addison Wesley Longman, Inc.
• Larman, C. (2004). Agile and Iterative
  Development A Managers Guide. Reading, MA
  Addison Wesley
• McGovern, J., Ambler, S.W., Stevens, M., Linn,
  J., Sharan, V., Jo, E. (2003). The Practical
  Guide to Enterprise Architecture. Prentice Hall
  PTR. 

26
Agile Valueswww.agilealliance.com

• We value
• Individuals and interactions
• Working software
• Customer collaboration
• Responding to change

• Over
• Processes and tools
• Comprehensive documentation
• Contract negotiation
• Following a plan

27
Agile Principleswww.agilealliance.com

• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software.
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.
• Business people and developers must work together
  daily throughout the project.
• Build projects around motivated individuals. Give
  them the environment and support they need, and
  trust them to get the job done.
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
• Working software is the primary measure of
  progress.
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be
  able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and
  good design enhances agility.
• Simplicity--the art of maximizing the amount of
  work not done--is essential.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behavior accordingly.

28
Keynote Description

• Agile Strategies for Enterprise Architects Agile
  software development is quickly being adopted
  within organizations worldwide and will likely to
  be the norm by the end of the decade.
  Architecture is an important part of any agile
  software development project, contrary to popular
  belief. Just like a traditional team can benefit
  from enterprise architecture (EA) support, when
  it's done right, so can an agile project team.
  The secret is in doing EA right, and traditional
  approaches to EA simply aren't "right" for agile
  projects the high failure rate with EA efforts
  tells us that traditional approaches likely
  aren't right for traditional teams either. This
  keynote describes effective strategies for EA
  which will enable enterprise architects to
  effectively support agile teams, strategies which
  are based on collaboration and working software
  instead of command-and-control and comprehensive
  documentation.