Literature describes traditional architecture as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution,” (ISO/IEC/IEEE). SAFe has a broader definition, defining Agile architecture as a set of values and practices that support the active evolution of the design and architecture of a system while implementing new system capabilities. It brings some characteristics, such as the need to evolve systems over time while supporting needs of current users, ensuring systems always run, supporting the continuous flow of value, and balancing intentional architecture and emergent design.
...value is what your customer wants or needs.
In a Scrum Team, we have a Product Owner. The Product Owner is the owner of the product backlog and accountable for prioritizing all the work to be done. Unfortunately, sometimes Product Owners don’t have a technical background – and theoretically, they don’t need to have it – but it leads to a lack of attention to the technical side of the product or solution. In this case, one option is to empower the team and rely on the developers to identify and assess any big technical change or implementation that needs to be done to support the business. In an Agile Release Train in SAFe, we have a Product Manager (PM), acting as the ART Product Owner for backlog items – aka business features – related to the business. The PM is responsible for features, new functionalities, and everything that brings direct value to customers. However, we also have a System Architect. The System Architect also acts as a Product Owner for the ART, being accountable for building the architectural runway and prioritizing technical and architectural backlog items, also known as Enablers.
Architects have the stereotype of being too technical and not handling or understanding the business. This is unfair. Moreover, many companies have a big gap between the business & business people, as well as between the architecture/technical side of things & the technical people. SAFe takes care of this part, bridging the gap between business and architecture by positioning architects – and in this case, specifically the System Architect – as people who are directly contributing and collaborating with business people. Architects are leaders and responsible for building the Agile Release Train backlog. Architects have a strong system thinking, and we will get there soon.
Architects are leaders and responsible for building the Agile Release Train backlog.
Think about the architectural runway as a real runway – a highway – that needs to be planned and built to allow business to pass through. If architects know nothing about the business and what is planned next, this runway won’t be built properly. If business does not give enough attention and room for technical and architectural activities, then the highway will not be sustained. These two sides of the coin need to collaborate, and priorities need to be assessed properly. Collaboration between Product Management and the System Architect of an Agile Release Train must be there, along with transparency, alignment, and trust, so that the balance between new features – bringing the most in terms of value to customers – and new Enablers – sustaining the whole business – is considered and done properly.
Business needs strategy. Architecture needs it, too.
Business needs funding to stay alive. Architecture needs it, too.
Architects have a strong system thinking. They design the architecture. They have a mindset of understanding how components interact with each other and what is the best way to design these interactions. Teams are components which are part of a bigger component called the Agile Release Train (ART). How teams interact is key to understanding and optimizing how your ART is delivering value. Lead time, time to market, dependencies – all of them rely on a high quality and well-designed Agile Release Train. You ART is also a component which is part of a system that is represented by the organization, and it is very important to design this component well to have it loosely coupled with other components. Onboarding architects in a value stream workshop – the first step towards assessing how an organization is structured, where the value is flowing, and what systems and teams are involved – brings a lot of value. Architects give an expressive collaboration in identifying your value stream.
More than technical actors, architects are key to a SAFe transformation. Since the beginning (by helping to design the ART), they are identifying architectural and technical activities to help support the business, acting at the portfolio level with a strategic view, and helping teams to execute their strategy.
SAFe has a specific training for architects – SAFe for Architects – to educate and explain how architects position themselves in a SAFe organization, either as team member architects, System Architects, Solution Architects, or Enterprise Architects. At Gladwell Academy, we offer this training both remotely and in-person in several different countries. Check our schedule to see if there’s a SAFe for Architects training taking place soon that’s right for you.