Application Architecture

The Dev Team is responsible for creating the architecture --the architectural and technical design discussions start as early as sprint planning (part II) and continue throughout the sprint as the design is being implemented (i.e. coding/construction). Defects, non-functional testing (such as performance, reliability, usability testing) also uncover design issues or problems which result in design discussions and may result in changes to the underlying app. architecture or specific component/subsystem designs.

In Agile projects, Architecture is emergent.

Architecture emerges from the team(s). In early stages of product development, more architecture is needed, so the development team(s) spends more time creating the architecture, but always also delivering at least some functionality.

http://www.pinterest.com/pin/478437160390046467/

Agree with the above, where architecture emerges.

I have a feeling, the following may also add some perspective --

Per the 2013 Scrum Guide, Topic Two:
The Development Team may also invite other people to attend in order to provide technical or domain advice.
.
.
.
i.e. this *could* be Sprint Planning. It may also be at other junctions during the sprint, when this discussion happens.

Is it also feasible that some architects join the scrum team for the first few sprints. Once the architecture is finalized, these architects leave the team?

Product Backlog refinement may take certain design considerations into account, in order to allow better estimation and to improve the readiness of PBI's for Sprint Planning.

Architecture can be defined as "significant design decisions". Seen from this perspective, Product Backlog refinement can be seen as a suitable juncture for facilitating architectural emergence, as certain design decisions may become significant at that point.

It depends on how the organization structures the work. I've seen a couple of models:

(i) Architects in the scrum teams during the initial sprints when the foundation is defined and implemented. In most cases, they are also coding as part of the development team.
(ii) Architects outside the team. The developers in the scrum teams interact with the architects.

The architecture is never "finalized" and continues to evolve throughout the product lifecycle due to changes in the market (technology or domain), or costs and quality reasons related to performance, maintainability, reusability, testability, security etc. However, you might be implying by "finalized" is that enough of the core "components" of the architecture are in place for rapid application development to occur off that foundation.

Some coach said once to me, that most of the beautiful buildings of Europe were build much before the school of architecture was established. So who was the architect of those buildings ?

Its a very valid question. The need and discussion of architecture comes only when something seems unchangeable.

The legacy code is untouched today because of fear of breaking something not because there is no other efficient way. So the problem is not the architecture, but the resistance , cost and fear of change.

But piece meal architecture works differently. we build something and use it, later "we find a better way" to build it, we rewrite it. In most cases the maintenance of bad code is far more expensive than changing the architecture. Value of the new technology also adds to the benefits.

The field of architecture existed many hundreds of years (Egypt, Sumeria, India, Sri-Lanka, China, Greece, Europe) before modern architecture was established.

So with the changes in the Scrum Guide (Nov 2020), does the entire Scrum team become responsible for creating the emerging architecture or would it just be Developers (within the Scrum Team) responsible for it?

I'd suggest that the Developers (within the Scrum Team) can be held accountable for it, in so far as the creation of an emergent architecture proves necessary for increments to be Done.

Thank You Ian!