Re: Internet "architecture"
[email protected] (Noel Chiappa)
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
> From: John Day <[email protected]> Well, I see that we are indeed, as suspected, all over the place on the meaning of the term. (I'll give mine below, along with some thoughts provoked by this dicsussion.) I'm not sure we can reach agreement on a meaning, but I so think it was/is useful to bring out just how 'undefined' this term is. > I basically use the dictionary definition of "a style of construction". > The important distinction being between an architecture and buildings > built to that architecture. I'm going to diagree with this one a bit, because I think one can speak of 'the architecture of "Fallingwater"' as well as 'the architecture of FLLW' - although I would use the term 'architectural style of FLLW', reserving the singular term for i) specific instances, and ii) the field itself. So Wright's 'architectural style' would include such features as greater integration of the building and the setting (both from an external viewpoint, as well as from an internal one); greater integration of the interior spaces (large openings between major spaces); etc. But that's a style, and some of his buildings have aspects which are only in a very few of his buildings (e.g. cantilevering), but are part of their 'architecture'. So I would continue to make what I think is a useful distinction, between an overall style, and the 'architecture' of a particular instance. To me, in the information systems area, the 'architecture' of a particular system has three main aspects: i) The overall form of the system, i.e. the service model it presents to its users. This may be viewed as a 'requirements list', but in good architectures, I think this goes beyond mere requirements (which are often transitory), into something deeper: I have this 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." which is speaking of things that are, in some sense, explicitly outside any list of requirements that were known at the time it was drawn up. ii) The classes of objects in the system, their properties, etc; and the classes of names (and their properties, how they apply to the objects, and how they inter-relate to each other) for those objects. iii) How a system is broken up into pieces; where the functionality boundaries are, and how, when and what information is passed over the interfaces among the pieces. I was pondering the difference between 'architecture' and 'engineering', and I'm not sure there'a a hard and fast line between the two. I think it's more of a spectrum, and while many things are clearly at one end, or the other, sometimes you get into some gray. For instance, in TCP/IP, the notion that the hosts are responsible for retransmissions is clearly (to me, at least :-) 'architectural', whereas the specific algorithm used is 'engineering', and those both seem pretty clearly to be at one end or the other. But I suspect there are things which aren't so clear (although my brain is working a bit slowly today, and can't cough one up on demand). Noel