Technology is an enabler and accelerator for today’s modern product organizations. Companies and organizations often rally around agile working methods and creating effective teams. At the same time, the technology is paradoxically forgotten or taken for granted. It is often when technology poses an obstacle or when the technical debt has grown above the surface that technology issues come up on the agenda.
So the question is, how can we bring in technology development as an equally obvious part of product development? How do we ensure that features and technical enablers mutually contribute to great products? How do we ensure that the technology together with agile working methods solves bottlenecks and enables value flow?
This is where the poster Agile Architecture in a Nutshell comes in.
Download the poster as a High-Res PDF here
The poster is intended as a cheat sheet of condensed wisdom based on experience from digital product organizations. It can be printed and set up in the corridor and be a support in the dialogue between PM, PO, agile coaches, scrum masters, architects, tech leads and developers.
The poster helps to have a dialogue about complex questions such as: What is agile architecture and what is it good for, how do we accomplish technical transition through continuous improvements, how do we take bigger technical leaps, what can we do instead of reorganizing, how should we think when layering the architecture, what is the architect’s role in the DevOps journey, how do you achieve governance in an agile way, how do you get the teams to build in the right way, how should we visualize the architecture, what competence requirements should are important when we hire an architect, what tools does an architect need etc.
Solutions to questions like these differ, of course, depending on the company, industry, history and current challenges. But the poster can be used as a guide in the discussion with engaging illustrations, models and concepts that contribute to the dialogue. All to contribute to working agile with the architecture, which in turn contributes to even more awesome products reaching the market faster.
What is Agile Architecture?
There are plenty of definitions of architecture. There are also plenty of theoretical discussions when architects discuss. At the same time as the architectural work is something very concrete – a work of removing obstacles and creating new opportunities with the help of technology. An attempt to define agile architecture is therefore: “flexible structure that is created just in time to enable value flow”.
It may be wishful thinking, but what is needed is a “flexible structure” that helps the teams today and tomorrow, where it is easy to adapt the architecture to new product requirements, new forms of collaboration and to add new or remove old technology. It leads the thought to loosely coupled architecture that is layered, component-based or broken down into microservices.
“That is created just in time” where long-term and intentional design is balanced with emergent architecture. If the architecture is planned too far in advance, plans and target architectures are out of date before they are used, and vice versa, if the architecture is not planned in advance, the teams create hacks and workarounds. It’s about putting your ear to the rail and finding a sweet spot between the two. Something that must take place in close collaboration with product owners, flow managers and teams.
Architect to enable Value flow
Architecture is fundamentally about continuously creating and improving the flow of value to the customer through products using technology.
Central to achieving this is a constant tug-of-war between the drive to create business value and counter-forces in the form of technical constraints. Business value – the ability to constantly improve time to market, eliminate bottlenecks and improve product quality through technology. Limitations in the form of technical debt and lock-ins created by Conway’s Law which, in a simplified way, means that the teams build the architecture they need, which is often an obstacle when products, teams and ways of working change.
(more…)
