ในครั้งที่ 12 เรายังคงค้างการเล่าถึงวิธี migrate service application จากเดิมไปสู่ microservices architecture และ DevOps ผู้สอนใช้ paper จาก IEEE Software ปี 2016 เป็นตัวอย่างถึงกระบวนการ วิธีการ การเปลี่ยนแปลง ขั้นตอนในการพิจารณา และท้ายสุด การเข้าสู้การปรับกระบวนการ release การพัฒนาทักษะของคน การจัดกลุ่มการทำทีม และการใช้ tools ต่างๆ เพื่อให้ microservices architecture นั้นสามารถ enabled DevOps culture ได้

ในครั้งที่ 12 เราทบทวน lecture 11 เกี่ยวกับ space-based architecture และ microservices architecture ใน lecture 12 เราเริ่มเนื้อหาที่นิยามของ DevOps ในมุม solution และในมุม architecture เราพูดคุยและวิเคราะห์กันต่อไปถึง implication ของ DevOps คุยกันเรื่องประวัติศาสตร์ที่มาของ DevOps บ้างเพื่อให้เข้าใจใน proposefulness โดยเราก็ไปจบ lecture เมื่อเล่าถึงองค์ประกอบที่สำคัญของ DevOps ทั้งในเรื่อง People Process และ Tools (ที่เป็นตัวแทน technology)

ในครั้งที่ 11 เราสรุป lecture 10 ในส่วนที่เป็น events และ services โดยเราจะนำเอาทั้งสองความหมายนี้มาใช้เป็น abstraction ของโครงสร้างสถาปัตยกรรมซอฟต์แวร์ สองแบบ คือ space-based architecture และ microservices architecture.

ในครั้งที่ 10, 11 และ 12 จะเป็นการให้ตัวอย่างถึงแนวทางการปฏิบัติในปัจจุบัน lecture 10 จะเป็นการบรรยายเกริ่นถึงการออกแบบซอฟต์แวร์ที่เรามีการใช้ abstraction เข้ามาช่วยในเรื่องของการแยกย่อยหน่วยในตัวปัญหาหรือ requirements โดยที่สถาปนิกซอฟต์แวร์ต้องพิจารณาคือการกำหนดให้มีโครงสร้างที่เหมาะสมกับการทำให้เกิดคุณสมบัติตามที่ต้องการ

ในครั้งที่เก้า บรรยายวันที่ 10 เม.ย. 64 เป็นการบรรยายต่อจากเนื้อหาคราวที่แล้วของ lecture 9 Security และ Simplicity ที่เรามีกิจกรรมให้ทำ ทำให้ไม่ทันในครั้งก่อนจึงยกมาทำในครั้งนี้ เนื้อหาส่วนของความมั่นคงปลอดภัยจะมีมาก และมีหลายเรื่องที่ต้องเกริ่นให้ฟัง แต่ไม่ได้ลงในรายละเอียด ทำให้เราจึงใช้ เวลาอีกเกือบ 1 ชั่วโมงทำกิจกรรมออนไลน์​ (ไม่ได้โพสเทปไว้)

ในครั้งที่เก้า บรรยายวันที่ 3 เม.ย. 64 เรามีบรรยายสรุปส่วนที่เป็นเนื้อหาก่อนหน้านี้คือ scalability และ agility โดย property ทั้งสองแสดงให้เห็นถึงปัจจัยของ software dependency ที่มีผลต่อ fault isolation และ development agility ตามลำดับ ใน lecture ที่ 9 เราจะกล่าวถึง security in software development และ software simplicity ที่เป็น architecture property ที่มีความหมายกว้างครอบคลุม interactions จาก contexts ที่อาจจะควบคุมไม่ได้เพราะไม่รู้ หรือมีเหตุการณ์ที่จะเกิดขึ้นโดยธรรมชาติ นอกเหนือไปจากปัจจัยในตัวซอฟต์แวร์เอง (ตาม open systems definition ใน systems thinking)

ในครั้งที่แปด บรรยายวันที่ 13 มี.ค. 64 เรามีบรรยายสรุปส่วนที่เป็นเนื้อหาก่อนหน้านี้คือ performance และ availability ที่เป็น architecture property ที่ตรงไปตรงมา มีนิยามชัดเจน การวัดทำได้โดยง่าย ใน lecture 8 เรานำเอาคุณลักษณะของซอฟต์แวร์ ที่สนับสนุนกันมาใช้ได้แก่ วิธี schedule และการมี fault isolation property ของซอฟต์แวร์ เพื่อทำให้เกิด scalability

ในครั้งที่เจ็ด 6 มี.ค. 64 เรามีบรรยายสรุปส่วนที่เป็นเนื้อหาก่อนหน้านี้ และเริ่มเข้าสู่การยกตัวอย่างที่ครบสี่กระบวนการ model, design, measure, และ evaluate ที่จะทำเป็นตัวอย่างกับ architectural properties ที่สำคัญของซอฟต์แวร์ ได้แก่ performance และ availability

ในครั้งที่หก 27 ก.พ. 64 เรามี recap lecture 5 ได้คุยต่อเรื่อง trade offs ของ architectural properties และยกตัวอย่าง trade offs และในช่วงที่สองเราได้คุยกันในรายละเอียดของ software architecture process ที่จะนำมาใช้ใน lecture ต่อไป ซึ่งจะเป็นแบบง่ายๆ ที่ adopt มา ก่อนจบเรามีการเปรียบเทียบ process ที่ใช้กับ ATAM (architectural trade-off analysis method)

ในครั้งที่ห้า 20 ก.พ. 64 เรามี recap lecture 4 ได้คุยต่อเรื่อง ISO 42010 ที่ค้างไว้ รวมถึงอธิบายความสัมพันธ์ระหว่าง concern viewpoints และ views เพิ่มเติม และอธิบายรวมถึงยกตัวอย่าง คุณสมบัติทางสถาปัตยกรรม (Architectural properties) ที่มีทั้งแบบ primitive และ compound