How do you control the architecture in a flexible design?

Question

How do you guarantee that the project will be built with "good" design solutions that allow a flexible software architecture?

How do you balance between completely moving away from architecture to teams on the one hand, and let the whole architecture be controlled by several people on the other?

Do you have an “architecture group”, “architecture label” or something like that?

Answer 1

A prerequisite for Agile approaches is an architecture that you already know how to use.

If the architecture is not defined and fully understood, you cannot use the Agile approach.

You will need technical splashes that show how the architecture works and how the different parts will fit together. You can do this preliminary sprints, but they will not directly lead to release to users. This is a special case for accessing an architecture that you can use.

Once you have completed this “attempt to understand architecture,” you can begin to perform sprints that lead directly to user releases.

Answer 2

I could explain how to do this, but this says it is better than I could.

Answer 3

I would also recommend reading the fowlers Is Design Dead file, as far as I understand its arguments, if you consider all flexible practices as a whole, then you get the freedom to make big changes and therefore you can develop the architecture.

Refactoring works most efficiently with continuous interaction, testing is improved with TDD and continuous integration ... I could continue. The evolving "architectures" are limited only if you cannot make the big changes required to correct the "errors."

In addition, I think that you have an architect as an interested person in the project, they tell user stories, which, in turn, are transferred to the architect.

It is also a good way to use pair programming with an architect working as part of a pair. In this context, an architect is not so much a devoted person as a hat that a member of the development team wears while pair programming.

I think that XP does not diminish the role of the architect (and architecture), it simply puts responsibility on all team members for the delivery and distribution of costs throughout the project life cycle.

[edit]

In other comments, do not be afraid of any preliminary planning, zero zero moment is a good time to try to outline a plan, just do not bring it strictly to a certain time scale.

Answer 4

In my experience, the best way to do this is with experienced developers / architects working on projects that see a vision of architecture daily.

I would suggest it to the developer of the architecture management project and ensure that all new work is consistent with it.

Answer 5

I handle this by doing some planning ahead - as a rule, I have some experience working with a similar application to help with this. If not, I will do some research in space to get an idea. As soon as the basic architecture is presented, I will begin to develop from it, based on my priority stories. Then I will reorganize when I go to eliminate flaws or errors in the architecture.

Answer 6

Without making a big design ahead, usually there is a basic project that applies to each project. This usually defines the basic levels that must be followed in the design of the application. Most other design decisions are made by each developer.

Our development process is based on short bursts of development with frequent review. The quality of each architecture architecture solution is reviewed at the time of review. It also includes verifying that the code follows the architecture of the product.

Depending on the type of project and the tools available, we also use tools such as macker to automatically check the integrity of the layer cake.