Home > Architecture, DAD discussions, Inception phase > Disciplined Agile Architecture: Initial Architecture Envisioning

Disciplined Agile Architecture: Initial Architecture Envisioning


An important aspect Disciplined Agile Delivery (DAD) is its explicit inclusion of an Inception phase where project initiation activities occur.  Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  Some people will mistakenly refer to this effort this Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception and the November 2010 Agile State of the Art survey found that agile teams have Construction iterations of a bit more than 2 weeks in length).

Regardless of terminology, agile teams are doing some up front work.  Part of that initial work is identifying an initial technical architecture, typically via some initial architecture envisioning http://www.agilemodeling.com/essays/initialArchitectureModeling.htm.  Because your architecture should be based on actual requirements, otherwise you’re “hacking in the large”, your team will also be doing some initial requirements envisioning  http://www.agilemodeling.com/essays/initialRequirementsModeling.htm in parallel.  Your architecture will be driven in part by functional requirements but more often the non-functional requirements, also called quality of service (QoS) or simply quality requirements.  Some potential quality requirements are depicted in the figure below (this figure is taken from the Disciplined Agile Delivery book but was first published in Agile Architecture Strategies ).

Architectural views and concerns

Some architects mistakenly believe that you need to do detailed up front modeling to capture these quality requirements and then act upon them.  This not only isn’t true it also proves to be quite risky in practice, see my discussion about Big Modeling Up Front (BMUF)  for more details.  Disciplined agilists instead will do just enough initial modeling up front and then address the details on a just-in-time (JIT) basis throughout construction.  Of course it’s important to recognize that just enough will vary depending on the context of the situation, teams finding themselves at scale will need to do a bit more modeling than those who don’t.  It’s also important to recognize that to address non-functional requirements throughout construction that you need to have more than just architectural modeling skills.  This topic will be the focus of my next blog posting in this series.

About these ads
  1. October 11, 2012 at 9:45 am

    If
    – most software projects exist to maintain (correct/enhance) an existing product
    – agile productivity is highest when teams are stable (i.e. same people each project)
    – shorter release cycles provide better adaptation to markets
    – a product backlog is almost always greater than the project/release backlog
    would it make sense to drop the project paradigm for anything not greenfield?

    and if we do away with projects in favor of ‘continuous maintenance’ is there a need for inception?

    In which case, inception is required for greenfield projects, but not for most software development, which is instead based on an extant (and continuously revised) backlog. When the backlog no longer exists … I don’t know what happens

  2. October 11, 2012 at 1:24 pm

    Good question. One of the things that we talk about in the book is that when those sorts of things happen (stable team across releases, shorter release cycles, …) then Inception does in fact start to disappear over time.

    BUT:
    – There is still some Inception effort on the first release, and hopefully decreasing for release 2, release 3, …
    – There is still some need for Inception when there’s been a break in continuity (a mostly new team working on the new release, the solution hasn’t been worked on for awhile, …)

    The implication is that you need to work in the right manner for the situation that you find yourself in. Different situations require different approaches. This is why DAD promotes a goal driven approach, not a prescriptive one. You’ve still got the same goals of identifying an initial technical strategy or addressing changing stakeholder needs, for example, but you will address those goals differently. A stable, experienced team in maintenance mode will address those goals in a different (and very likely more efficient) manner than a new team that is still figuring things out.

    The age-old consultant answer of “it depends” still holds. DAD tries to answer the follow on question of “on what”.

    Skip, good to see you on this site as well as attending my Intro to DAD webcast earlier today. Once the recording of that webcast is available I will announce here in the blog.

  3. Valentin Tudor Mocanu
    July 10, 2014 at 1:14 am

    We can have more cases
    – projects for new product
    – projects for changes to existing product
    – “projects” for fixing problems on exiting products

    The easy case is , and of course we need an initial architectural envisioning. The existent architecture could be preserved or could be more or less changes. Any of this option it is an architectural decision (change or preserve).

    When we have a new product, that it is a high risks case, where the architectural envisioning it s mandatory and critical.

    Defects fixing – it is special kind of beast. Could be viewed as very, very small project that should make the fix and preserve the architecture. In many cases, severe or repeated defects could be sign of architecture problems. That could be observed also in non-software endeavors. Robert C. Martin has give the example of the Space Shuttle, but the history of engineering it is full of undesired events were major defects are caused by bad architectural decisions. There are many cases were because of the defects magnitude you cannot continue with that architecture

    My conclusion – the relationship between functional, non-function requirements and their realization by architecture and design must be a persistent concern. A similar monitoring and concern must be done for relationship between architecture/design and the products defects.

    imho without architecture envisioning we were out of real engineering.

  1. October 14, 2012 at 10:44 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 625 other followers