Architect in Agile Team

In the last post I described what I think about the role of an analyst in agile team. The second role that I would like to mention is the role of the architect. This role is defined in the classic approach to software development. However, the agile approach to architecture and architects does not mention much. Only in the assumptions of the agile manifesto (my emphasis) appears:

The best architectures, requirements, and designs emerge from self-organizing teams

And here the problem begins, because a self-organizing team may be the best of the best, but the development of a complex architecture sometimes requires some wider competence. You need a look at the solution from a different, broader perspective. This perspective may include application architecture, but also business architecture. This wider perspective is necessary especially in large organizations, where we have not only agile teams, but also external suppliers, teams working more classically. In addition, we have many ongoing projects and technologies that cannot be changed, etc.

Theoretically, when the team develops its own architecture, it increases understanding and acceptance of architecture for everyone, because they worked on it as a team this time. In the case of many cooperating teams, we may already have too many points of view and a total crisis may occur. Going further, in larger applications and solutions composed of many applications, the emphasis on early provision of functionality may lead to significant coordination problems. Too much agility can lead to chaos. Controlling the situation begins to require the cooperation of many different teams.

Work coordination is needed.

Particular attention should be paid to not only not to duplicate all functions, but also to ensure their availability at the right moment. What’s more, besides the architecture of the application, you cannot forget about the business architecture. Planned changes in business processes must be consistent with the schedule of changes in applications.

Simply put, no team in a larger company is able to see the whole picture or rationally anticipate all changes over time. Many of the mentioned changes appear outside the scope of their work. For this reason, teams need a certain intentional architecture, understood as a set of purposeful, planned architectural guidelines that, taking care of the solution design, its performance and usability, will be a guidepost for teams during synchronization of implementation.

This is where the place for the architect appears.

Architects can help define “rules” that will help connect teams. There is a difference between software design and architecture. Architects do not deal with the architecture of a single application, but rather should provide guidance on how applications should work together to ensure the implementation of business processes, also the so-called. “end-to-end” processes.

Architects set the functional boundaries of individual applications. Architects should understand the high level of abstraction which functions an application should provide. They should also understand technological limitations resulting from past decisions as well as current organization decisions.

Architects do not need to know exactly all the attributes in the database tables or interface operations. However, they must know what services individual applications offer and what data groups they process. Architects must also support the quality of solutions by supervising the implementation of a number of non-functional requirements.

It is this knowledge together with the application development map that allows for the co-ordination and coordination of the work of many agile teams. An architect in agile terms is one of those roles that have the task of limiting the effects of excessive “bad” agility. An architect is a person who must have a long-term vision going beyond the sprints.

When we look at the architect’s role from the point of view of SCRUM, this role does not exist. Probably some of the competences of the application architect will be taken over by a more experienced team member. Solution architects, corporate and business architects do not get involved in these teams because their scope of work goes beyond sprints. For this reason, the role of architects should be constructed next to the teams. Perhaps an architecture team will be created in large companies. Please note that I wrote next to them and not the bands.

An architect is a person whose competence and experience is to support and strengthen the organization. The architect’s role is not to plan the work of the teams, but only to strengthen and coordinate their work. For this reason, the architects, the owners of the products, the team can be put in a line, as the people who should cooperate in providing the best solution.

Should the above architecture be created at the very beginning of the project?

It’s rather difficult. There are too many factors to be sure that nothing will change. It seems that it is wise to first build an initial architecture and define the development goals of architecture. You may be able to prepare a coarse, target application map. Such a “road map”, which will allow the teams and other stakeholders to present the direction to which architecture is heading.

The “road map” can and should also apply to business processes. It is worth knowing which processes we are going to robotize, which to automate and which to extinguish. In subsequent iterations, in the next sprints, architects detail architecture to help teams decide or define guidelines on how to communicate between applications and the scope of data processing.

When writing about the guidelines, it is worth mentioning a wider catalog of architecture products.

In my opinion, architectural products should be considered in the strategic and operational context. From a strategic point of view, architects should, in accordance with the business strategy and IT strategy, develop and communicate technologies and architectural principles related to cooperation between applications. These should be meaningful short documents. The vision of target and transitional architecture in UML or ArchiMate notation is welcome. Links between high-level business processes and applications even indicated.

Operationally, depending on the organization, architects have minimal architectural guidance or in more complex situations high level architecture. Diagrams of components and sequences are welcome. Architects should also make architectural decisions when planning sprints. Register of decisions and architectural deviations is indicated. It is especially useful when the decisions are periodic.

To sum up. The role of the architect in an agile approach, in my opinion is important. Architects do not act as team members, but they can support these teams. Coordination of “global” changes both in the business and application layer is not easy. In my opinion, however, it is necessary. I think architects are the ones who are able to “embrace chaos” and I hope that they are doing it 🙂

More from my site

  • Implementation of the Methodology – Selection of a Modeling Tool In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build […]
  • Reviews of Models in Enterprise Architect Software development is a process in which the reviews of the status of work are a daily or almost everyday situation. Verification of analytical and design works as well as architectural […]
  • When is it worth modeling in UML? For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the […]
  • Modeling of Business Processes in the Software Development Process Business process modeling is relatively common today. In many organizations, it is even done in two places :-). In a cell responsible for improving or supervising processes and in IT, […]
  • Analyst in Agile Team The role of the analyst and the importance of analysis in many organizations is strengthening and in others it is disappearing. Quite often, where there is an agile approach, the role of […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top