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.
Take a Business & Product First Approach
For various reasons, it is common for reorganizations to occur on an ongoing basis as an imagined universal solution to friction in product development. The next step is to review the working methods. But without actually changing the underlying architecture, which then limits continued product development.
The BAPO model is a reminder that instead says that the business and product strategy (B) should drive architecture and technology (A). These in turn must drive process, working methods & tools (P). These should be used to define the organization (O) to realize the product and technology strategy.
Adapt a Pace Layer Architecture
The lack of architecture work and architecture governance often leads to spaghetti code and big ball of mud. The code ends up in one big lump and it is very difficult to know which end of the thread to pull to change the front-end, back-end or any part of the code. When you find the thread, you don’t know which other parts are affected when the code is changed.
One way to handle this is through a Pace Layered Architecture. In short, a Pace Layer Architecture is a technical stack that enables efficient development of digital products and services. The layers encapsulate code that belongs together and is loosely coupled to underlying complexity to ensure correct, efficient, reusable, configurable development.
Encourage a DevOps Culture
DevOps is about continuously improving the development value flow by improving collaboration, knowledge exchange, standardization, automation and building the ability of the teams to manage both development and operations. Much of this is about constantly improving working methods with the help of technology by improving CI/CD pipelines, improving the developer experience and developing technical platform services. Different companies have reached different stages in the DevOps journey and an architect needs to be at least well versed in the subject and be involved in guiding the construction of the technology stack that is needed.
To Architect
So how do you accomplish a technical transition from a current state to something better? One way is through a stepwise approach.
Start from the actual technical current situation, expectations from the customer, technical possibilities and go to the root cause of technical pain points.
From the current state, outline a technical vision, rather than a detailed target architecture. Overly detailed target architecture work risks being out of date before it is used.
Based on the long-term vision and the current situation, develop principles that guide the development work, which make it easier for the teams to make decisions themselves within given frames.
Specify a first step based on the current situation, to move forward towards the vision. Carry out a “slice”, i.e. take a step end-to-end in a way that goes through all layers of the architecture and creates value for the customer.
When the first step is taken, again deepen the understanding of the new present situation, correct the principles and the vision if necessary and take the next step.
Larger technical leaps
Sometimes it is not enough with a step-by-step approach as described above. It can be difficult to build new in the right way and at the same time eliminate technical debt, there may be a need to introduce new technologies for servers, storage, networks, etc. One way to achieve greater technical mobility is to create Enabling teams. It is a team whose task is to relieve product teams and platform teams with, for example, technical debt and more extensive modernization. Also here, the enabling teams should try to establish new technologies and platforms in a sliced way based on current needs from the product teams.
Alignment
A challenge in architecture work is to ensure governance and that the teams develop in the way that has been agreed upon. How to ensure that the teams follow common principles and that you build towards a common target architecture. Based on agile principles and values, decisions must be made closest to where the expertise exists, and the architects’ task is to make it easier for the teams to make their own decisions. There are several ways to do this:
Self-assessment: the teams assess based on common values, principles and standards. One way is to have a dialogue about what it means to build green vs. to build red. Developers care about building things the right way and by having a common understanding of what it means to build things the right way, they bring problems and challenges to the surface.
Coaching: The architect works closely with the teams and acts on pull, i.e. the teams’ need to, for example, get help in facilitating a target architecture. This is based on deep technical knowledge, trust and a culture where it is ok to ask for help.
Self-service: The next level of self-assessment is for teams to evaluate technical solutions by answering questions in forms or through automated code review.
Architecture Review Board: It is also possible to create a forum for complex architecture issues that span multiple teams, trains, or similar. The main idea is that teams and trains should make decisions themselves, but there can also be situations where technical issues cross organizational borders, making an architecture forum necessary. Important to bear in mind is that the forum should contribute to self-leadership and to enable value flow. There may be a need to make decisions centrally that are negative for an individual team, but the best for the whole.
The Architect
Being an architect in a fast-moving and complex world, where technology is increasingly integrated and changing continuously, is no easy task. The personal qualities quickly tend to become endless and almost impossible to fulfill. But here are some particularly important areas:
Visualization – the architect needs to be a master of visualization. The architecture is often abstract and hidden inside hardware. The architect’s task is to conceptualize, based on the target group and needs at the time. Perhaps the most important thing is to visualize together with others, where experts and stakeholders meet and have a dialogue that leads to shared learning. There are models such as the C4 model and others, which can be used as a common language.
Toolbox – the architect needs to have a number of tools. Principles with common rules and approaches, standards in the form of technical choices, reference models with a common language, templates, design patterns, etc. This to put it in the hands of others, to enable them to carry out architectural work themselves.
Trusted advisor – an architect needs courage and the ability to drive change. Much of what the architect works with is about technology, but at least as much is about bringing people along to accomplish change. Based on that, the architect needs to be a change leader and trusted advisor for senior executives, decision makers, product owners and developers. For example, the architect needs to be trusted to be included in the early stages of the company’s planning and strategy, as well as a facilitator and advisor in technical discussions in the teams.
In summary, all these concepts and ideas presented in the poster can be used in your organization. The exact detail and solution to complex challenges will differ, but hopefully the poster will help you reach a common ground to take the necessary steps forward in your organization.
Now, let’s release the poster to the wind and hope that it spreads to as many organizations as possible and contributes to making the world a little better.
Feel free to contact us if you have any questions.
Free to download, use and share
The posters are published under Creative Commons License, so please use it and share it as you like. If you are interested in doing a translation to any other languages please let me know and I will help you with the file and publish it here in the blog as well.
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material for any purpose, even commercially.
This license is acceptable for Free Cultural Works.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Here you find all the other Free Agile in a Nutshell-posters in the series that is now translated to 14 languages and downloaded over 80.000 times worldwide.
