The success of the
DevOps organization largely comes from focusing on cultivating a strong DevOps team. However, with the in-depth implementation of DevOps, DevOps organizations are faced with a dilemma, in the delivery team and process can not define the corresponding roles and activities for the application architect. DevOps organizations strive to introduce application architecture care, but find it difficult to coordinate with DevOps values, goals, and practices. At the same time, due to the lack of application architecture guidance, it is difficult for DevOps organizations to plan and promote DevOps actions.
DevOps organizations are faced with the dilemma related to application architecture. In a nutshell, they are mainly reflected in the following three aspects:
1. The relationship between the
application architect and the DevOps team is becoming more and more dysfunctional, and at the same time, the lack of communication foundation and mechanism makes it difficult to communicate effectively;
2. The development process does not elaborate when to seek application architecture guidance, which leads to the lack of architectural guidance for application development, and at the same time it is difficult to coordinate the emerging architecture (Emergent Architecture) with the previous architecture requirements;
3. The application architecture role is not defined in product management, and cross-application impacts (such as collaboration and dependency) may not be effectively identified.
In response to the dilemma related to application architecture, in modern application development,
DevOps organizations need to define the responsibilities of application architects so that application architects and DevOps teams can communicate more effectively and deliver more valuable products. In most cases, the application architect is not a member of the DevOps team, because the architectural skills are very scarce and must serve multiple teams. Architects should become domain experts with unique perspectives, coaches who promote architectural knowledge and skills within the team, and mentors to help the team make the best decisions. Specifically, the following three aspects should be focused:
1. Establish a communication mechanism between the DevOps team and the application architect so that the
DevOps team will treat the application architect as an SME, coach, and mentor.
2. Let the application architect provide architectural principles and patterns to guide the emergent design of a single solution (Emergent Design)
3. Let the application architect maintain a high-level view of the product backlog and coordinate across DevOps teams to discover the effects between systems, such as interfaces, reuse, etc.
1 Application architect and DevOps team communicate effectively with different roles
Generally, DevOps teams initially use Agile Framework (such as Scrum) to define development-centric roles and activities, and then add operations-oriented roles and activities to help team members work together better.
Members of the DevOps team work together face to face every day. Over time, through continuous improvement, the DevOps team has formed a transparent, trustworthy, and efficient working atmosphere. DevOps, a team-centric approach, can hardly accommodate outsiders. For example, one of the responsibilities of ScrumMaster is to protect the team from external disturbances.
DevOps should determine and promote the relationship between the DevOps team and the application architect, so that the DevOps team will transform the application architecture from a disruptor to a partner, and the application architect will become a domain expert (SME), coach (Coach) and guide (Guide) , To be jointly responsible for the successful delivery of valuable software.
In traditional software development practices, application architects may only communicate and interact with the technical leaders or project managers of the development team. However, in the DevOps team, the application architect needs to understand the role of the typical DevOps team and establish relationships with it to form effective communication.
· ScrumMaster: ScrumMaster is the team's coach (Coach), facilitator, guardian and guide. They can ensure that everyone understands and follows all aspects of the application architecture of the development process, and work with the team and application architect to optimize the process and promote the interaction between the team and the application architect. Application architects should view ScrumMaster as a very valuable alliance.
· Product Owner: PO is the customer (or business) representative, to ensure that the application contains valuable features. They work with application architects to ensure that application architecture requirements are covered in the backlog. PO and application architects work together to identify and understand cross-team impact and adjust backlogs.
· Developers: Treat
application architects as mentors and potential coaches and consultants. As with any SME job, developers should seek input and clarification from the application architect when necessary. In the development and design of stories, developers can discuss the importance or impact of architecture with the application architect. Developers with architectural knowledge can act as representatives and spokespersons for application architects.
· Platform team: work with architects to ensure that applications use platform services more appropriately. In turn, the architect provides feedback on the evolution of the platform. For example, the architect may suggest creating the function as an application service, rather than a part of the application itself. In the case of multiple platform choices, the architect helps determine which platform is suitable.
· Operations team: Work with application architects to identify methods to maximize application operability, resilience, sustainability, and security. These methods include adding metrics, adding or modifying tool chain components, integrating with management tools such as security event monitoring, and providing configurable options for application behavior.
· Support team: It is a key source of feedback for architects. These feedbacks include the actual and production effectiveness of design decisions.
In addition, the application architect is usually related to the overall solution of the product value stream, so the application architect can identify the collaboration between DevOps teams from a broader perspective and provide trade-off solutions; at the same time, it can help the DevOps team fully understand that only The stronger the application portfolio, the greater the customer's value.
2 Application architects continue to provide principles and models for solutions and embrace feedback
In traditional software development organizations, application architects have been committed to providing a large number of pre-designs to provide application architecture input for the development team. In
DevOps organizations, DevOps teams usually quote the Agile Manifesto, especially the principle that "the best architecture, requirements, and designs come from self-organizing teams." The DevOps team uses an iterative and incremental approach to build applications and continuously evolve solutions to continuously improve and improve the understanding of the needs of stakeholders and how to best meet the needs. Therefore, a large number of static architecture specifications delivered by application architects cannot evolve or provide value, thus becoming a source of waste and a constraint on the value stream.
This does not mean that the application architecture input does not help the DevOps team. If there is no application architecture input, the applications created by the DevOps team will lack important features (such as lack of security, scalability, or reliability), and cannot provide sufficient value to customers; at the same time, applications may also be different due to different basic platforms and weak integration, etc. It cannot match well with other products in the product portfolio. In addition, if the team cannot use the knowledge in the reusable model, it will increase the burden of SME, because SME has to reinvent the wheel. Eventually, experts will run out of capacity and prevent large-scale expansion.
Despite being seen as a barrier to deliberate architecture, the emergent architecture allows agile teams to participate in the creation of application architecture and better match the application architecture. The goal of the application architect and DevOps team is the same, which is to create valuable applications for customers, but they have different perspectives. The DevOps team mainly focuses on the application itself, while the application architect pays more attention to the position of the application in the enterprise application portfolio and provides a consistent customer experience across the application portfolio. Therefore, the tension between the DevOps team and the application architect is inevitable. However, application architects must be willing to discard preconceived ideas and delay architectural decisions to the last moment.
To achieve continuous guidance, application architects are not encouraged to provide a large number of application architecture artifacts for agile teams in advance. The agile team will not be ready to use, or will be seen as an attempt to control the application design. Conversely, application architects should enter some at a time, following the rhythm of the agile team, as problems and opportunities arise during the application creation process. This requires the
application architect to continue to communicate with the DevOps team.
The application architecture principles form the basis of the continuous guidance. Application architects need to provide guidance from the basics. Application architects should fully understand the principles of enterprise application architecture and apply them consistently. Application architects should be prepared to communicate principle-based reasons to clarify why a given requirement needs to be introduced, or recommend the use of a particular pattern. The actual application architecture emerged in the discussion between the application architect and the DevOps team.
Regular feedback should be collected throughout the process. The actual application architecture that emerges during the team's application creation process is not only consistent with the application architecture principles, but often reveals new insights into these principles. Application architect leaders should use these insights to evolve application architecture principles and practices. Application architecture leaders should consider using agile “review” technology to enhance the feedback loop with the application architect team.
3 Application architect maintains a high-level view of product to-do items and influences the items
Backlog is the main driving force of DevOps team activities. The work items in the to-do list are initially coarse-grained, and the DevOps team will break them down into more fine-grained stories. As the work progresses, the to-do list becomes larger and larger, making it difficult to identify the impact of different teams across a single Backlog. In turn, this has led to certain conflicts that can only be found in the production environment and require expensive repetitive work. It also results in opportunities for reuse or collaboration not being realized. It is one of the role of application architects to discover these conflicts and opportunities while taking action to avoid or use them. By continuously guiding the
application development team, the application architect will maintain the Backlog view, which has both breadth and depth. In this way, they can influence Backlog accordingly. When an agile team needs guidance on application architecture, understanding and monitoring Backlog is the key to preparing guidance. Application architects can influence Backlog in 3 areas: Item Priority, Cross-Team Impact and DoD (Definition of Done).
