Architecture Antipatterns - Revision history

Suhridk at 11:48, 23 April 2012

2012-04-23T11:48:20Z

Suhridk: /* Reinvent the Wheel */

2012-04-14T11:40:05Z

Reinvent the Wheel

Suhridk: /* Reinvent the Wheel */

2012-04-14T11:31:32Z

Reinvent the Wheel

Suhridk: /* Architecture by implication */

2012-04-14T11:14:32Z

Architecture by implication

Suhridk: /* Jumble */

2012-04-14T10:57:44Z

Jumble

Suhridk: /* Jumble */

2012-04-14T10:52:42Z

Jumble

Suhridk: Created page with "= Intro = * Arch. antipatterns are common problems and mistakes in the creation, implementation and management of the architecture. = Vendor Lock-in = * Symptoms: ** Commerci..."

2012-04-14T10:28:05Z

Created page with "= Intro = * Arch. antipatterns are common problems and mistakes in the creation, implementation and management of the architecture. = Vendor Lock-in = * Symptoms: ** Commerci..."

New page

= 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 =

* Symptoms:
* Causes:
* Fix:

@@ Line 46: / Line 46: @@
 ** Adopt SEI architecture based process steps.
-= Design by committee ==
+= Design by committee =
 * Belief that everyone should have a say and process should be democratic.
@@ Line 90: / Line 90: @@
 * Place personnel in the correct role and empower them.
 * Architects are abstractionists with significant experience in the majority of key technologies.

← Older revision		Revision as of 11:40, 14 April 2012
Line 78:		Line 78:
	** Reuse good ideas.		** Reuse good ideas.
	** Training, communication, reward reuse.		** 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.

← Older revision		Revision as of 11:31, 14 April 2012
Line 66:		Line 66:

	= Reinvent the Wheel =		= 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.

@@ Line 30: / Line 30: @@
 = Architecture by implication =
 * Symptoms:
@@ Line 42: / Line 45: @@
 * Fix:
 ** Adopt SEI architecture based process steps.

← Older revision		Revision as of 10:57, 14 April 2012
Line 28:		Line 28:
	** Vertical elements as extensions for specialized functionality and performance.		** Vertical elements as extensions for specialized functionality and performance.
	** Incorporate metadata into the architecture.		** Incorporate metadata into the architecture.
		+
		+	= Architecture by implication =
		+
		+	* 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.

@@ Line 17: / Line 17: @@
 = Jumble =
 * Symptoms:
 * Causes:
 * Fix: