The answer is of course to build your product and solutions incrementally with continuous learning cycles. In the lean-agile context, the teams are the true engines of the development. What about the architecture in the lean agile context?
Architecture is a property of a system, not a description of its intended design, so like it or not – the architecture will be there, despite focusing on it or not. Architectural thinking will enable the usage and the development of the product, or it could inhibit it, for sure. Here are three important things to focus on for the IT architect who wants to make a difference to product development.
Value creation
Aligning the strategic vision of the product with what is being built is always a challenge. Aligning business requirements with the technical requirements is a real balance act. SAFe provides good ceremonies and rituals to bridge this. The architect is a suitable candidate to facilitate mapping of the strategic intent of the enterprise with the product vision and its product development increments.
Utilize architectural thinking to bring clarity among different stakeholders. The important process of structuring, mapping, and splitting important backlog items such as epics, features, and stories are typical architectural skills that should be utilized to facilitate scoping in different contexts. The art of aligning and prioritizing the product backlog is key to ensure value is created step by step.
Also spend the time necessary to understand the quality attributes of your product. Some of the quality attributes will be perceived during execution, and some are simply affecting the ability to change. Always rely on the perpetual relevance of the non-functional requirements. Facilitate this dialogue and utilize the teams to define the relevant product behavior, always related to the product life cycle. This will make a true difference for the value of your products appearance and adaptability.
Continuous flow
Products should be developed continuously. Every team should have the possibility to design their part of the delivery! An adaptive design, always full stack perspective, and the ability to deliver incrementally is key to a modern development process.
The system architect should encourage and enable this but also anchor the solution vision and remind the teams of the intentional architecture. This could include relevant standardization of technical layers (UX, SW framework, API, DB, technical platform etc.) naming conventions or preferred patterns. Prove in demo and practice to the team how this will speed up the delivery pace and support the product quality. Early feedback from the teams is the most important factor to understand if an architectural decision is contributive or not. This is also a part of the continuous learning cycle that SAFe encourage.
Architecture thinking should be the true enabler for flow. Nota bene – an architecture review boards should never act as an impediment for flow. Architects should also act as ambassadors for improving the DevOps flow to enable continuous exploration, integration, and delivery. You can´t have business agility without investing in technical agility. This will make a huge difference to your product development flow.
Communication and collaboration
The explicit architecture is the perfect communication tool as it contributes to motivate teams and enables collaboration. Every team should have the possibility to see the bigger picture – what are the context, what are the value being created incrementally etc. This is sometimes hard for the business owners or the product management team to clarify.
Model it out, use your architectural skills to visualize different perspectives and views of the product and the solution. Customer perspective, financial perspective, development vs operation perspective etc. The architect should be the true facilitator for this. Just enough modeling and documentation is key though and mitigation of all sorts of analysis-paralysis manners without focus on value creation.
Architects should be available to the different development teams all the way and encourage communication and collaboration. Bridge the classical gaps between business vs IT, development vs operation and utilize the architect elevator between the strategic and operational levels.
