These architecture decisions are usually implemented by a much larger group of
developers and maintainers. In order manage these elements effectively, there are
significant challenges for architects in managing the people and relationships. Some
examples include: communicating the design to developers, achieving buy-in from managers
and developers, and managing the implementation and extension of the design.
The following AntiPatterns focus on some common problems and mistakes in the creation,
implementation, and management of architecture. Lack of commonality between systems in
terms of design and technology is the cause of frustrating inability to provide
interoperability and reuse between related systems. Improved enterprise architecture
planning can be used to align system developments.
|Architecture by Implication
||System that is developed without a documented architecture;
often due to overconfidence based on recent success.
||Define architecture in terms of multiple
viewpoints corresponding to system stakeholders.
||Automatic generation of interfaces for
distributed, large-scale systems from fine grain header files.
||Separation of the architecture-level framework design from
the subsystem-specific design is essential to manage complexity.
|Cover Your Assets
software processes often employ authors who list alternatives instead of making decisions.
||Establish clear purposes and guidelines for documentation
tasks; inspect the results for the value of documented decisions.
|Design by Committee
||Committee designs are overly
complex and lack a common architectural vision.
||Proper facilitation and software development
roles can lead to much more effective committee-based processes.
||People sometimes use obscure references to
esoteric papers, theories, and standards for intimidation or short-term gain.
||Individuals and the organization should encourage and
practice mutual education and mentoring.
||Interface designs are an un-factored mixture of
horizontal and vertical elements, leads to frequent interface changes, lack of
||Partition architectural designs with respect
to horizontal, vertical, and metadata elements.
|Reinvent the Wheel
||Legacy systems with overlapping functionality that
dont interoperate. Every system built in isolation.
||Use architecture mining and "best of
breed" generalization to define a common interface, then object wrapping to
||An ad hoc software structure makes it difficult to extend
and optimize code.
||Frequent code refactoring can improve software
structure, support software maintenance, and iterative development.
||Uncoordinated software architectures lead to lack of
adaptability, reuse, and interoperability.
||Use enterprise architecture planning to
coordinate system conventions, reuse, and interoperability.
||Ad hoc integration solutions and lack of abstraction lead
to brittle, un-maintainable architectures
||Proper use of abstraction, subsystem facades,
and metadata leads to adaptable systems.
|Swiss Army Knife
||Over-design of interfaces leads to objects with
numerous methods that try to anticipate every possible need -- leads to designs that are
difficult to comprehend, utilize, and debug, as well as implementation dependencies.
||Defining a clear purpose for the component and properly
abstracting the interface is essential to managing complexity.
|The Grand Old Duke of York
||Four out of Five developers cannot define good
abstractions; this leads to excess complexity.
||Project teams should have designated architects who are
abstractionists, i.e. possess the architecture instinct.
||Proprietary, product-dependent architectures do not manage
complexity and lead to a loss of control of the architecture and maintenance costs.
||Providing an isolation layer between
product-dependent interfaces and the majority of application software enables management
of complexity and architecture.
project teams make for ineffective organizations and overruns. Heroic programmers are
||Small projects (4 people in 4 months) are much more likely
to produce software success.
||A technology is assumed to have positive
qualities due to its open systems packaging or claimed standards compliance. Few standards
have test suites (< 6%) and few products are actually tested for conformance.
||Discover the real truth behind the claims. Question
authority. Assume nothing. Shift the burden of proof to the marketing organization. Talk
directly to the technical product experts and developers.