Architecture and Engineering Practices (สถาปัตยกรรมกับ Engineering Practices)

ในช่วงปลายศตวรรษที่ 20 methodology ในการพัฒนาซอฟต์แวร์หลายสิบแบบได้รับความนิยม รวมถึง Waterfall และ Agile หลายรูปแบบ (เช่น Scrum, Extreme Programming, Lean และ Crystal) ในเวลานั้น สถาปนิกส่วนใหญ่เชื่อว่าสิ่งเหล่านี้ไม่ส่งผลต่อสถาปัตยกรรมซอฟต์แวร์ และมองว่าการพัฒนาเป็นกระบวนการที่แยกออกจากกันโดยสิ้นเชิง อย่างไรก็ตาม ในช่วงหลายปีที่ผ่านมา ความก้าวหน้าด้าน engineering ได้นำประเด็นด้าน process เข้ามาสู่สถาปัตยกรรมซอฟต์แวร์ การแยก process ในการพัฒนาซอฟต์แวร์ออกจาก engineering practices นั้นมีประโยชน์ เมื่อพูดถึง process เราหมายถึงวิธีการจัดตั้งและบริหารทีม วิธีจัดประชุมและจัด workflow กล่าวโดยสรุปคือกลไกที่คนจัดระเบียบและมีปฏิสัมพันธ์กัน ส่วน engineering practices หมายถึงเทคนิคและเครื่องมือที่ไม่ขึ้นกับ process ซึ่งทีมใช้ในการพัฒนาและ release ซอฟต์แวร์ ตัวอย่างเช่น Extreme Programming (XP), continuous integration (CI), continuous delivery (CD) และ test-driven development (TDD) ล้วนเป็น engineering practice ที่พิสูจน์แล้วว่าได้ผล และไม่ขึ้นกับ process ใดโดยเฉพาะ ดังนั้น คำว่า software engineering จึงครอบคลุมทั้งการพัฒนาซอฟต์แวร์และ practice เหล่านี้

การให้ความสำคัญกับ engineering practices เป็นเรื่องสำคัญ การพัฒนาซอฟต์แวร์ยังขาด feature หลายอย่างที่มีอยู่ในสาขา engineering ที่เติบโตเต็มที่กว่า ตัวอย่างเช่น วิศวกรโยธาสามารถคาดการณ์การเปลี่ยนแปลงเชิงโครงสร้างได้แม่นยำกว่าที่วิศวกรซอฟต์แวร์จะคาดการณ์แง่มุมที่คล้ายกันของโครงสร้างซอฟต์แวร์ได้มาก นั่นหมายความว่าจุดอ่อนที่สุดของการพัฒนาซอฟต์แวร์คือการประเมิน (estimation) ว่าจะใช้เวลาเท่าไร resource เท่าไร เงินเท่าไร ส่วนหนึ่งที่ทำให้เรื่องนี้ยากคือ practice การประเมินแบบดั้งเดิมไม่รองรับธรรมชาติเชิงสำรวจของการพัฒนาซอฟต์แวร์และสิ่งที่ไม่รู้ล่วงหน้าซึ่งมักเกิดขึ้นเมื่อพัฒนาซอฟต์แวร์

แม้ process ส่วนใหญ่จะแยกจากสถาปัตยกรรม แต่ iterative process กลับเข้ากับธรรมชาติของสถาปัตยกรรมได้ดีกว่า การพยายามสร้างระบบสมัยใหม่อย่าง microservices ด้วย process ล้าสมัยอย่าง Waterfall จะสร้างความขัดแย้งอย่างมาก แง่มุมหนึ่งของสถาปัตยกรรมที่ Agile methodology โดดเด่นจริงๆ คือการย้ายจาก architectural style หนึ่งไปสู่อีกแบบหนึ่ง Agile methodology รองรับการเปลี่ยนแปลงเช่นนี้ได้ดีกว่า process ที่เน้นการวางแผนหนักๆ เพราะมี feedback loop ที่รวดเร็ว และสนับสนุนเทคนิคอย่าง Strangler Pattern และ feature toggle

สถาปนิกมักทำหน้าที่เป็น project technical leader ด้วย ซึ่งหมายความว่าต้องเป็นผู้กำหนด engineering practice ที่ทีมใช้ เช่นเดียวกับการพิจารณา problem domain อย่างรอบคอบก่อนเลือกสถาปัตยกรรม สถาปนิกก็ต้องมั่นใจว่า architectural style และ engineering practice ของตนเข้ากันได้ดี ตัวอย่างเช่น ปรัชญาของ microservices architecture ตั้งสมมติฐานว่าทีมจะทำ automate สิ่งต่างๆ เช่น machine provisioning, testing และ deployment การพยายามสร้าง microservices architecture ด้วยทีม operations ที่ล้าสมัย process แบบ manual และการทดสอบที่น้อยมักนำไปสู่ความล้มเหลว เช่นเดียวกับที่ problem domain ต่างกันเหมาะกับ architectural style ต่างกัน engineering practice ที่ต่างกันก็เช่นกัน

วิวัฒนาการทางความคิดยังคงดำเนินต่อไป จาก Extreme Programming สู่ continuous delivery และไกลกว่านั้น เมื่อความก้าวหน้าด้าน engineering practice เปิดทางให้ความสามารถทางสถาปัตยกรรมใหม่ๆ เป็นไปได้ หนังสือของ Neal Building Evolutionary Architectures นำเสนอวิธีคิดใหม่เกี่ยวกับจุดตัดระหว่าง engineering practice กับสถาปัตยกรรม ซึ่งช่วยปรับปรุงวิธีที่เรา automate architectural governance ได้ หนังสือเล่มนี้เสนอศัพท์ใหม่ที่สำคัญและวิธีคิดเกี่ยวกับ architectural characteristics และครอบคลุมเทคนิคสำหรับสร้างสถาปัตยกรรมที่เปลี่ยนแปลงได้อย่างราบรื่นตามกาลเวลา

ในโลกของการพัฒนาซอฟต์แวร์ ไม่มีสิ่งใดหยุดนิ่ง สถาปนิกอาจออกแบบระบบให้ตรงตามเกณฑ์บางอย่าง แต่เพื่อให้แน่ใจว่า design ของพวกเขาจะอยู่รอดทั้งการ implement และการเปลี่ยนแปลงที่หลีกเลี่ยงไม่ได้ สิ่งที่เราต้องการคือ evolutionary architecture

Building Evolutionary Architectures แนะนำแนวคิดของการใช้ architectural fitness function เพื่อปกป้อง (และควบคุม) architectural characteristics เมื่อการเปลี่ยนแปลงเกิดขึ้นตามกาลเวลา จำได้ไหมจาก Chapter 6 ว่า architectural fitness function เป็นวิธีการประเมินความสมบูรณ์อย่างเป็นภาวะวิสัยของ architectural characteristic บางอย่าง การประเมินนี้อาจรวมกลไกหลายอย่าง เช่น metric, unit test, monitor และ chaos engineering

เพื่อดูว่า fitness function ช่วยทำให้จุดตัดนี้สอดคล้องกันได้อย่างไร ลองพิจารณาปัญหาทางธุรกิจที่ต้องการ time to market ที่รวดเร็ว Time to market แปลว่า agility นั่นคือความสามารถของระบบในการตอบสนองต่อการเปลี่ยนแปลงอย่างรวดเร็ว Agility เป็น composite architectural characteristic ที่ประกอบด้วย maintainability, testability และ deployability (ดู Chapter 6 ) ทั้งสาม architectural characteristics นี้ได้รับอิทธิพลจาก engineering practice และขั้นตอนต่างๆ และด้วยเหตุนี้จึงสามารถวัดและติดตามผ่าน fitness function ได้ ตัวอย่างเช่น ทั้ง microservices และ service-based architecture รองรับ agility ในระดับสูง อย่างไรก็ตาม หาก engineering practice ที่เกี่ยวข้องกับ architectural characteristics เหล่านี้ไม่สอดคล้องกับสถาปัตยกรรม ระบบจะไม่บรรลุเป้าหมายและความต้องการด้าน agility เหล่านั้น fitness function สามารถช่วยระบุความไม่สอดคล้องได้ กระตุ้นให้สถาปนิกดำเนินการเพื่อปรับ engineering practice ให้สอดคล้องกับสถาปัตยกรรม (หรือในทางกลับกัน)