Architecture Antipatterns

Intro

• Arch. antipatterns are common problems and mistakes in the creation, implementation and management of the architecture.

Vendor Lock-in

• Symptoms:
  • Commercial component upgrades drive the application software maintenance cycle.
  • Commercial component does not subscribe to any open systems standard.
• Causes:
  • No technical approach to isolating application software from direct dependency on the product version.
• Fix:
  • Introduce an isolation layer
  • Hardware abstraction layer
  • Adoption of open systems standard and carefully choose components that meet this standard.

Jumble

• Vertical design elements are those dependent on specific software application and individual implementation.
• Horizontal elements are those that are common among applications.
• Symptoms:
  • Both the horizontal and vertical design elements get mixed up.
  • This makes design less stable and less reusable. Wide change impact.
• Causes:
  • No special effort involved, programmers just focused on getting job done.
• Fix:
  • Identify the horizontal elements and delegate them to a separate architectural layer.
  • Vertical elements as extensions for specialized functionality and performance.
  • Incorporate metadata into the architecture.

Architecture by implication

• Belief that 20 percent of an engineer’s time should be devoted to planning.
• The unfortunate consequence is that many organizations attempt to formalize too much of the planning - Planning is most effective when it is personally motivated and utilized.

• Symptoms:
  • Lack of architecture specifications for a system under development. Usually, the architects responsible for the project have experience with previous system construction, and therefore assume that documentation is unnecessary.
  • Hidden risks caused by scale, domain knowledge, technology, and complexity, all of which emerge as the project progresses.
  • Ignorance of new technologies.
  • Absence of technical backup and contingency plans.
• Causes:
  • Overconfidence of managers, architects, and/or developers.
  • No risk management.
  • Reliance on previous experience.
• Fix:
  • Adopt SEI architecture based process steps.

Design by committee

• Belief that everyone should have a say and process should be democratic.
• However, only a small no of people can define good abstractions.
• Too many features and variations to be able to build in a reasonable time frame.
• Lacks conceptual clarity.

• Symptoms
  • Documentation voluminous and difficult to understand.
  • Nobody free to make decisions outside of committee.
  • No prioritisation of required features and quality attributes.
• Causes
  • No project architect or architect doesnt have power.
  • Design and editing attempted in a group of >5 people.
  • Concerns not identified, separated and traded off.
• Fixes
  • Provide architect with real power.
  • Improve facilitation of meetings. Strict time awareness.

Reinvent the Wheel

• Symptoms:
  • Closed system architectures designed for one system at a time with no view to future reuse.
  • Replication of functions readily available from COTS.
  • Extended development cycles with many prototypes before the architecture becomes mature enough to support long term system development and maintenance.
• Causes:
  • Poor knowledge and communication.
• Fix:
  • Architecture mining.
  • Identify existing designs - good or bad and architectural styles.
  • Reuse good ideas.
  • Training, communication, reward reuse.

Grand old Duke of York

• Abstractionists versus Implementationists.
• Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts - implementationists. Abstractionists are comfortable discussing software design concepts without delving into implementation details.
• Implementationists tend to outnumber abstractionists approximately 4 to 1 and thus abstractionists are often outvoted during design decisions.

Symptoms:

• The primary consequence is software designs with excessive complexity, which make the system difficult to develop, modify, extend, document, and test.
• Software usability and system maintenance are impacted by a failure to use effective abstraction principles.

Solution:

• Place personnel in the correct role and empower them.
• Architects are abstractionists with significant experience in the majority of key technologies.