The mantra of faster delivery, sprints and scrums resonate within the agile context of IT. In this blog, we will not discuss agile as such, but focus on The Scaled Agile Framework (SAFe) 4.0 and the role of the architect in this framework.
Bringing the agile mindset to everyone in IT
During their presentation about SAFE 4.0, Danny Dujardin and Bart Lipkens illustrated the renewed role of the architect in the agile mindset at the first inno.com seminar. These seminars are an initiative of inno.com to share their experience with practitioners and experts on relevant subjects such as architecture, project management and development practices. It is a unique insight into inno.com’s experience in the field.
Before starting to discuss the role of the architect, it should be clear that SAFe 4.0 is not about agile programming, but about bringing the agile mindset into the whole IT delivery factory. As you know, the digital revolution that is taking place is increasing its pace even more than before in IT. SAFe 4.0 defines an ideal agile mindset for everyone to benefit from.
Do we still need Enterprise architects?
Enterprise architects in IT have been struggling with the ideas of agile programming. Do we still need them? Is the work enterprise architects do not necessary anymore? Is it really possible to develop big complex solutions without architects? Most of the architects predicted that complex projects would fail when using the agile methodology. And time has proven them both right and wrong. Agile programming has known successes in complex programs, but failures as well.
These experiences have shown that enterprise architects still have a vital role to play. Their role and function has now been accepted by the agile community, you can see it clearly when looking at the SAFe 4.0 framework. But does this means that everything is going well for the architect? Can they continue as before? No, the architect should also embrace the agile mindset.
A new role: being a teamplayer with a long term vision
While SAFe 4.0 gives the architect its position back in the agile development cycle, it also challenges him to be a different architect. Instead of being the almighty authority on architecture, he must become an enabler of architecture. He must change into someone who develops a long-term vision where teams can build on. Moreover, this vision has to be flexible. Not only the architecture itself is of importance, but the practice as well. This means he can no longer do all the architecture work alone, but should become a guide and a supporter for the teams while moving towards a working architecture.
The architect becomes one of the members of the agile team. He should be with the teams when they discuss the design and solution for each component. He should explain the bigger picture and how everything connects. But he should also accept the proposed changes and value their insights and experience in the development. In other words: close and regular communication becomes a key skill for the architect. Also the times when the architect could think out a project during months of study in solitude are far gone. He should harness the collective experience of the team to quickly find solutions together, because the people who are building are closer to the real problems than the architect.
SAFe 4.0 also introduces the concept of enablers. These are technical initiatives meant to support the development of business initiatives. This concept is a clear message towards people who think agile is only about development of direct business value. If only direct gains are pursued, the whole cannot become a system that leverages efficiency gains of common components or the use of well-designed interfaces. There cannot be a clearer message that there should be room for this kind of technical work where others can build upon to make better solutions.
And last, SAFe 4.0 accepts also that architectural practices can and should exists, but embedded in the teams. This enables the teams to do architecture themselves. If it is clear upfront that there is a certain practice chosen, e.g. SOA, and each team is aware of this, the team could independently construct their solution while adhering to the practice. This only works if each member has a clear understanding of what the implications are and what a good practice means. Doing so enables solutions that do not fight the overall architecture but instead complements it. Via communities of practice, such practices can be discussed, learned, and instilled in the organization. So also here, the architect should change and become a mentor ready to teach, but also to learn himself.
So, while SAFe 4.0 recognizes the role of the architect, it also urges to change his practice and the architect himself. From the ultimate authority, he should descend from his ivory tower and be more of a team player, contributing, teaching, and communicating with the teams. And of course, understand that architecture should be flexible. Just like he has to be flexible in accepting new insights from the people building the systems.