Introduction
In 2011, Kent Beck, one of the creators of The Agile Manifesto, provided an intriguing explanation of Agile by turning it on his head, in his talk "Software G-Forces: The Effects of Acceleration". More than 10 years later, this is still a compelling watch, particularly in considering how Agile has been utilized between now and then. It also raises some interesting questions about the ways in which it could relate to architecture.
Agile as an Emergent Property
Essentially, we can view Agile as an emergent property of faster releases. More than just an invented imperative of how teams "should work", it can be seen as an observation on how development has reacted to this increasing velocity. Looking through this lens, we can observe different characteristic traits, such as how, over time, previous best practices have become worst practices (or vice versa) as time has gone on and context changed. For example, extensive manual testing and highly structured software specification being undertaken by BA's went from best practise to poor. While conversely, releasing straight to live environments has gone from being considered a "cowboy practice" to an established norm.
Breaking Down the Walls
In addition, Agile has broken down the wall between business and development by reducing potentially extensive specifications down to a sentence or two on a small card. This represents 'the promise of a conversation' that comes with Agile, making communication a more central part of the workflow. Similar walls could be seen break down when devops came along, bridging development and IT operations in the name of tighter, faster iteration.
The Impact on Architecture
With more rapid releases has come the requirement for a high level of reliability to be baked into code and automated processes, which pinpoints how the emergence of Agile radically changes architecture design and implementation, and also notably contradicts the idea of architecture being a top-down design activity.
Vertical vs Horizontal Design
One can consider a significant area of contrast between Agile and traditional architecture to be in terms of verticals and horizontals. In Agile, the rapid source of incremental value comes in the form of user stories: individual units of work designed to directly provide value to the users. This is what's known as a vertical slice. A user story is focused on just that – the user, and everything they encounter from UX to the backend. Whereas traditional architecture is predicated on horizontal, system-wide design: log-in systems, email systems, caches, and data stores just to name a few examples. This exists at odds with delivering vertical slices of user value, and is the reason we find so-called "technical stories", which have nothing to do with user value, in supposedly Agile projects.
The Future of Agile Architecture
This contrast is probably why we haven't really seen a truly Agile architecture yet. It might even be the leading reason why so many companies run into problems trying to truly adopt Agile across the entire organization.
So, it demands the question: what might an Agile architecture look like? With user stories as our units of value, it could be significantly different from the grand designs we often see, and more like a modest solution that simply gets the job done. With the earlier point on best and worst practices switching sides, this could even be considered (and likely viewed by many) as an "anti-architecture".
The Potential of Microservices
But the building blocks could already be here with the emergence of microservices. Similar to devops before, there is still a process of maturity ahead (during which one can expect many spaghetti-like messes to be created), though it is well underway. There isn't quite a full alignment between microservices and something so vertical as a user story, however, they do provide a level of encapsulation that an agile architecture will require. The scalability and benefits provided by their orchestration can potentially offset the challenges that will come with reframing architecture as a vertical design activity.
Conclusion
At Fluxus, we try to think outside of the box. With our AWS development services, alongside fixed-term transformation consulting, we can tackle your architecture in an Agile way. Let's get in touch and build something;
