1.2. Software Architecture as a Discipline

As a professional discipline, software architecture has at least a dozen schools of thought. Some of the major schools of thought include:

• Zachman Framework [Zachman 97]

• Open Distributed Processing (ODP) [ISO 96]

• Domain Analysis [Rogers 97]

• Rational's 4+1 View Model [Booch 98]

• Academic Software Architecture [Bass 98]

Alternative architecture approaches share concepts and principles, but their terminologies differ greatly. Each architecture school is relatively isolated from the others. In the literature of any given school, perhaps one or two other schools are acknowledged, however briefly. None of the schools appear to make any significant use of the results of the others. Since the terminology between these groups varies significantly, communication is difficult, especially between practitioners using different architecture approaches. Upon further study, we find that the goals of each school are quite similar, and each school has some unique value to offer.

In addition to these schools, there are many vendor-driven approaches that are tied to specific product lines, such as Netscape ONE, Sun Enterprise JavaBeans, and Microsoft BackOffice. In fact, every vendor appears to have a unique architectural vision for the future founded upon its own product lines.

Many vendors actually have minimal understanding of application architecture. Thus, I focus here on those approaches which consider key application drivers with appropriate product support for underlying capabilities.

Architecture Approaches

Here is a brief tour of the major schools of software architecture thought.

Zachman Framework

Derived from IBM research and practice, the Zachman Framework is a traditional architecture approach; i.e., it is decidedly non-OO. The Zachman Framework is a reference model comprising 30 architecture viewpoints. The reference model is a matrix, which intersects two paradigms: journalism (who, what, when, why, where, and how) and construction (planner, owner, builder, designer, subcontractor). Architects choose from among these viewpoints to specify a system architecture.

Open Distributed Processing

A formal standard from ISO and ITU (telecommunications), Open Distributed Processing (ODP) defines a five-viewpoint reference model (enterprise, information, computational, engineering, and technology). ODP defines a comprehensive set of terminology, a conformance approach, and viewpoint correspondence rules for traceability. The product of seven years of standards work, ODP is a recent adoption that fully supports OO and component-based architecture. In fairness, I should note that ODP is my primary approach to software architecture.

Domain Analysis

A process for the systematic management of software reuse, domain analysis transforms project-specific requirements into more general domain requirements for families of systems. The requirements then enable the identification of common capabilities, which are used as the basis for horizontal frameworks and reusable software architectures. An important capability of this approach is the definition of robust software designs, which are relatively resistant to requirements and context changes.

4+1 View Model

A four-viewpoint approach is under development by Rational Software. The viewpoints include: logical, implementation (formerly "component"), process (i.e., runtime), and deployment. The "+1" denotes use case specifications supporting requirements capture. This approach is closely aligned with the Unified Modeling Language and the Unified Process.

Academic Software Architecture

Academic software architecture comprises a community of computer science researchers and educators constituting an academic field. Their educational efforts are focused on basics and fundamentals. In their research contributions, this community avoids proven architectural standards and practices in order to achieve originality, theoretical formality, and other academic goals.

Common Principles

It is often said that the principles of software are simple. For example, let's consider (1) simplicity and (2) consistency. Architects agree that managing complexity (i.e., achieving simplicity) is a key goal, because it leads to many architectural benefits, such as system adaptability and reduced system cost. For example, a simpler system is easier to test, document, integrate, extend, and so forth.

" Explore the situation from more than one point of view. A seemingly impossible situation might become transparently simple " [Rechtin 97].

Simplicity is most necessary in the specification of the architecture itself. Most architectural approaches utilize multiple viewpoints to specify architecture. Viewpoints separate concerns into a limited set of design forces, which can be resolved in a straightforward and locally optimal manner.

Consistency enhances system understanding and transfer of design knowledge between parts of the system and between developers. An emphasis on consistency contributes to the discovery of commonality and opportunities for reuse. Architects agree that unnecessary diversity in design and implementation leads to decidedly negative consequences, such as brittle system structure.

Architecture Controversies

The principal disagreements among architecture schools include: (1) terminology, (2) completeness, and (3) a priori viewpoints.

Architects disagree on terminology due to their backgrounds or schools of thought. For example, when discussing software interfaces, the consistency principle is variously called: standard interfaces, common interfaces, horizontal interfaces, plug-and-play interfaces, and interface generalization. We can also argue that variation-centered design (from design patterns) and component substitution are largely based upon consistent interface structure.

Unnecessary diversity of terminology leads to confusion, and sometimes to proprietary advantage. Some vendors and gurus change terminology so frequently that keeping up with their latest expressions becomes a time-consuming career.

Differences in terminology lead to miscommunication. In contrast, some distinct areas of disagreement among architecture schools can't be resolved through improved communications alone.

The notion of complete models is promoted by legacy OO approaches (e.g., OMT), the Zachman Framework school, and various others. These groups have promoted a vision that complete models (describing multiple phases of development) are a worthwhile goal of software development projects. Other schools would argue that multiple models are not maintainable, that unnecessarily detailed models are counterproductive, and that architectural significance should be considered when selecting system features for modeling.

These contrary notions can be summarized in terms of the principle of pragmatism. We side with the pragmatists for the above reasons and because most software systems are too complex to model completely (e.g., multithreaded distributed computing systems). Pragmatism is a key principle to apply in the transition from document-driven to architecture-centered software process.

The selection of architecture viewpoints is a key point of contention among architecture schools. Some schools have preselected a priori viewpoints. Some schools leave that decision to individual projects. The Zachman Framework is an interesting case, because it proposes 30 viewpoints, from among which most projects select groups of viewpoints to specify.

Variable viewpoints have the advantage that they can be tailored to address the concerns of particular system stakeholders. Predefined viewpoints have the advantage that they can accompany a stable conceptual framework and a well-defined terminology, as well as predefined approaches for resolving viewpoint consistency and architecture conformance.

Innovative Software Architecture

There are many active and successful schools of software architecture thought. Software architecture is a discipline unified by principles, but divided by terminology. The various architecture schools can be viewed as different branches of an evolutionary progression.

The Zachman Framework has evolved from the traditional non-OO approaches. ODP is an outgrowth from object-oriented and distributed-computing paradigms that has achieved stability, multiindustry acceptance, and formal standardization. Both Zachman and ODP approaches have enjoyed significant success in production-quality software development. Domain analysis has demonstrated its worth in defining robust, domain-specific software architectures for reuse. The 4+1 View Model is an approach undergoing development, in parallel with the Unified Process.

All of the above can be described as innovative software architecture approaches. They are being applied in practice, based upon various levels of proven experience. Academic research in software architecture is defining a baseline for architecture knowledge that resembles a lowest common denominator of the above approaches. Fortunately, the academic community has legitimized the role of the software architect, regardless of whether their guidance is useful to innovative architects.

In our opinion, software architects should have a working knowledge of the innovative approaches described above. In addition, they should utilize one of the product-quality architecture frameworks in daily practice. Component architecture development is a challenging area, requiring the best of stable conceptual frameworks supporting sound architectural judgment.

The Architecture Paradigm Shift

The nature of information systems is changing from localized departmental application to large-scale global and dynamic systems. This trend is following the change in business environments toward globalization. The migration from relatively static and local environments to highly dynamic information technology environments presents substantial challenges to the software architect (Figure 1.1).

A majority of information technology approaches are based upon a set of traditional assumptions (Figure 1.2). In these assumptions the system comprises a homogeneous set of hardware and software which is known at design time. A configuration is relatively stable and is managed from a centralized system management configuration. Communications in traditional systems are relatively predictable, synchronous, and local. If the state of the system is well known at all times and the concept of time is unified across all the activities, another key assumption is that failures in the system are relatively infrequent and, when they do occur, are monolithic. In other words, either the system is up or the system is down.

In the building of distributed application systems, most of the assumptions are reversed. In a distributed multiorganizational system it is fair to assume that the hardware and software configuration is heterogeneous. The reason is that different elements of the system are purchased during different time frames by different organizations and many of the decisions are made independently. Therefore in a typical configuration you have a variety of information technology. It is also the case that hardware and software configurations are evolving. Occurring within any organization are turnover in employees and evolution of business processes. The architecture of the organization impacts the architecture of the information technology. As time progresses, new systems are installed, systems are moved, new software is acquired, and so on. When multiple organizations are involved, these processes proceed relatively independently, and the architect must accommodate the diverse evolving set of configurations.

In distributed systems, the assumption is that there is remote processing at multiple locations. Some of this remote processing is on systems that were developed independently and therefore have their own autonomous concept of control flow. This reverses the assumption of localized and unified processing resources. There are some interesting implications for the concepts of state and time. The state of a distributed system is often distributed itself. The state information may need to be replicated in order to provide efficient reliable access at multiple locations. It is possible for the distributed state to become nonuniform in order to get into error conditions where the replicated state does not have the desired integrity and must be repaired. The concept of time-distributed systems is affected by the physics of relativity and chaos theory. Electrons are traveling near the speed of light in distributed communication systems. In any large system there is a disparity between the local concepts of time, in that this system can only have an accurate representation of partial ordering of operations in the distributed environment. The total ordering of operations is not possible because of the distances between information process. In addition, distributed communications can get quite variable and complex. In a distributed system there are various qualities of service which communications systems can provide. The communications can vary by timeliness of delivery, the throughput, the levels of security and vulnerability to attack, the reliability of communications, and other factors. The communications architecture must be explicitly designed and planned in order to account for the variabilities in services.

Finally, the distributed system has a unique model of failure modes. In any large distributed system components are failing all the time. Messages are corrupted and lost, processes crash, and systems fail. These kinds of failures happen frequently and the system must be architected to accommodate for them.

In summary, distributed processing changes virtually all of the traditional system assumptions that are the basis for most software engineering methodologies, programming languages, and notations. To accommodate this new level of system complexity, architects have three new needs.

First, architects need the ability to separate complex concerns, in particular to separate concerns about business-application functionality from concerns about distributed-system complexity. Distributed computing is a challenging and complex architectural environment unto itself. If systems are built with traditional assumptions, architects and developers are likely to spend most of their time combating the distributed nature of real-world applications. Problems and challenges of distributed computing have nothing to do fundamentally with business-application functionality.

The purpose of information technology is to establish new business processes. By separating concerns, we can focus on the business functionality that is the true purpose of the information system. Ideally, architects would like to separate distributed-system issues into categories of design, where the majority of components are purchasable as commodity communication infrastructure.

Object-oriented architects also need the ability to future-proof the information systems that they are planning. It is important to accommodate commercial technology evolution, which we know is accelerating and beginning to provide substantial challenges for architects and developers. Future-proofing also requires the ability to adapt to new user requirements, since requirements do change frequently and account for a majority of system software cost over the life cycle. It is important to plan information systems to support the likely and inevitable changes that users will require in order to conduct business.

A third need for object-oriented architects is the ability to increase the likelihood of system success. Corporate developers to date have had a very poor track record of creating successful systems. The object-oriented architect is responsible for planning systems with the maximum probability of delivering success and key benefits for the business. Through proper information technology planning, we believe that it is possible to increase the likelihood of system delivery on time and on budget.

In confronting these three needs, authorities in software engineering and computer science tend to agree that architecture is the key to system success. Authorities in areas ranging from academia to commercial industry are declaring that software architecture is essential to the success and management of information systems. There is a long and growing list of software authorities who have come to this conclusion. Unfortunately, it is not always clear to everyone what software architecture truly is. In order to provide clarification, we need to take a look at some of the reference models which provide definitions of software and systems architecture (Figure 1.3).

The needs that we are discussing have been thoroughly considered by many authorities. There are two leading meta-architecture frameworks that guide the development of software system architecture. One of the popular frameworks originated at IBM and is called the Zachman Framework. The Zachman Framework predated the popularity of object orientation and took the perspective of separating data from process. In the Zachman Framework there are six information system viewpoints as well as five levels of design abstraction. The original Zachman Framework published in 1987 contained viewpoints for the network, the data, and the process of the information system [Zachman 97]. A subsequent revision introduced three additional viewpoints. The current framework resembles the set of traditional journalistic questions, which include who, what, when, why, where, and how. Each viewpoint in the Zachman Framework answers a chief set of questions to ensure that a complete system engineering architecture is created.

The Zachman Framework formed a matrix of architecture descriptions which are also organized in terms of levels. There are five levels of description above the information system implementation. They range from architectural planning done by individual programmers at the finest grain to the overall enterprise requirements from the investors' perspective of the information system. In total, the Zachman Framework identifies 30 architectural specifications, which provide a complete description of the information system. In practice no real-world project is capable of creating these 30 or more detailed plans and keeping them all in synchronization. When the Zachman Framework is applied, systems architects partition the viewpoint into various categories and create architectural specifications that cover all of the different Zachman descriptions without having to create the large number of specification documents that the Zachman Framework implies. One example is a very successful architecture initiative by the United States Department of Defense called the C4ISR architecture framework, where C4ISR stands for Command and Control, Computers, Communication, Intelligence Surveillance, and Reconnaissance. The C4ISR architecture framework is used to describe DOD information technology at the highest echelons of the organization. The primary benefit in this case is that different service organizations and agencies can communicate their architectural plan through common-viewpoint description.

Beyond the Zachman Framework, object-oriented architects have discovered additional needs for defining computational architecture and other viewpoints which are not obvious applications of the Zachman principles. The international standards organization (ISO) has also considered these architectural issues. Recently completed is the ISO reference model for open distributed processing called RM-ODP. This model belongs to a category of ISO standards called open distributed processing (ODP). ODP is an outgrowth of earlier work by ISO in open systems interoperability. The Open Systems Interconnection (OSI) seven-layer reference model identified an application layer which provided minimal structure and guidance for the development of application systems. In fact, the seventh layer for applications groups remote procedure calls, directory services and all other forms of application level services within the same architectural category, not defining any particular structure or guidance for this significant category of functionality.

A Standard for Architecture

Among the various architecture approaches, there is a useful international standard that defines what information systems architecture means, the Reference Model for Open Distributed Processing (RM-ODP) [ISO 96]. We will cover it as one way to think about software architecture. This model is representative of mature software architecture practice today.

RM-ODP defines five essential viewpoints for modeling systems architecture:

• Enterprise Viewpoint

• Information Viewpoint

• Computational Viewpoint

• Engineering Viewpoint

• Technology Viewpoint

The five viewpoints provide a comprehensive model of a single information system.

An enterprise viewpoint contains models of business objects and policies. Enterprise policies include permissions, prohibitions, and obligations. An information viewpoint includes the definition of information schemas as objects. Three kinds of RM-ODP schemas include static, invariant, and dynamic. A computational viewpoint includes definitions of large-grained object encapsulations, including subsystem interfaces and their behaviors. These three viewpoints define architecture in a manner that makes distributed computing transparent. An engineering viewpoint exposes the distributed nature of the system. The distribution transparencies supported by infrastructure are declared explicitly. The allocation of objects onto processing nodes is also specified. RM-ODP defines a reference model of distributed infrastructure called a channel which is used to model all forms of middleware connections.

RM-ODP defines eight distribution transparency properties. It is interesting to note that only a handful of these properties are supported by major commercial infrastructures (without resorting to niche-market products). For example, CORBA products provide full support for access, location, and transaction transparency, with some support for failure and persistence transparency. Microsoft's Distributed Component Object Model (DCOM) provides support for persistence and transaction transparency, with limited support for the other properties.

Open distributed processing and its reference model are the result of ten years of formal standardization work at ISO. The reference model for open distributed processing is object oriented. It provides a referenced model that was intended to address three fundamental goals: (1) to provide a standard framework for further work and additional detailed standards under the open distributed processing initiative, (2) to provide a set of common terminology and concepts that could be applied for the development of product and application systems for open distributed processing, (3) to provide a guideline for object-oriented architects to specify software systems. This third purpose is directly relevant to the day-to-day practices of systems architects.

Open distributed processing includes several other standards which are significant (Figure 1.3). In particular, it has adopted the interface definition language from CORBA as a notation for a specified computational architecture. It also has a standard for the trader service, which is the key directory service supporting the discovery of application functions in distributed systems. The trader service has subsequently been adopted as a commercial standard through the object management group. The group's object management architecture is a commercial specialization of open distributed processing.

All together, the OMG's consensus standards and the ISO open distributed processing form a set of software architecture standards that are useful intellectual tools for most software architects and developers.

RM-ODP has three completed standards documents. Part one of the standards is a non-normative overview and summary of the overall concepts and terminology. All three parts of the adopted standard are cosponsored by the International Telecommunications Union ITU-T through their X.900 series. The cosponsorship of both ISO and ITU-T represents a broad international consensus on this guideline for object-oriented architecture.

Part two of the standard is the foundations document, comprising a glossary of standard terminology for object oriented distributed systems.

Part three of the standards is the architecture document. It defines the various viewpoints for object-oriented architecture along with their structuring rules and various open distributed processing functions which enable distributed computing.

Altogether, these three standards documents comprise less than 200 pages of documentation with the normative parts, part two and part three comprising about 100 pages. Even though this is a relatively short standard, it provides a great deal of valuable information. Many ISO standards are relatively inscrutable to the practicing software engineer; this standard is no exception. However, we believe that the effort to understand it is very worthwhile, given the challenges of distributed computing in business process change that need to be resolved.

Who supports RM-ODP? RM-ODP is the product of formal standards bodies including ISO and IEEE. The IEEE is an accredited standards organization reporting to ISO; therefore, the IEEE is a voting participant and joint supporter of RM-ODP as well. RM-ODP is the formal standards basis for the object management group's object management architecture and all of the resulting technologies that the group has adopted which form the basis for distributed object computing and technologies that are available commercially. RM-ODP is also accurately used in several mission-critical industries which depend upon information technology for their income. In particular, RM-ODP is applied across the telecommunications industry through the telecommunications information network architecture consortium, and RM-ODP is actively used by telecommunication companies such AT&T, Lucent, and Nortel. In the telecommunications industry, information technology is their business, and distributed information systems success is essential to maintaining their competitive advantage.

Also applying ODP actively is the financial services industry. Companies such as Merrill Lynch, Morgan Stanley, and various mortgage lending organizations are applying RM-ODP to define new information systems concepts. The deployment of new information technologies is becoming one of the key competitive advantages that these companies have for creating new market channels to distribute and transact new financial instruments and securities, and perform other financial services. For these industries failure of information systems directly affects bottom-line profitability and is usually not an option. If these influential companies accept this architectural approach and apply it actively, can your organization afford not to consider its benefits?

The RM-ODP comprises five standard viewpoints. Each viewpoint is a perspective on a single information system (Figure 1.4). The set of viewpoints is not closed, so that additional viewpoints can be added as the needs arise. Another of their purposes is to provide information descriptions that address the questions and needs of particular stakeholders in the system. By standardizing five viewpoints, RM-ODP is claiming that these five stakeholder perspectives are sufficient for resolving both business functionality and distributed systems issues in the architecture and design of information systems. RM-ODP is an elegant model in the sense that it identifies the top priorities for architectural descriptions and provides a minimal set of traceability requirements which are adequate to ensure system integrity.

The enterprise viewpoint of our RM-ODP takes the perspective of a business model. The enterprise models should be directly understandable by managers and end users in the business environment. The enterprise viewpoint ensures that business needs are satisfied through the architecture and provides a description which enables validation of these assertions with the end users.

The information viewpoint defines the universe of discourse in the information system. The perspective is similar to the design information generated by a database modeler. The information viewpoint is a logical representation of the data and processes on data in the information system.

Each of the five RM-ODP viewpoints is object oriented, and they provide a complete model of the system from the given perspective. The information viewpoint is an object-oriented logical model of the information assets in the business and how these assets are processed and manipulated.

The computational viewpoint partitions the system into software components which are capable of supporting distribution. It takes the perspective of a designer of application program interfaces for componentware. The computational viewpoint defines the boundaries between the software elements in the information system. Generally, these boundaries are the architectural controls that ensure that the system structure will embody the qualities of adaptability in management of complexity that are appropriate to meet changing business needs and incorporate the evolving commercial technology.

The engineering viewpoint of RM-ODP exposes the distributed nature of the system. Its perspective is similar to that of an operating system engineer who is familiar with the protocol stacks and allocation issues that are necessary to define the distributed processing solutions for the information system.

The fifth viewpoint is the technology viewpoint. It defines the mappings between the engineering objects and other architected objects to specific standards and technologies including product selections. The viewpoint is similar to that of a network engineer who is familiar with the protocol standards and products available commercially which are appropriate selections to configure the information system.

All five RM-ODP viewpoints are co-equal in the sense that they do not form levels of description; rather each viewpoint provides a complete model of the information system that is object oriented and corresponds to the other viewpoints. Each defines various constraints on the design of the information system that provide various architectural benefits for each of the system's stakeholders. The RM-ODP viewpoints enable the separation of concerns which divide the business and logical functionality of the system from the distributed computing and commercial technology decisions of the architecture.

The first three viewpoints identify informational and computational characteristics. The enterprise and information viewpoints are purely logical views of the business, represented as object-oriented models (Figure 1.5). The computational viewpoint is independent of the distribution of software modules, but it must define computational boundaries which are enabled for distribution. The CORBA IDL notation for specifying computational interfaces is appropriate for this purpose. IDL provides a way to define computational interfaces which are independent of the distribution and deployment issues in enterprise development. The first four viewpoints—enterprise, information, computational, and engineering—are independent of specific implementations. In other words, the majority of the architectural design is independent of the specific product selections which configure the system. This property of RM-ODP enables the evolution of technology components without impacting the overall architectural constraints defined in the first four viewpoints. The engineering viewpoint defines qualities of service and distribution transparencies which evolving technology selections must support. The terminology of RM-ODP assists in providing concise descriptions of these technology requirements.

RM-ODP contains many terminology definitions which are useful concepts for object-oriented architects. Some of the key definitions in RM-ODP are the distribution transparencies. RM-ODP defines in distribution transparencies which specify the qualities provided by distributed computing infrastructure (Figure 1.6). Currently available commercial infrastructures provide some subset of these, such as location, and access transparencies provided by CORBA along with partial support for persistence in transaction transparency. Additional transparencies are available through niche-market products and through custom implementations which are enabled by proper architectural separation of infrastructure requirements from technology selections. Technologies which do not provide access transparency, such as Microsoft COM+ and the distributed computing environment, do not adapt well to the future evolution of distributed systems (Figure 1.7).

RM-ODP provides standard definitions for distributed infrastructure objects that enable abstract descriptions of engineering constraints. Figure 1.7 is an example of the engineering objects which RM-ODP defines. These engineering objects are capable of defining the characteristics of all forms of distributed infrastructure, including remote procedure calls, screening data interfaces, and asynchronous interfaces for signaling. Among the most important features of RM-ODP are its definitions supporting conformance assessment. After all, what is the purpose of architectural documentation unless we can assess conformance—that is, make sure that the implementation of the system corresponds to the written and intended architectural plans.

RM-ODP defines four categories of conformance and proceeds to specify how conformance is represented in an architectural plan. The first category is called programmatic conformance. This is the usual notion of behavioral testing of software interfaces. Many of the programmatic conformance points will occur in the computational viewpoint specification of RM-ODP based architectures.

Perceptual conformance includes testing at user interfaces in communications ports that represent external boundaries to the system. Usability and user interface testing can be defined through perceptual conformance assessment. Interworking conformance involves testing between systems implementations. It is not sufficient for individual systems to have programmatic conformance in order to guarantee interoperability. Interworking conformance includes interoperability testing between working implementations, which is an additional requirement beyond programmatic conformance.

Interchange conformance involves testing of the exchange of external media, such as disks and tapes. It ensures that information that is stored on external media can be interpreted and assimilated in other systems that conform to the same standards. RM-ODP also defines correspondence requirements between the various viewpoints of application architecture. In general, the objects defined in each of the viewpoints do not have to be explicitly correspondent, because they represent independent description of the system representing various levels of granularity of descriptions and constraints.

Several key points of correspondence must be ensured. The computational viewpoint must support any dynamic behaviors that are specified in the information viewpoints. The information viewpoint represents the information in the information system and its processing. Whenever a process occurs, it must be explicitly allocated to the internal operation of one of the computational modules or it must be explicitly allocated to a particular computational interaction—in other words, invoking a software interface to cause the processing of information. In addition, there is an explicit correspondence requirement between the computational and engineering viewpoints. In general, engineering objects outnumber computational objects, because the engineering viewpoint exposes the objects in the distributed infrastructure, which may be numerous. For every computational interface defined in the computational viewpoint, there must be an explicit correspondence to engineering interfaces in the engineering viewpoint objects. The computational boundaries must map onto distributed engineering objects so that the distribution strategy is clarified by the architecture.

Applications and Profiles

Open systems standards (such as RM-ODP) are purposely generic so that they apply to all domains. To make standards deliver their benefits, a profile is required. A profile is an implementation plan for how the standard is applied within a context. Several profiles of RM-ODP are in use today.

The 4+1 View Model is a viewpoint-based architecture approach supported by OO tools such as Rational Rose. The viewpoints include:

• Use Case View

• Logical View

• Process View

• Implementation View

• Deployment View

The use case view models enterprise objects through a set of scenarios. The logical view includes object models of packages, classes, and relationships. The process view represents control flows and their intercommunications. The implementation view defines the modular structure of the software. The deployment view identifies the allocation of software onto hardware. An architecture defined as a 4+1 View Model covers aspects of all 5 RM-ODP viewpoints.

RM-ODP is being applied in several industries, including financial services and defense. For example, the United States Department of Defense (DoD) has a profile of RM-ODP, called the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance Architecture Framework (C4ISR-AF). C4ISR-AF defines three viewpoints: operational architecture, system architecture, and technical architecture. An information viewpoint is also specified.

Before applying the framework, DoD services defined their architectures using disparate conventions. C4ISR-AF is currently used by all DoD services to describe their architectures. The framework is enabling technology exchanges across diverse system development programs. Reuse opportunities and common interoperability solutions are being identified and defined as a result.

Viewpoint Notations

Within each viewpoint, the RM-ODP approach uses formal notations (or specification languages) that support architecture description.

One of the most useful notations for specifying computational viewpoints is the ODP interface definition language (ODP IDL). ODP IDL is a related international standard that is identical to CORBA IDL. It enables the specification of object encapsulations that can be implemented on multiple infrastructures, such as CORBA, Microsoft COM, and the Adaptive Communication Environment (ACE). Since ODP IDL is programming-language independent, a single interface specification suffices to define interoperable interfaces for C, C++, Ada95, COBOL, Smalltalk, the Java programming language, and Microsoft IDL. These mappings are defined by open systems standards and supported by commercial products.

Another useful notation for describing architecture viewpoints is the Unified Modeling Language (UML). UML is an object-oriented notation recently adopted by the Object Management Group. UML is also supported by Microsoft in its respository and development environment technologies.

Although it is not widely publicized, RM-ODP is providing architectural benefits in multiple industries. RM-ODP is a formal standard that defines how to describe distributed OO architectures. In practice, RM-ODP's viewpoints, models, and transparency properties are useful conceptual tools for object-oriented architects.