Being truly agile is the dream of any organization. In practice, the term ‘agile’ is often translated into: being able to deliver new customer features fast. This however is not exactly what the original agile manifesto meant. Many things about agile are in fact wrongly interpreted, like: working software OVER documentation is in practice often translated to working software NO documentation. And the idea agile made architecture obsolete, because agile teams are self-steering. A while ago I had the opportunity to talk to Arie van Bennekum about some of the misconceptions of agile. He himself acknowledged to me that architecture is vital for making agile work in a complex enterprise environment. And that agile meant that teams are self-organizing instead of self-steering, meaning they still have to play by the policies and rules of the organization. But besides the the misinterpretations of what agile way of working should be like, of course your architecture should also be able to facilitate or enable agility. If your architecture is made up by an enormous monolith application with enormous internal dependencies (a.k.a big ball of mud) then good luck to you. And even if you don’t have such limiting architecture, how do you ensure you constantly keep cleaning up technical debt so you don’t create one in the future?
Categories