Understanding Architectural Anti Patterns

square-peg-round-hole-21

Anti Patterns provide a mechanism to capture and analyse real-world recurring problems. I study Anti Patterns across the Information Systems landscape, taking a series of views including Business, Cultural, Organisational and Technological.

Anti Pattern collection and analysis feeds continuous improvement, an important facet of any approach to Enterprise Architecture. This ensures the approach neutralises or (at worst) dilutes the consequences of Anti Patterns, reinforcing best practice design principles and provision of 21st Century Architectures.

Anti Patterns are usually well-known or easily recognised (but sadly, frequently ignored). Codification of tacit knowledge however ensures that practitioners (at all levels of experience) benefit from a) highlighting the Anti Pattern, b) instilling a culture of Anti Pattern research and c) placement of Anti Patterns ‘front of mind’.

It is important to realise that Anti Patterns (occasionally) become Patterns. Patterns equally need to be periodically reviewed to determine if they are still fit for purpose. This is natural, as understanding of problem spaces and availability of new technologies and approaches means that using dated Patterns becomes inevitable (if they are not being reviewed within reasonable timescales). Patterns have shelf lives, and architects must have the sophistication and discipline to ‘let go’ of favourite techniques, software, applications and hardware if circumstances indicate they are adding to long term cost.

Some consider Service Oriented Architecture to have been proven an Anti Pattern. Others consider that client/server is now a Pattern, having been an Anti Pattern for some time. Because there is often different opinions and finely balanced arguments, the evidence for categorisation of an Anti Pattern (and the context which surrounds that categorisation) must be empirical, not emotional.

In a series of future posts on Anti Patterns I will outline and explore those which must be avoided, and how to mitigate against their intrinsic risks.

There are a number of excellent online Anti Pattern resources, a few to illustrate further are provided below:

  1. ArchitectureAsRequirements
  2. ArchitectureByImplication
  3. AutogeneratedStovepipeAntiPattern
  4. ChangesInAugustTen
  5. CoverYourAssets
  6. DoerAndKnower
  7. JumbleAntipattern
  8. KillTwoBirdsWithOneStone
  9. NotTheAppropriateProtocol
  10. PoliticsOrientedArchitecture
  11. RequirementsAsArchitecture
  12. RollYourOwnDatabase
  13. StandingOnTheShouldersOfMidgets
  14. StovepipeAntiPattern
  15. StovepipeSystem
  16. SumoMarriage
  17. SwissArmyKnife