Architecture models can take various forms, including text, informal drawings, diagrams or other formalisms (modeling language). An architecture description will often employ several different "model kinds" to effectively address a variety of audiences, the "stakeholders" (such as end users, system owners, software developers, system engineers, program managers) and a variety of architectural "concerns" (such as functionality, safety, delivery, reliability, scalability). Often, the models of an architecture description are organized into "multiple views" of the architecture such that "each [view] addresses specific concerns of interest to different stakeholders of the system". An "architecture viewpoint" is a way of looking at a system (RM ODP). Each view in an architecture description should have a viewpoint documenting the concerns and stakeholders it is addressed to, and the model kinds, notations and modeling conventions it utilizes (ISO/IEC/IEEE 42010). The use of multiple views, while effective for communicating with diverse stakeholders and recording and analyzing diverse concerns, does raise potential problems: since views are typically not independent, the potential for overlap means there may be redundancy or inconsistency between views of a single system. Various mechanisms can be used to define and manage "correspondences" between views to share detail, to reduce redundancy and to enforce consistency. A common misunderstanding about architecture descriptions is that ADs only discuss "technical issues", but ADs need to address issues of relevance to many stakeholders. Some issues are technical; many issues are not: ADs are used to help architects, their clients and others manage cost, schedule and process. A related misunderstanding is that ADs only address the "structural" aspects of a system. However, this rarely satisfies the stakeholders, whose concerns often include structural, behavioral, aesthetic, and other "extra-functional" concerns. The earliest architecture descriptions used informal pictures and diagrams and associated text. Informal descriptions remain the most widely used representations in industry. Influences on architecture description came from the areas of Software Engineering (such as data abstraction and programming in the large) and from system design (such as SARA). Work on programming in the large, such as module interconnection languages (MILs) focused on the expression of the large-scale properties of software: modules (including programs, libraries, subroutines and subsystems) and module-relationships (dependencies and interconnections between modules). This work influenced both architectural thinking about programming languages (e.g., Ada), and design and architecture notations (such as Buhr diagrams and use case maps and codified in architectural features of UML: packages, subsystems, dependences) and much of the work on architecture description languages.