Did someone lose Architecture’s invite to the Agile party?

It sure is awkward showing up to party and realizing it was invite only and you are not sure you ever got one. Similarly, there’s a weird tension that exists for any Architect that gets injected into a true Agile development environment for the first time. No longer are there extensive drawn out sessions and phases to layout a long term plan and design to build something to last ‘forever’. Scrum Teams are self organizing and everything is evolving so rapidly.

It’s likely less dramatic, but the tension is real. The open question exists : “How much architecture needs to be done upfront vs how much should be deferred until the requirements are nailed down?” In reality a rapid development environment, like Agile leaves little time to address cross cutting concerns and setting up all the infrastructure needed for a large scale system. Such an activity also requires a broad view across multiple features and teams.

There’s sort of a trade-off; You spend too much time up front planning and you lose your ability to adapt to changing requirements. You move too fast and it could be chaos. One recommendation is to go with what George Fairbanks terms “Just enough architecture.” But, what does that really mean and how does it apply to different complexity of projects? Like Rick Kazman once illustrated, building a shed is so much different to building a skyscraper. While it’s easier to operate within a self-organizing team when building the former, the latter requires more attention to detail. On the flip side, it’s simply a waste of time to devote the same amount of time upfront building a shed as you would a skyscraper.

George Fairbank’s comment is really hinting on having the right amount of architecture at the right time. Overall, I believe risk reduction should be the chief motivation in how we approach architecture in Agile. It should influence how an Architect approaches documentation and evaluation as well (twin tension points for Architects in an Agile environment).

So how do we hit the ‘Sweet spot’ between upfront planning and agility? Here are 5 things I have learned

·  Focus on what poses the greatest risk to the system’s main function and qualities. Then channel your energy to mitigate that risk.

·  Seek to architect around separation of concerns, loose coupling and decomposability.

·  Document only what is needed. If there’s no audience for your documentation you probably don’t need it. If there’s a part of the architecture that a lack of clarity for a newcomer might become a RISK for the project/system, document it. Also, starting with a design that captures simple end to end functionality upfront is a reasonable goal.

·  Lean on good code and test suites to reflect architectural patterns and decisions.

·  Emphasize experimentation (Spikes). And take advantage of such agile principles as an Architecture Runway and Technical debt. Discipline and rigor around them allow for resolving trade offs.

In conclusion, Architecture might no longer get a red carpet like it used to in dev gigs, but there’s no doubt that it definitely does have an invite to the Agile party.