[e2e] Internet "architecture"

Noel Chiappa jnc at mercury.lcs.mit.edu
Mon Apr 15 11:40:56 PDT 2013

    > From: John Day <jeanjour at comcast.net>

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

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

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).


More information about the end2end-interest mailing list