Architecture - Revision history

Jnc: /* See also */ Instruction set architecture

2023-10-22T22:30:14Z

Jnc: /* Architectural techniques */ wording tweak

2019-07-14T19:19:35Z

Architectural techniques: wording tweak

← Older revision		Revision as of 19:19, 14 July 2019
Line 19:		Line 19:
	Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.		Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of truly great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

	[[Category: Basics]]		[[Category: Basics]]

Jnc: +cat

2018-12-14T17:31:47Z

+cat

← Older revision		Revision as of 17:31, 14 December 2018
Line 20:		Line 20:

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

			[[Category: Basics]]

Jnc: /* Architectural techniques */ Mention levels

2018-10-01T13:13:58Z

Architectural techniques: Mention levels

← Older revision		Revision as of 13:13, 1 October 2018
Line 11:		Line 11:
	Another common technique is '''layering''', which is an attempt to introduce an ordering among the sub-systems, to reduce/remove 'dependency loops' among the sub-systems. (Dependency loops are undesirable, as it makes the system more complex, and more bug-prone.)		Another common technique is '''layering''', which is an attempt to introduce an ordering among the sub-systems, to reduce/remove 'dependency loops' among the sub-systems. (Dependency loops are undesirable, as it makes the system more complex, and more bug-prone.)

	If this can be achieved, it allows the system to be built more easily (as only the lowest-~~layer~~ sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).		The sub-systems are organized into stack of '''levels''', with each one building on the capabilities of the layer(s) below, and adding new capabilities.

			If this can be achieved, it allows the system to be built more easily (as only the lowest-level sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).

	The actual structure in most systems is usually a [[hierarchy]], not a simple layered stack, as often more than one higher-level component will use the services of a given lower-level component.		The actual structure in most systems is usually a [[hierarchy]], not a simple layered stack, as often more than one higher-level component will use the services of a given lower-level component.

Jnc: link

2018-01-19T15:38:57Z

link

← Older revision		Revision as of 15:38, 19 January 2018
Line 13:		Line 13:
	If this can be achieved, it allows the system to be built more easily (as only the lowest-layer sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).		If this can be achieved, it allows the system to be built more easily (as only the lowest-layer sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).

	The actual structure in most systems is usually a ~~'''~~hierarchy~~'''~~, not a simple layered stack, as often more than one higher-level component will use the services of a given lower-level component.		The actual structure in most systems is usually a [[hierarchy]], not a simple layered stack, as often more than one higher-level component will use the services of a given lower-level component.

	Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.		Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

Jnc: /* Architectural techniques */ Add hierarchy

2018-01-18T13:59:20Z

Architectural techniques: Add hierarchy

← Older revision		Revision as of 13:59, 18 January 2018
Line 9:		Line 9:
	In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces (modules; or sub-systems, themselves composed of modules, in more complex systems): deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture (and of the job of the system architect, the person who lays out the overall design).		In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces (modules; or sub-systems, themselves composed of modules, in more complex systems): deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture (and of the job of the system architect, the person who lays out the overall design).

	Another common technique is '''layering''', which is an attempt to introduce an ordering among the sub-systems, to reduce/remove 'dependency loops' among the sub-systems. If this can be achieved, it allows the system to be built more easily (as only the lowest-layer sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).		Another common technique is '''layering''', which is an attempt to introduce an ordering among the sub-systems, to reduce/remove 'dependency loops' among the sub-systems. (Dependency loops are undesirable, as it makes the system more complex, and more bug-prone.)

			If this can be achieved, it allows the system to be built more easily (as only the lowest-layer sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).

			The actual structure in most systems is usually a '''hierarchy''', not a simple layered stack, as often more than one higher-level component will use the services of a given lower-level component.

	Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.		Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

Jnc: Add arch as used in CPU descs

2018-01-16T21:01:47Z

Add arch as used in CPU descs

← Older revision		Revision as of 21:01, 16 January 2018
Line 3:		Line 3:
	So, for example, the architecture of a [[Central Processing Unit\|CPU]] would include a high-level view of: the [[Arithmetic logic unit\|ALU]]; other computational elements (e.g. a [[floating point]] unit); the [[register]]s (both those visible to the [[programmer]], and internal registers); the [[data path]]s which connect them all together; and the control system (usually [[microcode]]) which runs the whole ensemble.		So, for example, the architecture of a [[Central Processing Unit\|CPU]] would include a high-level view of: the [[Arithmetic logic unit\|ALU]]; other computational elements (e.g. a [[floating point]] unit); the [[register]]s (both those visible to the [[programmer]], and internal registers); the [[data path]]s which connect them all together; and the control system (usually [[microcode]]) which runs the whole ensemble.

	In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces: deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture (and of the job of the system architect, the person who lays out the overall design).		The term is also used in a more restricted sense, to mean 'the user view of the system, across multiple models/versions'; in other words, it tries to separate out the implementation details from the time-invariant fundamental description.

			==Architectural techniques==

			In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces (modules; or sub-systems, themselves composed of modules, in more complex systems): deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture (and of the job of the system architect, the person who lays out the overall design).

			Another common technique is '''layering''', which is an attempt to introduce an ordering among the sub-systems, to reduce/remove 'dependency loops' among the sub-systems. If this can be achieved, it allows the system to be built more easily (as only the lowest-layer sub-systems need to be working at first), and more easily understood (since most of the higher-layered sub-systems can be ignored, when trying to understand the functioning of one particular sub-system).

	Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.		Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

Jnc: Punc

2017-08-19T17:32:04Z

Punc

← Older revision		Revision as of 17:32, 19 August 2017
Line 1:		Line 1:
	'''Architecture''' in the field of information systems refers to the high-level organization and structure of a system. The term is applied to both [[hardware]] and [[software]].		'''Architecture''' in the field of information systems refers to the high-level organization and structure of a system. The term is applied to both [[hardware]] and [[software]].

	So, for example, the architecture of a [[Central Processing Unit\|CPU]] would include a high-level view of the [[Arithmetic logic unit\|ALU]], other computational elements (e.g. a [[floating point]] unit), the [[register]]s (both those visible to the [[programmer]], and internal registers), the [[data path]]s which connect them all together, and the control system (usually [[microcode]]) which runs the whole ensemble.		So, for example, the architecture of a [[Central Processing Unit\|CPU]] would include a high-level view of: the [[Arithmetic logic unit\|ALU]]; other computational elements (e.g. a [[floating point]] unit); the [[register]]s (both those visible to the [[programmer]], and internal registers); the [[data path]]s which connect them all together; and the control system (usually [[microcode]]) which runs the whole ensemble.

	In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces: deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture.		In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces: deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture (and of the job of the system architect, the person who lays out the overall design).

	~~Archtecture~~ is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.		Architecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

	Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

Jnc: A decent start

2017-08-19T13:55:23Z

A decent start

New page

'''Architecture''' in the field of information systems refers to the high-level organization and structure of a system. The term is applied to both [[hardware]] and [[software]].

So, for example, the architecture of a [[Central Processing Unit|CPU]] would include a high-level view of the [[Arithmetic logic unit|ALU]], other computational elements (e.g. a [[floating point]] unit), the [[register]]s (both those visible to the [[programmer]], and internal registers), the [[data path]]s which connect them all together, and the control system (usually [[microcode]]) which runs the whole ensemble.

In particular, modern systems make heavy use of '''modularization''' - breaking the overall system up into well-defined pieces: deciding where to put those boundaries, and defining the interactions across them, is a key part of a system's architecture.

Archtecture is usually guided by defined goals/requirements that the system has to meet, but these are of only so much use. The problem is that any large system - and particularly software systems - have long lifetimes, and the environment, and uses, of the system usually change considerably over that time period - in ways that are usually impossible to foresee.

Hence the aphorism that "''The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

← Older revision		Revision as of 22:30, 22 October 2023
Line 20:		Line 20:

	Hence the aphorism that "''The hallmark of truly great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.		Hence the aphorism that "''The hallmark of truly great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle.''" Longer lifetimes for an architecture are usually gained, not by focusing primarily on a system's goals and requirements, but by trying to understand, at a deep level, what the system does, and then organizing it to do that in as simple, general and flexible a way as possible.

			==See also==

			* [[Instruction set architecture]]

	[[Category: Basics]]		[[Category: Basics]]