The next generation of knowledge and expertise
Needed: A Standard for Software
Architecture
Introduction
Today’s Chief Information Officers (CIOs) are faced with the important challenge
of Information Technology governance. Governance is a key to providing
efficiencies and effectiveness for the purchase, management, development, and
retirement of information technology, and may also provide a means to direct
technology toward a desired business end-state or future architecture.
Many CIOs have issued Life Cycle Management Directives (LCMDs) as a basis for
governance. A LCMD is a corporate policy containing definitions of required
processes and documentation items that are aimed at providing significant
direction to developers, maintainers, and users throughout the life cycle of IT
systems. LCMDs generally establish one or more review boards that watch the
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
progress of projects ensuring that LCMD standards are followed and establish
benchmarks at which projects must appear before these boards to argue
compliance prior to moving on.
Many CIOs have wisely based their Life Cycle Management Directives on
engineering and management standards produced by recognized standards
bodies such as the Institute of Electrical and Electronic Engineers (IEEE). There
are many such standards;1 some of those related to software architecture are
listed in appendix B of this work. These standards are highly regular and
consistent, and form a robust set of guidelines that are particularly well
constructed and useful for governance purposes.
Software Architecture Undefined
The IEEE standards contain the ideas of software architecture. The standards
speak to the importance of defining software components and software
connections to enhance human understanding, requirements mapping,
configuration management, quality control, operation and maintenance, test
and evaluation, safety and security, and other life cycle considerations;2 but
the descriptions provided are very general. The IEEE does not define software
architecture as a technical term, but its standards use the ideas of software
architecture (see appendix B)3.
There has been a great deal of technical research in the area of software
architecture beginning with the early works of Zimmerman [27] and Parnas [19,
20, 21], and more recently in the works of Fielding [8], Perry and Wolf [1, 22],
Shaw [2, 9], Clements [5] and others4.
We believe that in this modern era of service oriented architecture methods and
message-based services interconnect (e.g., SOAP, REST) that the idea of
software architecture is most appropriate.
Software Architecture Defined
A software service5 may be composed of many levels of abstraction for many
phases of operation, each with its own software architecture. Each component
1
The number of formal IEEE publications exceeds 3000.
See the list of IEEE standards that include the notion of software architecture at the end of this work.
3
The IEEE does define architecture, architectural design, architectural structure, architectural viewpoint,
architectural style, software structure, and other related terms such as software components.
4
See bibliography for a selection of research articles; several of them are published in IEEE publications.
5
We use the term system in its general systems sense. That is, a set of components that work together to
achieve a goal or an objective.
2
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
of a system may also be a component of a higher level architecture. In today’s
world such a combination of components may be referred to as a service. Each
component consists of main routines, sub-routines, and function calls. In
addition, each component participates with other components in performing a
service which is a basic unit of execution. Likewise each component can be
connected to another element, and each component uses data passed to it by
other components.
In our view, to be consistent with service oriented language, components are
connected using connectors to form services, and services communicate by
passing data over those connections6.
Each element of a system may also be an element of a higher level architecture.
In today’s world such a combination of elements may be referred to as a service.
Each element consists of main routines, sub-routines, and function calls. In
addition, each element participates with other elements in performing a service
which is a basic unit of execution. Likewise, each element can be connected to
another element, and each element uses data passed to it by other elements.
In our view, to be consistent with service oriented language, a software element
is called a component; components are connected using connectors to form
services, and services communicate by passing data over those connections.
So, on our view software architecture is defined by a configuration of
architectural elements, that we call components, connectors, and data that are
organized in some relationship to achieve a desired set of architectural
properties.
Software Architecture is a run-time
abstraction
Some older literature treats source code in an architectural fashion. While this
may well be a reasonable way to provide organizing principles for source code
that is not the subject matter of this work. We are dealing with executable
(objects) in this work. We reserve the term architecture as a run-time
abstraction, possibly using a different term for the organization of source code;
a good choice of terminology for source code organization might well be
software structure.
6
Connection of services is called an orchestration or a choreography depending upon the nature of the
services.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
We view software architecture as an abstraction of the run-time elements of a
software system during some phase of its operation. A system may be
composed of many levels of abstraction and many phases of operation, each
with its own software architecture.
Thus our terminology follows that of Perry and Wolf [1, 22] in distinguishing
various type of processing elements. Processing elements are those software
elements that perform transformations on data. We call them components in
line with current service oriented terminology. Data elements contain
information that is used and transformed by components. Connecting elements,
which we call connectors, are the glue that holds the different pieces of the
architecture together. We now begin to follow Fielding’s definitions [8].
A component is an abstract unit of software instructions and internal
state that produces a transformation of data.
A connector is an abstract mechanism that mediates communication,
coordination, and cooperation among components.
Data is an element of information that is sent from a component or
received by a component via a connector.
A component is a unit of software instructions and internal state information
that transforms data. The behavior of each component is part of the
architecture insofar as that behavior can be observed or discerned by another
component. A component is defined by its interface and by the services it
provides to other components.
Connectors enable communication between components by transferring data
without changing the data7. On the other hand, a component may, and usually
does, transform data in its actual operation8.
Some definitions of software architecture ignore data. A datum is an element of
information that is transferred between components via connectors. Examples of
data are messages, parameters, and serialized objects. These data are not
hidden by services. Other information that is hidden by a service or which a
component “serves” is not included in this definition of data. As an example, it
is most likely that a “file name” could be passed from one component to another
as data. It is also possible that the file corresponding with the file name is
7
A connector may consist of service that transform the data for transfer, performs the transfer, and then
reverses the transformation for delivery. However that behavior is a mechanism that is not part of the
software architecture; it is an implementation.
8
Some components may not transform data. A component might validate data or scan data or record data
without modifying it.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
passed between components; but such a file is more likely encapsulated by the
component and is not data from our perspective9.
Data is particularly important where a choice must be made between interacting
with a component directly or transforming the component into a data element,
transferring it across a network, and then transforming it back to a component
that can be interacted with locally. This mobilization question is an increasingly
common decision that must be made at the architecture level. Regardless of
this pragmatic consideration, we believe that characterization of data passed
between components is important in software architecture efforts.
Conclusions
We believe that a standard for software architecture is needed in today’s service
oriented environments.
We believe that software architecture can be defined by a configuration of
architectural elements called components, connectors, and data that are
organized in a relationship to achieve a desired set of architectural properties.
We believe that software architecture provides a consistent basis for
consideration of many important properties of modern systems across the entire
system life cycle and relates directly to many existing standards.
We believe that software architecture is an important and useful element of IT
Governance and should be standardized.
9
Components can generate data by manipulation of encapsulated information resources.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
Appendix A – Bibliography
1. D. E. Perry and A. L. Wolf. Foundations for the study of software
architecture. ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992,
pp. 40-52.
2. M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.
Zelesnick. Abstractions for software architecture and tools to support
them. IEEE Transactions on Software Engineering, 21(4), Apr. 1995, pp.
314-335.
3. G. D. Abowd, R. Allen, and D. Garlan. Formalizing style to understand
descriptions of software architecture. ACM Transactions on Software
Engineering and Methodology, 4(4), Oct. 1995, pp. 319-364.
4. R. Allen and D. Garlan. A formal basis for architectural connection. ACM
Transactions on Software Engineering and Methodology, 6(3), July 1997.
5. L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice.
Addison Wesley, Reading, Mass., 1998.
6. M. Boasson. The artistry of software architecture. IEEE Software, 12(6),
Nov. 1995, pp. 13-16.
7. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal.
Pattern-oriented Software Architecture: A system of patterns. John Wiley
& Sons Ltd., England, 1996.
8. R. T. Fielding and R. N. Taylor. Principled design of the modern Web
architecture. In Proceedings of the 2000 International Conference on
Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. 407416.
9. D. Garlan and M. Shaw. An introduction to software architecture.
Ambriola & Tortola (eds.), Advances in Software Engineering & Knowledge
Engineering, vol. II, World Scientific Pub Co., Singapore, 1993, pp. 1-39.
10. D. Garlan, R. Allen, and J. Ockerbloom. Exploiting style in architectural
design environments. In Proceedings of the Second ACM SIGSOFT
Symposium on the Foundations of Software Engineering (SIGSOFT`94),
New Orleans, Dec. 1994, pp. 175-188.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
11. D. Garlan and D. E. Perry. Introduction to the special issue on software
architecture. IEEE Transactions on Software Engineering, 21(4), Apr.
1995, pp. 269-274.
12. D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch, or, Why
it's hard to build systems out of existing parts. In Proceedings of the 17th
International Conference on Software Engineering, Seattle, WA, 1995.
Also appears as: Architectural mismatch: Why reuse is so hard. IEEE
Software, 12(6), Nov. 1995, pp. 17-26.
13. D. Garlan, R. Monroe, and D. Wile. ACME: An architecture description
language. In Proceedings of CASCON`97, Nov. 1997.
14. P. Inverardi and A. L. Wolf. Formal specification and analysis of software
architectures using the chemical abstract machine model. IEEE
Transactions on Software Engineering, 21(4), Apr. 1995, pp. 373-386.
15. R. Kazman, L. Bass, G. Abowd, and M. Webb. SAAM: A method for
analyzing the properties of software architectures. In Proceedings of the
16th International Conference on Software Engineering, Sorrento, Italy,
May 1994, pp. 81-90.
16. J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying distributed
software architectures. In Proceedings of the 5th European Software
Engineering Conference (ESEC`95), Sitges, Spain, Sep. 1995, pp. 137-153.
17. R. T. Monroe, A. Kompanek, R. Melton, and D. Garlan. Architectural
Styles, Design Patterns, and Objects. IEEE Software, 14(1), Jan. 1997, pp.
43-52.
18. M. Moriconi, X. Qian, and R. A. Riemenscheider. Correct architecture
refinement. IEEE Transactions on Software Engineering, 21(4), Apr. 1995,
pp. 356-372.
19. D. L. Parnas. On the criteria to be used in decomposing systems into
modules. Communications of the ACM, 15(12), Dec. 1972, pp. 1053-1058.
20. D. L. Parnas. Designing software for ease of extension and contraction.
IEEE Transactions on Software Engineering, SE-5(3), Mar. 1979.
21. D. L. Parnas, P. C. Clements, and D. M. Weiss. The modular structure of
complex systems. IEEE Transactions on Software Engineering, SE-11(3),
1985, pp. 259-266.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
22. D. E. Perry and A. L. Wolf. Foundations for the study of software
architecture. ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992,
pp. 40-52.
23. S. P. Reiss. Connecting tools using message passing in the Field
environment. IEEE Software, 7(4), July 1990, pp. 57-67.
24. M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.
Zelesnick. Abstractions for software architecture and tools to support
them. IEEE Transactions on Software Engineering, 21(4), Apr. 1995, pp.
314-335.
25. M. Shaw and D. Garlan. Software Architecture: Perspectives on an
Emerging Discipline. Prentice-Hall, 1996.
26. R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whitehead Jr., J. E.
Robbins, K. A. Nies, P. Oreizy, and D. L. Dubrow. A component- and
message-based architectural style for GUI software. IEEE Transactions on
Software Engineering, 22(6), June 1996, pp. 390-406.
27. H. Zimmerman. OSI reference model -- The ISO model of architecture for
open systems interconnection. IEEE Transactions on Communications, 28,
Apr. 1980, pp. 425-432.
28. (IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of
Software Engineering Terminology, IEEE, 1990.
Appendix B - IEEE Standards containing
Software Architecture Ideas
1. (IEEE730-02) IEEE Std 730-2002, IEEE Standard for Software Quality
Assurance Plans, IEEE, 2002.
2. (IEEE829-98) IEEE Std 829-1998, IEEE Standard for Software Test
Documentation, IEEE, 1998.
3. (IEEE830-98) IEEE Std 830-1998, IEEE Recommended Practice for Software
Requirements Specifications, IEEE, 1998.
4. (IEEE982.1-88) IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures
to Produce Reliable Software, IEEE, 1988.
5. (IEEE1008-87) IEEE Std 1008-1987 (R2003), IEEE Standard for Software
Unit Testing, IEEE, 1987.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
6. (IEEE1012-98) IEEE Std 1012-1998, Software Verification and Validation,
IEEE, 1998.
7. (IEEE1016-98) IEEE Std 1016-1998, IEEE Recommended Practice for
Software Design Descriptions, IEEE, 1998.
8. (IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE Standard for Software
Reviews, IEEE, 1997.
9. (IEEE1044-93) IEEE Std 1044-1993 (R2002), IEEE Standard for the
Classification of Software Anomalies, IEEE, 1993.
10. (IEEE1059-93) IEEE Std 1059-1993, IEEE Guide for Software Verification
and Validation Plans, IEEE, 1993.
11. (IEEE1061-98) IEEE Std 1061-1998, IEEE Standard for a Software Quality
Metrics Methodology, IEEE, 1998.
12. (IEEE1074-97) IEEE Std 1074-1997, IEEE Standard for Developing Software
Life Cycle Processes, IEEE, 1997.
13. (IEEE1175.1-02) IEEE Std 1175.1-2002, IEEE Guide for CASE Tool
Interconnections—Classification and Description, IEEE Press, 2002.
14. (IEEE1209-92) IEEE Std 1209-1992, Recommended Practice for the
Evaluation and Selection of CASE Tools, (ISO/IEC 14102, 1995), IEEE Press,
1992.
15. IEEE1219-98) IEEE Std 1219-1998, IEEE Standard for Software
Maintenance, IEEE, 1998.
16. (IEEE1220-98) IEEE Std 1220-1998, IEEE Standard for the Application and
Management of the Systems Engineering Process, IEEE, 1998.
17. (IEEE1228-94) IEEE Std 1228-1994, Standard for Software Safety Plans,
IEEE, 1994.
18. (IEEE1233-98) IEEE Std 1233-1998, IEEE Guide for Developing System
Requirements Specifications, 1998.
19. (IEEE1320.1-98) IEEE Std 1320.1-1998, IEEE Standard for Functional
Modeling Language-Syntax and Semantics for IDEF0, IEEE, 1998.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com
20. (IEEE1320.2-98) IEEE Std 1320.2-1998, IEEE Standard for Conceptual
Modeling Language-Syntax and Semantics for IDEFIX97 (IDEFObjetct),
IEEE, 1998.
21. (IEEE1348-95) IEEE Std 1348-1995, Recommended Practice for the
Adoption of CASE Tools, (ISO/IEC 14471), IEEE Press, 1995.
22. (IEEE1362-98) IEEE Std 1362-1998, IEEE Guide for Information TechnologySystem Definition-Concept of Operations (ConOps) Document, IEEE, 1998.
23. (IEEE1462-98) IEEE Std 1462-1998//ISO/IEC14102, Information Technology
— Guideline for the Evaluation and Selection of CASE Tools.
24. (IEEE1465-98) IEEE Std 1465-1998//ISO/ IEC12119:1994, IEEE Standard
Adoption of International Standard ISO/IEC12119:1994(E), Information
Technology-Software Packages-Quality requirements and testing, IEEE,
1998.
29. (IEEE1471-00) IEEE Std 1471-2000, IEEE Recommended Practice for
Architectural Descriptions of Software-Intensive Systems, Architecture
Working Group of the Software Engineering Standards Committee, 2000.
30. (IEEE1517-99) IEEE Std 1517-1999, IEEE Standard for Information
Technology-Software Life Cycle Processes- Reuse Processes, IEEE, 1999.
31. (IEEE1540-01) IEEE Std 1540-2001//ISO/IEC16085:2003, IEEE Standard for
Software Life Cycle Processes-Risk Management, IEEE, 2001.
32. (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry
Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.
HTA Technology Security Consulting ● 30 S. Wacker Dr., 22nd Floor ● Chicago, IL 60606
Voice 708-862-6348 ● Fax 708-868-2404● http://www.HTA-Inc.com