Patterns in IT architecture

Patterns are "Good Practices" for architecting, designing and building IT systems.

The past decennia IT systems are built for solving many types of problems. Many of these solutions can be re-used. Patterns describe re-usable solutions. Many hundreds of patterns exist in the IT industry today, for all types of solutions, like software design, infrastructure, etc.

Patterns describe the best way to solve a problem. Examples of patterns are (in no particular order):

• Working in layers
• How to setup redundancy
• Using plugins
• DMZ
• Snapshots
• Using caching

The patterns describe the problem that is solved, the working area, the actual solution and the advantages and disadvantages of the solution.

Grady Booch describes on his website (sign-on is necessary) a collection of patterns that are described in various books available on the market. The patterns are only stated on the site, the actual description of the pattern can be found in the books (the names of the books and ISBN numbers are also stated on the site).

Besides patterns, there are also Anti-patterns. These describe solutions that will not work in practical situations, but are still used frequently in designs. 

Lately, I have read a few books on patterns and anti-patterns. While for most architects and designers the patterns don't contain much new insights (most of what is described can be found in the day-to-day practice), there are always some issues that can be learned from. Apart from that, patterns are what the Germans call a "aha-erlebnis": one gets the confirmation that the choices made in (previous) projects were the right ones.

If you have to design solutions in areas that you have little experience with, studying patterns is recommended, as well as having knowledge about anti-patterns. This will prevent you for making generally made errors and mistakes, and it helps architecting proven IT solutions.