Musings on Architecture in an Agile World

With everything currently going on at the moment I thought I would take a little bit of a break from the mock-up gamification design and post some musings around some work related subjects that have come up recently.

My experience has been, when people think of architecture in an Information Technology sense, they think of complex, sometimes hard to interpret, diagrams and artefacts that look good on paper but take a long time to develop and are potentially harder to implement.

Everyone is doing agile

In the project delivery realm, it seems like everyone is doing agile these days and if you’re not working within an agile methodology you may as well look for other projects. Unfortunately there are some that assume agile means no documentation and no pre-planning, just sit with the customer and bang out a product. Also unfortunately, there are also some who believe that agile projects should go through a project gating cycle. Sometimes for each cycle. That’s right. EVERY. SINGLE. ITERATION.

Architecture is about direction, not detail

I’m, generally speaking, a pragmatist when it comes to architecture and solution design. Architecture should be fluid enough to adapt to project methodology, development methodology, development patterns, requirements, strategy and users. Consequently, all architectures should provide enough direction to ensure everyone is heading the right way without boiling the ocean. For agile projects, where problems and requirements are not clearly defined, architectures should provide breadth and options. For waterfall projects, where problems and requirements are clearly defined, architectures should provide depth and direction.

Architecture is also about providing shared vision

Architecture should also be about providing a shared vision. In an agile project, where the goal is far away and there are many hills in between, that end vision will be indistinct but the direction will be set. Architecture needs to mimic that, aiming for the general direction of what we think is right while providing options to get there. As the goal creeps closer the direction firms up and the options to reach the goal diminish. In the review of every sprint of an agile project the architecture should be reviewed, options trimmed and depth provided based on the success and failures of the last sprint.

Ivory towers look good from afar but are impractical up close

Sorry architects but this means, now more than ever, the shouting of directions from the ivory tower are not effective or successful. Direction and strategy at the organisational level is still important and valuable, but polishing architecture artefacts for five years before presenting them as “finished” is not useful. Architects need to be conduits between management, providing detail to the strategy, and developers, providing strategy to the detail. Too much either way is a recipe for disaster.