Chapter Wrap Up

Summary

To establish conceptual integrity in our architecture, we’ll need an architectural lead. One of this person’s roles is to ensure that the architecture is always as simple as possible (but not simpler).

The architecture will evolve over time, and will not be stabilized before the business development starts, because freezing the architecture will prevent its improvement and simplification. The often-heard requirement of stable software means nothing else than asking for hardware. Software is soft by nature and therefore changeable. This is also true for the architecture.

Cutting-edge technology imposes an extra burden on a project. With a large project, we have enough burdens, so there is no need for an extra one. So avoid these types of difficulties and question any corresponding suggestions. Keep in mind that “proven” and “state-of-the-art” are mutually exclusive qualities.

In general, we have to respect that the size of the team will have a major impact on the architecture. Testing, refactoring, and standards will not only help to keep the system flexible and changeable, but they also ensure that the system will be understandable to everybody on the team—because everybody uses the same good practices.