"Without groundwork, it's just guesswork."

• A design keeps teams aligned. Without some form of design, developers, testers, network admins, DBAs and sysadmins can easily misinterpret requirements. 

• A design helps us to catch architectural or integration risks early rather than discovering them halfway through the build.

• A design helps ensure that wider strategy is taken into account.

• A design helps new starters onboard without needing to reverse-engineer the solution.

• A design helps you differentiate a decision from a bug.

• A picture is worth a thousand words.

• A design should be a living artifact, updated for every later Change to the solution.

• A design should be collaborative. I.e. It needs input and discussion from technical teams (e.g. Design Approval meetings)

• A template should be used to reduce unnecessary involvement of technical teams and ensure consistency.

• A design should capture why a decision was made (Architecture Decision Record)

• Standards should be defined and enforced.

Bibliography

Glossary