InfoQ

InfoQ

Presentation

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Recorded at:
Recorded at

Agile Architecture Is Not Fragile Architecture

Presented by James Coplien & Kevlin Henney on Jun 10, 2008 Length 00:54:57
Sections
Process & Practices
Topics
Architecture ,
Agile Techniques ,
Adopting Agile ,
Agile
Tags
QCon ,
Qcon London 2007
The next QCon is in London March 5-9, Join us!
 

How would you like to view the presentation?

In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Architecture is perceived as a heavy-weight activity which does not fit into an Agile process, so many teams start without it, just to find themselves re-doing the software later because the code structure was not good enough to support maintainability and evolution. In this presentation, Coplien and Henney describe how to start with enough architecture to ensure long term success of the project.

Bio
Coplien is a Senior Agile Coach, and Systems Architect working at Gertrud&Cope. He is a well-known industry speaker, author, and innovator. Henney is an independent consultant and trainer based in Bristol, UK. He has developed and delivered training courses, consultancy and software across a number of domains.

About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
I love this presentation! by Sadek Drobi Posted
Interesting... by Ilja Preuß Posted
Re: Interesting... by Sadek Drobi Posted
Agile Fragile Architecture summary by Martien van Steenbergen Posted
Pity no write up... by Rob Brown Posted
Fantastic by Peter Andersen Posted
  1. Back to top

    I love this presentation!

    by Sadek Drobi

    Don’t Play dumb! If you know some stuff celebrate that you know it and put a peg in the ground.

    To do agile you should be standing on a firm foundation.

    Stability != Static

  2. Back to top

    Interesting...

    by Ilja Preuß

    though a little bit long-winded.

    I also was a bit disappointed that they confuse the adjective "agile" with the *name* "Agile Software Development". Scrum, DSDM and XP are instances of the latter, which is *defined* by the Agile Manifesto.

  3. Back to top

    Re: Interesting...

    by Sadek Drobi

    Agile software and more precisely Scrum have existed some time before the Agile Manifesto. So it is allright to talk about agile software without referring to the manifesto. Jim for instance AFAIK is one of the pioneers of agile developpement, yet he did not take a part in the Agile Manifesto meeting.

  4. Back to top

    Agile Fragile Architecture summary

    by Martien van Steenbergen

    "Transcript" below is a copy of wiki.aardrock.com/Agile_Architecture_is_not_Fra...

    Free interpretation of [www.infoq.com/presentations/Agile-Architecture-... InfoQ: Agile Architecture Is Not Fragile Architecture]

    By James Coplien and Kevlin Henny.


    • Agile Architecture is not a blueprint.

    • Agile Architecture is about what changes you can ignore.

    • Agile Architecture is about impactful choices up front that will make later chioces easy..

    • Agile Architecture is not laissez fair.

    • Agile Architecture embodies the critical design decisions that typify a system: relates to cost of change, organisational structure (isomorph; ...'s law)m structure of code, capabilities of a system, etc.

    • Agile Architecture is about the significance of decisions that need to be understood and assessed.

    • Agile Architecture is about to see the forest for the trees.

    • Agile Architecture is subject to change.

    • Agile Architecture is not about insuring fear.

    • Agile Architecture is about stable ground, but not frozen (static) ground.

    • CAT DOG‚ÄîComponent Architecture Group and Distributed Objects Group

    • Agile Architecture is about a shared vision that educes the best out of smart knowledgeable developers and delivers (business) value in the most effective and efficient way.

    • Agile Architecture is not about big (outdated buggy) documents.

    • Agile Architecture is about the documentation that packs the punch, that describes what matters.

    • Agile Architecture is about writing that what matters in a way that matters (go, have a writing course).

    • Agile Architecture is about getting a Mercenary Analist.

    • Agile Architecture is about empowering local decisions (decision makers near the action).

    • Agile Architecture is about patterns and principles.

    • Agile Architecture is about team conversations and communication and team effort and team organisation and team structure.

    • Agile Architecture is about minimal coupling and maximum cohesion.

    • Agile Architecture is about speeding up, getting velocity in your team.

    • Agile Architecture is the foundation for interaction design (GUI)‚ÄîThe Interface is the Program, (Raskin))‚Äîthe user interacts almost immediately with the architecture (tightly linked through the user interface).

    • Agile Architecture is about separation of concerns, not about divorce‚Äîinvites to focus on protocol over API.

    • Agile Architecture is guided (driven) by interaction design (and the domain model).

    • Agile Architecture is about understanding the thing you are building, about the process of building it, and about making progress in building it.

    • Agile is an adjective (bijvoegelijk naamwoord)‚Äîhaving the faculty of quick motion, nimble, active, ready. Latin: to do. (You actually have to do something.) Agilious.

    • Agile is not a method, a religion. (Although, in the English language, you can verb any noun and noun any verb.)

    • Agile can describe a process, an organisation, an architecture, a mentality, an attitude, a mindset, a skill set, etc.

    • Agile is not "done" (you cannot "do" agile).

    • Agile does not sound scary.

    • Agile Architecture makes you ready.

    • Agile Architecture makes you active.

    • Agile Architecture makes you nimble.

    • Agile Architecture enables you to move quickly.

    • Agile Architecture is good when it reduces the significance of decisions (so you can have decision makers near the action with confidence).

    • Agile Architecture helps amortising cost of change. (Architectuur helpt met teniet doen van veranderkosten).

    • Agile Architecture helps releasing energy and passion in those who use it, live it or grow on it.

    • Agile Architecture becomes ossified (verbeend, versteend, afgestompt) door FUD (AOT) en bureaucracy.

    • Agile Architecture is about making the hard decisions early so the easy decisions become easier. Doing the easy ones first makes the hard ones harder. Metpahor: fill up a barrel with various size stones: first the big ones, then the small ones: gives more leverage: the small rocks will find the spaces to fit into.

    • Agile Architecture is about discrimination between reversible and irreversible decisions (at the appropriate time; sometimes knowing that it is or will be an important decision, and you are not yet able to decide but know when you must be. So you can safely defer your decision until then).

    • Agile Architecture is about forgiveness and that it is okay to make mistakes.

    • Agile Architecture is about sustainability of people, process and code.

    • Agile Architecture is about feedback at different levels of (time) scale.

    • Agile Architecture is about awareness and visibility of what is being built and how.

    • Agile Architecture is about the right detail at the right time and in the right place (TDD).

    • Agile Architecture facilitates and guides test-driven development.

    • Agile Architecture is about the engagement of the people in the process.

    • Agile Architecture is about failing comfortably fast (rather than slow and in an agonizing and painful) and knowing about it.

    • Agile Architecture is about fashionable systems.

    • Agile Architecture is about dramatically reducing risk at all levels.

    • Agile Architecture is about dramatically reducing evolutionary costs (operations and maintenance, even demolition).

    • To Architect is not a verb. To Design is. Architecture is a product of design.

    • Architects are developers, coders and designers.

    • Agile Architecture is about (SSSUFD) Some Short Small Design Up Front.


      • Ten minutes is good, half an hour is max.

      • Let the code participate in the design session.

      • BUFD the project slayer.

      • Analyze This To Death (ATTD).

      • Fear-driven design (FDD) vs. Courage Driven Design (CDD) with TDD at different levels of (time) scale for your feedback loops.

      • Niels Bohr: Be careful about predicting things, especially if they concern the future. The joy of quantum mechanics.

      • BUFD is on one extreme.

      • NUFD (No Up Front Design) is the other extreme.

      • Can work under condition (circumstances) degree of familiarity.

      • There is no such thing as NUFD‚Äîyour years of experience do count as UFD.

      • Architectural patterns are UFD based on up front experience.

      • NUFD needs YNUFE (You Need Up Front Experience)).

      • Risky paths do need SSSUFD.

      • RUFD (Rough Design Up Front): give me the map, the whole elephant, the countours, the vision, the overview, that's enough. I can then figure out the right details at the right time.

      • How much of RUFD is enough?


        • It depends.

        • Develop your feel about it.

        • It can take as long as two sprints and as short as '''about a week'''.

        • A nice packaging is to use a single sprint.

        • Must have working code at the end of this sprint.

        • Deliver your architecture as code, as abstract base classes and some '''base-lined''' documents.

        • It grounds you in reality and gives you the platform to take off and implement the user stories as you go forward.

        • Spike it.



    • Agile Architecture is about pay now or pay later:


      • Especially in the financial market.

      • Second or third to market are often more successful thant first to market.

      • Marktonderzoek wijst uit dat sterftecijfer onder first to market is veel hoger dan onder second or third to market.

      • Als tweede of derde in de markt zijn geeft je de mogelijkheid te leren van de fouten van anderen.

      • Zie bijvoorbeeld AltaVista -> Yahoo -> Google.


    • Agile Architecture is about a single up front sprint doing inception, cranking out abstract base classes and some relevant baselined documentation.


      • Accelerating during the third and subsequent sprints.


    • Agile Architecture is about doing RUFD and poetry or short stories as documentation during the first sprint.

    • Agile Architecture is about continuously evolving the architecture after the first sprint.

    • Agile Architecture is about having it finished at the end of each sprint.

    • Agile Architecture is about structure that aligns with the domain and its organization (and its ecosystem).

    • Agile Architecture is about efficient refactoring‚ÄîNot about being first to market, then redesigning your whole system during the fourth sprint after you had the "Oh, shit" experience during the third sprint, taking a three-month slip, and ending up as last and loser.

    • Agile Architecture is about the critical things that we currently do not know enough and will '''inform''' (give form and shape to) our system and take responsibility for it now, and defer the less critical ones to a subsequent sprint and handle them at the right time.

    • Agile Architecture is about interfaces: locality, dependancy horizon: put yourself in a class and look for its boundaries:


      • Where do you enter the system classes?

      • How much and how far can you see?

      • It's really worrying if you can see yourself‚Äîstrange loops.

      • How distant is it?

      • How much do you need to know (of the world) in order to implement yourself?

      • You want the world to be relatively small in order to be good at your responsibilities.

      • You want the horizon to be fairly close. Interfaces are a very useful way to increase locality (as well as decision makers near the action).


    • Agile Architecture is about having the courage to change architecture


      • Don't be afraid of changing architecture‚Äîtt's software.

      • Hindsight often shows that it wasn't so hard after all‚Äîit's software. It's malleable.

      • Be suprised by how '''soft''' you can make it, especially the coupling‚Äîmake it loose.

      • Hardware is relatively easy to change too.

      • Decompose it and rearrange it in new, innovative ways and be surprised.

      • Decompose with respect to time.


  5. Back to top

    Pity no write up...

    by Rob Brown

    I liked the presentation with many things mentioned that I liked to hear about but I just can't go back and watch or jump around the video trying to find them again - would have liked a transcript :(

  6. Back to top

    Fantastic

    by Peter Andersen

    Great work James and Kevlin!

    /Peter
    www.codelean.com

Educational Content

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.

Polyglot Persistence for Java Developers - Moving Out of the Relational Comfort Zone

Chris Richardson shows how he ported a relational database to three NoSQL data stores: Redis, Cassandra and MongoDB.

The Golden Circle – Why How What

Jean Tabaka challenges the audience to reflect on what Agile practices they are employing, how they are using them, ending with the questions “Why have their organization chosen to go Agile?

The Web Platform as a Limitless Pool of Innovation, with Andreas Gal

Andreas talks about the benefits of the Open Web and how it compares to proprietary stacks. He also talks about various projects that push the envelope like Boot to Gecko, Broadway and pdf.js.

Hadoop and NoSQLin a Big Data Environment

Ron Bodkin discusses early adoption of Hadoop, NoSQL and describes MapReduce and related libraries and Frameworks. Other topics include Hive, Pig, multi tenancy, and security in a big data environment

Spring and Platform Interoperability

Stephen Bohlen explains how Spring helps with interoperability between Java and .NET, demoing it with the help of a sample application.

How to Stop Writing Next Year's Unsustainable Piece of Code

Guilherme Silveira mentions some of the turning points in project development that may affect the quality of the code offering advice on avoiding writing crappy code.