Architecture Lifecycle Issues - Revision history

Suhridk at 11:47, 23 April 2012

2012-04-23T11:47:42Z

2012-04-13T21:55:19Z

Role of the architect

2012-04-13T21:47:42Z

Team organisation

2012-04-13T21:37:01Z

Architecturally significant requirements

2012-04-13T21:28:42Z

Product Factors

2012-04-13T19:23:00Z

Product Factors

2012-04-13T19:22:36Z

Product Factors

2012-04-13T19:18:30Z

Organisational Factors

2012-04-13T19:18:02Z

Organisational Factors

2012-04-13T19:15:59Z

Product Factors

← Older revision		Revision as of 11:47, 23 April 2012
Line 135:		Line 135:
	* Implements or guides implementation.		* Implements or guides implementation.
	* Advocates.		* Advocates.
		+
		+	[[Category:SYAR]]

← Older revision		Revision as of 21:55, 13 April 2012
Line 123:		Line 123:
	* Therefore needs people mgmt skills as well as technical competency.		* Therefore needs people mgmt skills as well as technical competency.
	* Makes the ultimate decisions - Attempts to reconcile conflict between stakeholders.		* Makes the ultimate decisions - Attempts to reconcile conflict between stakeholders.
		+	* Must be a keeper of the flame
		+	** Have a clear vision (architectural description).
		+	** Ensure that the vision is communicated.
		+	** Ensuring the vision is maintained.
		+	* Architect role must be kept different from mgmt role.
		+
		+	* Architect creates the vision.
		+	* Is the key technical consultant.
		+	* Makes decisions.
		+	* Coordinates.
		+	* Implements or guides implementation.
		+	* Advocates.

@@ Line 113: / Line 113: @@
 ** Each major component represents a "domain" and therefore relies upon a pool of expertise in a certain area.
 ** Dynamic behaviour may cut across teams.
-* High/low bandwidth communication between teams.
+* High bandwidth communication necessary within team and low bandwidth communication across teams.
 * Organisation can also have a reverse impact on the definition of the architecture.
 ** Members of a certain group (e.g. DB) may view problems as being group centred.

← Older revision		Revision as of 21:37, 13 April 2012
Line 107:		Line 107:
	** Address properties of different categories of components (e.g. naming, referencing, communication)		** Address properties of different categories of components (e.g. naming, referencing, communication)
	** Address process of manipulating components (e.g. configuring or upgrading).		** Address process of manipulating components (e.g. configuring or upgrading).
		+
		+	= Team organisation =
		+
		+	* Team allocation typically determined by static components of the arch.
		+	** Each major component represents a "domain" and therefore relies upon a pool of expertise in a certain area.
		+	** Dynamic behaviour may cut across teams.
		+	* High/low bandwidth communication between teams.
		+	* Organisation can also have a reverse impact on the definition of the architecture.
		+	** Members of a certain group (e.g. DB) may view problems as being group centred.

← Older revision		Revision as of 21:28, 13 April 2012
Line 99:		Line 99:
	* All issues collected and a summary of strategies formed.		* All issues collected and a summary of strategies formed.
	* Output of global analysis process is a set of strategies that form context for the architecture definition		* Output of global analysis process is a set of strategies that form context for the architecture definition
		+
		+	= Architecturally significant requirements =
		+
		+	* Requirements may predefine architecture. e.g. safety standards.
		+	* How to recognise such architecturally significant requirements ?
		+	** Cannot be satisfied by one component without dependence on rest of system (e.g. availability)
		+	** Address properties of different categories of components (e.g. naming, referencing, communication)
		+	** Address process of manipulating components (e.g. configuring or upgrading).

@@ Line 95: / Line 95: @@
 * Related Strategy: See: encapsulate general purpose hardware.
 * All issues collected and a summary of strategies formed.
 * Output of global analysis process is a set of strategies that form context for the architecture definition

@@ Line 87: / Line 87: @@
 # Product cost
 * Issue: Easy Addition and removal of features
 * Factors: O4.1 (Org Factor) : TIme to market short
@@ Line 93: / Line 94: @@
 * Strategy: Separate components and modules across dimensions of concern
 * Related Strategy: See: encapsulate general purpose hardware.

@@ Line 55: / Line 55: @@
 == Organisational Factors ==
-# Management
+* Management
-# Staff skills
+* Staff skills
 ** e.g. Analyze factors
 ** experience in multithreading.
@@ Line 65: / Line 65: @@
 ** Only 1 developer
 ** Strategy: avoid use of multiple threads.
-# Process and development environment
+* Process and development environment
-# Development schedule
+* Development schedule
-# Development budget
+* Development budget
 == Technological Factors ==