A todo esto ¿Qué es una arquitectura?

  • 2,493 views
Uploaded on

Serie de semiarios DCC8090. Charla: "A todo esto, ¿Qué es una arquitectura?". Autor: Juan Carlos Barroux. 2008.

Serie de semiarios DCC8090. Charla: "A todo esto, ¿Qué es una arquitectura?". Autor: Juan Carlos Barroux. 2008.

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,493
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
109
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 11 de Junio 2008 Juan Carlos Barroux R. jbarroux@leconseil.cl http://www.linkedin.com/in/juancarlosbarrouxr
  • 2. Agenda ¿Qué es una arquitectura? ¿Qué no es una arquitectura? ¿Para qué necesito una arquitectura? ¿Cómo se hace una arquitectura? ¿Y los arquitectos entonces? ¿Cómo los reconozco? ¿Qué hace un[a] arquitect{o,a}? ¿Cómo se crea un[a] arquitecto{o,a}? ¿Hacia dónde vamos con la arquitectura? Reflexiones arquitectónicas finales.
  • 3. ¿Qué es una arquitectura?
  • 4. ¿Qué es una arquitectura? Architecti est scientia pluribus disciplinis et variis eruditionibus ornata, cuius iudicio probantur omnia quae ab ceteris artibus perficiuntur opera. Vitruvius ca. 80 - ca. 20 a.
  • 5. ¿Qué es una arquitectura? Los invariantes de un sistema.
  • 6. ¿Qué es una arquitectura? Distribución en el tiempo y en el espacio de los objetos.
  • 7. ¿Qué es una arquitectura? “Architectures are hollistic bridges, but also processes” James Baty
  • 8. ¿Qué es una arquitectura? Un proceso que genera una visión compartida de las relaciones entre los componentes de un sistema.
  • 9. ¿Qué no es una arquitectura? • Un dibujo • Algo estático • Una imposición • Un secreto
  • 10. ¿Qué es un[a] arquitect{o,a}? “Tous imbéciles. Oublient toujours l’escalier des maisons” Gustave Flaubert
  • 11. ¿Para qué necesito una arquitectura? ¡Para controlar la complejidad! Los sistemas son complejos y dinámicos.
  • 12. ¿Cómo piensa un arquitecto? • Se hace preguntas: •¿Dónde se me va a romper? •¿Dónde me van a penetrar? •¿Dónde no va a escalar? •¿Dónde me estoy amarrando? •¿Dónde es demasiado complejo? •¿Cómo lo administro? •¿Cómo le agrego nuevas funciones? •¿Qué se me olvidó?
  • 13. ¿Cómo piensa un arquitecto? ➔ No piensa en “features” ➔ Piensa en términos de interrelaciones entre subsistemas. ➔ A nadie le importa el clockage de una CPU como a nadie le importa el diámetro de un cilindro.
  • 14. ¿Cómo piensa un arquitecto? • Piensa como un traductor. • Le traduce al cliente lo que le dice el ingeniero calculista, el constructor civil, el estucador, el pintor, el albañil, etc.
  • 15. ¿Cómo piensa un arquitecto? • Piensa en terminos “vendedores” Architecture : The integration in a single seductive speech of the 4 Ss (Systems, Software, Storage and Services) into a single S, the Solution.
  • 16. ¿Cómo se hace una arquitectura? • Definir metas, objetivos e hipótesis • Especificar las métricas • Generar la descomposición funcional • Dimensionar la carga de cada función • Colapsar funciones en sistemas • Validar escalabilidad • Validar disponibilidad • Validar seguridad • Generar vista física primera instancia
  • 17. ¡Gracias! http://www.leconseil.cl/ Versión 1.1
  • 18. Introduction to Systems Application Architecture by E. F. Wheeler A. G. Ganek Systems Application Architecture Is a framework in ready been published, and more will follow as SAA which applications are developed that they run con- so evolves and expands over time. The specifications sistently on major ISM computing systems. This paper presents the motivation and requirements for this are open and available to encourage customer and framework and describesthe main elementsof its software-vendor participation in the development of structure. It also discusses effect on current proc- the applications that adhere to SAA. In addition, a fourth essing technologies and on application development. key element of the SAA strategy is IBM’S own com- mitment to provide Common Applications that will executeacross the SAA system environments. As customer, software-vendor,and IBM SAA applications become available,the new dimension of consistency among them will augment the end user’s access to I n March 1987, IBM introduced Systems Applica- tion Architecture (SAA), a significant new direction for IBM software which provides the framework for applications of all kinds. the development of consistent applications across SAA is a key strategic direction for IBM, analogous to the major IBM computing environments-Sys- the System/360 announcement in 1964 that intro- tem/370, A S / ~ O Oand, Personal System/2@. ~~ This an- duced a family of hardware systems. SAA defines a nouncement is not about a specific product, but family of software operating systems whose goal is rather a pervasive software architecture that under- to meet the following customer needs: lies the commitment to provide, in an evolutionary way, cross-systems consistency across a broad spec- Increased programmer and end-user productivity trum of hardware, architecture, and operating sys- Enhanced ease of use and support by providing tems environments. It is a software-based approach consistency among applications to present the breadth of IBM’S product line to its Improved communications capability and usabil- customers as a family of software systems-a family ity for enterprise-widesolutions that will provide enterprise-wide solutions to busi- Increased return on customers’ information sys- ness computing problems. tems investment via greater leverageof program- mer resourcesand user experience SAA is composed of three significantelements- Common User Access, Common Communications Copyright 1988 by International Business Machines Corporation. Support, and Common Programming Interface- Copying in printedformforprivateuse is permittedwithout that govern software interfaces, protocols, and con- payment of royalty provided that ( 1 ) each reproduction is done ventionsfor human interaction with applications without alteration and the Journal reference and IBM copyright (2) and systemservices, communication mechanisms notice are included on the first page. The title and abstract, butno other portions, of this paper may be copied or distributed royalty that interconnect SAA systems, and programming freewithoutfurtherpermission by computer-basedandother interfaces for program development. Many of the information-servicesystems.Permission to republish anyother specifications that describe these elements have al- portion of this paper must be obtained from the Editor. 250 WHEELER AND GANEK I M SYSTEMS JOURNAL, VOL 27, NO 3, 1988 B
  • 19. These needs are to be met by providing consistent, During the mid- to late 196Os, the function of oper- durable interfaces in IBM software products. ating system software increased as newer technology, such as larger memory, became more available and This paper is intended to illuminate the concept of as the complexity of the hardware increased. These SAA, demonstrate the motivations for this direction, developments spawned the widespreaduseof the and explain its overall structure. Subsequent papers class of software we now call application enablers, in this issue will enlarge upon selected aspects and including the high-level languages and a variety of components of SAA and highlight the technical chal- other programming services. This software was a big lenges, trade-offs, and solutions involved in the im- step forward, since applications developed in high- plementation of this architecture. level languagesdid not have to deal directly withthe details of the hardware. But most largeapplications Background required additional, machine-specific support out- side these languages and so were still directly de- Perhaps the easiest way to understand howcross- pendent on the underlying hardware. The advances systems consistency Systems Application Archi- and in application enablers, combined with the enhance- ment of operating system software to provide so- phisticated “batch processing”for automated job scheduling, print spooling, and other aspects of sharedresource management, comprised the first major stage in the evolution of operating system Use of application enablers technology. became widespread. By the 1970s, the use of display terminals to access computing resources and data stored on line had become common, and technology had also made communication possible between systems. To sup- port thesechanges,systemsoftwareincreased in scope and provided interconnect facilities to tie sys- tecture will meet customer requirements and remove tems together. This, in turn, gave customers the constraints to their growth isto present an historical opportunity to bring key aspects of their businesses perspective on the evolution of IBM software. on line and interconnect processors throughout their businesses. Databaseand data communication prod- In the mid-l950s, the programs that existedwere ucts were the leading technology advances of this primarily application programs, executing the func- second stage operating system evolution. Together of tions for which acomputer was acquired. The hard- with interactive support for program development, ware manufacturer provided the hardware, and the this stage made the capabilities of computer systems customer, with the aid of rudimentary operating directly available to terminal operators. Computer systems and assemblers, wrote the software. Since resource sharing now had an on-line, interactive the application programs ran on the hardware di- interface that was extended to non-data-processing rectly, they were tiedto the instruction set or “archi- professionals as well as to industry personnel. tecture” of the hardware. By the late 1950s and early 1960s, hardware-oriented system software began to Today, technology has progressed the point where to emerge. This software, which was code could be that the need for application-enabling software is recog- shared by allcustomers, consisted primarily input- of nized and provisionhasbeen made forit.Such output routines. The routines operated card readers, enabling capabilityincludes management of data in punches, printers, tape devices, and, toward the end relational form, application-generation products, of this period, disk storage. In addition, high-level and display management, to name just a few. The languages, notably FORTRAN and COBOL, were intro- result is that application programshavebecome duced and offered the potential to ease greatly the largely insulated from the underlying software and task of programming. The net effect was to improve hardware. With the use of this application-enabling the productivity of application developers. But, for technology, the effort expendedin creating an appli- the most part, the applications of this periodre- cation is, by and large, directed at solving the prob- mained directly related to the specific hardware sys- lem, rather than fitting the solution to a particular tem on which they were running. hardware architecture or operating system. IBM SYSTEMS JOURNAL, VOL 27, NO 3, 198B WHEELER AND GANEK 251
  • 20. The structural changes just described occurred In contrast, because the application enablers for each throughout IBM’S product line. In the mid-l970s, system have evolved independently and have been each computer family and its operating system as a optimized for the system on which they run, appli- pair, alongwith the associatedset of application cations that use the enablers have also become seg- enablers, were optimized to a particular purpose, in mented by operating system. This condition limits terms of criteria such as performance, capacity, and the utility and increases the complexity of intercon- application environment (i.e., batch, interactive, or necting heterogeneous systems because dispar- of the transaction processing). Each was designedand built ity of the application environments across systems. to be the best-of-breed for its intended goals. Collec- If the needs of an installation grow beyond the tively, they allowed to move forwardto compete IBM capacity of a particular system, this segmentation across a broad range of markets by satisfying cus- makes it difficult to migrate up the product line. The tomer requirements at each point in the range. This same barrier applies to the migration of applications strategyproved to besuccessful and waswell-ac- that run on large systems when the need arises to cepted in the marketplace. replicate them on smaller, departmental systems. The result is that the IBM product line appears as a By the early 1980s, the span of computing power number of independent systems, each one offering from the smallest to largest machine in the IBM advantages withinits domain. product line had grown drastically.To provide com- petitive solutions across this increased range, several As we look forward to the end of this decade, hard- new environments were added. Today, in all of the ware technologyis expected to continue to improve major environments except the two smallest, per- at its historical rate of 20 to 25 percent per year. sonal systems and the System/36, the power of the Clearly, it is IBM’S goal to continue to position the hardware and the structure of the softwarehave product line to exploit fully this enormous range of progressed to the point where application enablers computing capability. As a result of this growth, we provide levels of function that are roughly equal and havearrived at a key point in the evolution of that have, by and large, insulated the applications systems software,one that affords the opportunity to from the hardware, although theyremain tied to the integrate key systems across the entire spectrum of operating system on which they run. processor power. In the case of the System/36, the structure of the Technology has progressed to the point where we software has reachedthe same point of evolution as can provide a full-function system, Operating Sys- the others, but the small size the system hasmeant of tem/2’” (os/zTM) Extended Edition, on the current that the depth of function has certain limitations. As line of intelligent workstations. This development an example, a relational database management sys- will enable the graphicspower of the intelligent tem is not available. In the IBM Personal Computer workstation to be combined on one system with the Disk Operating System (PC DOS), neither the struc- full set of operating system functions such as data- ture of the software nor the depth of function is base and communication facilities. The System/36 equivalent to what is found in the larger systems. and System/38 are replaced a new, unified system, by Applications on PC DOS are still largely tied to the the os/4ooTM operating system and ~ ~ 1 4 0 0 hardware, hardware, and some advanced application enablers that has the capability to support from four worksta- are either not available or limited in function. tions to more than four hundred, depending, of course, on the workload and configuration. This During the latter part of this evolution, the emer- system combines the ease of use of the System/36 gence of Systems Network Architecture (SNA) per- and the advanced software technology of the Sys- mitted the interconnection of any combination of tem/38, together with state-of-the-art hardware for these systems and communication with a variety of enhanced performance and capacity. third-party equipment. SNA also brought the capa- bility to more easilymanageextremelylarge net- These developments are undeniably important for works of interconnected systems. The benefits of the small and intermediate computing environ- interactive computing, coupled withthe connectivity ments. But it is equally important that, for the first of these networks, provide significant capability for time, there will be a full set of application enablers customers to bring together diverse aspects of their on all of our systems. By using the application ena- businesses for access a single terminal anywhere from blers to mask the underlying hardware operating and within the enterprise. system, the product line can be presented to cus- 252 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988
  • 21. tomers in a single coherent way from the smallest erating system environment on a personal computer intelligent workstation the largest System/370 ma- to today also offer a full realization of the potential of chines asa single family. Application developers can cooperativeprocessing. In cooperativeprocessing, begin to develop common applications that run on intelligent workstations used in conjunction with are host systemsin an integrated way to provide the end user with the advantages of both personal and host- based computing. Cooperative processing allows the user to have a single, seamless view of the function of an application, whereas, in fact,the implementa- SAA defines a consistent set tion is split between the workstation and the host. This implementation model is of key importance to of application enablers. SAA and will be addressed more depth later in this in article. Requirements To support a product line that spans an ever-increas- each system ofthe family, rather than being limited ing capacity range, more than one hardware archi- to a particular operating system or hardware archi- tecture and operating system will be required. Ex- tecture, thereby minimizing the effort required to actly how many are required and what part of the build such applications and to migrate users from range each can span may change over time as tech- one system to another. nology changes. Built on each of thesearchitectures and operating systems willbe a set of application To make this happen, SAA defines a consistent setof enablers matched to its system. When one considers application enablers that span the systems and min- the IBM product line, the broadest in the industry, imize the historical differences, making these appli- ranging from the IBM PC to the 3090 (which repre- cation enablers the unifying force for future. the sents a factor of about 1000 in performance), it is evident that multiple hardware architectures and The establishment of consistent application enablers operating systems are necessary. They are necessary across a family ofoperating systemsgoes wellbeyond today to allow customers to exploit this wide range the goal of portability of applications from one en- of capacity, and they will continue to be needed to vironment to another. When this consistency is com- exploit the expanded capacity of the future-capac- bined witha rich setof communications capabilities ity driven by technology improvements that, as in- and protocols for the interchange of data and for dicatedearlier, continue at rates in excess of 20 process synchronization, the family-of-operating- percent per year. Hardware architectures and oper- systems concept extends to a global environment in ating systems have natural limits, both upward and which interconnected systems concurrently partici- downward, and when forcedto operate beyond those pate in addressing the needs of the enterprise. The limits, do so either poorly or with difficulty. result is called an Enterprise Information System, which represents the third major stage of operating In IBM, the multiple hardware architectures and op- system evolution. Such an environment is a distrib- erating systems are well-positioned take advantage to uted system, and the programming functions that of the progress of technology. We face a different enable it are referred to as distributed services. The problem: how to present that technology in a con- implication of such a capability is that any system sistent way. Consistency acrossthe product line can in the family can interact with any other system by be achievedby making the interfaces of the software using the range of distributed services. Distributed consistentacrosshowever many implementations applications are thosewritten to exploit multiple are required to span the range. This mechanism system configurationsto satisfy a variety of require- works because software technology is now advanced ments, including specializedprocessingneeds and enough to have the interfaces for application ena- those motivated by geography,security,capacity, bling independent of the hardware,even on the availability, and organizational considerations. smallest and largest systems. Within this context, the technological advances in power and improvements in price/performance of The guidance necessary for defining an architecture personal computers that enable a full-function op- that meets the challenge of consistency across the IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988 WHEELER AND GANEK 253
  • 22. I Figure 1 General software structure 254 WHEELER AND GANEK BM SYSTEMS JOURNAL, VOL 27. NO 3. 1988
  • 23. product line can be obtained by identifying the key facturing automation, health-care systems, thou- and requirements for productive useof heterogeneous sands of others that deliver the solutions to problems data processing systems.Numerous IBM studies, cus- for which computers are used. tomer advisory councils, and user group meetings, as well as discussions with software vendors, have This software model, which began as an organiza- repeatedly determined three leading requirements in tional tool for high-end systems, has been mapped this area: against each of IBM’S major operating systems: Mul- tiple Virtual Storage (MVS), Virtual Machine/System Usability-the need for applications to be easier Product (VM/SP), os/400, and os/2 Extended Edition, and simpler to use and to learn and found to be generally applicable. The host sys- Productivity-the need for a straightforward and tem environments of MVS, VM, os/400support all and productive way to develop applications that op- of the key functions of the model, although in many erate across a variety of operating systems and cases with different interfaces.os12 supports most of thereby ensure a wider range of usefulness, ob- these functions; however,some either are not yet viating the necessity of rewriting applications to supported at this time or are not applicable, such as meet the demands of different environments Job Entry or Data Center Systems Management. Connectivity-the ability to connect systems and Despite these omissions, the model still applies to peripheral equipment in an easy and consistent os/2 Extended Edition, since the majority of func- way, supported with the tools necessary to manage tions are present, and the components it does have the interconnected environment simply and effi- can be structured according to the blue-, green-,and ciently yellow-layerapproach. The model not only simplifies the classification of products within the various sys- Structure tems, but provides a basisfordefining common elements across these operating systems to yield a Systems Application Architecture provides consis- common set of interfaces for application programs. tency across dissimilar operating systems. The cor- The idea of cross-systems consistency was developed nerstone of the definition of such an architecture is from this concept of a common framework giving a conceptual model that describes softwarestructure rise to common interfaces. in a generic way and provides a coherent organiza- tion of function. This model,shown in Figure 1, SAA uses the generic software structure model as a consists of four layers, each of which representsset a basic building block address the three key require- to or category of related functions. This structure pro- ments for cross-systems consistency. It does this by vides a foundation for understanding the strategic controlling three new specificationsthat relate to the elements of IBM software and how they fit together. requirements for consistency on a one-to-one basis The blue, or bottom, layer in the figure is software the and also by building directlyon the system structure uniquely related to the hardware. This software is model, as shown in Figure 2. As can be seen in the geared to manage and exploit the capabilities of the figure, the SAA components surround the software specifichardware and architecture forwhich it is structure in such a way as to provide consistent user, designed. Included in this layer are functions that programming, and communications access to the manage physical system resources such as memory, operating systems functions of each system-Mvs, disk storage, printers, and processor dispatching. The VM/SP, ospoo, and os12 Extended Edition. yellowlayerrepresents communications software, which provides the connectivity to allow communi- SAA is controlled by the specifications ofthe follow- cation among systems and applications and the abil- ing three elements: Common User Access,Common ity to manage the interconnection of systems. This Communications Support, and Common Program- software entails communication protocols and net- ming Interface. They are discussed below. work management. The green layer represents the products directly related to writing and executing Common User Access. The first component governs applications, also called the application-enabling the end-user interface and is called Common User products. Included in this category are services such Access (CUA). This interface controls how the system, as database, query and report writing, and transac- including the applications, interacts with a person at tion management, along with languages such FOR- as a workstation or terminal. It is this interface that TRAN and COBOL. At the top, the red layer represents ensures that the way things look to the user and the application software such as office systems, manu- actions required of the person by the system are IBM SYSTEMSJOURNAL, VOL 27, NO 3, 1988 WHEELER AND GANEK 255
  • 24. Figure 2 model Consistent interfaces built on system structure PROGRAMMERS MVS VMlSP END USERS o1 s2 256 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3. 1988
  • 25. familiar no matter whattasksareperformed. By providing a well-designed end-user interface for ap- plication programs, applications are made easier to portions of SNA and international standards. learn and easier to use. By making the end-user interface consistent across applications and across Included in ccs are the following facilities: systems, skill acquired with one application or on one system is usually transferable to other systems Data streams-Data streams govern the way in and applications. CUA provides the window through which data are handled and formatted whentrans- which the user views and accesses applications.The mittedovera communications link.They are enhanced ease of use the consistency it provides and provided in SAA for support of display devices, will augment the number of applicationsreadily document text, and printers. available to theuser. Application services-These services relate to services that enhance the function of the network. CUA is defined for the interaction between humans Examples includedistribution services that enable and computers. In dealing with how the machine asynchronous distribution of data throughout the communicates withpeople, it addresseswhat the network, protocols that define common office computer presents to the workstation operator, in- functions such as document interchange, and net- cluding screen layout, of color and highlighting, use work management. messages, and help information. Also important to Sessionservices-Theseservicesreflect the SNA CUA is how the user communicateswith the machine, Logical Unit (LU) Type 6.2 Advanced Program- which involves the keyboard layout and usage, the to-Program Communications protocol, which de- use of a mouse, scrolling, selection mechanisms. and fines a rich set of communications services along CUA is intended to provide a consistent and highly with a consistent programming interface on each usable framework forthe dialog betweenthe person of the SAA systems. and the machine that will result in continuity among Network-Thenetworkfacilityapplies to Low different applications and across the four SAA sys- Entry Networking Nodes (Type Nodes), which 2.1 tems. The guidelines and rules are developed to support peer-to-peer communication across nodes enhance ease of use,and the continuity achieved by in the network. pervasive application of these conventions will en- Data link controls-These controls provide link hance ease of learning. CUA is designed to take full usage and management disciplines such as Syn- advantage of the capabilities of the intelligent work- chronous Data Link Control (SDLC) for teleproc- station, which has the greatest capacity for a highly essing links, Token-Ring for local area networks, interactive user interface. Dependent workstations and x.25 for packet-switched networks. are also supported in the specification; however,the limitations of this technology will restrictthe use of The subject of Common Communications Support some of the dynamic features available intelligent on is explored in detail in the paper by Ahuja in this of workstations.CUA allows a framework consistency issue.’ to exist between these different kinds of workstations, while still encouraging full utilization of the potential Common Programming Interface.The third element of the intelligent workstation. with which cross-systems consistency is concerned is application enabling, addressed SAA by the Com- in Common User Access is discussed in greater depth mon Programming Interface(CPI). It specifies how a in the paper in this issue by Berry.’ programmer is write and attach a new application to to IBM’Sfamily of SAA systems. The application writer Common Communications Support. The second SAA uses this interface exploit the power ofthe system. to element controls the interconnect protocols and is Having such an interface allows applications to be called Common Communications Support (ccs). independent of the underlying system therefore, and, This interface deals with how systems work together to run on any system of the IBM SAA family, maxi- to accomplish a job. For example, it controls how mizing the return on investment in application code. systems communicate with one another to store, It is also valuable because an application program- retrieve, and move information through the com- mer can apply skill using theCPI across the whole at munications network. With consistent interconnect IBM SAA family-not just asinglesystem-vastly implementations provided by ccs, customerscan increasing productivity.This component of SAA de- build networks of systems with vastly differing ca- fines a set of application building blocks consisting IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988 WHEELER AND GANEK 257
  • 26. of languages and programming services for applica- face for Communications (CI) provides a consistent, tion programmers. It already contains a rich set of high-level programming interface for the LU Type published interfaces that will expand over time to 6.2 protocol for program-to-program communica- include an even broader spectrum of interfaces for tion. application enabling. The role played by the Common Programming In- The CPI language set provides consistentimplemen- terface in SAA is elaborated upon in the paper by tations of the most widely used languages that are Wolford in this issue.3 applicableacross the SAA system spectrum. The Cooperative processing As indicated earlier, the advance of technology has now permitted the cooperative processing modelto be employed cost-effectively for a wide variety of applications. Use of this model has many benefits Cooperative processing can now and is a key aspect of the SAA direction. The use of an intelligent workstation as an integral part of an be employed cost-eff ectively. application makes it possible to provide the appli- cation user with the most advanced and usable hu- man-to-machine interaction available in informa- tion systemstechnology. This capability includes advancedscreen-display techniques and windows, keystroke-initiated processing interactions, and high- performance use of graphics. By using these capabil- scope of the languagesetencompasseshigh-level ities in conjunction with host-system services, the languages, procedures languages, application gener- application can afford to offer the useraccess to ators, and expert systems. The number of products shared files, databases, transaction services, special- in this category is increasing as SAA requirements the ized computing functions, and peripheral equipment broaden. Included at this time are the COBOL, C, such as printers and plotters. Because the user per- FORTRAN, and RPG high-level programming lan- spective of the workstation/host interaction is made guages; the REXX procedures language; the Cross and transparent, the image of asingle application is System Product (CSP) application generator. Al- preserved, as depicted in Figure 3. Advanced com- though not supported at this time, expert systems munication support, the Common Programming In- technology is planned for inclusion in SAA in the terfacefor Communications, and multitasking in future. 0s/2 Extended Edition allow workstation users to concurrently utilize local applications that are writ- The services of the CPI provide key enablers for the ten for the personal computer and cooperative ap- development of portable and integrated applications. plications that exploit host-system services a con- in Central to the SAA direction is the relational database sistent way, with easy transitions from application accessed via the Structured Query Language (SQL) to application. standard database language. Complementary to the relational database is the QueryInterface that is Distributed processing usable by end users and programs to access relational data. The DialogInterfaceprovidesahigh-level, Aswe have seen, cooperative processing makes it programmable capability for defining displaying and possible to present an integrated and seamless view terminal screens that conform to the Common User of intelligent workstation and host-system capabili- Access specification. Mechanisms are provided that ties.AdvancedProgram-to-Program Communica- control the relationship betweenvariables in the tion (APPC) capabilities, as defined by the SNA L 6.2 u program and fields and selections as portrayed on protocol and accessed via CI, provide aconsistent the the screen.Navigation among multiple panelsis way to interconnect all of the SAA systems. This supported. The Presentation Interface enablesa interconnection allows application function to be lower-level control of screens and printers for text split acrossintelligent nodes in the network in a and graphic format display as well as multiple-win- general way, providing for the distribution of func- dow support; it is used in the implementation of the tion across multiple host systems well as intelligent as Dialog Interface.The Common Programming Inter- workstations. Consistent implementations of CI per- 258 WHEELER AND GANEK IBM SYSTEMS JOURNAL. VOL 27. NO 3, 1988
  • 27. Figure 3 Cooperativeprocessing HOST SYSTEMS IBM SYSTEMS JOURNAL, VOL 27. NO 3, 1983 WHEELER AND GANEK 259
  • 28. mit distributed application functions to be written an application program; it is the entire life cycle from independently of the system on whichtheywill conception and definition of the requirements to execute, allowing function to be distributed accord- production usage and ongoing maintenance. Major ing to the requirements of an enterprise and redis- improvements in productivity necessitate not only tributed asnecessary those when requirements enhancements to each phaseof the process, but also change to accommodate growth, reorganization,and a more comprehensive approach to the problem as consolidation. a whole. This approach in SAA will emphasize an integrated family of tools which providean applica- Built on the APPC base and the additional capabilities tion development environment to share program- of the Distributed Data Management (DDM) archi- ming objects throughout the life cycle.A key element tecture, generalized distribution of data throughout in such an approach is a common data repository a networkof heterogeneous systems be achieved. can affordingadvanced features for storing and retrieving Distributed data means that files and databases can such objects, for describing their attributes, and for be dispersed throughout the network, yet are acces- defining relationships among them. These capabili- sible by any program as if located on the local system. ties would allow information related to an applica- The remote location of the data is thus transparent tion to be created once and be shared throughout to the application program. The application program the product life cycle. invokes the same interfacefor SQL or high-level language record I/O operation regardless ofthe loca- The application development environment is an ex- tion of the data, and the appropriate communica- cellent candidate for utilizing cooperative processing tions processing is implicitly generated the case of in to achieve the best possible ease of use toexploit and remote data. The communications processing takes the value of local processing powerin an intelligent advantage of the ccs data formats, session protocols, workstationwhereverapplicable. Host facilities network management, and data link control facili- would be likewise used where appropriate, such as ties. for the data repository. Distributed relational data and distributed files are discussed in more depth in this issue in the papers Common applications by Reinsch4and Demers.’ The manifestation of the SAA concept is the set of Application development applications that exploit its principles to achieve its objectives. The characteristics of these applications, The value of applications that comply with SAA is called Common Applications, are directly derived enhanced because those applications from the principles of cross-systems consistency that we have explored in this paper. Such applications Are easier to learn and use as a result of the CUA execute on all the SAA operating systems, providing Execute in a broader range of processingenviron- consistent function across a vast range computing of ments as enabledby the CPI power. They adhere to the CUA specification to in- Interconnect that range of systems as needed via teract with people in a highly usable and consistent the ccs way. Similarly, where applicable, they utilize ccs the Utilize advanced technologies such as relational to effect interactions from system to system. They data and cooperative and distributed processing are also based on the CPI, which enables consistent function and implementation. Foremost design con- Attainment of these benefits depends on the creation siderations are integration and extensibility across of applications that take advantage of these features. the breadth of the enterprise they serve. Cooperative A critical aspect of the strategy to support SAA is to processing is emphasized wherever applicable en-to provide a set of tools that will greatly improve pro- hance the function, usability, and integration of the ductivity in the development process for such appli- application. cations. IBM is committed to deliver many such Common The program development process normally consists Applicationstargeted to support specific industry of a sequenceof stages,including requirements gath- requirements as well as cross-industryneeds. An ering, analysis design, code and development, system example of the latter is Office and Decision Support, integration and test, and maintenance. This se- which is analyzed in a case study in this issue by quence reflects more than just the construction of Dunfee et a L 6 260 WHEELER AND GANEK I M SYSTEMS X)(JRNAL. VOL 27, NO 3. 1988 B
  • 29. The objectives and value of Common Applications Flexible connectivity of heterogeneous systems as are as suitable for IBM’S customers and independent provided by ccs to allow the concurrent use ofthe software vendors as they are for IBM. The emphasis variety of computing capabilities inthe enterprise in an integrated and complementary way Consistent programming interfaces as provided by the CPI to allow application development to be independent of the system selection, programsto be portable from system to system, and program- As SAA evolves, the support of the ming skill expanded to be applicable across the systems in the enterprise Enterprise Information System will continue to expand. The Enterprise Information System support will be further enhanced by the advances in distributed processing that will facilitate transparency of location for data and function across the enterprise. This capability will help mask the complexity of the in- terconnected environment and will permit applica- on an open, published set of interfaces, protocols, tion programmers to focus more on the problem to and conventions is designed to encourage customer be solved. Continued emphasis on network and sys- and vendor participation. tem management tools as well as consistent security mechanisms across the scope of the Enterprise In- formation System will be required to minimize the Enterprise Information System effort to support and control the diverse systems in Cooperativeprocessing,advanced communication the enterprise. facilities, distributed data, and Common Applica- Conclusion tions permit an end user, through the window of the intelligent workstation, to access all of the capabili- In summary, Systems Application Architecture de- ties available in the network to which that worksta- fines I B M S solution to achieve cross-systems consis- tion is attached. Notonlyarediversecapabilities tency. It provides an architectural framework for a accessible, but the complexity of the interconnec- familyof operating systems that spans the three tions is not apparent. This environment, concep- orders of magnitude in the range of power of com- tually depicted in Figure 4, i; the Enterprise Infor- puting hardware now offered in IBM’S product line. mation System, a central theme in SAA. The objective SAA achieves the framework via an extensive set of is to provide enterprise-wide solutions to business published protocols, interfaces, conventions that and problems by extending the scope of applications to give rise to Common Applications, which are port- span multiple systems, from workstations to mid- ableacrossdiverse environments; this setmakes range systems mainframes, that may be geograph- to possible the interconnection and integration of these ically dispersed. This objective allows an enterprise environments. SAA provides a consistent, state-of- to install and configure information processing sys- the-art userinterface to achieve the bestpossible tems according to the needs of the business, includ- usability. ing organizational,geographic, and historical factors, while still achieving the integration so vital to pro- SAA is evolving,continually encompassing a broader ductivity and effectiveness. scopeover time in order to keeppacewith the advances of technology in both hardware and soft- As SAA evolves, the support of the Enterprise Infor- ware. Its goal, however, remains the same-to pro- mation System will continue to expand. The key to vide the base of usability, consistency, and connec- the success of this direction is the cross-systems tivityrequired to makeuse of programming re- consistency foundation: sources and user experience most effectively, thereby increasing productivity and protecting software in- Consistent userinterface as defined by CUA to vestment. SAA brings a comprehensive unificationto allow consistent human interaction with infor- IBM’S family of systems, providing access an enor- to mation processing facilities across entire scope the mous spectrum of processing power via architec- an of the enterprise, enhancing ease of use knowl- and ture that is available now and is the base for expan- edge transfer sion in the future. IEM SYSTEMS JOURNAL, VOL 27, NO 3. 1988 WHEELER AND GANEK 261
  • 30. Figure 4 Enterprise Information System MID-RANGE LARGE 262 WHEELER AND GANEK IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988
  • 31. Personal System/2 is a registered trademark, and AS/400, Oper- ESA/370. In June 1983, Mr. Ganek was named development ating System/2, OS/2, and OS/400 are trademarks, of Interna- manager of the MVS System DesignDepartment, involving work tional Business Machines Corporation. on a variety of advanced technology activities. In 1985, he was appointed manager of MVS Design and Performance Analysis, where he was responsible for technical plan and content of the the Cited references MVSbase control program future releases and, in1986, was promoted to program manager.Later that year, Mr.Ganek joined 1. R. E. Berry, “Common User Access-A consistent and usable the Information Systems and Storage Group staff as a technical human-computer interface for the SAA environments,” IBM assistant. In 1987, he went to the Corporate Programming Staff, Systems Journal 27, No. 3, 281-300 (1988, this issue). where he contributed to a number of efforts concerning IBM’s 2. V. Ahuja, “Common Communications Support in Systems programming strategy and Systems Application Architecture. He Application Architecture,” IBM Systems Journal 27, No. 3, began his current assignment in June 1988 and is responsible for 264-280 (1988, this issue). VM/XA Advanced Systems direction, design, planning, and prod- 3. D. E. Wolford, “Application enabling in SAA,” IBM Systems uct introduction support. Journal27, No. 3, 301-305 (1988, this issue). 4.R. Reinsch, “Distributed database for SAA,” IBM Systems Journal 27, No. 3, 362-369 (1988, this issue). 5. R. A. Demers, “Distributed files forSAA,” IBM Systems Reprint Order No. G321-5323. Journal 27, No. 3, 348-361 (1988, this issue). 6. W. P. Dunfee, J. D. McGehe, R. C. Rauf, and K. 0. Shipp, “Designing SAA applications and user interfaces,” IBM Sys- tems Journal 27, No. 3, 325-347 (1988, this issue). Earl F. Wheeler IBM United States, 2000 Purchase Street, Pur- chase, New York 10577. Mr. Wheeler is IBM Vice President and General Manager, Programming Systems. He joined IBM as a junior engineer in 1957 in Endicott, New York. Throughout his career, he has played a significant role the development of IBM’s in products. During the late 1960s, he was responsible the systems for management of intermediate processors suchas the Model 40and Model 50 of the IBM System/360 and the emerging System/370 Model155. During his assignment as Laboratory Director in Kingston, New York,in the early1970s,he directed the early formulation of Systems NetworkArchitecture. As Systems Devel- opment Division Vice President of Industry Systems, and Vice President, Communications Systems Division, in the mid-I970s, Mr. Wheeler directed product management for all of IBM’s com- munication products, including the 3270 displays, 370X multi- plexors, and industry terminals. During this period, he was instru- mental in managing the convergence of the IBM communications product line to support SNA. As Assistant Group Executive, Systems Development, Information Systems and Technology Group, in the early1980s,hewasresponsible for the product strategy for all System/370 systems software. Mr. Wheeler came to Corporate Headquarters as IBM Director of Programming in 1984 and was elected IBM Vice President, Programming, in 1985. In his current position, he is responsible directing the worldwide for development of IBM’s application-enabling software product of- ferings and is the chief architect of SystemsApplication Architec- ture. Alan G. Ganek IBM Data Systems Division, P.O. Box 100, Kingston, New York 12401. Mr. Ganek is manager of VM/XA Advanced Systems. received hisMS. in computer science from He Rutgers University in 1981. He joined IBM as an associate pro- grammer in 1978 in Poughkeepsie, New York. Hisfirstassign- ments involved the implementation of the MVS operating system software support for the cross-memory and 370/XA architectures. In 1981 he joined the MVS System Structure Technology depart- ment, wherehe contributed to the definition of the Enterprise System Architecture/370 leading to a first patent award. He later became team leaderfor the MVSsoftware support design for IBM SYSTEMS JOURNAL, VOL 27, NO 3, 1988 WHEELER AND GANEK 263
  • 32. IEEE Std 1471 and Beyond∗ Rich Hilliard ConsentCache, Inc. rh@ConsentCache.com January 1, 2001 Overview It achieves this by being based upon a conceptual framework for architectural description (see figure 1). I describe the key contributions of IEEE Std 1471 to the The breadth of this framework is worth appreciating discipline of software architecture representation. After relative to current work in architectural research and reviewing the contributions of IEEE 1471, I discuss how practice. To my mind, much of this work has focused on we (the community interested in Software Architecture) what are portrayed as Models in the conceptual frame- may build upon the foundation provided by IEEE 1471 work, including architecture description languages, and to continue to improve and disseminate techniques for related tools. While important, much of this work lacks architectural description. a larger context needed in most practical, industrial- (Although three pages is insufficient to give a strength applications. By reifying notions like Stake- useful example of an IEEE 1471-conformant archi- holders and Concerns, the IEEE 1471 framework sug- tectural description, there are a number of ap- gests a basis for dealing with these wider issues in a plications of IEEE 1471 in the literature. Visit theory of architectural description. the IEEE Architecture Working Group web site (http://www.pithecanthropus.com/˜awg) for links.) Content Requirements on ADs The content requirements of IEEE 1471 are stated in IEEE Std 1471 ... the terminology of the conceptual framework. These requirements define what it means for an architectural IEEE Std 1471–2000 is IEEE’s Recommended Practice description (AD) to conform to the Standard. The prin- for Architectural Description of Software-Intensive Sys- ciples underlying these requirements are briefly summa- tems [7]. To my knowledge, this is the first formal rized here. standard to address what is an architectural descrip- ADs are interest-relative: The audiences for an AD tion (AD). It was developed by the IEEE Architec- are the various stakeholders of the system, each with ture Working Group with representation from industry, specific concerns (such as security, performance, or con- other standards bodies and academe, and was subject structability) for the architecture. An AD should be to intensive reviews by over 150 international reviewers, explicit in addressing these stakeholders. Therefore, an before its publication this past Fall. AD must explicitly identify the system’s stakeholders IEEE 1471 establishes a set of content requirements and their concerns for the system. on an architectural description (AD) – a collection of Concerns form the basis for completeness: An products to document an architecture. As such, the AD must addresses all stakeholders’ concerns. If it does Standard plants a stake on how ADs should be orga- not, it is by definition, incomplete. nized, and their information content, while: (i) ab- Multiple views: An AD is organized into one or more stracting away from specific media (text, HTML, XML); views. Each view is a representation of the entire sys- (ii) being method-neutral (it is being used with a vari- tem of interest intended to address a particular set of ety of existing and new architectural methods and tech- stakeholder concerns. niques); and (iii) being notation-independent, recogniz- Although the use of views is hardly new with ing that many diverse notations are needed for recording IEEE 1471, its contribution is to motivate the use of various aspects of architectures. views (the source of much hand-waving in the Software ∗ Position paper for SEI’s First Architecture Representation Architecture literature) with respect to addressing spe- Workshop, 16–17 January 2001. cific concerns of specific stakeholders. 1
  • 33. Figure 1: IEEE 1471 Conceptual Framework Views are modular: A view may consist of one or fied stakeholder concern must be addressed by one of more architectural models. the selected viewpoints. To satisfy the concerns to be addressed by a partic- Viewpoints are first-class: Each viewpoint used in ular view, multiple notations may be used. This is one an AD is “declared” before use (either “in line” or of the several places where IEEE 1471 is “parameter- by reference). A viewpoint declaration establishes the ized” to accommodate the wide range of best practices stakeholders addressed by the viewpoint; the stake- in Software Architecture modeling. holder concerns to be addressed by the viewpoint; the Inter-view consistency: An AD must document any viewpoint language, modeling techniques, or analytical known inconsistencies among the views it contains. methods used therein; and the source, if any, of the This is a fairly weak requirement – based on current viewpoint (“prior art”). A viewpoint may also include: consensus; I imagine as a community we can do much any consistency or completeness checks associated with better in the future (see below). the underlying method to be applied to models within the view; any evaluation or analysis techniques to be Views are well-formed: Each view has an underlying applied to models within the view; and any heuristics, viewpoint identifying a set of architectural concerns and patterns, or other guidelines which aid in the synthesis specifying how the architectural description meets those of an associated view or its models. concerns, using languages and notations, models, ana- This principle is perhaps the primary contribution of lytical techniques and methods. A viewpoint is a set of IEEE 1471 – to provide a means by which the many conventions for constructing, interpreting and analyzing architectual techniques in use today may be uniformly a view. described so that they may be used by others, compared This is another “parameter” in IEEE 1471. Orga- and combined. nizations may define and select their own set of useful viewpoints. In fact, IEEE 1471 does not even specify a fixed set of viewpoints; the Standard is “agnostic” ... And Beyond about where viewpoints come from. Instead, the fol- lowing principle is employed: In addition to codifying best current practices in archi- Concerns drive viewpoint selection: Each identi- tectural description, a goal of the IEEE for the develop- 2
  • 34. ment of IEEE 1471 was to provide a foundation for the Formalization. The conceptual framework of continuing evolution of the discipline of Software Archi- IEEE 1471 is an informal, qualitative model. If it tecture. To conclude this position paper, I briefly note is useful, which appears to be the case, it may be a few opportunities of this kind. insightful to attempt to formalize the concepts therein. Such a formalization could have benefits in several of the topics just mentioned: viewpoint reuse, view Reuse. Viewpoints, being system-independent, are checking, view integration, and inter-view analysis. highly reusable. The viewpoint construct is intended Finally, there are another set of advanced topics in to facilitate capture of one important kind of architec- architectural description barely addressed by today lan- tural knowledge: when to apply given representational guages and tools. See [6] for discussion. mechanisms to address particular stakeholder concerns [5]. However, very little of present architectural knowl- edge is captured in this fashion. For example, there is References much work in the academic literature on modeling archi- tectures via components, ports, connectors, roles, and [1] Alexander Egyed and Rich Hilliard. Architectural their configurations which might be termed a “Struc- integration and evolution in a model world. In tural Viewpoint.” By having a clear viewpoint declara- Bob Balzer and Henk Obbink, editors, Proceedings tion, it would be easier to apply this knowledge more Fourth International Software Architecture Work- uniformly. One useful role for organizations like SEI shop (ISAW-4), 4 and 5 June 2000, Limerick, Ire- would be to serve as a repository for reusable view- land, pages 37–40, 2000. points. [2] Rich Hilliard. Using the UML for architectural de- scription. In Robert France and Bernhard Rumpe, View Checking. IEEE 1471 is essentially silent on editors, UML ’99 The Unified Modeling Lan- the issue of checking or analysis of individual views, guage, Second International Conference, volume except to say that a view must be well-formed with 1723 of Lecture Notes in Computer Science, pages respect to its viewpoint – delegating the checking to 32–48. Springer, 1999. any technique associated with the viewpoint. Viewpoints will vary in their rigor, associated ana- [3] Rich Hilliard. Views and viewpoints in software sys- lytic techniques, etc., which may be brought to bear on tems architecture. Position paper from the First checking a view. By having uniform declarations it may Working IFIP Conference on Software Architecture, be possible to “lift” techniques developed for one nota- San Antonio, 1999. tion to use with others. See [2] for a discussion of this [4] Rich Hilliard. Views as modules. In Bob Balzer in the context of use of the various notations of UML. and Henk Obbink, editors, Proceedings Fourth Inter- national Software Architecture Workshop (ISAW-4), View Integration and Inter-view Consistency. 4 and 5 June 2000, Limerick, Ireland, pages 7–10, It has been long recognized that introducing multiple 2000. views into architectural descriptions leads to an inte- [5] Rich Hilliard. Three models for the description of ar- gration problem – how does one keep views consistent, chitectural knowledge: Viewpoints, styles, and pat- non-overlapping? terns. Submission to WICSA-2, January 2001. Complex specifications require structure, such [6] Rich Hilliard and Timothy B. Rice. Expressiveness as different segments for different concerns. in architecture description languages. In Jeff N. However, different concerns also lead to dif- Magee and Dewayne E. Perry, editors, Proceedings ferent notations. ... [T]his leads to a multiple- of the 3rd International Software Architecture Work- view problem: different specifications describe shop, pages 65–68. ACM Press, 1998. 1 and 2 different, but overlapping issues. [8] [my em- November 1998, Orlando FL. phasis] [7] IEEE. Recommended Practice for Architectural De- The introduction of viewpoint declarations, while not scription of Software-Intensive Systems, October solving the problem, gives us a tool for detecting over- 2000. laps and inconsistencies, and potentially a substrate for [8] Mary Shaw and David Garlan. Software Architec- solving the integration problem. See [3], [4], [1] for three ture: Perspectives on an emerging discipline. Pren- different suggestions for tackling the view integration tice Hall, 1996. problem. 3
  • 35.   Architecture = Abstractions over Software Eyðun Eli Jacobsen Bent Bruun Kristensen Palle Nowack The Maersk Mc-Kinney Moller Institute for Production Technology University of Southern Denmark/Odense University, DK-5230 Odense M, Denmark e-mail: {jacobsen, bbkristensen, nowack}@mip.ou.dk Abstract Design of software architecture is seen as abstraction over the software domain, and describing architecture is considered to be a modeling process. A general view of a modeling process is presented and illustrated in the context of application domain modeling and of software domain modeling. The implications of this perspective are investigated in order to capture objectives and concrete forms of architectural descriptions. The consequences of this perspective on architecture are characterized. 1: Introduction In every software system, some architecture is present. The problem is that architecture is only implicitly available. The architecture did exist for developers during the design phase, but because it was not expressed explicitly, the architecture either has been lost, or has only been reproduced to some extent in software documentation. The consequences of the architecture are present in terms of the properties and qualities of the software. Software Architecture. Software architecture is defined in various different ways. [9]: “Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components. Such a system may in turn be used as a (composite) element in a larger system design.” [3]: “A software architecture is a description of the subsystems and components of a software system and the relationships between them. Subsystems and components are typically specified in different views to show the relevant functional and non-functional properties of a software system. The software architecture of a system is an artifact. It is the result of the software design activity.” [10]: “An architecture integrates separate but interfering issues of a system, such as provisions for inde- pendent evolution and openness combined with overall reliability and performance requirements. An archi- tecture defines guidelines that together help to achieve the overall targets without having to invent ad hoc compromises during system composition.” [1]: “The software architecture of a program or computing system is the structure or structures, which comprise software components, the externally visible properties of those components, and the relationships among them.” [8]: “Architecture means style or manner of building”. For a software system we interpret software architec- ture to mean the actual choice of architectural abstractions and language mechanisms, especially abstraction mechanisms, and the actual use of the elements chosen, i.e. how they are combined, their iterations, varia- tions etc.” In a brief characterization of these definitions of software architecture we claim that these describe orga- nization only, not abstraction. We distinguish between organizing and abstracting: If we organize a certain ¡ This research was supported in part by Danish National Centre for IT Research, Project No. 74.
  • 36. domain, we only put some kind of order in the domain, among the elements in the given domain. The result is that the elements are grouped, sorted, or otherwise related to each other according to different possibly overlapping organization principles. If we abstract from a certain domain, (may be in general for abstrac- tion and not only conceptual abstraction) we create new quot;conceptsquot;/elements in another domain, an abstract domain. The elements in the new domain describe the elements in the former domain, and the relations among elements in the former domain. By moving to another domain we create knowledge about the former domain, and not just order. The concepts/elements of the new domain carry information about the former domain. The architecture of some software is a model of the software. In this article we focus on conceptual models of software. A model is conceptual in the sense that it forms a conceptual understanding of something, and that it is based on concept formation in terms of classification, generalization and aggregation. Consequences: Abstractions over Software. Our thesis is that software architecture is abstractions over the software domain. Some immediate consequences of this thesis include that (1) The software must have been produced or at least be anticipated, i.e. the software domain must exist in some form. The software domain is given by descriptions — focus during architecture design is on these descriptions. The result of design are concrete/abstract descriptions (notation/diagrams) in addition to the software domain. But there is no given sequence — architecture may be created as a prescription of some anticipated software. (2) Architecture descriptions appears to be redundant descriptions. Because the software domain is available architecture design seems to be an additional and even redundant description. The challenge is to clarify why it is necessary to elaborate on the software description, to make an understanding / a mental model explicit, and to create abstractions over the software domain. (3) Architecture design requires abstraction. Abstraction implies, in addition to organization and delimita- tion, formation of concepts at another abstraction level together with use of the concepts at that level. We abstract from irrelevant details and concrete matters, given selected perspectives. But we have to find, in- troduce, and motivate the abstractions (and the perspectives). Enough experience in architecture design and insight in the given application is necessary to be able to come up with suggestions for the right abstractions, and to decide which are the correct and promising ones. (4) The nature of abstractions over the software domain is still partially unexplored and unfamiliar. In our abstractions in object-oriented modeling the descriptions are concrete — abstract matters are related to problem and the usage domains. Abstractions over the software domain are different — probably more abstract and unreal. The challenge is to clarify the essence of software abstractions, and specify the quality measure for abstractions. (5) The architecture design process must be covered by software development methodologies. Architecture is only superficially introduced, usually only mentally, because of lack of support of this in methodologies. Architecture design is difficult, and because architecture design is not covered by methodologies the general situation is that we have little experience, no very good examples or prototypical cases. Methodologies do not promote (acceptance of) reuse of design — reuse of code is still the rule. Article Organization. In section 2 we establish the necessary background for the perspective on soft- ware architecture to be discussed in section 3. In subsection 2.1 we briefly discuss a model of the domains and views in the design phase in the software development process. In subsection 2.2 we elaborate on an underlying model of abstraction processes in relation to software development processes. In section 3 we discuss consequences of architecture seen as abstractions over the software domain. We characterize the process-related and the notation-related aspects, and we propose principles governing architectural design. In section 4 we summarize the contributions of this article.
  • 37. Problem Domain Model System Domain Model Development Domain Model Usage Domain Model System User Developer Problem Domain Usage Domain Development Domain System Domain Figure 1. Domains and Models 2: Abstraction 2.1: Domains and Views In Figure 1 we illustrate the domains and models from an abstract generalized model of the software development process (the domains and models discussed in the following are a revised and more complete model than the model from [5]). In the analysis phase the problem domain model and usage domain model are constructed from the problem domain and usage domain through a cooperation between user and devel- oper. In the design phase the developer in the development domain uses the usage domain model to refine the problem domain model into a system domain model. The domains and models illustrate the vision during the system development process — as such they reflect the understanding according to the current iteration. The focus point in the illustration is the system to be developed. The system illustrates the concrete system — the actual, real system. The system is going to be used by some user. As such the system is part of the usage domain. The system takes care of some tasks in relation to the problem domain. The user has an understanding of the problem and usage domains — namely the models of these domains. When the user operates the system these models form the universe of the operations, their state and their results. The concrete form of the problem domain model and the usage domain model can be respectively [2]: object diagrams, class diagrams, use case diagrams, interaction (sequence and collaboration) diagrams, state chart diagrams, and activity diagrams. The system is going to be developed by some developer. As such the system is part of the development domain. The developer is part of the development domain — the model of this domain is implicitly given only (that is why the model has dotted lines). The system domain is the actual resulting software that comprises the system at the very concrete level. The system domain is the actual software. The system illustrates the software and everything else that is needed to make it a running system. The system domain model forms the developer’s conception of the integration of the problem and usage domain models at an abstract level. It is a refined, transformed and enriched problem domain model. The concrete form of the system domain model can be [2]: object diagrams, class diagrams, interaction (sequence and collaboration) diagrams, state chart diagrams, activity diagrams, component diagrams, deployment diagrams. Most of the diagramming techniques are the ones known from object-oriented analysis. When applying them to describe the system domain model we apply them differently: the objects and classes are of a more technical nature (not necessarily representing problem or usage domain phenomena and concepts); they belong to the software domain; they have more rigorously defined properties. As a result of the changed perspective on the objects and classes, the applications of diagrams in the description of a system domain model also has a more technical nature. In addition to these diagrams we can also specify or sketch designs in an object-oriented programming language. Depending on the goal of the description, the described code can act as a vehicle for communicating ideas or as a basis for a prototype implementation. The system domain model also supports the usage of the system, and not only the conception of the problem domain. The usage of the system is seen from two different points of view — the user’s and the developer’s.
  • 38. Problem Domain Model System Domain Model Development Domain Model Usage Domain Model Interface Components Functions & Model System Connectors User Developer User’s System View Developer’s System View Figure 2. System Views Figure 2 elaborates further on the distinct views on the system from the user and developer. The user view supports the understanding in terms of the problem and usage domains. The system operates on a model of the problem domain, based on some functions that support the identified usage patterns captured by the usage model, through an interface that exposes the functions according to the user’s capabilities etc. The developers view supports the understanding in terms of the system domain model. This understanding is controlled and supported by the development domain (model). The system is organized as a collection of components and connectors of very general nature. The actual organization of these reflects the functional and non-functional requirements to the system1 . The architecture model (Figure 3) is an abstraction over the system domain model. The architecture model forms the developer’s conception of the architecture of the system, i.e. the overall structures and their relations and interactions. The model focuses for example on structure and interaction embedded in the system domain model. The purpose of the architecture model is to understand the system domain model given a various selected perspectives on that model, to allow us to reason about and expose the support of non-functional requirements in the software, and to map the system domain model onto the logical platform. The system domain model includes descriptions, partial or complete, of software. Various kinds of design notations are used. Architecture Model Components & Connectors: Components Interface Logical & Connectors Functions Abstraction Components Model & Physical Connectors System Model Developer’s System View Figure 3. Abstraction and Components/Connectors In Figure 3 the architecture model is shown as a logical model — an abstraction over the system domain model. We call the system domain model a physical model because this is how the model of the system 1 The functional requirements is a set of requirements concerning the capabilities of a system — what the system should be able to support. The non-functional requirements is a set of requirements concerning qualities not related to the functionality of the system — for example usability, security, efficiency, correctness, reliability, maintainability, testability, flexibility, understandability, reusability, portability, adaptability. The logical platform is a description of the platform on which the system is going to be executed but at a logical level — i.e. requirements in terms of user interface, distribution, persistence and concurrency.
  • 39. domain is represented. The physical model is the basis for various additional models — logical models, because they express various understandings of the system domain model. The logical models together form the architecture model. In Figure 3 the models at both levels are illustrated as collections of components and connectors. Components and connectors should not be seen literally. The idea is only that at a certain level any description of a model can be seen as some specialized kinds of components and connectors. Also we have indicated that both components and connectors can be seen as structures with three ingredients, namely interface, functions and model, where each of these are recursively collections of components and connectors. The result of the design phase is not a model of some existing domain similar to the problem domain or the usage domain — the system domain is non- or only partial existing during the development process. Rather, the system domain model is a unique design, something constructed and created by the developer based on his skills and knowledge (the development domain), and from the problem and usage domain models. After its construction the system domain architecture models both works as models in addition to the problem and usage domain models, but from specific design perspectives. The problem and system domain models are the foundation for creating the architecture. The usage model is used during the design for controlling the transformation of the problem domain model into the system domain model. The usage model, together with the functional requirements, supply the information for adding and distributing the functionality to the problem domain model to the extent that this information is not already there. The architecture model is a constructive solution for how the non-functional requirements and the organization of the logical platform can be combined. 2.2: Abstraction and Modeling. The Nature of Abstraction. We discuss nature and purpose of abstraction — both in general, abstract terms and in terms specific to abstraction over the software domain. We distinguish between referent system and model system. The referent system is the domain we observe — the quot;realquot; world (even though it may be imaginary). The model system is the product we construct in the form of some explicit representation of the abstract model. We observe phenomena in the referent system, and we classify these by concepts also in the referent system. Figure 4 illustrates the referent and model systems. It includes the modeler and the perspective applied on the real world. The connections between the elements in the domains in the referent system and the model system are indicated by means of dotted lines. A number of more or less well defined notions within abstraction exist for concept formation in the referent system. These include among others classification, generalization and aggregation (and dual or inverse notions of these). When we observe phenomena in the referent system we always apply a perspective. The perspective determines which properties we choose to include in our abstract model — properties form concepts. Figure 4. Worlds, Perspectives & Models The purpose of abstraction is to understand. If we do not abstract, we only see a wilderness of different
  • 40. phenomena in the referent system. Applying concepts, we put order in chaos, so that we can understand the referent system. The concepts expresses our understanding — but always relative to a chosen perspective. The model describes the referent system phenomena and concepts, but it is not the referent system. And it is not a mirror image of the referent system. The model is a simplification, but more important the model expresses only one out of many possible interpretations of the referent system. It is necessary to introduce simplifications, and to focus on certain aspects of the referent system, in order to expose the understanding given the perspective. Else understanding drowns in details irrelevant to a perspective. Observation of phenomena is collective in the sense that several persons usually can agree upon that they observe some phenomena. However, conception of phenomena is subjective. Concepts formed mentally by observers are individual. By expressing the concepts explicitly in some notation they become collective in the sense that several people can discuss and understand the model — they share the understanding expressed through the model. The perceived concepts are subjective. The explicit model expressed in some notation may also be subjective, but it can be shared. Under given circumstances we can agree that the model is objective. That the model is objective, does not imply that it is fair or realistic. The perspective alone determines to which extent the model should reflect certain aspects of the referent system or not. It is not an overall goal to obtain any specific kind of correspondence between the model and the referent system. The success criterion for the model is to which extent it exposes the intention of the model as prescribed by the perspective. Perspectives are not formal specifications. In practice perspectives are not even fixed during modeling. They are developed together with the model. There is always a more or less precise expectation to the intention of the model. It may be intuitively clear what is important and what is not. But as the modeling process evolves with various candidates for concepts and properties of these, the perspective becomes visible too. At the end of the process the best explanation of the perspective may be the model itself. Specialization & Domain of Aggregation & Generalization Concepts Decomposition Exemplification Classification Domain of Phenomena Figure 5. Abstraction Processes We apply this general understanding of the nature and intention of abstraction when software architecture is seen as abstractions over software. The software is our referent system. We can all observe the software, and we can identify various kinds of phenomena in the software. We have to choose perspectives in order to guide the abstraction process. We can observe software either as program description or as program execution. The latter is typically a sequence of snapshots — infinitely many in general. Executions are controlled by means of input to the execution in a broad sense. The program description captures (statically) all (dynamic) executions and thus all sequences of snapshots. Program description can be seen as an abstraction over sequences of snapshots — a classification of these. Sequences of snapshots can be seen as exemplification of the program description. This abstraction (program description) is different in nature from the architectural abstractions we discuss in this article. In short program description is obtained by classification of program executions (e.g. sequences of snapshots) — executions are obtained by exemplifying program description (by having a generator work on the description). Program description and execution are bound to the same domain — the same referent system. Figure 5 illustrates the abstraction processes in conceptual modeling. Conceptual modeling can be seen as
  • 41. the underlying theoretical understanding of object-oriented programming although existing object-oriented notation only in a limited way supports this theory. The processes are fundamental abstraction processes. In object-oriented programming an object/class can be seen as a model of a phenomenon/concept — to give the class of an object corresponds to classification — to give an object of a class to exemplification. To let a (specialized) class inherit from a (general) class corresponds to form a specialization of that (general) class. To describe a (whole) class by use of references to (part) objects corresponds to form an aggregation of (part) objects. Software Development. Two significant and distinct application of abstraction can be identified in the software development process. In Figure 6 both these abstraction processes are shown and related. Figure 6. The Abstraction & Modeling Diagram During analysis we build models in order to make explicit our understanding of the problem and usage domains. We describe phenomena and concepts from the problem and usage domains with diagrams and code from the software domain. The problem and usage domains form the reference system and the software domain form the model system. During design we build models in order to make explicit our understanding of the envisioned software. We describe phenomena and concepts from the software domain with diagrams and additional notation from the architecture domain. The software domain forms the reference system and the architecture domain forms the model system. The illustration should be considered static; we do not impose any ordering of the described processes. Any practical development effort alternates between analysis and design. Instead we focus on the involved domains and abstractions. Whether we perform analysis or design we experiment with different concepts (and thus phenomena) in order to come up with suitable models. Many issues constrain the validation of the suitability of the models. A constraint of vital importance in object-oriented development is that the models formed during analysis are reflected in the models formed during design. To sum up Figure 6 contains two instances of the referent and model system — the model system of the left instance is also the referent system of the right instance. In the following we describe the two instances in more detail. Figure 7 illustrates the analysis perspective on software development. During analysis we form concepts over the problem and usage domains. We model these with object-oriented entities. Classes model concepts and objects model phenomena. In our object-oriented model, classes can be considered to specify the objects. Once the model has been established we understand and interpret the referent system in terms of the identified objects. Objects and classes are well-known mechanisms in notations for model systems. Other mechanisms such as references, subclassing, etc. are used to model notions from the referent system. In general a transforma- tion is necessary from the referent system to the model system. In general notation lacks mechanisms that directly support a lot of natural conceptual notions from the mental model. Such notions must be simulated by the transformation. Efficient and understandable representations of such notions in the common object paradigm are important.
  • 42. Figure 7. Analysis Phase: Functionality Figure 8 illustrates the design perspective on software development. During design (and implementation) we form concepts over the software domain — such concepts do not categorize anything from the problem and usage domains (at least only indirectly). The software domain is the reference system. The model system explicitly describes the phenomena and concepts from the software domain. Many different perspectives can be applied to form a software model; we discuss only architectural models of the software domain. Concepts formed over the software domain include design patterns [4], architectural patterns [3], com- ponents, connectors, and architectural styles [9]. Architectural descriptions seek to describe such concepts in a rigorous way. The descriptions specify representations of architectural phenomena, that facilitate the interpretation and understanding of the software domain. However, there is still no established conceptual framework for describing such concepts, and there is still a lack of support for describing architectural mod- els. Figure 8. Design Phase: Architecture In general the description of a model system is supported by our available language (or notation). The language reflects the conceptual framework through which we understand the model. The language can be formal or partially informal. 3: Architecture Static and Dynamic Aspects. We discuss static and dynamic aspects of software architecture. One dimen- sion of static and dynamic aspects is the distinction between (static) description of a system (the program) and (dynamic) execution of it (snapshots with state and state transitions).
  • 43. Description and Execution. Architectural information is obtained by abstracting over either the descrip- tion or the execution. In Figure 9 we illustrate the description to the left. The description is some representa- tion of the program. It is static — at least we postpone the discussion of the case where the program changes during the execution of it. To the right we illustrate a sequence of snapshot of the execution of the program (description). Each snapshot has some state, and transitions (simple or compound) take the execution from one snapshot to the next. The transitions are not discussed further, the dynamics is represented only through the selected sequence of snapshots. The snapshots are seen as sequences (for simplicity reasons only) — tree structures reflect various alternatives during execution in a natural way. Model Model Model ... Model Perspective Perspective Perspective Perspective ... Developer ... ... Program Description Program Execution Figure 9. Description & Execution For each snapshot the architecture can be described. By external stimuli, and as time goes by, the system makes transitions to a sequence of snapshots — each with an architecture. When we describe the architecture of a single snapshot we are describing the architecture of a static thing. But when we describe the architecture of a running program we are describing the relation between several snapshots. Several types of information can be obtained by applying different perspectives for the abstraction. The same architectural abstraction can be observed from both the description and the execution, but it will be expressed differently. In the execution the interaction among objects and object structures are in focus, while in the description the interaction is embodied in methods and classes — furthermore, in the description, there are many language mechanisms which are use to express something about the execution of the program, but do not themselves exist at the time of execution, and these language mechanisms can be subjects for architectural descriptions. 3.1: Process. The Description Process. First the interaction with the real world is defined. The system is treated as a black box. The execution is in focus. Next the overall system organization and interaction are defined. The system is treated as a white box. Still the focus is on the execution. From the understanding of the dynamic situations a description in the form of program/diagram is produced, together with abstract views of this. Characterization: Process of Architecture Design. ¢ Architecture design is innovative construction, not just modeling or transformation. Design of archi- tecture is not just modeling: There are no existing phenomena in the software domain to model (like in the analysis phase, where the developer can take the starting point in problem and usage domains). Design of architecture is not just transformation: There is no existing model available (like in im- plementation where the model resulting form the design has to be transformed into another model at programming language level). In practice innovative processes give problems both because they are difficult and expensive, and also because they are hard to control and administrate.
  • 44. ¢ Architecture design implies abstraction, not just organization. By organization we mean the process of arranging and relating subparts of wholes. This resembles aggregation and association to a large extent. Abstraction includes organization in the sense that chunks of substance have to be identified and delimited. But abstraction also involves classification and generalization — a given chunk is classified according to various existing or new concepts — the concept is related to other concepts. In addition the abstraction is thereafter treated at its abstract level. In practice it is straightforward to organize material. During that process we get some knowledge about the material. But by organization only we more or less just view information at the given level. To obtain important knowledge, we have to abstract. Abstraction is much more demanding than organization. 3.2: Notation. Characterization of Styles & Patterns. It is possible to characterize architectural styles and patterns by their static and/or dynamic nature: The Layer pattern [9] is a static style because it is unusual that a concrete layered structure is changing, whereas the pipes & filters pattern is a dynamic style, because the actual Pipes and Filters [9] and their structure vary during execution. Architectural Abstractions. Architectural abstractions over the software are (to a certain extent) depen- dent of the notation used for the software [8], but application domain independent. Architectural abstractions can be supported by means of patterns [4], frameworks [7] and architecture notation/languages (AL’s) [9]. Both pattern and framework technologies are powerful means of capturing abstractions over the software domain. Still the notation used for the representation of these is usual object- oriented notation — we simulate the architectural description. Only preliminary elements of specific archi- tectural notation/languages are available, and the understanding of the necessary expressive power of such a notation/languages is mainly captured through architectural styles (pattern-like abstractions at architecture level) [9] and [3]. Characterization: Notation of Architecture Design. ¢ Architecture notation can be informal. Any notation supports thinking of and description of solutions and models, but it also introduces limitations. To be innovative we need expressive freedom, for example by use of informal notation. In practice we seem to prefer complete/formal specifications, and we need to include all details also concerning architecture. Only with a formal notation the power of reverse engineering can possibly be obtained. ¢ Architecture notation can be several notations. During the innovation of a model several notations can be applied simultaneously, possibly to various partial models such that each of these models can be expressed in a special notation (for example type of diagrams). In addition, models can be created from different perspectives — often overlapping and containing redundant information. Redundancy supports understanding. In practice several notations and corresponding models introduce an incon- sistency problem. It is much more convenient with one unifying (but insufficient) notation, and it is much more straightforward to handle one unifying model. By different perspectives we usually intro- duce conflicting models to be resolved, and ultimately we have to choose among perspectives, or go through a complicated process to integrate and unify perspectives. 3.3: Principles. Characterization: Principles of Architecture Design. ¢ Architecture must be developed explicitly. The elements included in methodologies for architecture design are still preliminary. The result of the design is not described explicitly. Architectural design is still immature — our understanding of abstraction over software is still insufficient. The evolution process where architectural abstractions and abstraction mechanisms of architectural languages are developed further by mutual influence has not really started — it has started with architectural styles
  • 45. and patterns, but languages are still not available. In practice we mostly describe architecture implicitly as an integrated part of other models. When it is actually explicitly described/illustrated, it is usually done in object-oriented languages, as it is the case for design patterns and frameworks. Architectural abstractions are typically related to problem and the usage domains. The abstract world over the software domain is not explored in praxis. ¢ Architecture design must be supported by tools. Principles are usually (at least partially) supported by tools. Tools rely on notation. Because there is no unifying notation and the notation is partially informal, etc. tools for architecture design are not very powerful — they are more like simple drawing tools. In practice tools constitute the principles (and define praxis) in many organizations. Tools are important for process, notation and documentation standards. 4: Summary Design of software architecture is presented as abstraction over the software domain. Given this perspec- tive we characterize architecture according to process, notation and principles. This theoretical characteriza- tion represents a research point of view of architecture design. The main characteristics of architecture in this article are: 1) architecture is a model of the software domain, 2) architecture makes explicit some properties of the software and lets us reason about these properties, 3) architecture is in principle independent of the problem and usage domains. References [1] L. Bass, P. Clements, R. Kazman, K. Bass. Software Architecture in Practice. Addison-Wesley, 1998. [2] G. Booch, J. Rumbaugh, I. Jacobsen. The Unified Modeling Language User Guide. Addison-Wesley, 1999. [3] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. Wiley & Sons, 1996. [4] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [5] E. E. Jacobsen, B. B. Kristensen, P. Nowack: Models, Domains and Abstraction in Software Development. Proceed- ings of International Conference on Technology of Object-Oriented Languages and Systems, 1998. [6] E. E. Jacobsen, B. B. Kristensen, P. Nowack, T. Worm: Software Evolution: Prototypical Deltas. Proceedings of International Conference on Technology of Object-Oriented Languages and Systems, 1999. [7] R. E. Johnson, B. Foote: Designing Reusable Classes. Journal of Object-Oriented Programming, 1988. [8] B. B. Kristensen. Architectural Abstractions and Language Mechanisms. Proceedings of the Asia Pacific Software Engineering Conference, 1996. [9] M. Shaw, D. Garlan: Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, 1996. [10] C. Szyperski: Component Software. Beyond Object-Oriented Programming. ACM Press/Addison Wesley, 1998.
  • 46. Handbook of Software Engineering and Knowledge Engineering 1 Software Architecture RICK KAZMAN Software Engineering Institute, Carnegie Mellon University 4500 Fifth Ave., Pittsburgh, PA 15213, USA Email: kazman@sei.cmu.edu Software architecture is a rapidly growing sub-area of research and practice within software engineering. The foundation of any large software intensive system is its architecture. This artifact describes how the system will accomplish its tasks, how the development work will be broken down, how quality goals will be met, and much more. Because of its central importance, an architecture needs to be carefully designed and carefully analyzed, particularly in light of its ability to meet its quality requirements, such as performance, availability, security, and modifiability. The technical and business implications of an architecture need to be fully understood. And, in cases of legacy systems, the architecture of an existing system may need to be reverse engineered. Keywords: software architecture, architecture design, architecture analysis, architecture representation, reverse engineering 1. Historical Introduction Software architecture is a burgeoning field of research and practice within software engineer- ing. Or, to be more precise, the architecture of large, software intensive systems has been the subject of increasing interest for the past decade. What accounts for this surge of interest in a field that, until about 1990 was unheard of? To begin, the field did not spontaneously create itself in 1990. But that time-frame was when the term “software architecture” began to gain widespread acceptance and when the field first attracted substantial attention from both industry and the research community (e.g. [40], [34]). The field was created out of necessity. Software systems were growing larger: systems of hun- dreds of thousands or even millions of lines of code were becoming commonplace. Clearly the foundations of the ideas underlying the field that is today called “software architecture” were laid by Parnas, Brooks, Dijkstra and others in the 1960s through the 1980s ([4], [11], [13], [32], [33])—but what changed is that by the 1990s such large systems were becoming common. The pervasiveness of such huge systems meant that they needed to be understood and man- aged by ordinary skilled engineers. These systems were no longer solely the province of a se- lect few virtuosos [39]. Fundamentally, there are three reasons why software architecture is important to large, com- plex, software intensive systems: 1. Communication among stakeholders. Software architecture represents a common high- level abstraction of a system that most if not all of the system’s stakeholders can use as
  • 47. 2 Software Architecture a basis for creating mutual understanding, forming consensus, and communicating with each other. 2. Early design1 decisions . The software architecture of a system is the earliest artifact that enables the priorities among competing concerns to be analyzed, and it is the artifact that manifests the concerns as system qualities. The trade-offs between performance and se- curity, between maintainability and reliability, and between the cost of the current devel- opment effort and the cost of future developments are all manifested in the architecture. 3. Transferable abstraction of a system. Software architecture constitutes a relatively small, intellectually graspable model for how a system is structured and how its components work together; this model is transferable across systems; in particular, it can be applied to other systems exhibiting similar requirements and can promote large-scale reuse. These reasons will form the basis for the structure of this chapter. I will discuss how an archi- tecture affects the stakeholders of a system, as well as an organization and its business goals. I will discuss how architecture is a vehicle for communication, and hence how it is documented and represented are of critical interest. And I will talk about how an architecture, as the repos- itory of the first and deepest, most profound decisions about a system’s structure, needs to be design and analyzed with due diligence. So what is a software architecture? Definitions abound (the Software Engineering Institute’s web site [37], which collects definitions of software architecture, currently boasts over 60 of them), but I will use the one from [4], which represents a reasonably centrist view: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Note the key elements of this definition: • Architecture is an abstraction of a system or systems. It represents systems in terms of abstract components which have externally visible properties and relationships (sometimes called connectors, although the notion of “relationships” is more general than connectors, and can include temporal relationships, dependencies, uses relationships, and so forth). • Because architecture is about abstraction it suppresses purely local information; private component details are not architectural. • Systems are composed of many structures (commonly called views). Hence there is no such thing as “the” architecture of a system, and no single view can be appropriately represent anything but a trivial architecture. Furthermore, the set of views is not fixed or prescribed. An architecture should be described by a set of views that support its analysis and communication needs. 1. It should be noted that I use the word “design” to mean any constructive creative process. Architecture is the application of this creative process at the highest level of abstraction.
  • 48. Handbook of Software Engineering and Knowledge Engineering 3 These points will be discussed in detail in the remainder of this chapter. For the moment, how- ever, note that in almost every case where someone is interested in a software architecture they are also interested in a system architecture. 1.1. Related Terms The term “architecture” is currently in vogue. People talk about their business architecture, the operational architecture, their information architecture, their process architecture. By these uses of the term architecture they typically mean “structure”, or “organizing principles”, and nothing more in much the same way that news reporters will refer to the “architect” of a crime. However, some uses of architecture are related to the definition above. For example, a “refer- ence” architecture is commonly found in many domains. A reference architecture is a set of domain concepts mapped onto a standard set of software components and connectors. For example, the domain of compiler construction has a well-known reference architecture, which details the gross chunks of functionality (lexical analysis, syntactic analysis, code generation, optimization, etc.) mapped onto a set of components arranged as a pipeline [39]. Modern in- formation system architectures consist of a database, business logic, and a user interface mapped onto a 3-tier client-server structure. 2. Architecture and Its Effects on Stakeholders Although an architecture is a technical description—an engineering blueprint—of a system, it affects everyone involved with the system. Each stakeholder of a system—customer, user, project manager, coder, tester, etc.—is concerned with different characteristics of the system that are affected by its architecture. For example, the user is concerned that the system is us- able, reliable and available; the customer is concerned that the architecture can be implement- ed on schedule and to budget; the manager is worried (in addition to cost and schedule) that the architecture will allow development teams to work largely independently, interacting in dis- ciplined and controlled ways; the developer is worried about achieving all of those goals through coding; the tester wants to prove (or disprove) that these goals will be met. Architecture provides a common language in which different concerns can be expressed, ne- gotiated, and resolved at a level that is intellectually manageable even for large, complex sys- tems. Without such a language, it is difficult to communicate and comprehend large systems sufficiently to make the early decisions that influence both quality and usefulness. 3. Architecture as Communication Vehicle Architectures serve as a communication vehicle in two ways. The first way is that they are a common abstraction of the system, and so provide a convenient lingua franca—a language
  • 49. 4 Software Architecture that all stakeholders can speak and understand. Stakeholders often have different back- grounds (they may be managers, users, customers, testers, implementors, administrators, op- erators, etc.) and so have widely different views on what the system is or will be and how they perceive and interact with it. Many experiences with software architecture analysis have noted how reviewing a software architecture with a large number of different stakeholders allows their concerns to be aired in a common understandable language, often for the first time ([1], [5], [27]). The second way that architecture serves as a communication vehicle is that it is a technical “blueprint” for the system that is to be built, modified, or analyzed [20]. While this aspect of architecture is not more important than the first, it is less obvious and intuitive, so I now turn to that in more detail. 3.1. Architectural Structures In a house, there are plans for the structure of the house, the layout of the rooms, for electrical wiring, plumbing, ventilation, and so forth. Each of these plans constitutes a “view” of the house. These views are used by different people. The electrician primarily uses the wiring view. The carpenter primarily uses the structural view. Each specialist uses their own view to achieve different qualities in the house. The carpenter is primarily interested in making the walls straight and square and in assuring that joists are of sufficient strength to support the floors. The electrician is primarily concerned with providing appropriate electrical capacity in convenient locations, and in doing so in such a way as to safeguard the house’s occupants. But each of the specialists may need to consult other views than their primary one: the electrician must ensure that when he drills a hole through a wall or joist that this hole doesn’t compromise the structural properties of the house, or interfere with a location where a water pipe might need to run. As with houses, architectural structures must be used as both a description and prescription, must be used by multiple stakeholders. While the architect designs the overall structure of a computational system, many specialists will refine and implement each of the views. Common architectural structures include (e.g. see [27] and [40]): • functional (or logical) view • code view • development (or structural) view • concurrency (or process/thread) view • physical (or deployment) view The precise number, names, and types of these views are still a subject of some debate, and not a particularly interesting debate at that. Some specific guidance on architectural documen- tation is beginning to appear (e.g. [3]). For the purposes of making architectural documentation concrete in this chapter, I will briefly illustrate each one. For each one I will say what its com-
  • 50. Handbook of Software Engineering and Knowledge Engineering 5 ponents and connectors (or relationships) are, who uses it, and what it’s good for (what kind of reasoning it supports). 3.1.1. Functional View The functional view is an abstraction of system functions and their relationships. The compo- nents of the functional view are: functions, key system abstractions, and domain elements. The connectors or relationships between components found in the view are dependencies and data flow. The users of the view are domain engineers, product-line designers, and end users. These stakeholders think about this view in terms of what the functionality is, how data flows among the pieces, and what variability of functionality the architecture should support. The reasoning that is supports is, thus, decisions about what functionality should be in the architecture, the modifiability of the architecture (because part of modifiability depends on how functionality is partitioned with respect to the anticipated future changes [27]), product lines/reusability, tool support, and the allocation of work to various groups. For example, one might create a data- base group, or a transaction management group, or a user interface group in response to iden- tifying such functionality as important in this view. An example of a purely functional view is shown in Figure 1. This is a decomposition of an in- teractive system into its functional elements. Dialogue Virtual Toolkit Virtual Application Presentation Application Fig. 1. Functional View Example — The Arch/Slinky Metamodel 3.1.2. Code View The code view is what the programmer sees. Thus the components of this view are things like classes, objects, procedures, and functions, and their abstraction/composition into things like subsystems, layers, and modules. The connectors/relationships are again what a programmer sees—calls and method invocation—as well as containment relations like is-a-sub-module-of. The users of this view are programmers, designers, and reusers (who are also typically pro- grammers and/or designers). They use this view to reason about modifiability/maintainability, portability, and subsetability (the ability to field a subset of the system’s functionality without making major changes to its code).
  • 51. 6 Software Architecture An example of a pure code view is found in design patterns [15], as exemplified in Figure 2. WindowKit CreateScrollBar() CreateWindow() MotifWindowKit MSWindowKit return CreateScrollBar() CreateScrollBar() new MSWindow CreateWindow() CreateWindow() return new MotifWindow Fig. 2. Code View Example — The Abstract Factory Design Pattern Pure code views are seldom found in practice. In fact, pure views of any sort are seldom found in practice. What is more useful is showing one view mapped onto another. Code views typi- cally show the mapping of functionality onto code structures. 3.1.3. Development View The development view is another view that the developer sees, but it is distinct from the code view. It is a view of the structure of the source code as a repository that various users (pro- grammers and maintainers) create, modify, and manage. The components of this view are typ- ically files, and directories (although other organizations are possible, such as keeping all source files in a database). The main relationship between these files and directories is con- tainment. The users of the development view, in addition to programmers and maintainers are managers and configuration managers. These stakeholders use the view to reason about the modifiability/maintainability of the system (see [27] or [5] for examples of this), for dividing up the development and testing of the system, or for configuration management/version control. An example of the development view is shown in Figure 3. This view shows a greatly simplified view of the hierarchical structure of the directories and files comprising a physics simulation system. The top level directory is “Physics3D”. Sub-directories are advection, chemistry, gen- erator, etc. Each directory contains the source and the header files for that sub-system. This
  • 52. Handbook of Software Engineering and Knowledge Engineering 7 view provided a focus for the system’s stakeholders in determining division of labor, testing, integration, and maintenance. Physics3D hydro Wall.c advection CreateMatrix.c Wall.h History.c FormMatrix.c ... Variables.c Slide.c parallel Faces.c ... Comm.c Zones.c io Comm.h ... ChemInput.c Elements.c chemistry ChemInput.h ... Reaction.c MatInput.c slide Reaction.h ... InitSlide.c ReactionType.h materials InitSlide.h ... AlumModel.c PreProcess.c generator AlumModel.h ... BuildObjs.c ReactiveFlow.c thermal BuildObjs.h ... HeatGen.c BuildSlide.c obj HeatGen.h ... Boundary.c ... Fig. 3. Development View Example — A Physics Simulation System 3.1.4. Concurrency View When a complex system is deployed, it is typically packaged into a set of processes or threads which are deployed onto some computational resources. The concurrency view is a necessary step for reasoning about what processes or threads will be created and how they will commu- nicate and share (or compete for) resources. So the components of this view—processes and threads—interact with each other via data flow, events, and synchronization on shared resources. The users of this view are people who worry about deploying the system, who are concerned with the performance and availability of the system, as well as integrators and testers. This view is used to reason about perfor- mance, availability, and deployment. An example of a concurrency view is given in Figure 4. This view shows how a part of an air traffic control system is organized to provide high availability to the system [8]. Processes are triply replicated and clustered into groups of “operational units”. As it happens, each process in an operational unit is allocated to a different processor, but that information is intentionally omitted in this view. Operational units are organized into client-server relationships. Operation- al units consist of PAS (primary address space) processes and SAS (standby address space) processes. The primary process sends data by data management messages to its secondar- ies so that they are synchronized with its state. In the event of a failure, one of the SASs is
  • 53. 8 Software Architecture “promoted” to become PAS. Note that this view says nothing about what each operational unit’s function is or how processes are allocated to processors. This separation of concerns is intentional. Operational Unit Client SAS PAS SAS Standby Standby data mgt data mgt Service Service request response Operational Unit Server PAS SAS SAS Standby data mgt Fig. 4. Concurrency View Example — An Air Traffic Control System 3.1.5. Physical View The physical view of a system describes how the system is deployed in terms of its hardware resources. For small, trivial systems this description is equally trivial: there is a single computer on which all processing is done. But for large, complex systems there may be a myriad of sen- sors, actuators, storage devices, networks, and computers. The components are things like CPUs, sensors, actuators and storage. The connectors are typically networks or other communication devices (such as satellites or buses). The users of this view are hardware and system engineers who have to reason and worry about system de- livery, installation, and upgrade (in some cases doing upgrades while the system is still run- ning), as well as performance, availability, scalability, and security. An example of a physical view, adapted from [9], is shown in Figure 5. This figure shows a plethora of computers and interfaces to hardware devices (in this case sensors such as radar
  • 54. Handbook of Software Engineering and Knowledge Engineering 9 and actuators such as missiles) all connected by a LAN which is replicated to ensure that there isn’t a single point of failure in the communications network. Workstation Workstation ... Workstation Processor Processor ... Processor DB ... DB processor processor Standard interface unit Gun (electronic processor surveillance, counter- measures, Surface-to-air anti-submarine missile I/F warfare, etc.) interface Radar Surface-to director surface missile interface Video switch Plot and target extractor Torpedo processor Comm processor . . . . . replicated LAN . Fig. 5. Physical View Example — An Shipboard Command and Control System 3.2. Scenarios In addition to the above views of a software/system architecture, many architects use scenar- ios to annotate the architecture by tying the views together, as suggested by Kruchten [30]. What are scenarios? Scenarios are a brief description of a use of a system or a change to a system. They are often divided thus into two sub-categories: • use cases: sequences of responsibilities • change cases: descriptions of proposed changes to the system Scenarios are used: • to understand and validate the architecture, by allowing architects, designers, and programmers to “walk through” the architecture as it is affected by a scenario
  • 55. 10 Software Architecture • to communicate the architecture, particularly to those who have not had a major role in its creation • to tie the views together; as we have seen, views seldom occur in isolation. One view is typically mapped onto another view. Scenarios aid in this mapping process by providing a need to concretely realize some aspect of the architecture. • to understand the limits of the architecture, by seeing where it is difficult for the architecture to satisfy or be adapted to satisfy a scenario. So, for example, a maintainer might postulate a scenario like “Replace the middleware or com- munications infrastructure with one supplied by a different vendor” to understand the implica- tions of this change on the code view and the process view. A systems engineer might suggest a scenario such as “Half of the processors or servers go down during operation” or “The net- work fails during operation” to understand the implications of these failures on the performance or availability of the system. For example, here are some sample use cases for an embedded vehicle control system: 1. Change performance and handling parameters in the field, via the service program. 2. When the engine is not running, do not diagnose the presence of an engine oil pressure fault. 3. Override pre-set carburation parameters at run-time. These are anticipated uses of the system. In addition to these, the stakeholders will contribute a set of change cases, which represent their objectives for features and capabilities of the tool in the future: 1. Change devices and hardware configurations, including doubling the memory map or making a harness change. 2. Change the allocation of processes to processors, timing and priorities. 3. Port the user interface to WIndows CE. 3.3. Architecture Description Languages Hopefully by now you are convinced that architectural description is very important. It is central to an architecture’s success in being communicated from one stakeholder to another, being analyzable by describing the right information, and being actually built from the blueprints that the architectural descriptions represent. Because architectural description is so important, there have been many attempts to design specific languages to support this task (see [31] for a survey of architecture description languages, or ADLs). In fact, architectural description lan- guages have been both successes and failures. They have been successes in that many ADLs have been created and employed in both aca- demic and real-world projects. Each of these languages has concentrated on a different facet of architectural description and analysis (deadlock detection, consistency, completeness, real- time properties, etc.). This success has brought with it its own problems: since there is a pro- liferation of ADLs, there has arisen a need to exchange information among them. From this
  • 56. Handbook of Software Engineering and Knowledge Engineering 11 need grew ACME [18], an ADL specifically designed to be an architecture interchange lan- guage—a means for the many disparate ADLs to jointly describe an architecture and to jointly support many different kinds of analysis that are unique to specific ADLs. For example, if one wanted to analyze an architecture with respect to deadlocks and the meeting of real-time deadlines, one might need to consult two different ADLs, each of which supports one of these analyses. But then the process of ensuring that the architectural descriptions in each ADL are consistent either requires human intervention, and the potential for human oversight, or it re- quires a special-purpose translator to be written to map from one ADL to the other. The failure of ADLs is that none of them have been widely adopted. There have been some successes in specialized domains (see, for example, [4] where an ADL for describing object- oriented systems with real-time constraints is described), but these have been limited islands of success. All of this discussion, however, might be moot. The Unified Modeling Language (UML) [36] is being widely adopted by organizations to describe their object-oriented designs and is being extended (frequently in an ad hoc fashion) to describe architectural constructs as well. If it truly becomes a de facto standard for architectural description then at least the interchange prob- lem is trivially solved, and having a well understood, widely disseminated standard aids in communication of designs using this language. The UML is certainly not a panacea however. It was originally construed as a language to support object-oriented design and analysis, not as an ADL. As such, it does not include architectural concepts as first-class entities. It does not naturally support the successive refinement of designs, from architectural abstractions to any level of hierarchical refinement. And while many of its facilities can be tailored to be used to represent architectures, it is a big complex language and can be used by different architects in dramatically different ways. FInally, it is a relatively abstract language and thus it is not easy to communicate UML designs to non-technical people. Despite these problems, it is receiving a great deal of attention from practicing architects. For a critical evaluation of UML as an ADL, see [16]. 4. Architecture as Early Design Decisions A software architecture is a coherent, justified collection of a system’s earliest set of design decisions. These decisions, such as what style the system is composed of (client-server, pipe- and-filter, distributed objects, repository-centric, etc.) will affect much of what the system will become. These decisions will impose constraints on an implementation, e.g. all inter-process commu- nication is to be done via TCP/IP. These decisions will affect how system resources are allo- cated and arbitrated. And they will affect the tradeoffs that any system must necessarily make. The architecture will also affect the organization. There is almost always a strong correspon- dence between architectural structures and organizational ones. Why is this? Because archi-
  • 57. 12 Software Architecture tectural structures define coherent groupings of functionality and coherent sets of concerns. The concurrency view may suggest the need for a separate team that does performance plan- ning, modeling, and tuning. Or it may suggest the need for a team that worries about how sys- tem failures are detected and managed. Each of these teams might do their own analyses and require specialized tools, training, and knowledge. The code and development views also dic- tate system structure in terms of modules, sub-systems, or layers. These once again influence organizational structure. A module, sub-system, or layer represents a highly coherent set of functionality which suggests high internal coupling and low coupling to external entities. Con- way’s law [12] states that this must match the organizational structure because otherwise you will have information flows in the system that don’t match those of the organization. For exam- ple, the members of the database team typically know a great deal about each other’s code and internal interfaces. They likely only see the externally published interfaces from the user interface team or the telecommunications team. Human separation of concerns must match the software separation of concerns. To do otherwise is to burden the development team with the need to know too much about the details of the system. Thus organizational structure must match the architectural structures. Early design decisions made in the architecture may result in constraints on an implementa- tion. One such constraint is the choice of commercial components that can be easily integrat- ed. Although interoperability protocols exist, for the most part choosing any commercial component will affect the choice of what other components may be employed. For example, choosing Microsoft’s DNA (Distributed interNet Architecture) set of components (Windows NT, MS Transaction Server, Wolfpack, Distributed COM, MS Message Queue, MS SQL Server, etc.) will preclude, or at least make costly, the use of CORBA or Enterprise Java Beans com- pliant components [35]. Also the choice of an architectural style may make the use of some components difficult if they have widely divergent mechanisms for sharing data, passing con- trol, etc. [19]. An architecture’s earliest design decisions should center around the forms of its infrastructure: how components communicate, how they pass or share data, how they initialize, shut down, self-test, report faults, etc. When the computational structure—sometimes called a frame- work—for supporting these activities is built first (as suggested in [4]) then many benefits ac- crue. For one thing, there can be a working version of the system very early in its life cycle. The earliest version may do little other than start up and hum to itself, but it provides all the infrastructure for the sub-systems to work together. Many of these sub-systems can be imple- mented initially as stubs; simply reading their data from a file or always outputting the same values, or looking up their results from a table. As the system is developed, these stubs can be replaced by their fully functioning versions. This means that, over time, the system increas- es in fidelity. But having an early working version of the system is wonderful for team morale, increases customer confidence, allows for better estimation of progress by management, and means that integration and testing are continuous, rather than a risky “big-bang” activity late in the project.
  • 58. Handbook of Software Engineering and Knowledge Engineering 13 4.1. Architectural Styles I have mentioned the term “architectural style” several times in this chapter. Just what are these exactly? Early research in software architecture was motivated, in part, by the observa- tion that certain styles crop up over and over in practice in response to similar sets of demands. These styles, similar to object-oriented design patterns [15], but often higher abstraction cap- ture a recurring solution to a recurring problem. A style: • describes a class of architectures or significant architecture pieces, • is found repeatedly in practice, • is a coherent package of design decisions, and • has known properties that permit reuse. Shaw and Garlan first published a collection of architectural styles in [38]. Shaw and Garlan’s initial list consisted of: • independent components: communicating processes, implicit invocation, explicit invocation • data flow: batch sequential, pipe and filter • data-centered: repository, blackboard • virtual machine: interpreter, rule-based system • call/return: main program and subroutine, object-oriented, layered Others, such as Buschmann et al have augmented this collection [10]. There is no complete list of styles and there is no unique, non-overlapping list. Complex systems can exhibit multiple styles at once: styles overlap or can contain one another hierarchically. But each architectural style consists of at least the following information: • a set of component types (e.g., data repository, process, object) • a set of connector types/interaction mechanisms (e.g., subroutine call, event, pipe) • a topological layout of these components • a set of constraints on topology and behavior (e.g., a data repository is not allowed to change stored values, pipelines are acyclic) • an informal description of the costs and benefits of the style, e.g.: “Use the pipe and filter style when reuse is desired and performance is not a top priority More recently, the notion of Attribute-Based Architectural Styles (ABASs) [28] have added analysis reuse to design reuse, by joining together architectural styles and explicit analysis frameworks. 4.2. Architectures for Product Lines Another way in which a software architecture is a repository of critical early design decisions is that it is a reusable model which can become the basis for a product line. A software archi- tecture is an asset that an organization creates at considerable expense. This expense can
  • 59. 14 Software Architecture and should be reused. In fact, while other forms of reuse have historically shown little success, architecture-based product lines are proving to be a significant commercial success for many organizations. In fact, economics dictates that products be built in different ways than they were 10 or 20 years ago ([22], [6]). When creating a product line, new software engineering challenges are encountered that do not occur in single product developments. The creation and management of a set of core as- sets is both crucial to the success of the product line and is a major challenge, since a great deal of work goes into deciding which assets should be “core” and which should be “periph- ery”. The other major challenge in creating a product line is using the core assets to create products. In particular, new products will frequently require new functionality, and it must be determined if and how this functionality gets folded back into the core assets. The specific architectural challenges for a product line are twofold: managing the realization of quality attributes across instances of the product line and managing the variation in func- tionality while maintaining just a single architecture. The first problem challenges the architect to, for example, create a small, inexpensive, low-performance, uni-processor version of a product and a large, expensive, high-performance, multi-processor version using the same ar- chitecture. And the infrastructure to manage this variation cannot itself absorb too much of the system’s processing power. The second problem forces the architect to be able to accommo- date a wide variety of features or functions without changing the underlying model of how the system works. While these issues are by no means solved, a great deal of research and practical industrial experience shows that architecture-based software product lines can be efficient and econom- ical (e.g. [6], [9], [22]). 5. Architecture Design and Analysis If we accept the idea that an architecture is a key to an organization’s and a system’s success and if we accept that we should design and document this artifact carefully as a set of engi- neering blueprints, then we should also recognize that we need to analyze the artifacts that we have designed. We do this for several reasons: • to ensure that our design decisions are adequate to meet our quality attribute [21] goals; • to predict the quality attributes that the eventual system will possess; • to ensure that the system meets its stakeholders’ needs; • to make sure that the design decisions that are proposed are cost effective and bring maximal benefit to the organization.
  • 60. Handbook of Software Engineering and Knowledge Engineering 15 In short, we invest so much time and money in a software system that the architecture must be predictably competent. This is a characteristic of any mature engineering discipline: pre- dictability. How do we achieve predictability? How do they achieve it in other engineering disciplines? They achieve it through design reuse and through analysis reuse [39]. Design reuse at the ar- chitectural level currently takes two forms in today’s practice: object-oriented design patterns ([15], [10]), and architectural styles [38]. As described above, the notion of Attribute-Based Ar- chitectural Styles (ABASs) [28] have added analysis reuse to design reuse, by joining together architectural styles and analysis frameworks. 5.1. Architecture Based Design Using these building blocks, architecture based design can proceed as a true engineering ef- fort, rather than as an ad hoc process. As an example of a first attempt at this, the Architecture- based Design (ABD) Method [2] proposes a method for transforming a set of customer require- ments into an architecture for a system or a product-line, via a set of decompositions and re- finements. The ABD method begins, as do almost all software projects with a list of requirements relating to both functionality and quality attributes. It then recursively decomposes the architectural de- sign to meet these requirements. Each time it decomposes the design it assigns some func- tional requirements to design elements. It meets quality attribute requirements by associating architectural styles with these requirements and realizing those styles in the architecture. The design, as it evolves, concentrates on three architectural views: functional, concurrency, and physical. The creation of each of these views causes the architect to ask and answer questions of the design. These questions are typically posed as scenarios, which relate back to the requirements that spawned the process in the first place. The ABD method can be seen as a design-time realization of the ATAM, which will be presented next. 5.2. Architecture Based Analysis However an architecture design is done, it should be analyzed to ensure that the qualities that the architect has planned for the architecture can actually be realized. Several architecture analysis methods have been proposed, such as SAAM [27], ATAM [26], and SAA [5]. These techniques are all scenario based. They are scenario based because without scenarios it is difficult to precisely characterize a set of quality attribute goals. The software engineering com- munity does not understand, in any useful way, what it means to be modifiable, or available, or secure, or interoperable. So we substitute our lack of understanding of quality attributes with scenarios, which realize a specific quality attribute goals in a context: a stimulus, an environ- ment, and a response.
  • 61. 16 Software Architecture These architecture analysis methods analyze and “test” the architecture by generating a set of scenarios, and applying them to the architecture in much the same way that actual systems are tested or benchmarked by using standard simuli (a set of test cases as input), in the con- text of a standard operating environment (an execution platform, perhaps with a specified set of load or other environmental characteristics) that produce a set of responses (outputs) that are measured. The Architecture Tradeoff Analysis Method (ATAM), for example, realizes these activities with the following steps: Presentation: 1. Present the ATAM: the method is described to the assembled stakeholders (typically cus- tomer representatives, the architect or architecture team, user representatives, maintain- ers, administrators, managers, testers, integrators, etc.). 2. Present business drivers: the customer representative describes what business goals are motivating the development effort and hence what will be the primary architectural drivers (e.g. high availability or time to market or high security). 3. Present architecture: the architect will describe the proposed architecture, focussing on how it addresses the business drivers. Investigation and Analysis: 4. Map architecture to business goals: the architect and other key project personnel such as project manager or marketing/customer representative detail how the system’s quality attribute responses will map to value for the organization. 5. Generate quality attribute utility tree: the quality factors that comprise system “utility” (performance, availability, security, modifiability, etc.) are elicited, sub-categorized, spec- ified down to the level of scenarios, and prioritized. 6. Analyze architecture approaches: based upon the high-priority scenarios identified in the utility tree generation step, the architectural approaches that address those scenarios are elicited and analyzed (for example, an architectural approach aimed at meeting per- formance goals will be subjected to a performance analysis). During this step architectural risks, sensitivity points, and tradeoff points are identified. Testing: 7. Brainstorm and prioritize scenarios: based upon the exemplar scenarios, a larger set of scenarios is elicited from the entire group of stakeholders. This set of scenarios is pri- oritized via a voting process involving the entire stakeholder group. 8. Analyze architecture approaches: this step reiterates step 6, but here the highly ranked scenarios from step 7 are analyzed as test cases for the analysis of the architectural ap- proaches determined thus far. These test case scenarios may uncover additional archi- tectural risks, sensitivity points, and tradeoff points which are documented. Out-Briefing: 9. Present results: based upon the information collected in the ATAM (styles, scenarios, at- tribute-specific questions, the utility tree, risks, sensitivity points, tradeoffs) the ATAM team presents the results of the analysis to the assembled stakeholders detailing this in- formation and any proposed mitigation strategies.
  • 62. Handbook of Software Engineering and Knowledge Engineering 17 The fine details of this method are described elsewhere (see [26] and especially [24] for more exhaustive descriptions). The point is that techniques exist to analyze and evaluate the rami- fications of architectural design decisions before these decisions are committed to code and are extremely costly to change. These techniques are reasonably inexpensive and can be used at any point in the development life-cycle [1]. 5.3. Analyzing the Business Impacts of Architectural Decisions The benefits of a software system are only assessable relative to the business goals the sys- tem has been developed to serve. In turn, these benefits result from interactions between the system’s functionality and its quality attributes. Its quality attributes are, in most cases, dictated by its architectural design decisions. The architecture is thus not only the crucial artifact to study in making design tradeoffs but also the crucial artifact to study in performing cost-benefit analyses. A substantial part of this analysis is in determining the level of uncertainty with which we estimate both costs and benefits. A number of researchers have begun seriously considering how to link together business con- siderations with software analyses, employing methods from economics, such as portfolio the- ory and real-options theory ([42]). Although this kind of analysis is still in the early research stage, some methods and case studies already exist ([23]). 6. Architecture Reverse Engineering In this chapter I have discussed creating, documenting, and analyzing architectures. If these techniques are successful, then the architecture and the components that populate it will be one of an organization’s key assets for many years. This means that architectural mainte- nance becomes an issue, and one that is even more pressing over time than was the original creation of the architecture itself. But, in fact, maintenance begins from the day that an archi- tecture is first created. Why is this? If an architecture is designed with some property in mind (say, high performance or high reli- ability), then does this property hold for a system created from the architecture? The answer is: perhaps. Why can I not be more definite about this? Because there is, in general, no way of ensuring that the architecture that was designed is the architecture that is actually imple- mented. For this reason, it is important to include architectural conformance exercises in any mature architecture development practice. To do conformance implies either that you never allow an architecture’s realization to deviate from its specification, or (more likely) that you can extract an architecture from what you actually have built; to reverse engineer the system’s ar- chitectural structures from the individual atoms that are realized in code (procedure calls, method invocations, class definitions, inter-process communication, etc.).
  • 63. 18 Software Architecture There are additional reasons why you might want to reverse engineer a software architecture. An architecture’s documentation may not exist, or is lost, or erodes over time: • architectures may have never been documented, and the expertise needed for understanding the architecture lives only in the heads of employees who have left the organization • new products may be acquired for which no architectural documentation exists • the individual efforts of programmers may wittingly or unwittingly “erode” the architecture, by bypassing the abstractions that the architect designed For these reasons, it is often necessary to reverse engineer an architectural description from its existing assets (typically code and build files). There is no automatic process for doing this. It is an interpretive process that is carried out as an interactive dialogue involving an architect (or someone who can at least conjecture architectural structures from knowledge of the sys- tem or an examination of existing documentation) and a reverse engineering toolset [29]. Several such toolsets exist currently, such as ManSART [43], Dali [25], and the Philips toolset [29], and the Software Bookshelf [14]. Each of these toolsets has four major functions: extract- ing architectural primitives from a code base, storing the extracted information in a repository, visualizing the contents of the repository to the user, and manipulating the contents of the re- pository to reflect the architecture’s abstractions by applying a set of rules that map from the atomic extracted information to these abstractions. 7. The Future Software architecture is rapidly becoming a respected sub-discipline of software engineering. Many commercial organizations have created their own architecture organizations which act as internal consultants to other parts of the company, aiding in architectural specification, doc- umentation, analysis, and maintenance. This chapter has attempted to outline the highlights of the major software architecture practices. Of course, we can not expect to do much more than quickly introduce a set of topics in such a brief format, and provide references to the read- er for more information and motivation to want to go there. More exhaustive treatises on the subject exist (e.g. [4], [10], [22], [37], [38], [40]) and are being added to with increasing regu- larity. There have also been a number of attempts at predicting the future of software architecture (e.g. [17], [4]). These have listed areas such as architecture for dynamic systems, reflective architectures, architecture migration, and others as hot topics of research and practice for the future. One thing is for certain, however: as long as people continue to build large, complex, software-intensive systems then software architecture will continue to be of critical importance to the success of such systems.
  • 64. Handbook of Software Engineering and Knowledge Engineering 19 References 1. Abowd, G., Bass, L, Clements, P., Kazman, R., Northrop, L., Zaremski, A., “Recom- mended Best Industrial Practice for Software Architecture Evaluation”, Carnegie Mellon University, Software Engineering Institute Technical Report CMU/SEI-96-TR-025, 1996. 2. Bachmann, F., Bass, L., Chastek, G., Donohoe, P., Peruzzi, F., “The Architecture Based Design Method”, Carnegie Mellon University, Software Engineering Institute Technical Report CMU/SEI-2000-TR-001, 2000. 3. Bachmann, F., Bass, L., Carriere, J., Clements, P., Garlan, D., Ivers, J., Nord, R., Little, R., “Software Architecture Documentation in Practice: Documenting Architectural Lay- ers”, Carnegie Mellon University, Software Engineering Institute Special Report CMU/SEI-2000-SR-004, 2000. 4. Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison-Wesley, 1998. 5. Bengtsson, P., Lassing, N., Bosch, J., van Vliet, J., “Analyzing Software Architectures for Modifiability”, Hogskolan Karlskrona/Ronneby Research Report 2000:11, ISSN: 1103- 1581. 6. Bosch, J., Design and Use of Software Architectures, Addison-Wesley, 2000. 7. Brooks, F., The Mythical Man-Month -- Essays on Software Engineering, Addison-Wes- ley, 1975. 8. Brown, A., Carney, D., Clements, P., Meyers, C., Smith, D., Weiderman, N., Wood, W., “Assessing the Quality of Large, Software Intensive Systems: A Case Study.” Proceed- ings, European Conference on Software Engineering, Sept. 1995. 9. Brownsword, L., Clements, P., “A Case Study in Successful Product Line Development”, Carnegie Mellon University, Software Engineering Institute Technical Report CMU/SEI 96-TR-016, Carnegie Mellon University, 1996. 10. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern-Oriented Soft- ware Architecture: A System of Patterns, Wiley & Sons, 1996. 11. Clements, P., Parnas, D., Weiss, D., “The Modular Structure of Complex Programs”, IEEE Transactions on Software Engineering, Volume SE-11, No. 3, March 1985. 12. Conway, M., “How do Committees Invent?”, Datamation, April 1968, 28-31. 13. Dijkstra, E. W., “The structure of the ‘T.H.E.’ multiprogramming system,” CACM, vol. 18, no. 8, 453-457, 1968. 14. Finnigan, P., Holt, R., Kalas, I., Kerr, S., Kontogiannis, K., Muller, H., Mylopoulos, J., Per- elgut, S., Stanley, M., Wong, K., “The Software Bookshelf”, IBM Systems Journal, 36(4):564-593, 1997. 15. Gamma, E., Helm, R., Johnson, R., and Vlissides, J.; Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
  • 65. 20 Software Architecture 16. Garlan, D., Kompanek, A., “Reconciling the Needs of Architectural Description with Object-Modeling Notations”, Proceedings of the Third International Conference on the Unified Modeling Language, October, 2000. 17. Garlan, D., “Software Architecture: A Roadmap”, The Future of Software Engineering, A. Finkelstein, ed., ACM Press, 2000. 18. Garlan, D., Monroe, R. T., Wile, D., “Acme: An Architecture Description Interchange Lan- guage”, Proceedings of CASCON ’97, November 1997. 19. Garlan, D., Allen, R., Ockerbloom, J. “Architectural Mismatch: Why Reuse is So Hard”, IEEE Software, Nov. 1995, 17-26. 20. IEEE, 1999. Draft Recommended Practice for Architectural Description, P1471/5.2, December 1999. 21. International Organization for Standardization and International Electrotechnical Com- mission, Information technology — Software product evaluation — Quality characteris- tics and guidelines for their use, ISO/IEC 9216: 1991(E). 22. Jazayeri, M., Ran, A., van der Linden, F., Software Architecture for Product Families, Addison-Wesley, 2000. 23. Kazman, R., Asundi, J., Klein, M., “Quantifying the Costs and Benefits of Architectural Decisions”, CMU/SEI-2000-TR-0??, Software Engineering Institute, Carnegie Mellon University, 2000. 24. Kazman, R., Klein, M., Clements, P., “ATAM: A Method for Architecture Evaluation”, Car- negie Mellon University, Software Engineering Institute Technical Report CMU/SEI- 2000-TR-004, 2000. 25. Kazman, R., Carriere, S. J., “Playing Detective: Reconstructing Software Architecture from Available Evidence”, Automated Software Engineering, 6:2, April 1999, 107-138. 26. Kazman, R., Barbacci, M., Klein, M., Carriere, S. J., Woods, S. G., “Experience with Per- forming Architecture Tradeoff Analysis”, Proceedings of the 21st International Confer- ence on Software Engineering (ICSE 21), (Los Angeles, CA), May 1999, 54-63. 27. Kazman, R., Abowd, G., Bass, L., Clements, P., “Scenario-Based Analysis of Software Architecture”, IEEE Software, Nov. 1996. 28. Klein, M., Kazman, R., Bass, L., Carriere, S. J., Barbacci, M., Lipson, H., “Attribute- Based Architectural Styles”, Software Architecture (Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1)), (San Antonio, TX), February 1999, 225-243. 29. Krikhaar, R., Postma, A., Sellink, A., Stroucken, M., Verhoef, C., “A Two-phase Process for Software Architecture Improvement”, Proceedings of ICSM’99, (Oxford, UK), Sep- tember 1999. 30. Kruchten, P., “The 4+1 View Model of Architecture”, IEEE Software, Vol 12, No. 6, November 1995.
  • 66. Handbook of Software Engineering and Knowledge Engineering 21 31. Medvidovic, N., Taylor, R., “A Classification and Comparison Framework for Software Architecture Description Languages”, IEEE Transactions on Software Engineering, 26(1), January 2000, 70-93. 32. Parnas, D., “On a ‘buzzword’: hierarchical structure,” Proceedings IFIP Congress 74, 336-3390, 1974. 33. Parnas, D., “On the Criteria To Be Used in Decomposing Systems into Modules”, Com- munications of the ACM, 15(12), December 1972, 1053-1058. 34. Perry, D., Wolf, A., “Foundations for the study of software architecture”, SIGSOFT Soft- ware Engineering Notes, 17(4), October 1992, 40-52. 35. Roman, E., Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition, Wiley, 1999. 36. Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual, Addison-Wesley, 1998. 37. SEI Software Architecture, http://www.sei.cmu.edu/ata/ata_init.html. 38. Shaw, M., Garlan, D., Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996. 39. Shaw M., “Prospects for an Engineering Discipline of Software”, IEEE Software, 7(6), Nov 1990, 15-24. 40. Shaw, M., “Larger Scale Systems Require Higher-Level Abstractions”, Proceedings of Fifth International Workshop on Software Specification and Design, IEEE Computer Society, 1989, 143-146. 41. Soni, D., Nord, R., Hofmeister, C., Applied Software Architecture, Addison-Wesley, 2000. 42. Sullivan, K., Chalasani, S., Jha, S., “Software Design as an Investment Activity: A Real Options Perspective”, in Real Options and Business Strategy: Applications to Decision Making, L. Trigeorgis (ed.), Risk Books, December, 1999. 43. Yeh, A., Harris, D., Chase, M., “Manipulating Recovered Software Architecture Views”, Proceedings of ICSE 19, (Boston, MA), May 1997, pp. 184-194.
  • 67. dcml.org Gaining control of complexity The standard for the data center technical white paper This document describes the data center markup language (DCML), a structured XML- based format for describing the contents of data centers and the policies governing the management of those contents. DCML describes blueprints for constructing man- aged environments, the knowledge necessary to turn those blueprints into an environ- ment instance and the resulting environment.
  • 68. Table of Contents Introduction 1 New methods and approaches 1 Introduction to DCML 1 Why a standard? 2 Comparison to traditional approaches 2 Related standards 3 DCML concepts 3 Security 4 Overview of the DCML specifications 4 XML representation of DCML 4 Future DCML work 4 Authors: Tim Howes Chief Technology Officer Opsware Inc. Darrel Thomas Chief Technologist EDS Hosting Services 2
  • 69. technical white paper Introduction Over the past five to 10 years, dramatic changes have occurred in the data center landscape. The proliferation of the Internet and the World Wide Web made it dramatically easier to develop and deploy applications. The introduction of multitiered Web- based application architectures caused a substantial shift of computing power from client back to server. The continuing trend toward smaller, cheaper servers resulted in a dramatic increase in the number of servers. The result of these trends has been an explosion of complexity and scale in the data center. Today’s data centers often contain thousands or tens of thousands of servers, networking devices, storage devices and other special-purpose equipment, running an even greater array of operating systems, software, configurations and data. How well are we handling data center complexity? New methods and approaches These new approaches brought with them this description must be in a form new requirements, on behalf of customers, adaptable to a variety of environmental The information technology (IT) approach situations. Second is the set of policies for vendor independence and interoperability. to managing the data center has not kept governing the building of the environment. Just as traditional management approaches pace with these changes. IT departments are Approved and banned versions and com- led to the development of standards such still using methods developed when data binations of various technologies, the order as Simple Network Management Protocol centers were significantly less complex. in which software is installed and started, (SNMP) and Common Information Model These methods rely on armies of experts to the blessed configurations to be used, (CIM) for interoperable network monitoring the required support from underlying make manual changes to the environment and management applications, today’s new hardware – all must be specified to ensure and react to problems after they occur. The automated management approaches require the resulting environment conforms to result for IT has been a staggering increase standards that support interoperability standard best practices. Third is a descrip- in cost and decrease in quality. Traditional among solutions. The data center markup tion of the individual components that data center management tools such as language (DCML) is a proposal for one make up the environment itself. A DCML monitoring have not kept pace with these description is composed of these three such standard. changes either, employing the same pas- components, as depicted in Figure 1. sive, manual frameworks implemented a • After it is constructed, the data center decade ago. Advances among these tools Introduction to DCML environment endures constant change. have resulted in solutions that amplify the In the automated data center, there is a Patches are applied and removed, new bad results of the manual approach. need for a standard format to describe the versions of applications are rolled out and This situation led to new approaches to data contents of the data center and the policies rolled back, configurations are tweaked, governing the construction and management capacity is added and removed, and a center management. Although these new of that content. This need is evident in a host of other changes happen on a daily approaches go by different names and are number of scenarios: basis to support changing requirements. designed to solve different parts of the problem, they all share common character- • In an automated data center, these changes • Construction and change – Customers istics and goals. Data center automation, must be described in detail so they can often need to build or rebuild the full or be applied without human intervention. utility computing, adaptive enterprise partial contents of data centers. The Changes are governed by strict policies computing, on-demand computing and other build case occurs when new applications aimed at minimizing downtime caused by efforts focus on replacing the traditional or infrastructure are deployed, during disruptive changes and maximizing the manual, passive approach to data center technology refresh cycles and when agility with which good changes can be management with an automated, active increasing the capacity of existing made. Furthermore, the result of these applications. The rebuild case occurs approach. The active approach is designed changes must be documented and com- during disaster recovery, data center to reduce costs through increased labor and municated to monitoring and other systems. consolidation and migration, and during equipment utilization, and to increase quality simple system recovery. • Visibility – Many useful and illuminating by eliminating human error and enforcing conclusions can be drawn from an accu- best practices. These new approaches do not • Automated implementation of these rate and up-to-date representation of a scenarios requires two things. First is a replace the traditional monitoring, ticketing data center environment. Reporting on comprehensive blueprint of the environ- and other operational systems. Rather, hardware and software usage in the ment to be built. Hardware requirements, they typically integrate with and build on data center is an obvious example. But software components and configurations, those systems, making them more effective such information can also inform data networking and storage – all must be spec- in the new data center environment. center planning decisions, procurement ified to facilitate automation. Furthermore, decisions and other business processes. <1>
  • 70. technical white paper automation tools may be required to reproduce the components being described (for example, an OS-provisioning tool, an application-provisioning tool and a network- provisioning tool). A standard format enables these tools to interoperate more easily. Furthermore, some scenarios – such as a move between hosting providers – imply transfer of control between autonomous organizational entities, a situation for which standards are tailor-made. Figure 1: DCML scope includes environment components, data center blueprints, and best practice policies Comparison to traditional approaches Traditionally, tasks such as those described • For example, having a description of the In other scenarios, the knowledge is specific, above were accomplished by a variety requirements of applications slated to used to keep other systems in sync with the of means: inhabit a given data center, one can current state of the environment as changes infer the rack space, power and cooling are made – for example, incremental changes • Manually – System administrators, data- requirements necessary to house the to the list of servers that should be monitored. base administrators, application experts applications. Knowing the technology and others use their memory, expertise This use may imply a more incremental requirements represented in several and knowledge of the existing systems to description exchanged with systems in a data centers to be consolidated or reproduce them and communicate the migrated, one can infer the hardware real-time environment. DCML supports resulting changes to other systems. There and software that must be procured both types of uses. are numerous problems with this approach, to facilitate the transition. including slow execution time, inconsis- A DCML description provides the blueprint tency and poor quality resulting from • Management – As with traditional data that enables an appropriate data center human error, out-of-date documentation centers, the automated data center must automation tool (or set of tools) to reproduce and faulty memories of people. be monitored to detect faults and track the infrastructure described or extract useful performance, track down and fix problems, information from the description. Like an • Ad hoc and platform-specific standards – and perform day-to-day management. Some platforms define de facto standards architectural blueprint, a DCML blueprint Although the needs are similar to those of for representing certain types of infor- can be easily adapted to slightly different the traditional data center, the opportunity mation. For example, on Red Hat Linux, for improvement is huge. Traditional environments, such as hardware, networking the RedHat Package Manager (RPM) management systems suffer from not and data center variations. DCML can also package format is a de facto standard having an accurate and up-to-date view of describe the key building blocks (software for representing software packages. the environment – something automated packages, configurations, etc.) and policies Similar de facto standards exist on other systems provide. necessary to construct an actual environ- platforms. Problems with this approach ment based on the blueprint. Finally, DCML include a lack of cross-platform support In all of these scenarios, the common thread can describe the resulting environment and inability to represent the compre- is the need for knowledge of the configura- hensive set of information required across itself. All of these descriptions can be used tion of a data center, application, network components. Even within platforms, to extract information useful to traditional component, storage component or server. often there is no standardization. management systems, and to drive pro- In some scenarios, the knowledge is generic, curement and other planning processes. • Imaging – Disk images of the machines used to reproduce instances of an object. and their contents are created and used The first step in being able to reproduce to reproduce the configuration when something is to describe it. DCML provides a Why a standard? needed. Problems with this approach language for describing these data center A standards-based approach to these include the fact that images are tied elements, including applications, servers, problems provides a number of benefits. closely to specific hardware, network software components, configurations, network For the types of applications described and data center configurations. This and storage infrastructure, and hardware makes it difficult to change any of those above, multiple components from different and data center requirements. Often, such environmental variables when rebuilding. vendors are almost always involved and descriptions may be exchanged offline in their The storage management problem of must be described. A standard format organizing and retaining significant entirety between data center automation enables all components to be described numbers of large, unwieldy images is tools or with traditional management systems. using a single format. Similarly, multiple daunting. In addition, imaging generally only applies to server elements, leaving networking and other critical infrastruc- ture components unable to participate. <2>
  • 71. technical white paper • Backups – The contents of disks are center automation tools. Where DCML description of a server are instructions for backed up to tape and often stored offsite overlaps with definitions found in performing this instantiation. Note the dif- for disaster-recovery purposes. If a disaster CIM, DCML references CIM to avoid ference between the DCML concept of a occurs, the tapes are retrieved and duplicating work. server (a description of a generic class that restored. Problems with this approach can be instantiated in a variety of environ- • SDM – Microsoft’s Systems Definition include the time required for backup and Model (SDM) is a recently announced ments) and the traditional concept of a restore, and the difficulty getting a consis- initiative complementary to DCML. server as designed by CIM and other stan- tent, usable backup image that will restore SDM establishes a technical contract dards (a description of a specific instance to a useful state. Backup systems are between development and operations. of a server). This concept of adaptability is generally better at selective file retrieval By providing a standard format for central to DCML. than wholesale system restoration. encoding Windows application compo- These solutions also share the problem of not nent requirements, SDM can help The concept essentially means that a DCML having a standard for representing the infor- automate the creation of a production description is like a blueprint. The blueprint mation they need to succeed. In the case of server for Windows-based applications. can be used to build the entity described imaging, there is no standard image format However, while SDM provides opera- in a number of different locations and tional requirements for an application across platforms, and sometimes no standard environments. During the build process, component, DCML provides the blueprint format even on a single platform. In the case blueprint variables (such as host name and for constructing and managing the entire of manual recreation, there is no standard environment in which that application networking information) are filled in and for representing the information needed – is running. Ultimately, SDM component configured with values that make sense for only the knowledge contained in the heads of requirements will feed directly into the the environment. In the case of reproductions people and whatever they may or may not DCML-defined constraints for Windows on different hardware, DCML must describe have captured on paper, in files, and other applications. the basic hardware requirements that can- places. These problems make it impossible to not be changed and those that can. For • ITIL – The IT Infrastructure Library is a reliably extract information needed for data collection of standards defining best- example, Intel-compatible hardware is required center planning, inventory management and practice IT processes. ITIL standardizes to reproduce a Microsoft Windows server, other functions among the key needs iden- processes such as service desk, change but there may be flexibility in the exact tified above. Clearly, given the diverse of management, service level management manufacturer, model or amount of memory. software, hardware, vendors and applications and others. DCML is an important imple- mentation component of these ITIL DCML accomplishes this adaptability involved, a standard format is needed. processes in automated environments, through the use of requirement attributes making them more reliable, consistent and “marked-up” configuration files. A Related standards and vendor-independent. DCML-capable data center automation There are several standards either defined system uses the requirement attributes • OSS/J – The Operational Support System or in process to address related problems, through Java initiative is defining a set of to determine hardware and other compati- but none of them can be used in place of standard application program interfaces bilities. When configuring systems, the DCML. These related standards are described (API) used to communicate with and data center automation system uses the briefly below. between IT OSS and business support marked-up configuration file to substitute systems. OSS/J defined APIs for service configuration values appropriate to the • CIM – The Common Information Model is activation, trouble ticketing, billing and new environment. a Distributed Management Task Force quality of service, with other APIs in (DMTF) standard for describing overall process. When and if OSS/J defines inter- The need for adaptability is clear in disaster management information in a network/ faces to data center automation systems, recovery situations, data center migrations enterprise environment. CIM defines an DCML will provide important content and consolidations, even when using DCML abstract data model, method for instan- communicated through those interfaces. to describe additional server capacity. In tiation in XML, and mappings to other all these scenarios, the entities described management and information standards DCML concepts by DCML often need to be reproduced in such as SNMP and Lightweight Directory environments requiring different hardware, Access Protocol (LDAP). CIM’s focus A data center can be thought of as a com- is on providing end-to-end consistent different network configurations, different plex entity composed of simpler lower-level management abstractions to be used clustering configurations, different connecting entities. For example, a server’s composed by monitoring and other traditional components, and simple differences such of an operating system, patches, various management systems. Although CIM is as host name and IP address. software components, configurations, and quite comprehensive in this area and overlaps somewhat with DCML, CIM is associated access rights and policies gov- Another key DCML concept is the ability to not well suited to the data center erning the use of the server. To instantiate represent best practices, standards and automation problem, which is DCML’s such a server in a data center environment policies used in the management of a data much narrower focus. Many of CIM’s requires certain underlying support from the center environment. Without the ability to concepts and data elements can be hardware, network and physical environment capture and represent this kind of informa- mapped onto DCML for use with data in which it lives. Included in the DCML tion, a data center automation or utility <3>
  • 72. technical white paper computing solution is simply an “amplifier” DCML defines two constructs to enable • Storage specification – This specification for the bad (or possibly good) practices the security of the information conveyed describes how to represent storage knowledge possessed by each individual. in a DCML document: topology, software and configuration DCML allows application-, organization- information in DCML. • Encrypted – The encrypted construct is and technology-wide best practices to be • Software specification – It describes how used to encrypt the payload it carries described and, therefore, interpreted by to avoid unauthorized viewing. Any to represent software components in data center automation systems. These encryption algorithm may be used, DCML, their configurations and associated best practices relate primarily to software provided it follows a few simple rules. data. Software components include and their configurations, and are captured operating systems, patches, packaged • Signed – The signed construct is used software applications and custom soft- by the best-practices library portion of a to sign the payload it carries to avoid ware applications. DCML description. The DCML blueprint unauthorized tampering. Any signature describes how to combine these best- algorithm may be used, provided it fol- practice standard configurations with the lows a few simple rules. XML representation of DCML physical components to create a best- There are many different ways to represent practices data center environment. The encrypted and signed constructs may the information described above. We chose appear at any level of a DCML document Another key DCML requirement is the ability XML Schema as the language to describe and may be nested within one another, to represent the wide variety of diverse DCML. XML has become the lingua franca enabling maximum flexibility. technologies in today’s (and tomorrow’s) of information exchange on the Internet. It data centers without imposing requirements is widely known, widely implemented, and that those technologies be changed. This Overview of the DCML well-understood technology. XML parsers requirement is a practical one. Imposing specifications and generators are readily available from new requirements on technologies to be Describing the entire contents of a data a number of sources, making implementa- managed has many advantages in theory, center in enough detail to be able to repro- tion cost relatively low. XML Schema is a but actually getting those technologies duce those contents is a daunting task, given convenient method of defining standard changed poses serious challenges to the the diversity of technologies represented XML documents. deployment of DCML. Because it imposes in a typical data center. Yet, you do not DCML components are defined using XML no requirements on the technologies it have to solve the entire problem to start doing Schema, a standard way to represent the describes, DCML can be useful today, useful things. For example, you can solve structure, content and semantics of XML without the long adoption cycles that have the capacity management problem for many documents. XML Schema is defined by accompanied other management standards applications simply by describing servers, the W3C. such as SNMP and CIM. software components and configurations. Therefore, we have taken an incremental Future DCML work Security approach to defining DCML, which is com- DCML is in its infancy. Much work is Although DCML is neither a security proto- posed of the following set of specifications: required to make it into a suitable stan- col or concerned directly with security itself, • Framework specification – This describes dard. Nevertheless, early work on the there often may be a need to represent the overall DCML approach, formats and specification and prototype implementation sensitive information in DCML. For example, conventions used in subsidiary standards, is promising. Our intention is to form a to reproduce a server, one might need to and how DCML components are combined consortium of representative like-minded reproduce the password file contained on and related to one another. It also describes organizations willing to commit time and that server. To reproduce the state of an how DCML can be extended in the docu- resources to the further development application, one might need to reproduce ments below and in future documents. of DCML as an industrywide standard. sensitive data maintained by that application. • Hardware specification – This specifica- That organization will submit the DCML tion describes how to represent server, specification to a standards body such DCML provides the mechanisms by which network, storage and security hardware sensitive information can be separated from as DMTF, IETF, OASIS, or SNIA. The requirements in DCML. Because this type nonsensitive information and secured specific organization will be chosen at of information overlaps with work already using appropriate means. For example, the appropriate time. done by CIM, this specification describes DCML enables information components how DCML references CIM to represent to be signed to prevent tampering and/or the information. encrypted to prevent unauthorized access. • Network specification – It describes how DCML does not define the mechanisms by to represent network topology, software which this occurs – it merely provides a and configuration information in DCML. framework in which it can be done. <4>
  • 73. technical white paper About the Authors Tim Howes Tim Howes is co-founder, chief technology officer and executive vice president of development at Opsware Inc. (formerly Loudcloud), where he is responsible for product development and strategy. Prior to co-founding Opsware Inc., Tim held a number of senior technical positions at America Online, Inc. and Netscape Communications Corp. Before joining Netscape, he was a researcher and National Science Foundation project director at the University of Michigan, where he co-invented the Lightweight Directory Access Protocol (LDAP). Tim holds a Ph.D. in computer science from the University of Michigan. Darrel Thomas Darrel Thomas is chief technologist of the EDS Automated Hosting Services division, where he leads architecture, implementation and business-to-technology strategy. His responsibilities include acquisition strategy, and integration and automation evangelism across EDS. Previously, Darrel was the chief architect, designer and implementation lead for EDS’ original Internet IT Hosting offering as well as the WebVault™, EDS’ original leading-edge hosting environment. He was also chief technologist of Persona, Inc. – the first identity management and privacy services provisioning entity – which developed and provided online personal information (PII) and identity management services. Darrel holds a bachelor of science degree in computer science from Millsaps College in Jackson, Mississippi. Contacts Tim Howes, Chief Technology Officer Opsware Inc. 599 N. Mathilda Avenue Sunnyvale, CA 94085 phone: 408 744 7300 e-mail: howes@opsware.com Darrel Thomas, Chief Technologist EDS Hosting Services 5400 Legacy Drive Plano, Texas 75024-3199 phone: 1 800 566 9337 e-mail: darrel.thomas@eds.com <5>
  • 74. About the DCML Organization The DCML Organization is an open, independent, vendor-neutral, non-profit corporation being formed to create an open, freely licensed specification, Data Center Markup Language (DCML), and to encourage its broad adoption. DCML is the first standard that provides a structured model and encoding to describe, construct, replicate and recover data center environments and elements. DCML is designed to provide a mechanism to enable data center automation, utility computing and system management solutions to exchange information about the environment to make utility computing a reality. In addition to developing specifications, the organization intends to work with formal standards bodies, enable and administer certification and compliance programs, and perform user and market education. For more information about how to join the DCML Organization, or to learn more about planned activities and DCML, visit www.dcml.org. DCML is a trademark of the DCML Organization. All other product names, service marks, and trademarks mentioned herein are trademarks of their respective owners.
  • 75. Role Description: Architect Charter: The Architect, through the application of best practices, structured principles, and broad and deep technical knowledge, maps business requirements to technical solutions and provides technical leadership to the implementation of these solutions. In addition to delivery-oriented responsibilities, the Architect plays key roles in selling and presales activities and the development and capture of intellectual property within Sun. Scope: The Architect is an individual contributor position responsible for the overall design and technical oversight of complex business initiatives in customer consulting engagements. This responsibility typically spans all layers of the business infrastructure interfaces with the account customer and customer executive management to define requirements and recommend solutions. Work is performed at an independent level with very limited oversight and direction. Failure to complete project tasks, resolve problems, or ensure a professional working environment may jeopardize the overall project and Sun relationship with customer. Participates in projects as a technology leader and team leader. Provides technical leadership and direction and peer support within Sun. Key Responsibilities & Contribution Areas Architectural Consulting The Architect, working or teaming with a account teams, professional services, and partners to define a technical solution to be implemented that will address customer needs. The Architect guides the technical delivery of the solution and mentors the technical team assigned to implement the project. Typical major activities and key responsibilities include: Reviewing existing IT ecosystem, customer strategic goals, existing capabilities, and other factors that influence project direction. Collecting customer business and technical requirements and creating technical solutions (e.g., master architecture plans, blueprints, roadmaps, etc.) based on Sun products and solutions. Articulating in a clear manner, alternatives in terms of cost, benefit, and risk where multiple solutions exist. Assisting the Project/Technical Manager in the creation of technical project plans and work breakdown structures. Providing technical vision including ensuring overall coherence of implementation strategies. Consulting with senior customer management on project status and architectural direction. In addition to these tasks, the Architect may serve as a contributor to the implementation efforts of a given project. Business Development The Architect assists in the creation of new business opportunities and driving a Sun product-based architecture. This may include extensions or expansions of existing projects, or the development of new FINAL Updated: 6/11/03 FINAL
  • 76. Role Description: Architect opportunities. Typical major activities and key responsibilities include: Presenting technical solutions to customers, partners, or other Sun organizations Demonstrating Sun Architecture credibility and capability through high-level discussions of customer needs and Sun's approach to meet those needs Influencing technical decision makers to adopt appropriate solutions by applying broad and deep technical expertise and persuasive communications skills. Technology Leadership A key responsibility of the Architect is to develop, capture, and share architectural patterns and innovative technical solutions. Furthermore, the Architect will function as an enabler, mentor, and role model by effectively transferring their knowledge to others within the TSO. Typical major activities/key responsibilities of this role include: Developing or synthesizing relevant and innovative technical solutions or intellectual property to problems facing current or prospective Sun customers. Leading and participating in activities to foster technical community . Serving as a mentor and role model to guide the careers of other technical contributors. Experience/Education: Typically requires a Bachelor's degree and 10 – 12 years of technical consulting experience OR an advanced degree and 8 – 10 years technical consulting experience OR an equivalent combination of education and experience. Experience should include business management principles. Skills & Competencies: Deep and broad technical knowledge of Sun products and solutions and the overall IT environment. Knowledge of competitive environment and alternative technological solutions/approaches. Extensive technical knowledge within a specified domain (e.g., system design and implementation, application architecture, etc.) Ability to demonstrate consultative customer management skills including expectation setting, problem resolution, and selling of services and capabilities. Ability to function and communicate effectively in business and technical domains and demonstrated ability to develop key relationships and maneuver in a politically charged environment. Recommended grade level: E10-E12 or Architectural Manager (ARM) FINAL Updated: 6/11/03 FINAL