Potential Misconceptions about Agile Architecture

 

Recently at the Scott W. Ambler + Associates site we received a series of questions from someone who wanted to better understand how architecture issues are addressed on agile project teams.  It seemed to me that the questions were sufficiently generic to warrant a public response instead of a private one.  So, over the next few days I’m going to write several blog postings here to address the issues that were brought up in the questions.  It’s important to note that I will be answering from the point of view of Disciplined Agile Delivery (DAD), and not agile in general.  Other agile methods may provide different advice than DAD does on this subject, or no advice at all in some cases.

The goal of the first blog posting in this series is to address several potential misconceptions that appeared in the email.  I want to start here so as to lay a sensible foundation for the follow-on postings.

Partial Misconception #1: Agile can be prefixed in iteration 0 by architectural design

I’ve named this a “partial misconception” for a few reasons:

1. Disciplined agile teams do some up-front work.  This is called the Inception Phase in DAD, although other methods may refer to it as iteration/sprint 0, warm up, initiation, or other names.  Up-front work is an explicit part of DAD.
2. Iteration 0 isn’t an accurate term.  Although I have used this term in the past when discussing project initiation, the reality is that the average agile team spends about a month doing project initiation activities whereas the average iteration length is two weeks.  So, Inception really isn’t a proper iteration.
3. Inception is more than just architecture.  Several activities typically occur at this point in time, particularly initial architecture envisioning, initial requirements envisioning, initial release planning, and putting the team together to name a few things.

Chapters 6 through 12 in Disciplined Agile Delivery describe these project initiation activities in detail.  Also, I recently wrote that it requires discipline to keep Inception short.

Partial Misconception #2: On principle, Agile is against “big” anything

This is also a “partial misconception” for several reasons:

1. There is in fact a lot of agile rhetoric against big artifacts.  It’s very easy to find agile writings about the challenges with big requirements up front (BRUF), big modeling up front (BMUF) in general, and detailed up front planning for instance.
2. Disciplined agile is against needless waste, not “big” things.  Many traditional modeling and planning practices prove to be quite wasteful in practice.  A serious cultural challenge that the traditional community has is that they are afraid to throw out the bathwater because they assume that the baby will go with it.  I believe that Disciplined Agile Delivery (DAD), and Agile Modeling before it, make it quite clear that it’s possible to gain the benefit of thinking before doing without taking on the very serious problems around doing too much thinking before doing.  So, have the discipline to keep the thinking “baby” yet discard any needless documentation “bathwater”.
3. In rare situations it’s appropriate to create “big” artifacts.  Disciplined agilists aim for sufficient artifacts, the size of which will depend on the context of the situation that your team finds itself in.  In a recent article for Dr. Dobb’s Journal, Disciplined Agile Architecture, I explicitly explored how initial architecture envisioning on an agile project may result in “big” artifacts in some situations.  These situations are very rare mind you, ignoring cultural imperatives to create big artifacts because some people still haven’t made the jump to a disciplined agile approach, but they do happen.  One of the strengths of the DA toolkit is that it is goal driven, not prescriptive, and explicitly explores the tradeoffs surrounding the amount of detail to capture and when to do so.

Partial Misconception #3: Refactoring system architecture beyond mid-implementation is much more expensive than refactoring components

Once again, this is a partial misconception.  I suspect part of the problem is a lack of understanding of what refactoring is really all about, a recurring problem with experienced traditionalists, and part because of a lack of understanding of how architecture is address by disciplined agile teams.  Some thoughts:

1. Refactorings are simple, not difficult.  The goal of refactoring is to make SMALL changes to your design that improve the quality without changing the semantics of the design in a practical manner.  This is true of code refactorings, database refactorings, user interface refactorings, and other types of refactorings.  Small changes are inexpensive to make given the appropriate skills, tools, and organizational environment.
2. Architectural rework (not refactoring) is often difficult.  Rework, or rewrites, are very large changes the goal of which is typically to replace large portions of your solution.  Yes, the later in the lifecycle such rework occurs very likely the more expensive it will be because you’ve built more based on that architecture that is now being reworked.  This is a general issue, not just an agile one.
3. Disciplined agile teams get going in the right direction to begin with. The practice of initial architecture envisioning, which we describe in detail in Chapter 9 of Disciplined Agile Delivery, aims to think through the architectural strategy before getting into construction.
4. Disciplined agile teams prove their architecture works early. The first construction milestone, prove the architecture, reduces the risk of architectural rework.  The goal is to prove that the architecture works by building a working end-to-end skeleton of the solution which implements critical/difficult technical requirements.  This is an agile “fail fast” strategy, or as we say in DAD a “succeed early” strategy, that reduces technical risk on your project.   As an aside, including explicit light-weight milestones such as this is one of many agile governance aspects built right into DAD.
5. Disciplined agile teams have an architectural role.  This role is called Architecture Owner and one of the responsibilities of the person in this role is to guide the team in architectural issues throughout the entire DAD lifecycle.
6. There are no guarantees.   No matter how smart your approach, there’s still a chance that rework can happen.  For instance, you can be mid-way through a project and the vendor of a major architectural component of your solution decides to withdraw it from the market.  Or the vendor goes out of business.  Or perhaps your firm is taken over by another firm and the new owners decide to inflict, oops I mean bless you with, their architectural strategy.  Stuff happens.  Once again, this is a general issue, not specifically an agile one.
7. Quality decreases the cost of rework.  Disciplined agilists will write high-quality code, with a full regression test suite in place, at all times during Construction.  It’s easier to rework high quality artifacts compared with low quality artifacts, so if you get stuck having to perform rework at least the pain is minimized.  My article Agile Testing and Quality Strategies overviews many techniques.

In short, disciplined agile teams do what they can to avoid architectural rework to begin with by having an explicit architecture owner role who focuses on architectural issues throughout the entire lifecycle, by identifying a viable architectural strategy early in the project, proving that architectural strategy works early in Construction, and producing high-quality artifacts throughout the lifecycle that are easier to rework if needed.   With continuous documentation practices and a focus on producing artifacts which are just sufficient enough for the situation at hand, this proves to be far more effective than traditional strategies that assume you require large up-front investments in “big” artifacts, that rely on validation techniques such as architecture reviews instead of the far more concrete feedback of working code, and that often leave quality strategies to the end of the lifecycle (thereby increasing the cost of any rework).

I plan two follow-on blog postings in this series, one exploring how initial architecture envisioning works and one about how to address initial quality requirements (also called non-functional requirements or quality of service requirements) on disciplined agile projects.  Stay tuned!

At Scott W. Ambler + Associates we offer a one-day workshop entitled Agile Architecture: A Disciplined Approach that you should consider if you’re interested in this topic.  We also offer coaching and mentoring services around agile architecture.