“Everything everywhere” – the age of digitalization requires convenient access to and constant availability of IT systems throughout all channels and devices. However, this means additional complexity in company processes and procedures. As a result, the digital transformation is accompanied by a rigorous agile restructuring of organizations – often blindly following every trend. A consistent enterprise architecture often falls by the wayside and technical debts pile up continuously. Whilst agile evangelicals often fail to pay the necessary attention to sustainable architectural approaches, conventional enterprise architects and lead architects lend weight to holistic architectural management.
Based on the views of these colliding worlds, we call the fifth sin, the “Deadly Sin of Architectural Superbia”.
One of the key design principles of agile organizations is self-organizing teams. These teams are intended to promote the creativity of employees, free them from complex dependencies in their environment and thus increase productivity.
But, does this also work when developing IT applications in large companies? Especially here, the coordination and collaboration between projects and architecture departments is often perceived as inefficient and associated with red tape. It actually seems as if the introduction of agile methods is changing the rules of the game. Agile teams are granted far more autonomy than traditional project teams regarding architecture decisions.
Almost every IT application landscape is characterized by complexity and numerous dependencies, which cannot be managed by small and possibly isolated agile teams. For a lot of companies’ considerable damage can occur when traditional and agile dogmatists clash and fail to jointly set up a contemporary agile architecture management approach.
Agile mindset and architecture - does this add up?
Architecture in traditional companies usually consists of clear guidelines, rules, principles and decisions that are made by architectural committees. In most cases, architects specify artefacts and processes to establish a sustainable enterprise architecture. When implementation projects require the expertise of (lead) architects, e.g., for architectural decisions, they often constitute organizational bottlenecks due to a large number of projects. Nevertheless, anyone who does not follow the architectural guidelines must explain themselves in committees and the project is temporarily on hold due to architectural discussions.
Agile teams, on the other hand, are of a manageable size and complete architecture tasks independently. Architecture rules, guidelines or even processes and committees do not exist or are self-organized. Architecture tasks tend to focus on the day-to-day project activities and their progress. In addition, architectural knowledge varies from team to team and is characterized by continuous learning and acquiring experience.
As a result, missing architecture documentation can give rise to “head monopolies”, which makes it difficult to establish a sustainable enterprise architecture.
Architecture management in the digital age demands a changed and more agile set-up with an accordingly adjusted mindset. It is important to allow both agile and also classic perspectives when designing the architecture environment. In this, one’s own ego and architectural pride (superbia) should not get in the way. The focus of the teams has to be to finish architecture task quickly and successfully. In addition, a suitable approach is necessary to make the increasingly complex (enterprise) architecture more manageable and controllable.
Architecture in an agile environment means being part of a community
On the one hand, an agile mindset means freedom, self-determination and continuous learning. On the other hand, it also means being more consistent and efficient in everything we do or did in the past. These rules do not only apply to managers, but to every member of the team. Projects are not “only” done for the senior management, but for an actual customer with concrete requirements and a vision. As a result, any action of each team member has a crucial impact on the overall outcome and everyone bears responsibility for this result. It is therefore important to support each other and celebrate success stories together. As a result, team members develop a group identity which lets teams grow together on another level.
Support is not only provided within one’s own team but also across teams. Thereby, it is important to proactively promote communication with other teams, to help each other and to learn from one another.
The agile manifesto underpins these approaches: It underscores mutual support and the importance of individuals and interactions.
Overall, it does not matter whether these interactions take place in a casual atmosphere over a game of table football, over a drink or at an organized event or meetings. Every employee is a noticeable vital part of a community and can see and feel their added value.
Architecture – the agile way?
The well-known, agile frameworks address the topic of scalable architecture work and recommend different approaches in this regard. Nexus, for example, says that an “integration team” is responsible for informing the teams about the company’s architecture standards. In Large-Scale Scrum (LeSS), architecture tasks at the team level are handled by experienced team members, eliminating the role of the enterprise architect. In Scaled Agile Framework (SAFe), on the other hand, enterprise architects combine architectural questions and decisions at different levels and provide the technical vision and strategic direction.
But what can be derived from the frameworks in terms of architecture and what other recommendations are there based on practical experience?
In the agile world, the main objective is to follow a collaborative, decentralized and light-weight approach. Lean governance is used to define important issues while intentionally leaving other issues open for the community and teams. Teams can make decisions independently, discuss them in the community and thus help to shape the guidelines bottom-up. One could assume that an agile approach to architectural issues would result in a chaos of different, decentral “designed” architectural styles. In order to avoid such cross-team or company-wide issues, teams must be enabled accordingly. On the one hand, architecture assets such as guidelines, standards and frameworks must be accessible in a common and uniform language at a single point of information and documentation. On the other hand, it should be possible to get assistance from architects with a comprehensive and strategic perspective. Therefore,
it is necessary to clearly define roles and responsibilities and to spread them across “broader shoulders”.
With the help of the developed architectural knowledge, teams can solve simple architectural issues by themselves without the need to involve architects.
Ideally, “architecture gurus” provide guidance by acting as facilitators in close cooperation with the teams and assisting them with active (methodological) support. Moreover, architecture services are “bundled” in the form of a community of practice (CoP), comparable with a guild or a shop, and can be requested by the teams according to the “pull principle”. CoPs thus maintain an overview of critical or cross-team issues. If necessary, they also take care of formats for comprehensive communication and decision-making.
Preferably, comprehensive decisions are based on prototypes or walk-throughs and feedback is solicited from architects, teams and other stakeholders. Such cross-team formats, which are also suitable for casual exchanges and brainstorming sessions, include open spaces, architecture snacks or architecture cafes.
Nevertheless, the independent architectural work of the teams should also be promoted whilst adhering to the standards in place. CoPs can use gamification approaches such as hackathons, scoring boards or architecture belts to playfully create competition and showcase achievements. This allows to distribute and establish architectural knowledge and understanding in the agile organization.
Recommendations
The architecture discipline plays a key role in the strategic orientation of companies. Especially when scaling across multiple teams, business and organizational dependencies lead to challenges in communication and coordination. To establish modern and efficient architecture management and overcome architectural pride, we recommend the following:
Architectural awareness must be omnipresent throughout the entire (enterprise) community, from the employees to the top managers.
Key roles (managers, product owners, scrum/agile masters, architects, etc.) of the (enterprise) community must be directly involved in the architectural work and have to embody the changed architecture mindset.
Architecture management must be established in the form of a suitable, agile organizational setting, such as a CoP or a guild.
Lean architecture governance has to be based on providing certain architectural solutions (e.g., documentation, guidelines) or leaving them deliberately up to the agile teams.
Architecture decisions must be encouraged to be addressed and demonstrated by the teams (bottom-up).
Architecture guidelines and standards have to be proactively designed by the teams.
Creative communication formats (e.g., architecture snacks, architecture cafes) have to be set up for the entire enterprise community.
Cross-team assistance must be promoted and appreciated. The necessary capacities have to be allocated.
The architectural autonomy of the teams has to be increased by leaving problem solving and responsibilities to them.
Successful architecture work and community-wide communication have to be stimulated and rewarded.
All employees and roles must be provided with opportunities for ongoing training and professional development in the field of architecture.
Summary
If it is possible to integrate a community-based architecture management approach into the agile organization and thus to anchor architecture tasks and ways of thinking across the board, (enterprise) architecture management can become significantly faster and more efficient than in traditional organizational set-ups. Consequently, architectural adjustments, redundant functionalities and time-to-market can be reduced which helps to satisfy customer needs within the digital age.
