สถาปนิกซอฟต์แวร์คือวิศวกรซอฟต์แวร์ที่รับผิดชอบใน การเลือก การออกแบบระดับสูงที่เกี่ยวข้องกับโครงสร้างและพฤติกรรม โดยรวมของระบบ ^{[ 1 ]}

หน้าที่ของสถาปนิกซอฟต์แวร์คือการจับคู่ลักษณะทางสถาปัตยกรรม (หรือที่เรียกว่าข้อกำหนดที่ไม่ใช่ฟังก์ชัน ) กับข้อกำหนดทางธุรกิจ ตัวอย่างเช่น: ^{[ 2 ]}

• การจะให้ ลูกค้าพึงพอใจในระดับสูงนั้นจำเป็นต้องอาศัยความพร้อมใช้งานความทนทานต่อข้อผิดพลาดความปลอดภัย ความสามารถในการทดสอบ ความสามารถในการกู้คืน ความคล่องตัว และประสิทธิภาพในระบบ
• การควบรวมและซื้อกิจการ (M&A) จำเป็นต้องอาศัยความยืดหยุ่นความสามารถในการปรับขนาด ความสามารถในการปรับตัว และความสามารถในการทำงานร่วมกัน
• งบประมาณและเวลาที่มีจำกัด ทำให้จำเป็นต้องพิจารณาความเป็นไปได้และความเรียบง่าย
• การนำผลิตภัณฑ์ออกสู่ตลาดได้เร็วขึ้นนั้นจำเป็นต้องมีระบบที่บำรุงรักษาได้ ทดสอบได้ และใช้งานได้ง่าย

สถาปัตยกรรมซอฟต์แวร์และสถาปนิกซอฟต์แวร์จึงต้องจัดการกับความไม่แน่นอนโดยธรรมชาติ หน้าที่ของสถาปนิกซอฟต์แวร์คือการตัดสินใจเกี่ยวกับขนาดของส่วนประกอบทางสถาปัตยกรรม ซึ่งสามารถส่งผลต่อผลลัพธ์ของระบบได้อย่างมาก ทั้งในเชิงบวกและเชิงลบ Neal Ford และ Mark Richards เสนอแนวทางแบบวนซ้ำเพื่อจัดการกับความท้าทายในการระบุและกำหนดขนาดของส่วนประกอบให้เหมาะสม วิธีนี้เน้นการปรับปรุงอย่างต่อเนื่องเมื่อทีมพัฒนาความเข้าใจที่ละเอียดอ่อนยิ่งขึ้นเกี่ยวกับพฤติกรรมและข้อกำหนดของระบบ^{[ 2 ]}

โดยทั่วไป แนวทางดังกล่าวเกี่ยวข้องกับวงจรที่มีหลายขั้นตอน: ^{[ 2 ]}

• มีการกำหนดกลยุทธ์การแบ่งส่วนระดับสูง ซึ่งมักแบ่งออกเป็นด้านเทคนิคหรือด้านโดเมน มีการกำหนดแนวทางสำหรับหน่วยที่เล็กที่สุดที่สามารถนำไปใช้งานได้อย่างมีประสิทธิภาพ ซึ่งเรียกว่า "ควอนตา" แม้ว่าการตัดสินใจพื้นฐานเหล่านี้จะเกิดขึ้นในช่วงแรก แต่ก็อาจมีการทบทวนอีกครั้งในภายหลังหากจำเป็น
• ส่วนประกอบเริ่มต้นจะถูกกำหนดตามกลยุทธ์ที่วางไว้
• ข้อกำหนดต่างๆ จะถูกกำหนดให้กับส่วนประกอบที่ระบุไว้
• บทบาทและหน้าที่ความรับผิดชอบของแต่ละองค์ประกอบได้รับการวิเคราะห์เพื่อให้เกิดความชัดเจนและลดความซ้ำซ้อนให้น้อยที่สุด
• มีการประเมินคุณลักษณะทางสถาปัตยกรรม เช่น ความสามารถในการขยายขนาด ความทนทานต่อข้อผิดพลาด และความสามารถในการบำรุงรักษา
• ส่วนประกอบต่างๆ อาจได้รับการปรับโครงสร้างใหม่ตามข้อเสนอแนะจากทีมพัฒนา

วงจรนี้ทำหน้าที่เป็นกรอบการทำงานทั่วไปและสามารถปรับใช้กับโดเมนต่างๆ ได้

รูปแบบสถาปัตยกรรมที่ไม่เหมาะสมต่อไปนี้อาจเกิดขึ้นเมื่อสถาปนิกทำการตัดสินใจ รูปแบบที่ไม่เหมาะสมเหล่านี้มักจะเกิดขึ้นตามลำดับที่ก้าวหน้า โดยการแก้ไขปัญหาหนึ่งอาจนำไปสู่การเกิดขึ้นของอีกปัญหาหนึ่ง^{[ 2 ]}

• สถาปนิกอาจชะลอหรือหลีกเลี่ยงการตัดสินใจด้านสถาปัตยกรรมเนื่องจากกลัวว่าจะเลือกผิด เพื่อแก้ไขปัญหานี้ การทำงานร่วมกันอย่างต่อเนื่องและใกล้ชิดกับทีมพัฒนาจึงมักเป็นสิ่งจำเป็น โดยการเลือกด้านสถาปัตยกรรมจะได้รับการปรับเปลี่ยนตามความคิดเห็นของพวกเขา นอกจากนี้ โดยทั่วไปแล้ว การตัดสินใจจะเกิดขึ้นใน "ช่วงเวลาที่เหมาะสมที่สุด" เพื่อให้แน่ใจว่ามีข้อมูลเพียงพอที่จะพิสูจน์และตรวจสอบความถูกต้องของการตัดสินใจ ในขณะเดียวกันก็หลีกเลี่ยงความล่าช้าที่ไม่จำเป็นซึ่งอาจนำไปสู่ภาวะอัมพาตจากการวิเคราะห์และขัดขวางความคืบหน้าของทีม^{[ 2 ]}
• รูปแบบที่ไม่พึงประสงค์อีกประการหนึ่งอาจเกิดขึ้นเมื่อการตัดสินใจด้านสถาปัตยกรรมถูกลืม ไม่ได้รับการบันทึก หรือไม่เข้าใจ ทำให้เกิดการอภิปรายซ้ำแล้วซ้ำเล่าโดยไม่มีข้อสรุป ซึ่งมักเกิดขึ้นเมื่อใช้อีเมลในการสื่อสารการตัดสินใจด้านสถาปัตยกรรม เพื่อแก้ไขปัญหาเหล่านี้ สถาปนิกมักจะให้เหตุผลทั้งทางเทคนิคและทางธุรกิจในบันทึกเดียวของการตัดสินใจด้านสถาปัตยกรรม (โดยปกติคือบันทึกการตัดสินใจด้านสถาปัตยกรรม) บันทึกที่มีประสิทธิภาพมักจะรวมถึงชื่อเรื่อง สถานะ บริบทของปัญหา การตัดสินใจเฉพาะ และผลที่ตามมาหรือการแลกเปลี่ยน^{[ 3 ]}บันทึกนี้สามารถเก็บรักษาไว้ในที่เก็บข้อมูลที่เข้าถึงได้ เช่น วิกิ หรือโดยตรงภายในที่เก็บโค้ดโดยใช้Markdownการสื่อสารมุ่งเน้นไปที่ลักษณะและบริบทของการเปลี่ยนแปลง และมุ่งเป้าไปที่ผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องเท่านั้น เพื่อให้มั่นใจว่ามีแหล่งข้อมูลที่ถูกต้องเพียงแหล่งเดียวที่อัปเดตอยู่เสมอ นอกจากนี้ หากการตัดสินใจด้านสถาปัตยกรรมไม่ได้ให้คุณค่าทางธุรกิจ ที่จับต้องได้ หรือหากคุณค่าทางธุรกิจไม่สอดคล้องกับผู้มีส่วนได้ส่วนเสียทางธุรกิจ อาจจำเป็นต้องพิจารณาใหม่^{[ 2 ]}

• สถาปัตยกรรมซอฟต์แวร์
• วิศวกรรมซอฟต์แวร์
• รายชื่อรูปแบบและสไตล์สถาปัตยกรรมซอฟต์แวร์

• สมาคมสถาปนิกซอฟต์แวร์นานาชาติ (IASA)