On architecture

ในสภาพแวดล้อมแบบ On-premises ลูกค้ามักจะมีทีม Architecture เทคโนโลยีส่วนกลาง (Central Team) ที่ทำหน้าที่กำกับดูแลทีมผลิตภัณฑ์หรือทีมฟีเจอร์อื่น ๆ เพื่อตรวจสอบว่าพวกเขาปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด (Best Practice) หรือไม่ โดยปกติทีม Architecture เทคโนโลยีจะประกอบด้วยบทบาทต่าง ๆ เช่น: Technical Architect (โครงสร้างพื้นฐาน), Solutions Architect (ซอฟต์แวร์), Data Architect, Networking Architect และ Security Architect ซึ่งบ่อยครั้งทีมเหล่านี้จะใช้ TOGAF หรือ Zachman Framework เป็นส่วนหนึ่งของขีดความสามารถด้าน Architecture องค์กร

ที่ AWS เรานิยมกระจายขีดความสามารถเหล่านี้ไปยังทีมต่าง ๆ มากกว่าการมีทีมส่วนกลางเพียงทีมเดียว แน่นอนว่ามีความเสี่ยงเมื่อคุณเลือกที่จะกระจายอำนาจการตัดสินใจ เช่น การตรวจสอบว่าแต่ละทีมบรรลุมาตรฐานภายในหรือไม่ เราลดความเสี่ยงเหล่านี้ด้วยสองวิธี: วิธีแรก เรามี แนวปฏิบัติ (Practices) (วิธีการทำงาน, กระบวนการ, มาตรฐาน และบรรทัดฐานที่ยอมรับร่วมกัน) ที่มุ่งเน้นการส่งเสริมให้แต่ละทีมมีขีดความสามารถนั้นด้วยตัวเอง และเราจัดตั้งผู้เชี่ยวชาญเพื่อตรวจสอบว่าแต่ละทีมได้ยกระดับมาตรฐานที่พวกเขาต้องบรรลุ วิธีที่สอง เรานำ กลไก (Mechanisms) มาใช้เพื่อดำเนินการตรวจสอบโดยอัตโนมัติเพื่อให้มั่นใจว่ามีการปฏิบัติตามมาตรฐาน

“ความตั้งใจดีเพียงอย่างเดียวไม่เคยได้ผล คุณต้องมีกลไกที่ดีเพื่อทำให้สิ่งต่าง ๆ เกิดขึ้นจริง” — Jeff Bezos

นี่หมายถึงการแทนที่ความพยายามอย่างเต็มที่ของมนุษย์ด้วยกลไก (ซึ่งมักจะเป็นระบบอัตโนมัติ) เพื่อตรวจสอบการปฏิบัติตามกฎหรือกระบวนการ แนวทางการกระจายอำนาจนี้ได้รับการสนับสนุนโดย หลักการความเป็นผู้นำของ Amazon (Amazon Leadership Principles) และเป็นการสร้างวัฒนธรรมในทุกบทบาทหน้าที่ที่ให้ ยึดความต้องการของลูกค้าเป็นตัวตั้ง (Works back from the customer) การทำงานย้อนกลับจากลูกค้าคือส่วนสำคัญพื้นฐานในกระบวนการนวัตกรรมของเรา เราเริ่มจากลูกค้าและสิ่งที่พวกเขาต้องการ แล้วปล่อยให้สิ่งนั้นเป็นตัวกำหนดและชี้แนะความพยายามของเรา ทีมที่ยึดติดกับลูกค้า (Customer-obsessed) จะสร้างผลิตภัณฑ์เพื่อตอบสนองต่อความต้องการของลูกค้า

สำหรับด้าน Architecture นี่หมายความว่าเราคาดหวังให้ทุกทีมมีความสามารถในการสร้าง Architecture และปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด เพื่อช่วยให้ทีมใหม่ได้รับขีดความสามารถเหล่านี้ หรือช่วยทีมเดิมยกระดับมาตรฐานให้สูงขึ้น เราจึงเปิดช่องทางให้เข้าถึงชุมชนเสมือนของเหล่า Principal Engineers ที่สามารถช่วยรีวิวการออกแบบและช่วยให้พวกเขาเข้าใจว่าแนวทางปฏิบัติที่ดีที่สุดของ AWS คืออะไร ชุมชน Principal Engineering ทำงานเพื่อให้แนวทางปฏิบัติที่ดีที่สุดนั้นชัดเจนและเข้าถึงได้ ตัวอย่างเช่น การจัดกิจกรรม Lunchtime talks ที่เน้นการนำแนวทางปฏิบัติที่ดีที่สุดไปใช้กับตัวอย่างจริง ซึ่งการบรรยายเหล่านี้จะถูกบันทึกไว้และสามารถนำไปใช้เป็นส่วนหนึ่งของสื่อการสอนสำหรับสมาชิกทีมใหม่ได้

แนวทางปฏิบัติที่ดีที่สุดของ AWS เกิดขึ้นจากประสบการณ์การรันระบบนับพันระบบในระดับอินเทอร์เน็ต (Internet scale) เรานิยมใช้ "Data" ในการกำหนดแนวทางปฏิบัติที่ดีที่สุด แต่เราก็ใช้ผู้เชี่ยวชาญเฉพาะด้าน (Subject Matter Experts) เช่น Principal Engineers เป็นผู้กำหนดด้วยเช่นกัน เมื่อ Principal Engineers เห็นแนวทางปฏิบัติที่ดีที่สุดใหม่ ๆ เกิดขึ้น พวกเขาจะทำงานร่วมกันเป็นชุมชนเพื่อตรวจสอบว่าทีมต่าง ๆ ได้ปฏิบัติตาม ในเวลาต่อมาแนวทางปฏิบัติเหล่านี้จะถูกกำหนดเป็นกระบวนการรีวิวภายในอย่างเป็นทางการ และถูกสร้างเป็นกลไกที่บังคับใช้การปฏิบัติตาม (Compliance) โดย Well-Architected Framework คือการนำกระบวนการรีวิวภายในของเรามาปรับใช้ในรูปแบบที่ลูกค้าเข้าถึงได้ ซึ่งเราได้รวบรวมแนวคิดของ Principal Engineering ผ่านบทบาทหน้างาน เช่น Solutions Architecture และทีมวิศวกรรมภายในไว้ด้วยกัน Well-Architected Framework จึงเป็นกลไกที่ขยายขนาดได้ (Scalable mechanism) ที่ช่วยให้คุณได้รับประโยชน์จากการเรียนรู้เหล่านี้

ด้วยการปฏิบัติตามแนวทางของชุมชน Principal Engineering พร้อมการกระจายความเป็นเจ้าของด้าน Architecture เราเชื่อว่า Architecture องค์กรที่เป็นไปตามหลัก Well-Architected จะเกิดขึ้นได้โดยมีจุดเด่นจากการขับเคลื่อนด้วยความต้องการของลูกค้า ผู้นำด้านเทคโนโลยี (เช่น CTO หรือผู้จัดการฝ่ายพัฒนา) ที่ดำเนินการรีวิวแบบ Well-Architected ในทุกเวิร์กโหลดจะช่วยให้คุณเข้าใจความเสี่ยงในพอร์ตโฟลิโอเทคโนโลยีของคุณได้ดียิ่งขึ้น ด้วยวิธีนี้คุณสามารถระบุประเด็นร่วมกันในแต่ละทีมที่องค์กรสามารถแก้ไขได้ผ่านกลไก การฝึกอบรม หรือ Lunchtime talks ที่ Principal Engineers ของคุณสามารถแบ่งปันแนวคิดในหัวข้อเฉพาะเจาะจงกับหลาย ๆ ทีมพร้อมกันได้