We investigated the use of XML, eXtensible Mark-up Language, as a way to represent software architecture models described with an Architectural Description Language (ADL). We believe XML provides a flexible and extensible framework highly suited to ADLs. Also, its adoption imparts many advantages that the ADL community can enlist to fulfil the responsibilities ADLs may soon be called to provide the industrial sector. Introduction The body of current ADL research contains a variety of dialects and implementations [LKA+95, AG97, Zel96, GMW97]. Most of the ADLs are focused within a particular research area and feature a corresponding set of capabilities. The advantages of a maturing ADL technology are increasingly sought after in the industrial sectors. Accordingly, we believe industrial adoption of ADLs will grow [Gar95]. Accompanying the increase in use will be an increase in the importance of software system architecture models within the enterprise. This increase in importance will result in expanded expectations for the versatility of software architecture models. This paper is organized as follows. First, we list and describe a set of capacities necessary for a softwareengineering environment. The capacities are examined with respect to the capabilities currently found in ADLs. Next, we describe the goals of our investigation. Following a brief overview of XML, we discuss how XML satisfies the list of capacities we identified as advantageous by a software-engineering environment. Desirable SEE Capacities The following list looks at the capacities modern enterprise development environments are likely to expect. While some of these capacities are intrinsically supported, or planned for, some of them will require additional ADL facilities. 1. Representation – This is the capacity to describe complex software architectures, an innate ability for any ADL. The ADL must feature a clear vocabulary for identifying and symbolizing the elements and the structure of the system [PW92]. The resulting model is required for the rest of the capabilities on the list. 2. Analysis – This is the capacity to evaluate architecture. Architecture evaluation includes, but is not limited to, dependency analysis, simulation, theorem proving, syntax checking, testability, reliability, etc [PW92]. 3. Traceability – Requirements will inevitably change in the fast-paced environment that software systems are targeted toward. Two-way traceability between a set of requirements and the software architecture elements satisfying those requirements will be needed for impact analysis of changes at either end. In addition to requirements, the software architecture requires a flexible capability for associating system elements with other system artifacts, such as schedules, documentation, presentations, rationale, etc [PW92].