What's in a Name? (ชื่อนี้มีความหมายว่าอย่างไร)

You keep using that word. I do not think it means what you think it means.

Inigo Montoya, from The Princess Bride

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

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

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

ผม ไม่ได้พูดแบบนี้เพื่อดูถูกคำว่า software engineering , 1 ที่ Margaret Hamilton บัญญัติขึ้นในยุค 1960 แต่คำนี้เป็นความมุ่งหวังพอๆ กับที่เป็นความจริงในตอนนั้น คำนี้เกิดขึ้นเพื่อเรียกร้องให้ปรับปรุงคุณภาพของซอฟต์แวร์ที่สร้างขึ้น และเป็นการยอมรับว่าโครงการซอฟต์แวร์มักล้มเหลว ทั้งที่ถูกนำไปใช้ในงานที่สำคัญต่อภารกิจและความปลอดภัยมากขึ้นเรื่อยๆ มีความพยายามมากมายในการปรับปรุงสถานการณ์นับแต่นั้นมา แต่จากประสบการณ์ 20 ปีในวงการของผมเอง ผมมองว่าเรายังต้องเรียนรู้อีกมากในการทำงานให้ดี (หรืออย่างน้อยก็ดีขึ้น)

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

บางทีคำว่า architect หรืออย่างน้อยความเข้าใจทั่วไปเกี่ยวกับสิ่งที่สถาปนิกทำ อาจเป็นสิ่งที่สร้างความเสียหายมากที่สุดในแง่นี้ นั่นคือแนวคิดของคนที่วาดแผนละเอียดยิบให้คนอื่นตีความ และคาดหวังให้ทำตาม ความสมดุลระหว่างศิลปินกับวิศวกร ที่คอยควบคุมดูแลการสร้างสิ่งที่มักเป็นวิสัยทัศน์เดียว โดยมุมมองอื่นทั้งหมดต้องยอมตาม ยกเว้นข้อโต้แย้งเป็นครั้งคราวจากวิศวกรโครงสร้างเรื่องกฎฟิสิกส์ ในวงการของเรา มุมมองแบบนี้ต่อสถาปนิกนำไปสู่แนวปฏิบัติที่แย่มาก สถาปนิกสร้างไดอะแกรมแล้วไดอะแกรมเล่า เอกสารหน้าแล้วหน้าเล่า โดยหวังจะกำหนดการสร้างระบบที่สมบูรณ์แบบ ในขณะที่ล้มเหลวที่จะคำนึงถึงอนาคตที่ไม่มีทางรู้ได้แน่นอน และไม่มีความเข้าใจเลยว่าแผนของพวกเขาจะยากแค่ไหนในการนำไปปฏิบัติจริง หรือจะได้ผลจริงหรือไม่ ยังไม่ต้องพูดถึงความสามารถในการเปลี่ยนแปลงเมื่อเรารู้มากขึ้น

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

ดังนั้นถ้าสถาปัตยกรรมซอฟต์แวร์แตกต่างจากสถาปัตยกรรมของสิ่งปลูกสร้าง บางทีเราควรจะชัดเจนขึ้นว่าสถาปัตยกรรมซอฟต์แวร์คืออะไรกันแน่