Agile Architecture Is Not Fragile Architecture

Recorded at:

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.

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 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.

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.

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 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.

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.

I found many concepts of this presentation while I was reading "Lean Architecture for SW Agile development". I think that the best way to describe the Architecture, is this quote ".. a good up-front architecture can reduce re-factoring. To argue that you should start with a casually or briefly considered design and then let re-factoring bring you to good code structure recalls an old adage ....: Hope is not a plan"