定义架构

While the central concept in the Standard is architecture description, it was unavoidable that such a document could escape offering a definition of architecture as well.

This page presents the definition and discusses its rationale. For discussion of other terms used in the Standard, see the [conceptual model].

3.2 architecture
⟨system⟩ fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

What follows is a brief exegesis of “architecture” and its definition in the Standard, phrase by phrase.

⟨system⟩ uses an ISO convention (of angle brackets) to signify that the term being defined pertains to the subject field of systems. Within the Standard, the terms concernenvironment and stakeholder are also designated as pertaining to the subject field of systems.

The term system, in this definition and throughout the Standard, is a placeholder for a long list of things including:

  • systems in the spirit of ISO 15288: “that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities”;
  • software products and services as described in ISO 12207;
  • software-intensive systems as described in IEEE Std 1471:2000™: “any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole” which includes “individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest”.

The Standard does not impose any definition of system upon users of the Standard. In addition to the types of systems listed above, the Standard can be used to express the architectures of conceptual systems or natural systems.

An architecture is what is fundamental to a system — not necessarily everything about a system, but the essentials.

The disjunction, concepts or properties, was chosen to support two different philosophies without prejudice. These philosophies are:

Architecture as Conception: an architecture is a concept of a system in one’s mind;
Architecture as Perception: an architecture is a perception of the properties of a system.

Under either philosophy, an architecture is abstract — not an artifact. The Standard uses another term, architecture description, to refer to artifacts used to express and document architectures.

Alas, there is widespread usage of the term “architecture” which confuses the abstract idea with the artifacts capturing that abstraction — particularly in the field of enterprise architecture.

The architecture of a system is cognizant of the system in its environment; the environment determines the totality of influences on the system. One often-cited difference between architecture and design is this: architecture is outwardly focused on the system in its environment; whereas design is inwardly focused once the system boundaries are set.

That which is fundamental to a system may take several forms:

  • its elements: the constituents that make up the system;
  • the relationships: both internal and external to the system; and
  • the principles of its design and evolution.
摘自IT帮《TOGAF认证公开课》讲义

It is interesting that different architecture communities place varying emphases on these. Software architecture has often been focused on software components as elements and their interconnections as a key relationship. System architecture emphasizes sub-system structures and relationships such as allocation. Enterprise architecture emphasizes principles. The definition recognizes that all of these may play a part in architecture.

Note that principles of its design and evolution may be formulated by an architect, “reverse engineered” from an existing system, or even discovered in nature — depending on the system. While for man-made systems the architecture often reflects an intentional stance, this intention is not part of the definition.

Other definitions of architecture

The Oxford English Dictionary reminds us there are two senses of the term.

architecture noun

  1. the art or practice of designing and constructing buildings. schools of architecture or design
    the style in which a building is designed and constructed, especially with regard to a specific period, place, or culture: Georgian architecture
  2. the complex or carefully designed structure of something: the chemical architecture of the human brain
    the conceptual structure and logical organization of a computer or computer-based system

Although the Standard focuses on the artifacts used to describe architectures in the 2nd sense above, it recognizes that architecture description is one set of practices within the larger art or practice of architecture, sometimes called architecting, and that there is a unity to the notion of architecture from its roots in the built environment, through civil and more recent fields. As Zachman reminds us, Architecture is architecture is architecture. [pdf]


In the original edition, IEEE 1471:2000, the definition was:

architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

“Organization” was removed in the revised edition because that term already had a specialized meaning within the ISO context. Components was replaced because that term was frequently misunderstood as referring to software components. For discussion of other changes between the 2000 and 2011 editions of the Standard see [2011 Change Page].


Early definitions in software and systems architecture naturally focused on the structural nature of architecture, by analogy with the ideas of architecture in the built environment.

a software architecture is a set of architectural (or, if you will, design) elements that have a particular form. [Perry and Wolf, 1989]

Recent definitions have emphasized architecture as a web of decisions:

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization — these elements and their interfaces, their collaborations, and their composition [Kruchten, The Rational Unified Process]

Note the use of significant — not all decisions are part of the architecture, but only those that are fundamental.


The IEEE 1471/ISO 42010 definition has been utilized, extended (and sometimes misunderstood) by many others in many forms. For example:

The architecture of anything is:

  • Its fundamental organization–embodied in its components and their relationships to each other and their environment.
  • The principles that govern its design and evolution. [Holcman, 2010]

Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change. [pdf]

TOGAF ignores the distinction between architecture and architecture description, leading to confusions throughout the TOGAF 9 document:TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In TOGAF, ‘architecture’ has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

The Software Engineering Institute has collected a large number of definitions of software architecture [SEI page].

转:Defining architecture
http://www.iso-architecture.org/ieee-1471/defining-architecture.html

更多文章

业务架构学习群资料

W8.1 业务架构的IT谬论(PPT讲义)

常见的误解是组织内的IT部门拥有自己的业务架构。虽然这种方法的出发点是好的,但实际上抑制了组织创建内聚视图的能力,这对于实现业务架构的好处是非常重要的。本次分享将讨论IT如何与组织的业务架构相匹配,在更大的范围内表示IT的价值以及如何应对共同挑战的建议。

阅读更多»
其他免费资料

敏捷概论

1.浏览三大敏捷方法(XP、Scrum和看板)
2. 为敏捷建立一个共享词汇表
3.学习敏捷的简单心智模型

阅读更多»