Difference between revisions of "Architecture"

From Computer History Wiki
Jump to: navigation, search
(A decent start)
 
m (Punc)
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.

Revision as of 18:32, 19 August 2017

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 CPU would include a high-level view of: the ALU; other computational elements (e.g. a floating point unit); the registers (both those visible to the programmer, and internal registers); the data paths 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).

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.