his paper focuses on the conventions, terminology, and notation that are needed to support the harvesting and reuse of reference architectures. (Within the context of papers in this issue, it would be helpful to readers if this paper is read before the papers on reference architectures and engagement experiences that are included in this issue.)

The business background

In projects that are developing computing systems for business solutions, it is generally recognized that the use of predefined, reusable assets in the form of architectural, analysis, and design patterns can enable large reductions in project cost, time scale, and risk. However, effective large-scale deployment of architectural patterns is dependent on key concepts, terms, and notations being used consistently, and being understood and accepted across a broad community of information technology (IT) architects and systems integrators. Without a common language, deployment is likely to be patchy, inefficient, and error-prone and to require huge support resources. Lack of consistency seriously inhibits scalability.

In 1996 and 1997, IBM's Global Industries business unit, which has the mission of developing and supporting packaged industry solutions, recognized the need to adopt an improved, asset-based approach to its product development. At the same time, IBM's Global Services business unit had independently concluded that IBM and its customers, and IBM's services professionals worldwide, would benefit greatly from an asset-based approach to solutions development in which architectural and design assets would be gathered from completed projects and redeployed on many other, similar projects. Both business units agreed that the increased emphasis on assets and work products for development and for services engagements necessitated a comprehensive metamodel that would underpin the description of those assets and work products more precisely and effectively.

Independently of the Architecture Description Standard (ADS) project, the Enterprise Solutions Structure (ESS) project had already developed a specific metamodel used to document the (mostly technical) frameworks that it was developing. This metamodel, in a simplified form, was implemented in a Lotus Notes**-based tool, which was used to distribute these assets to users of ESS.

The Architecture Description Standard project was created to develop a more wide-ranging version of this metamodel and the semantic descriptions to support it. The output from this project, ADS, provides a common language through the definition of a formal metamodel, a glossary (see the Appendix), and a detailed semantic specification.

The primary audience for the standard consists of IT architects working on solution development and deployment projects. Such work might be either in the context of a client engagement or a development project within an IBM solution development organization. In the former context, assets in the form of work products conforming to the standard may be selected, customized, and used to build IT systems for the customer. In the latter context, developers will create work products conforming to the standard which can then be widely deployed.

Such work products will typically contain descriptions of groups of entities from the metamodel, documented in the form prescribed by ADS. Thus, both providers and consumers of work products will benefit from a common, unambiguous definition. Within a single project, ADS will enable more precise, unambiguous, and semantically rich communication among project personnel.

The standard is intended to be used for solution development and deployment across the IBM Corporation worldwide. It is the foundation for the Systems Integration/Application Development (SI/AD) method and its associated work products. It will be initially deployed to all SI/AD architects via SI/AD education classes. It will also be deployed to a wider range of architects via classes that are currently under development. It is also the foundation for the structure and terminology of asset libraries (for example, ESS).

This paper summarizes the main concepts in ADS. A full description is available in IBM's formal ADS documentation.

Influences on ADS technical strategy

Several themes contributed to the technical strategy adopted for the Architecture Description Standard.

Requirements for an ADL. As discussed previously, there is a business requirement to be able to express architectural work products and assets in a consistent, unambiguous form. ADS is a language for describing and communicating architectural concepts. The phrase architecture description language (ADL) is commonly used for this type of standard, and there are an increasing number of ADLs available that broadly address the same concerns as ADS--they are all formal languages that can be used to describe the architecture of an IT system.¹ They differ from modeling or programming languages in that their focus is mainly on architectural concepts--abstractions of components, connections, protocols, and the behavior of the complete system.

Because of some of IBM's unique requirements (specifically, those relating to developing asset-based services with a multiskilled work force), no existing ADL was identified that met all requirements and was deployable to IBM's architecture community.

Integration of application development with infrastructure design. One of the conclusions from earlier work was that the success of major solution development projects in IBM often depended critically on the integration of application and infrastructure.² Therefore, one of the principles that guided the development of ADS was the recognition that infrastructure design is a specialized skill and that its exponents habitually deal with concepts, entities, and methods that are different from those in "traditional" application development. This recognition led the ADS project to divide the architectural model into two parts: a functional aspect and an operational aspect.

The operational model, described below, is focused specifically on aspects of architecture necessary for the infrastructure designer to perform his or her job. Although ADS defines these two models, in actual fact they share many entities and can be considered as dealing with the same material, but from different perspectives. Hence, we use the terms "functional aspect" and "operational aspect," and it is through the formal definition of the way entities are shared and used across these aspects that ADS contributes to the integration.

Precision and consistency. Although it might seem desirable to strive to achieve the highest levels of precision and consistency for a technical standard such as this one, we do not believe that it is necessarily the case. To assist the rapid development of asset-based services in IBM, the emphasis in the ADS project was to provide a practical standard that can be readily adopted by a wide range of people in development projects.

One objective, therefore, was to define an architecture description standard sufficient to enable consistent definition and use of architectural templates by practitioners and to underpin the architectural aspects of IBM methods (for example, the SI/AD and IPD, or Integrated Product Development, methods). Another, related, objective was to provide a consistent base of concepts, terms, and notations for the education and training of architects in templates and methods.

Such a standard does not have to be comprehensive to be effective. It only needs to cover the core areas of architecture, which must be defined and understood in a standard way to enable effective deployment of architecture templates. This set, therefore, consists of those concepts that are regularly used in project work products or assets and that need to be standardized for practitioners to do their work.

Although underlying precision and consistency are important (and will be achieved through the metamodel), practicality, trainability, and usability as they apply to practitioners are paramount. The critical factor for success is whether the resulting set of concepts, terms, and notations is small, simple, and accessible enough to be taught to large numbers of practitioners in a broad spectrum of courses.

Exploitation of IBM's existing best practices. In our work developing the Architecture Description Standard, we have attempted to reconcile and synthesize various IBM best practices and combine them with wider industry initiatives. The main IBM sources we have integrated are:

• WSDDM-OT (worldwide solution design and delivery method-object technology)
• WSDDM-ISD (infrastructure design), which itself incorporates the earlier IBM End-to-End Infrastructure Design Method
• ESS, a major asset base of IBM reference architectures and associated architectural assets

Use of industry standards. During the 1990s, the largest and most influential industry initiative on the representation of software systems has been the work undertaken by the Object Management Group³ (OMG) to produce a Unified Modeling Language (UML). ADS decided to adopt UML (v1.1) as the basis for ADS concepts, terms, and notations because UML is being widely adopted as a de jure and de facto software modeling standard.⁴ It represents a major investment of intellectual effort and conceptual convergence by the world's leading software methodologists. Consequently, most of the major modeling tool vendors will provide CASE (computer-assisted software engineering) tool support for UML.

In addition, many IBM IT architects are already familiar with UML concepts and notations (indeed IBM was closely involved in the development of UML), and most of the key concepts in WSDDM-OT, WSDDM-ISD, and ESS, with which they are familiar, can be mapped to UML concepts.

During the development of ADS, we have identified some limitations in UML for architecture description and areas in which IBM best practice would be lost or diluted if we conformed slavishly to UML. In these areas we have extended UML so that valuable concepts or notations are not lost. This extension has proved to be most necessary in the area of infrastructure design, where the UML coverage of important concepts such as connections between nodes, and service-level requirements, is limited.

The technical strategy has therefore been to adopt a pragmatic approach: integrating concepts from IBM's WSDDM-OT, WSDDM-ISD, and ESS; expressing these concepts in UML terms and notation wherever possible; extending UML where required while ensuring that the concepts are usable by practitioners. The authors believe that this strategy has achieved a coherent and usable architecture description standard that carries forward the strengths of the methods and standards from which it is derived.

The architecture definition standard

This section begins with a definition of architecture and then describes its various characteristics.

What is an architecture? The IT industry has proposed numerous definitions for the concept of architecture, widely varying in scope and emphasis. The main focus of ADS is on describing the structure of "components," the relationships between them, and the way in which they interact dynamically. Hence, ADS has adopted the following definition:

The architecture of an IT system is the structure or structures of the system, which comprise software and hardware components, the externally visible properties of those components, and the relationships among them. (Adapted from Bass et al.¹)

Note that this definition incorporates hardware components in the scope of a systems architecture. In practice, most project activity is concerned with software architecture, design, and implementation. Therefore, it might be argued that a purely software scope is sufficient--ADS would then describe a software architecture. Occasionally, however, it is necessary to include hardware components in an architectural definition (usually where specialized or unfamiliar hardware devices are needed). Also, through its operational aspect, ADS brings a closer focus on describing computer platforms and their physical connections and on delivering service levels. Therefore, it is appropriate that ADS should include hardware.

Functional and operational aspects. In the context of a development project, a complete IT system architecture serves multiple purposes, among them:

• Breaking down the complexity of the IT system so that developers can analyze and design components that are relatively isolated from one another
• Analyzing the functionality so that required technical components (or infrastructure) can be identified
• Assisting in the analysis of service-level requirements so that the means of delivering them can be designed
• Providing a basis for the specification of the physical computer systems on which the IT system will execute and the mapping of components onto these computer systems

In large projects, a division of responsibilities becomes necessary for the simple reason that a single person cannot possibly be skilled in all the technologies, methods, tools, and techniques needed for all these purposes. Also, the activities of any large project need to be partitioned so that small groups (subprojects or work groups) can manage their own creative work, with the integration of the whole project being performed at a higher level. In practice, large projects include work groups concerned primarily with application design and development. Their focus is on the first of the above purposes. Other groups are concerned with infrastructure design and development, and they focus on the last three purposes. Each group has specialized techniques to address its particular concerns.

The Architecture Description Standard reflects this separation of concerns by identifying two main aspects of architecture: the functional and the operational aspect.

The focus of the functional aspect is on describing the function of the IT system and is primarily concerned with the structure and modularity of the software components (both application and technical), the interactions between them, their interfaces, and their dynamic behavior (expressed as collaborations between components).

The focus of the operational aspect is on describing the operation of the IT system and is primarily concerned with representing network organization (hardware platforms, connections, locations, topology, etc.), where software and data components are "placed" on this network, how service-level requirements (performance, availability, security, etc.) can be satisfied, and the management and operation of the whole system (capacity planning, software distribution, backup, and recovery).

The aspects are summarized in Table 1.

Functional aspect concepts. The concepts and modeling notations used to describe the functional aspect of an IT system are discussed in the following subsections.

Components and relationship diagrams. The functional aspect is represented in terms of components and the relationships between components.

A component is a modular unit of software⁵ functionality, accessed through one or more interfaces. The functionality and state of the component are only externally accessible by using these interfaces (that is, they are encapsulated). Component is the primary concept used for modular design, with the well-established design principles of information hiding and of seeking high cohesion and low coupling.

The primary notation used for components in ADS follows the UML class diagram notation. (We represent a component by the UML class symbol--a rectangle, optionally with a section for operations.) Relationships between components are shown in a component relationship diagram in which we show a usage relationship between two components if one component uses the interface(s) of another component. This usage can be thought of as being based on a contract between the components; that is, there is an agreement between the two components about the services they can request from each other. We use the UML association notation to show this. Showing such a usage relationship implies that the components can communicate with one another. The design of the infrastructure must ensure that the necessary physical connectivity can occur.

Figure 1 shows an example of a component relationship diagram for a workflow system.

Figure 1

The component relationship diagram notation has a line with an arrowhead pointing from the "using" component to the "used" component. For example, in Figure 1 the workflow client application uses operations provided by the workflow engine component. Where each component uses (and therefore depends on) the other, the line can have arrows at each end. For example, the workflow engine uses the external workflow engine, and vice versa. (This interpretation slightly extends the standard UML arrowhead notation meaning direction of association navigation.)

Although the line could be read as a data flow or a message, this interpretation is not correct. A usage relationship between two components typically relies on one or more interfaces with many operations (and corresponding message types). Some of these messages may be passed in the opposite direction from the arrow (for example, callback), and data commonly flow in both directions.

The component relationship diagram can optionally show the multiplicities of relationships. For example, Figure 1 shows that each workflow client application interacts with a single workflow engine and that the workflow engine interacts with multiple clients (as shown by the 1 and * at the ends of the connecting arrow).

A component relationship diagram is essentially a static specification of the usage between components. It shows how components can use one another, rather than actual message flow or dynamic behavior (for these latter items, see the component interaction diagram shown later in Figure 3).

Composition of components. Complex components are frequently composed from simpler components. This arrangement can be visualized by showing one component inside another.

Figure 2 shows the component relationship diagram with the audit log encapsulated within the application agent. When one component is composed of another, the services of the contained component are not accessible from outside the composite component; that is, they are encapsulated. For example, in Figure 2, the application agent uses the audit log, but no other users or components can use the audit log. Encapsulation does not imply that the audit log is physically contained in the application agent, but that the application agent has a private relationship with it.

Figure 2

It would not be appropriate to show the Customer Information Control System (CICS*) application encapsulated in Figure 2, as its external interfaces may be used by multiple components.

(This is a standard UML class diagram notation for composition. If available tools do not support it, an alternative UML notation is the diamond symbol for aggregation.)

Describing component behaviors. We describe the required externally observable behavior of an IT system in terms of the widely used concepts of use cases and use case scenarios. For example, the statement "Withdraw Funds from ATM" is a use case, and "Successfully withdraw $100 from account 12345 at midnight" is a scenario of this use case (that is, one particular path through the use case).

In creating the architecture of a system, we need to allocate the responsibilities of the system as a whole to the components of the system. For each scenario, we divide up the system responsibilities among a number of components (e.g., one component might run the user interface, a second might manage workflow, a third might store data). To model how the components work together to process a scenario at run time, we have the concept of a collaboration.

A collaboration (among components) is a sequence of operations, identifying which components perform operations and which request operations, reflecting the time sequence. Collaborations are the primary way of modeling the dynamic behavior of components.

Collaborations are visually represented using component interaction diagrams (using standard UML notation). An interaction diagram shows the messages exchanged between components during a single collaboration; that is, it is an execution trace.

Figure 3 shows a component interaction diagram for the workflow system above. Each vertical line (column) represents a component that participates in the collaboration (e.g., workflow client, workflow engine). Each horizontal line represents a request, in the direction of the arrow, from one component to another. The name of the request (= invoked operation) is shown on the line (e.g., get_work_list). The names, types, and values of parameters can also be shown if required (but are omitted in Figure 3).

Figure 3

We use the standard UML sequence diagram notation to model component collaboration. UML also defines a semantically equivalent notation, the collaboration diagram, which can be used if required. (The collaboration diagram format shows the component topology more clearly but tends to make the time sequence of messages harder to see.)

Structuring of components. One of the most important architectural design processes consists of structuring the system as a whole into a suitable structure of components and relationships between components. This structuring addresses a number of concerns, including:

• Allocation of responsibilities to components, in such a way that each component has a cohesive set of responsibilities and redundancy is avoided
• Partitioning of components to take into account distribution requirements (For example, an initial component may have to be split into a client and a server component.)
• Optimizing the component structure to satisfy service-level requirements such as performance
• Incorporation of reusable components in the design, accommodation of legacy systems, or other constraints

The notations illustrated in Figures 1 to 3 are used to represent possible component structures and collaborations during this structuring process. It is common for the structuring to evolve through several elaboration points.

Subsystems. When describing an IT system, we often need to talk about some part of the system. Subsystems may be defined and used for several purposes, for example, to organize a large IT system into smaller "chunks" and to make it more comprehensible or manageable (e.g., accounts subsystem, inventory subsystem, system management subsystem) so that it can be more easily described to other people. It is also necessary to divide the system so that work can be allocated to development teams (e.g., one subsystem per team).

A subsystem is a subset of the components in an IT system. It can be defined by drawing an irregular line around some of the components (see Figure 4). For example, in Figure 4, the accounts subsystem consists of components C4, C5, C6, and C7.

Figure 4

Subsystems may overlap, e.g., component C6 is part of the accounts subsystem and also part of the image subsystem.

A subsystem may span platforms, i.e., the components in a single subsystem can be placed on several platforms. For example, a data access subsystem may have a database server component, a data access gateway, and a client data access port, each running on a separate platform (similarly for an Object Request Broker [ORB], a workflow subsystem, an accounts subsystem, or a systems management subsystem).

Domains and architectural templates. In addition to describing actual architectural components, it is important to be able to describe the way in which they interact and collaborate. The Architecture Description Standard Semantic Specification defines the concept of a domain, which is a set of structural and behavioral patterns that describe some part of the architecture of an IT system (e.g., workflow, transactionality, user interface, network communications). The description of a domain is expressed as a set of collaborations between components and the interfaces (defining component roles) used by these collaborations.

One of the prime motivations for domains is reuse--domains can represent architectural patterns (or templates)⁶ that occur across many components and may be observed (and therefore reused) in many IT systems. Since better reuse of assets is an expected benefit of ADS, the alternative terminology of "architectural template" is used in this paper and elsewhere. This emphasizes the reuse aspect and is consistent with the definition of the architectural template work product type, described in the IBM SI/AD method.

There are several well-known examples of architectural templates, often described by related terms such as reference model, reference architecture, domain description, or even industry standard.

Widely known examples of architectural templates include:

• The Smalltalk Model-View-Controller pattern: A standard set of component roles (model, view, and controller) for user interface management, the interfaces each role must support, and the collaborations which ensure that the user interface (view) is coordinated with the model.
• The Web architecture: A template in which the browser and server collaborate in well-understood ways (defined by HTTP--HyperText Transfer Protocol) to present information across the Internet.
• The Workflow Reference Model from the Workflow Management Coalition:⁷ A set of patterns of collaboration between standard component roles (invoking application, workflow enactment service, invoked application, monitoring application) and a detailed workflow application programming interface supported by each role for a component to be "workflow-aware."
• The OMG Object Transaction Services (OTS) specification: A standard set of component roles (transaction manager, resource manager, resource) and required interfaces for transaction management in a distributed object environment.
• The International Organization for Standardization-Open Systems Interconnection (ISO-OSI) seven-layer model: An architectural template for network communications with well-defined layer responsibilities and interfaces.

The same diagrams used for describing component structure and component interactions are also used in architectural templates.

Operational aspect concepts. This section introduces the concepts and notations used in the operational model, which describes the operational aspect of IT system architecture.

Network diagram. The network diagram represents network topology and shows where software components are placed on the nodes in the network (Figure 5).

Figure 5

The central concept is node. A node is a platform on which software executes. During early stages of the design process, a node represents a potential platform before decisions have been made about how to map it to actual platforms.

The network diagram in Figure 5 shows nodes as rectangles (ideally, where diagramming tools permit, as UML cuboids). Each node has a name and (optionally) the number of instances (in parentheses). Connections represent physical data paths between nodes (e.g., by local area network--LAN, wide area network--WAN, dial-up, wireless) and show the shape of the network.

Deployment units are placed on the nodes. A deployment unit is the smallest unit of software or data about which an architect makes a placement decision. Deployment units are shown as named items on each node. In practice, only the most significant units are shown in this diagram; otherwise it becomes too cluttered.

A deployment unit consists of one or more components. In practice, we often need to regard the data aspect (or state) of a component as being in one deployment unit and the execution of a component as being in another deployment unit. Sometimes we also need to distinguish the installation aspect of a component as being in a third deployment unit. Deployment units may be named to reflect this need (e.g., in Figure 5, E1-E14 are execution deployment units, D8 is a data deployment unit) or they may be annotated (e.g., component name [E], CName [D, I]).

Nodes are grouped together in locations. A location is a geographical entity (e.g., a zone or building type) and is shown by a dashed line around one or more nodes. Several network diagrams may be used to represent different aspects of a single IT system (e.g., operational system, systems management, developmental environment).

The network diagram is based on the UML deployment diagram notation with some extensions. Nodes correspond to the UML concept of node.

Walkthrough. One of the main ways of confirming that the operational aspect of a system is feasible and acceptable is to perform end-to-end walkthroughs of collaborations. A walkthrough is a narrative description of how the IT system processes a use case scenario, tracing the collaboration around the system. It is used to assess the operational behavior of the system, specifically whether the system will be able to satisfy service-level requirements such as security and availability.

Walkthroughs are usually documented in text (as a sequence of paragraphs) and cross-referenced to scenarios or collaborations. They can be documented using component sequence diagrams if required.

Placement. A key concern in the design of the operational model is placement--deciding how to group components into deployment units and on which nodes to place them. Placement is influenced mainly by what data the users are operating on, together with where the system users are and what activities the users perform. It is also influenced by nonfunctional requirements (see next subsection).

When implementing a commercial software package, the deployment units to be placed are predefined. In contrast, when a solution is being designed and developed, the placement process determines the grouping of components into deployment units and influences the partitioning of components.

Nonfunctional requirements. The other key influences on placement are the nonfunctional requirements, for example:

• Performance (end-to-end response time for specified services)
• Availability (e.g., 8.00-20.00 weekdays, 24 x 7, etc.)
• Security policies, etc.

A nonfunctional requirement is a quality requirement or constraint that an IT system must satisfy.

Service-level requirements (such as those listed above) are an important type of nonfunctional requirement. Nonfunctional requirements also include system qualities such as maintainability, even though these relate to attributes of the development process, rather than to attributes of the operational system (like service levels).

All kinds of constraints on an IT system are also represented using this construct, including business constraints (e.g., geography of locations), IT standards (e.g., CORBA**--Common Object Request Broker Architecture--compliance), and current infrastructure constraints (must run on specified existing middleware).

In ADS, nonfunctional requirements may be attached to any component or node, and the operational model is developed by placing components onto nodes according to their nonfunctional requirements and then successively refining placement decisions. Although nodes themselves should strictly be modeled as sets of (hardware) components, it is normally sufficient to regard the node hardware and operating system as a simple container for software components, with the interfaces to the hardware components being provided by the operating system.

Integration of functional and operational aspects. As noted earlier, one of the major challenges in developing systems is achieving more effective integration between what has traditionally been application development and infrastructure design areas of work. ADS separates the concerns of the functional aspect (collaborating components) and the operational aspect (satisfying service requirements). At times it is important to be able to work on one aspect without considering the other.

ADS facilitates the integration of functional and operational aspects in five main ways:

1. Component placement--Components (functional) are placed on nodes (operational) in order to meet the service-level requirements and other quality requirements of the IT system such as manageability. Co-located components are grouped into deployment units to ease placement. Where required, the stored data of the component can be placed on a separate node from where the data execute. Interactions (functional) are mapped to connections (operational).

2. Component structuring--Operational concerns influence component structuring. Operational issues are frequently neglected during application development. ADS shows the concepts and issues in the operational model that have a direct effect on the component model. Components are (re)structured to take into account distribution requirements, operational constraints, and the need to achieve service-level requirements. For example, a component may be split into a client component and a server-based component, with a usage relationship between them, to achieve a response time objective on the client.

3. Scenarios--ADS provides use case scenarios as a unifying theme that runs through both functional and operational models. A use case scenario is realized in the functional model as a collaboration between components, with a sequence of operations executed. This collaboration (based on the same scenario) can be represented as a walkthrough in the operational model to validate that the placed components can achieve required service levels.

4. Use case service-level requirements--ADS enables effective integration of service-level requirements (SLRs) between functional and operational aspects. ADS recommends the specification of SLRs for use cases, which are then carried over to their associated collaborations as component collaborations. SLRs in this form are a valuable input to validate that the operational model will satisfy requirements. However, SLRs are also attached to many other entities, including the IT system itself.

5. Technical components--Last but not least, ADS facilitates integration by treating the technical components as part of the functional aspect. Technical components are components represented in a component model with component sequence diagrams in exactly the same way as application components. This treatment enables standard component modeling techniques to be used to represent application or technical integration.

These five forms of integration are illustrated in Figure 6.

Figure 6

Elaboration points. As the development of an IT system proceeds, the nature of the material that developers deal with changes. At the start of a project, abstract concepts such as requirements, use cases, and principles are the primary concern of project personnel. Toward the end of a project, different, more concrete concepts dominate; executable code, hardware specifications, and test cases are some of the major concerns.

However, during the development of an architecture, some entities retain the same basic concept but become progressively more refined and detailed. This progressive refinement takes two forms:

• As more information becomes available, and as the project gains a better understanding of the nature of the problem, more detail is added so that, finally, enough detail is available for a designer or implementor to take over. There is a sense of continuous progression in this refinement.
• At certain points in the process, structural changes have to be made, again reflecting better understanding of the problem, the environment, and the technology available. For example, it may be necessary to divide and merge components to handle nonfunctional requirements such as availability or performance. At this point there is a discontinuity in the development of the structure of the architecture.

Furthermore, in any complex project, the division of responsibilities means that each subproject will need to make its own structural changes, and those changes will need to be synchronized among subprojects. These points, therefore, are obvious places to produce major work products. Where predefined work products are used in a project, it is imperative that both the creator and the user of each work product agree on these key points in the development process.

Elaboration points are places at which major structural changes are made in all relevant parts of the project. (Entities may be split, merged, or regrouped; some may be deemed to be no longer needed, and some new ones may be introduced.) Often, unusually large quantities of information are exchanged between subprojects so that a uniform and coordinated design can be achieved. At the same time, major work products may be exploited or created, and formal reviews of work products may be held. Elaboration points are sometimes equivalent to checkpoints or to the transition between "stages" or "phases" in development methods.

In the current version of ADS, exact elaboration points are not defined.⁸ However, the initial and final elaboration points in any project will generally be the same, even though the number and nature of intermediate ones may differ. For example, ADS recommends the following:

• Initial elaboration point: unconstrained by the limitations of technology, geographical distribution, and the customer's environment. At this stage, relatively coarse-grained and undetailed models and specifications are produced.
• Intermediate elaboration point: one, for example, in which the distribution of users and locations is taken into account so that components are geographically distributed, or when new technological components may be identified to support the component distribution.
• Physical elaboration point: fully constrained by the limitations of the technology available, geography, and the environment. Fine-grained and detailed models and specifications are produced. The work products at this point are a complete architectural specification of the IT system, including specifications of hardware and software products so that they may be ordered. This work may include upgrades to installed products or connections. A specification of the operational aspect is produced so that nodes and connections can be configured and components deployed and brought into operation. If any new functionality needs to be created, module specifications are created that can be taken by a developer or programmer to be developed and unit-tested.

Not every aspect need have the same elaboration points. The functional aspect may have an initial elaboration point (usually the first elaboration point encountered in a project), but the operational aspect will usually not. Each aspect may have differing intermediate elaboration points, reflecting the different concerns of each aspect. However, all aspects should have a physical elaboration point.

Readers familiar with the WSDDM infrastructure design (ISD) method will recognize that the end stages of ISD closely correspond to elaboration points.

The concepts are summarized in Figure 7. This figure shows the IT system with its two aspects, functional and operational. Within each aspect, the major concepts are shown, separated by a dashed line.

Figure 7

Notation. ADS defines several standard notations. Wherever possible, these use the OMG UML notations. Table 2 summarizes the notations used in ADS.

Relationship with existing terminology and roles. This section positions some commonly used terminology and roles with ADS concepts. None of the terms in the following subsections is defined in ADS.

Application architecture. An application architecture view emphasizes those components and their interrelationships that provide the application-dependent behavior of the IT system. As such it is a view of a part of the functional aspect of the IT system.

Technical architecture. A technical architecture view emphasizes those components and their interrelationships that provide the application-independent behavior of the IT system. As such it is also a view of a part of the functional aspect of the IT system.

It is important to understand that ADS does not distinguish between a technical architecture and an application architecture. Any such division is somewhat arbitrary, so that no formal distinction is possible. For example, a workflow manager run-time server (a component in ADS terminology) can be thought of as a technical component (part of a workflow manager product), yet it contains business process definitions and information about the business organization--clearly application concepts. This component, therefore, has both application and technical responsibilities.

For this reason, the ADS functional aspect encompasses components present in both application and technical architectures, and uses the same concepts and notations for them.

The application development and infrastructure development roles. Application development methods and practitioners concentrate on the functional aspects of an IT system. Their main concern is, on the one hand, to partition the work in such a way that it can be allocated to development groups and, on the other hand, to build new components in such a way that they support the functional requirements. Service-level requirements (such as availability and performance, etc.) are not the primary concern of the application developer, although they may greatly influence the design of their components (though other nonfunctional requirements such as maintainability may be a major concern).

The infrastructure designer forms clusters of business and technical components to populate nodes in locations. The formation of these clusters is based on analysis of service-level requirements. This activity results in specifications being drawn up both for nodes and new components. Some of the latter are then passed to the application developers for development, others are acquired from vendors.

This simple approach may ignore the essential feedback that the placement process generates and that should be used to further influence the design of the components. Furthermore, technical components (for example, messaging) may end up in a gray area between the application developers and infrastructure designers, depending on whether they are to be acquired or custom-built. The more rigorous approach and the emphasis on formal, complete component models in ADS will help to eliminate such tendencies.

Enterprise architect role. Enterprise architects (formerly IT architects) build architectural models to describe the functional requirements of the infrastructure based on business objectives, the IT vision, and principles. The enterprise architecture method is a guide for IT architects and consultants involved in defining enterprise-wide architectures for clients. It provides specific guidance on the steps required to develop an enterprise architecture and general guidelines for sizing and estimating, report writing, and quality assurance.

The concepts present in these models reflect the key building blocks of the architecture and the interfaces between them. These building blocks are further refined to represent a reusable set of specifications for which evaluation criteria and standards can be developed, and eventually product selection can be done.

Work is in progress to map enterprise architecture concepts to ADS concepts.

Concluding remarks

The Architecture Description Standard is a key part of the foundation for an asset-based business in IBM. It contains a metamodel of an IT system, a semantic description, and a glossary that are designed to be sufficiently comprehensive for the target user community. It is also designed to be simple enough to be deployed to a user with a wide range of skills.

In this paper we have described how ADS was based on the use of industry standards, particularly UML. We have shown how these standards have been extended in particular areas, such as the operational aspect of architecture, in order to highlight areas that IBM has learned in practice are crucial in the design of large-scale enterprise systems.

We anticipate that through facilitating asset creation and reuse, widespread use of ADS in IBM will deliver considerable benefits, measured in financial terms, as reductions in cost, risk, and time in development projects. Less tangible benefits will be a more concise and precise means of communication between different parts of development teams and between IBM and its clients. In other papers in this issue (on reference architectures and engagement experiences) it can be seen how early versions of ADS have already been successful in helping IBM to structure assets and then reuse them in architecture projects to the benefit of both IBM and its clients.

Acknowledgments

In addition to the authors of this paper, the Architecture Description Standard project team consisted of: John Cameron, Ian Charters, Martin Cooke, and Dave Vanberg (with Ed Kahan as project leader). The following also contributed to the development of ADS, either directly or through its predecessors: John Black, Steve Cook, Paul Fertig, George Galambos, Ralph Hodgson, Deborah Leishman, Tim Lloyd, and John Rothwell.

Appendix: Glossary of ADS terms

The main terms in the Architectural Description Standard are defined below. Entries that are considered to be "core" to ADS are represented in a large-size boldface type. General industry terms, or minor ADS terms, are regarded as "noncore" terms and are shown in regular-size boldface type.

Actor An actor is a human user or external system that interacts with the system being built, by executing use cases. An actor represents a coherent set of roles. Several users can play the same role, and one user can perform several roles.

Examples of actor could include customer service representative or credit authorization service (an external system).

Architecture"The architecture of an IT system is the structure or structures of the system, which comprise software and hardware components, the externally visible properties of those components, and the relationships among them." (Adapted from Bass et al.¹)

Architectural template An architectural template is a set of structural and behavioral patterns that describe some part of the architecture of an IT system (e.g., workflow, transactionality, user interface, or network communications). It describes component roles, the interfaces that components playing these roles must provide, and a set of standard collaborations.

Familiar examples of architectural templates are:

• The Web architecture, in which the browser and server roles collaborate in well-understood ways (defined by HTTP) to present information across the Internet
• The Workflow Reference Model, which defines the standard collaborations and interfaces by which a workflow system can interoperate with both client applications and invoked applications
• The ISO-OSI seven-layer model, which constitutes an architectural template for network communications with well-defined layer responsibilities and interfaces

*Trademark or registered trademark of International Business Machines Corporation.

**Trademark or registered trademark of Lotus Development Corporation, Object Management Group, Sun Microsystems, Inc., or Microsoft Corporation.

Cited references and notes

Accepted for publication October 4, 1998.