agile

Is Agile Architecture an Oxymoron?

Peter Cripps architecture , ,

Much has been written by many great minds on agile development processes and how (or indeed whether) architecture fits into such processes. People like:

  • Scott Ambler (Architecture Envisioning: An Agile Best Practice). “Some people will tell you that you don’t need to do any initial architecture modeling at all.  However, my experience is that doing some initial architectural modeling in an agile manner offers several benefits”.
  • Mike Cohn (Succeeding with Agile). “On an architecturally complicated or risky project, the architect will need to work closely with the product owner to educate the product owner about the architectural implications of items on the product backlog”.
  • Walker Royce (Top 10 Management Principles of Agile Software Delivery) : “Reduce uncertainties by addressing architecturally significant decisions first”.
  • Andrew Johnston (Role of the Agile Architect): “In an agile development the architect has the main responsibility to consider change and complexity while the other developers focus on the next delivery”.
  • Martin Fowler (Is Design Dead?):  “XP does give us a new way to think about effective design because it has made evolutionary design a plausible strategy again”.

I’ve been contemplating how the discipline of architecture, as well as the role of the architect, fits with the agile approach to developing systems whilst reviewing the systems development lifecycle (SDLC) for a number of clients of late. In my experience most people have an “either-or” approach when it comes to SDLC’s. They either do waterfall or do agile and have some criteria which they use to decide between the two approaches on a project by project basis. Unfortunately these selection criteria are often biased toward the prejudices of the person writing the criteria and will push their favourite approach.

Rather than treating agile and waterfall as mutually exclusive I would prefer to adopt a layered approach to defining SDLC’s as shown here.

The three layers have the following characteristics:

  1. Basic Process. Assume all projects adopt the simplest approach to delivery as possible (but no simpler). For most software product development projects this will amount to an agile approach like Scrum which uses iterations (sprints) and a simplified set of roles, namely: Product Manager, Scrum Master and Team where Team is made up of people adopting multiple roles (architect, programmer, tester etc). On such projects decide up front which artefacts you want to adopt. These don’t need to be heavy-weight documents but could be contained in tools or as sketches. Here the team member performing the architect role needs to manage an “emergent architecture”. The role of architect maybe shared or not dedicated to a single individual.
  2. Complex Process. At the next level of complexity where multiple-products need to be built as part of a single program of work and all these have dependencies some level of governance usually needs to be in place that ensures everything comes together at the right time and is of a consistent level of quality. At a micro-level this can be done using a scrum-of-scrums approach where a twice or thrice weekly scrum that brings together all the Scrum Masters happens. Here the architect role is cross-product as it needs to ensure all products fit together (including maybe third party products and packages). This may still be a shared role but is more likely to be a dedicated individual. This may involve some program level checkpoints that at least ensure all iterations have created a shippable product that is ready to integrate or deploy. The architecture is not just emergent any more but may also needs to be “envisioned” up-front so everyone understands where their product fits with others.
  3. Complex Integration Process. The final level of complexity is caused when not only multiple products are being developed but also existing systems need to be incorporated which have complex (or poorly understood) interfaces. Here the role of the architect is not only cross-product but cross-system as she has to deal with the complexity of multiple systems, some of which may need to be changed by people other than the core development team. Here the level of ceremony as well as the number of artefacts to control and manage the decisions around the complexity will increase. The architecture is certainly not emergent any more but also needs to be “envisioned” up-front so everyone understands where their product fits and also what interfaces they need to work with. This is something Scott Ambler suggests happens during “iteration zero“.

Each of these layers is built on a common architectural as well as process “language” so everyone has a common understanding of terms used in the project. I’m much in agreement with Mike Cohn’s comment on his blog recently where, in reflecting on the tenth anniversary of the Agile Manifesto he says: “The next change I’d like to see (and predict will occur) over the next ten years also occurred in the OO world: We stop talking about agile” and goes on to say “Rather than “agile software development” it is just “software development”—and of course it’s agile”.

I would like to see an agile or lean based approach as the de-facto standard that only adds additional artefacts or project checkpoints as needed rather than thinking that every time we need to either adopt an agile approach or a waterfall approach.

Architecture is Architecture?

Peter Cripps architecture ,

At OT 99 (that’s Object Technology 1999, now known as SPA for Software Process Advancement) I attended a session by Kent Beck called Software is Software – Beyond the Horseless Carriage. The basic premise of Kent’s talk was that it was about time the software business “grew up” and its practitioners recognise it for what it is, a discipline in its own right which no longer needs to continuously borrow terms and techniques from other industries and disciplines. The title of the session refers to the time when the automobile was first invented and people called them horseless carriages because horse-drawn carriages were the only frame of reference they had. Unfortunately, 12 years later, I don’t think we have quite got around to jettisoning our horseless carriages, especially in the upfront work that is done in trying to map out the major system components and their relationships, sometime referred to as architecture (a word which itself is borrowed from another profession of course). On the face of it this may not seem to be a problem; after all those other industries (civil engineering, auto-engineering even film making) have been around a lot longer and so must be able to offer good advice and guidance to the business of software mustn’t they? Actually, I think there is a problem and Kent Beck was, and still is, right.

  • The business of ‘making’ software is fundamentally different from any other human endeavor. Software is infinitely malleable and potentially changeable right up to (and sometimes after) it has gone into production. No other engineering discipline has that flexibility. At some point drawings and blueprints have to be signed off, factories and production lines have to be built, building sites prepared and production begun. After this any change becomes prohibitively expensive. With software the perception (and sometimes the reality) is that code changes can be made right up to the moment the software ships.
  • Most other engineering disciplines have fairly well defined job roles, often with their own professional organisations, training programmes and qualifications and well understood and mature tools. These roles are usually carried out by separate individuals (in the construction industry it’s unlikely the architect will roll her sleeves up and start laying bricks).
  • The engineering and manufacturing approach, or process, is by and large pretty well understood and has been refined over a long period of time (sometimes hundreds of years). The approaches can be taught and are an integral part of the role of being an architect or aero-engineer. Further, these approaches are built around a common language which is also taught and well understood by its practitioners.

A rigorous approach to the field of software architecture needs to recognise the differences whilst at the same time understanding its constraints and build a solid, engineering based approach to its development. This should include killing off the endless debates of agile versus waterfall or structured versus object-oriented and any of the other interminable ‘religious wars’ that we seem to love embarking on and focus in on what matters: applying IT in a reasoned and structured way to solving real-world (and sometimes complex) business problems.

As we enter the new year lets celebrate the field of software development for what it is and help forge the right amount of rigor and discipline in creating a ‘proper’ profession that finally loses the shackles of all those other industries. After all as this guy says (far more eloquently than me) “the processor is an expression of human potential” and is “akin to a painter’s blank canvas” (see this great drawing). I’d like to think of us architects as the painters ready to fill that canvas with great art. Oh heck, but that means we are now comparing architecture with art and that would never do.