ea of "OSI networks" failed completely when confronted with actual needs in public networks and more sound architectures (such as the Internet), the industry continues to align the description of today's network systems to the OSI RM, particularly in standards. Since a competent network architect does design architectures for optimal maintaineability and openness to new technologies and Preface requirements in mind, the strange situation exists that many standards continue to describe sound architectures in terms of a generic architecture (i.e., the OSI RM) that is not reflected by any network system in use today. Those standards are next to unintelligible. I was as enthusiastic as anybody else over the OSI RM at the time. However, when entering the field of network systems design later, I gained a deeper knowl- edge of how networks systems were actually built and what the real architectural needs were. This knowledge and experience has been transformed into AMLn. In this endeavor, I had to deal with two problems: 1. Finding the minimum set of concepts that could be the corner stones for the lan- guage. For a system domain that has been developing for over 100 years, those concepts should have been available for a long time. Except for concepts defined by OSI (which to a large extent are insufficient for modelling purposes), this is not so, however. The ITU-T (a leading standardization body for telecom- munication standards) tried for many years by publishing a steadily expanding list of thousands of terms. It gave it up some years ago when it found that, in reality, every standard defined its own concept definitions. Thus, this issue became a major research topic in developing AMLn. 2. Identifying the architectural principles that result in a stable system structure over a long time, and a model that is easy to understand, manage and relate to common-value models. The specification of a system type must cover two aspects: its behavior and structure. Behavior specification is a topic that can be covered quite acc