These terms reflect common usage, but are at variance with ANSI/IEEE Std 1471-2000 (in which "architecture" Terminology that is familiar to the majority of the TOGAF readership.Īn example of common terminology retained in TOGAF is the use of the terms "Business Architecture", "TechnologyĪrchitecture", etc. That our usage of terms defined by ANSI/IEEE Std 1471-2000 is consistent with the standard - and retaining other commonly accepted In TOGAF we endeavor to strike a balance between promoting the concepts and terminology of ANSI/IEEE Std 1471-2000 - ensuring Organizations that have incorporated, or plan to incorporate, ANSI/IEEE Std 1471-2000 into their IT architecture practice shouldįind that none of the key concepts in TOGAF is incompatible with this standard, although some of the terminology used is not One of the aims of this standard is to promote a more consistent, systematic approach toĪt the present time, TOGAF encourages but does not mandate the use of ANSI/IEEE Std 1471-2000. Principally through the adoption by ANSI and the IEEE of ANSI/IEEE Std 1471-2000, Recommended Practice for Architecturalĭescription of Software-Intensive Systems. TOGAF and Standards for IT Architecture DescriptionĪn important recent development in IT architecture practice has been the emergence of standards for architecture description, Of a building to its different stakeholders (electricians, owners, planning officials), so an IT architect might create physicalĪnd security views of an IT system for the stakeholders who have concerns related to these aspects. As with the architecture of aīuilding, it is normally necessary to develop multiple views of the architecture of an information system, to enable theĪrchitecture to be communicated to, and understood by, the different stakeholders in the system.įor example, just as a building architect might create wiring diagrams, floor plans, and elevations to describe different facets A single, comprehensive model is often too complex to be understood and communicated in its mostĭetailed form, showing all the relationships between the various business and technical components. The architect chooses and develops a set of views that will enable the architecture to be communicated to, and understoodīy, all the stakeholders, and enable them to verify that the system will address their concerns.Īn architecture is usually represented by means of one or more architecture models that together provide a coherent description The Role of Architecture Views IntroductionĪrchitecture views are representations of the overall architecture that are meaningful to one or more stakeholders in the Was developed by the Electronic Systems Center (ESC) of the US Air Force between 19.
Note that some of the material in this section is from The Command and Control System Target Architecture (C2STA), which
This chapter describes the role and taxonomy of architecture views. You are here: TOGAF 8.1.1 Online > Part IV: Resource Base > Developing Architecture Viewsĭeveloping a Business Architecture View |ĭeveloping a Communications Engineering View |ĭeveloping an Enterprise Manageability View |
0 kommentar(er)
