IEEE 1471เป็นมาตรฐาน IEEE ที่ถูกยกเลิกไปแล้ว ซึ่งใช้ในการอธิบายสถาปัตยกรรมของ "ระบบที่เน้นซอฟต์แวร์" หรือที่รู้จักกันในชื่อสถาปัตยกรรม ซอฟต์แวร์

ในปี 2011 มาตรฐานนี้ถูกแทนที่ด้วยมาตรฐาน ISO/IEC/IEEE 42010เรื่องระบบและวิศวกรรมซอฟต์แวร์ — คำอธิบายสถาปัตยกรรม

IEEE 1471 เป็นชื่อย่อของมาตรฐานที่รู้จักกันอย่างเป็นทางการว่า ANSI/IEEE 1471-2000 ซึ่งเป็นแนวทางปฏิบัติที่แนะนำสำหรับการอธิบายสถาปัตยกรรมของระบบที่เน้นซอฟต์แวร์ ใน ภาษาของ สถาบันวิศวกรรมไฟฟ้าและอิเล็กทรอนิกส์ (IEEE) นี่คือ "แนวทางปฏิบัติที่แนะนำ" ซึ่ง ^เป็นมาตรฐานที่มีข้อกำหนดน้อยที่สุด ในปี 2007 มาตรฐานนี้ได้รับการรับรองโดยISO/IEC JTC1/SC7 เป็นISO/IEC 42010:2007 วิศวกรรม ระบบและซอฟต์แวร์ -- แนวทางปฏิบัติที่แนะนำสำหรับการอธิบายสถาปัตยกรรมของระบบที่เน้นซอฟต์แวร์ [ ^{1 ]}

เป็นที่ยอมรับกันมานานแล้วว่า "สถาปัตยกรรม" มีอิทธิพลอย่างมากต่อวงจรชีวิตของระบบ อย่างไรก็ตาม จนกระทั่งเมื่อไม่นานมานี้ ปัญหาด้านฮาร์ดแวร์มักจะครอบงำความคิดด้านสถาปัตยกรรม และด้านซอฟต์แวร์ หากได้รับการพิจารณาเลย ก็มักจะเป็นสิ่งแรกที่ถูกลดทอนลงภายใต้แรงกดดันของการพัฒนา^{[ 1 ]} IEEE 1471 ถูกสร้างขึ้นเพื่อเป็นพื้นฐานสำหรับการคิดเกี่ยวกับสถาปัตยกรรมของระบบที่เน้นซอฟต์แวร์

ผลงานของมาตรฐาน IEEE 1471 สามารถสรุปได้ดังนี้ (ในรายการนี้ คำที่เป็นตัวเอียงคือคำที่กำหนดและใช้ในมาตรฐาน):

• เอกสารนี้ให้คำจำกัดความและแบบจำลองเชิงอภิมานสำหรับการอธิบายสถาปัตยกรรม
• ระบุว่าสถาปัตยกรรม ควรคำนึงถึง ข้อกังวลของผู้มีส่วนได้ส่วนเสีย ของระบบ
• กล่าวคือคำอธิบายทางสถาปัตยกรรม นั้น โดยเนื้อแท้แล้วมีหลายมุมมองไม่มีมุมมอง ใดมุมมองเดียว ที่สามารถครอบคลุมข้อกังวลของผู้มีส่วนได้ส่วนเสียทั้งหมดได้อย่างเพียงพอ
• เอกสารนี้ระบุถึงแนวคิดเรื่องมุมมองและจุดมองโดยที่จุดมองนั้นระบุถึงชุดของประเด็นปัญหาและการนำเสนอ / เทคนิคการสร้างแบบจำลองฯลฯ ที่ใช้ในการอธิบายสถาปัตยกรรมเพื่อแก้ไขประเด็นปัญหา เหล่านั้น และมุมมองคือผลลัพธ์ของการนำจุดมองไปใช้กับระบบใดระบบหนึ่ง
• ข้อกำหนดนี้กำหนดข้อกำหนดด้านเนื้อหาสำหรับคำอธิบายทางสถาปัตยกรรม และแนวคิดที่ว่าคำอธิบายทางสถาปัตยกรรมที่สอดคล้องกับข้อกำหนดนั้นจะต้องมีความสอดคล้องกันแบบ 1 ต่อ 1 ระหว่างมุมมองและทัศนียภาพ
• It provides guidance for capturing architecture rationale and identifying inconsistencies/unresolved issues between the views within an architecture description

IEEE 1471 provides informative annexes that relate its concepts to architecture concepts in other standards, including RM-ODP and IEEE 12207.

In August 1995, the IEEE Software Engineering Standards Committee (SESC) chartered an IEEE Architecture Planning Group (APG) to set direction for incorporating architectural thinking into IEEE standards. In April 1996, the Architecture Working Group (AWG) was created to implement the recommendations made by APG to the SESC. The AWG was chaired by Basil Sherlund, vice-chairs Ronald Wade, David Emery, the specification was edited by Rich Hilliard. The AWG had 25 members. Drafts of the specification were balloted and commented on by 130 international reviewers. In September 2000, the IEEE-SA Standards Board approved the specification as IEEE Std 1471-2000.

In 2006, ISO/IEC Joint Technical Committee 1 (JTC1), Information technology/Subcommittee SC 7, Software and systems engineering, adopted the specification as ISO/IEC 42010, under a special "fast-track procedure", in parallel with its approval by national bodies of ISO and IEC. A coordinated revision of this standard by ISO/IEC JTC1/SC7/WG42 and IEEE CS commenced in 2006, following the successful ISO/IEC fast-track ballot and in line with the IEEE standard 5-year review of the standard.

In November 2011,^[2] IEEE 1471-2000 and ISO/IEC 42010:2007 was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

According to IEEE 1471^[1][3][4] an architecture description can be used for the following:

• Expression of the system and its evolution
• Communication among the system stakeholders
• Evaluation and comparison of architectures in a consistent manner
• Planning, managing, and executing the activities of system development
• Expression of the persistent characteristics and supporting principles of a system to guide acceptable change
• Verification of a system implementation’s compliance with an architectural description
• Recording contributions to the body of knowledge of software-intensive systems architecture

According to IEEE Standard Glossary of Software Engineering Terminology^[5] the following definitions are used:

• architect: The person, team, or organization responsible for designing systems architecture.
• architectural description (AD): A collection of products to document an architecture.
• 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.
• designing: The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.
• system: A collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest.
• system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
• view: A representation of a whole system from the perspective of a related set of concerns.
• viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

IEEE 1471 uses the following conceptual framework.^[1][3][6]

1. A system’s environment, or context, can influence that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems.
2. A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to, that system.
3. Concerns are those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.
4. A system exists to fulfill one or more missions in its environment. A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.
5. Every system has an architecture, whether understood or not; whether recorded or conceptual. An architecture can be recorded by an architectural description.
6. คำอธิบายทางสถาปัตยกรรมจะถูกจัดระเบียบเป็นส่วนประกอบหนึ่งส่วนหรือมากกว่านั้น เรียกว่ามุมมอง (ทางสถาปัตยกรรม) แต่ละมุมมองจะกล่าวถึงข้อกังวลหนึ่งข้อหรือมากกว่านั้นของผู้มีส่วนได้ส่วนเสีย ของระบบ มุมมองคือการแสดงออกบางส่วนของสถาปัตยกรรมของระบบโดยสัมพันธ์กับมุมมอง เฉพาะ เจาะจง
7. มุมมองกำหนดแบบแผนที่ใช้ในการสร้าง การนำเสนอ และการวิเคราะห์มุมมองนั้น ด้วยวิธีนี้ มุมมองจึงสอดคล้องกับมุมมอง มุมมองกำหนดภาษา (รวมถึงสัญลักษณ์ แบบจำลอง หรือประเภทผลิตภัณฑ์) ที่จะใช้ในการอธิบายมุมมอง และวิธีการสร้างแบบจำลองหรือเทคนิคการวิเคราะห์ที่เกี่ยวข้องที่จะนำมาใช้กับภาพแทนของมุมมองนั้น ภาษาและเทคนิคเหล่านี้ใช้เพื่อให้ได้ผลลัพธ์ที่เกี่ยวข้องกับประเด็นที่มุมมองนั้นกล่าวถึง
8. คำอธิบายทางสถาปัตยกรรมจะเลือกมุมมองอย่างน้อยหนึ่งมุมมองมาใช้ โดยทั่วไปการเลือกมุมมองจะขึ้นอยู่กับการพิจารณาผู้มีส่วนได้ส่วนเสียที่คำอธิบายทางสถาปัตยกรรมนั้นส่งถึง และข้อกังวลของพวกเขาคำจำกัดความของมุมมองอาจเริ่มต้นจากคำอธิบายทางสถาปัตยกรรม หรืออาจถูกกำหนดไว้ที่อื่น (เช่นมุมมองของห้องสมุด )
9. มุมมองหนึ่งอาจประกอบด้วยแบบจำลองทางสถาปัตยกรรม หนึ่งแบบหรือมากกว่านั้น แบบจำลองทางสถาปัตยกรรมแต่ละแบบได้รับการพัฒนาโดยใช้วิธีการที่กำหนดไว้สำหรับมุมมองทางสถาปัตยกรรมที่เกี่ยวข้อง แบบจำลองทางสถาปัตยกรรมหนึ่งแบบอาจมีส่วนร่วมในมุมมองมากกว่าหนึ่งมุมมอง

IEEE 1471 ^{[ 1 ]}กำหนดชุดข้อกำหนดเชิงบรรทัดฐานสำหรับคำอธิบายสถาปัตยกรรมที่สอดคล้องกัน ซึ่งรวมถึงสิ่งต่อไปนี้:

• ข้อมูลการระบุตัวตน เวอร์ชัน และภาพรวมของ AD (ข้อ 5.1)
• การระบุผู้มีส่วนได้ส่วนเสียของระบบและข้อกังวลของพวกเขาที่พิจารณาว่าเกี่ยวข้องกับสถาปัตยกรรม (ข้อ 5.2)
• รายละเอียดของแต่ละมุมมองที่ได้รับการคัดเลือกเพื่อจัดระเบียบการนำเสนอสถาปัตยกรรม และเหตุผลในการคัดเลือกเหล่านั้น (ข้อ 5.3)
• ภาพสถาปัตยกรรมอย่างน้อยหนึ่งภาพ (ข้อ 5.4)
• บันทึกความไม่สอดคล้องกันทั้งหมดที่ทราบในส่วนประกอบที่จำเป็นของคำอธิบายทางสถาปัตยกรรม (ข้อ 5.5)
• เหตุผลในการเลือกแบบสถาปัตยกรรม (ข้อ 5.6)

• มุมมองสถาปัตยกรรมซอฟต์แวร์
• กรอบสถาปัตยกรรมองค์กร
• แบบจำลองวิว

• เว็บไซต์ IEEE 1471
• MEGAFเป็นโครงสร้างพื้นฐานสำหรับการสร้างกรอบสถาปัตยกรรมที่สอดคล้องกับคำจำกัดความของกรอบสถาปัตยกรรมที่ระบุไว้ในมาตรฐาน ISO/IEC 42010