การศึกษาเหล่านี้เผยให้เห็นความแตกต่างระหว่างบุคคลอย่างมากระหว่างผู้ปฏิบัติงานที่มีประสิทธิภาพสูงและต่ำ ซึ่งมักจะต่างกันถึงระดับสิบเท่า
— SACKMAN, ERIKSON, AND GRANT [1]
ในการประชุมสมาคมคอมพิวเตอร์ เรามักจะได้ยินผู้จัดการทีมพัฒนารุ่นใหม่ยืนยันว่าพวกเขาชอบทีมเล็กที่เฉียบคมซึ่งประกอบด้วยคนเก่ง ๆ มากกว่าโปรเจกต์ที่มีโปรแกรมเมอร์เป็นร้อยคนซึ่งก็หมายถึงคนระดับกลาง ๆ โดยนัย เราทุกคนก็คิดแบบนั้น
แต่การพูดถึงทางเลือกแบบง่าย ๆ แบบนี้กลับหลีกเลี่ยงปัญหาที่ยากจริง ๆ นั่นคือเราจะสร้างระบบ_ขนาดใหญ่_ให้เสร็จตามกำหนดเวลาที่มีความหมายได้อย่างไร? ลองมาดูปัญหานี้ในแต่ละแง่มุมให้ละเอียดกัน
The Problem (ปัญหา)
ผู้จัดการฝ่ายพัฒนาโปรแกรมตระหนักมานานแล้วถึงความแตกต่างด้าน productivity ระหว่างโปรแกรมเมอร์ที่ดีและไม่ดีอย่างมากมาย แต่ขนาดที่วัดได้จริงกลับทำให้พวกเราทุกคนตกใจ ในการศึกษาหนึ่ง Sackman, Erikson และ Grant ได้วัดประสิทธิภาพของกลุ่มโปรแกรมเมอร์ที่มีประสบการณ์ ภายในกลุ่มนี้เพียงกลุ่มเดียว อัตราส่วนระหว่างประสิทธิภาพที่ดีที่สุดและแย่ที่สุดเฉลี่ยอยู่ที่ประมาณ 10:1 ในด้านการวัด productivity และที่น่าทึ่งคือ 5:1 ในด้านความเร็วและขนาดของโปรแกรม! กล่าวโดยสรุป โปรแกรมเมอร์ที่ได้ $20,000/ปี อาจมี productivity สูงกว่าโปรแกรมเมอร์ที่ได้ $10,000/ปี ถึง 10 เท่า ในทางกลับกันก็อาจเป็นจริงได้เช่นกัน ข้อมูลไม่พบความสัมพันธ์ใด ๆ ระหว่างประสบการณ์และประสิทธิภาพเลย (ผมสงสัยว่าข้อนั้นจะเป็นจริงในทุกกรณีหรือไม่)
ผมได้แย้งมาก่อนแล้วว่าจำนวนคนที่ต้องประสานงานกันส่งผลต่อต้นทุนของความพยายามในการทำงาน เพราะต้นทุนส่วนใหญ่คือการสื่อสารและการแก้ไขผลกระทบจากการสื่อสารที่ผิดพลาด (system debugging) ซึ่งนี่ยิ่งชี้ให้เห็นว่าเราอยากให้ระบบถูกสร้างโดยคนจำนวนน้อยที่สุดเท่าที่จะเป็นไปได้ อันที่จริง ประสบการณ์ส่วนใหญ่กับระบบโปรแกรมขนาดใหญ่แสดงให้เห็นว่าแนวทางการใช้คนจำนวนมากนั้นมีต้นทุนสูง ช้า ไม่มีประสิทธิภาพ และสร้างระบบที่ขาดความสอดคล้องกันในเชิงแนวคิด OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE ฯลฯ — รายการนี้ยาวเหยียด
ข้อสรุปนั้นง่ายมาก ถ้าโปรเจกต์ 200 คนมีผู้จัดการ 25 คนที่เป็นโปรแกรมเมอร์ที่เก่งที่สุดและมีประสบการณ์มากที่สุด ก็ให้ไล่คน 175 คนที่เหลือออก แล้วให้ผู้จัดการเหล่านั้นกลับมาเขียนโปรแกรม
ทีนี้ลองมาพิจารณาวิธีแก้ปัญหานี้กัน ในแง่หนึ่ง มันไม่เข้าใกล้อุดมคติของทีมที่_เล็ก_และเฉียบคม ซึ่งโดยความเห็นร่วมกันแล้วไม่ควรเกิน 10 คน ทีมที่มีขนาดใหญ่ขนาดนี้จำเป็นต้องมีผู้จัดการอย่างน้อยสองระดับ หรือประมาณห้าคน และยังต้องการการสนับสนุนด้านการเงิน บุคลากร พื้นที่ทำงาน เลขานุการ และผู้ควบคุมเครื่องจักร
ในอีกแง่หนึ่ง ทีม 200 คนเดิมก็ยังไม่ใหญ่พอที่จะสร้างระบบที่ใหญ่อย่างแท้จริงด้วยวิธีการใช้คนจำนวนมาก ลองพิจารณา OS/360 เป็นตัวอย่าง ในช่วงพีค มีคนมากกว่า 1,000 คนทำงานบนระบบนี้ — โปรแกรมเมอร์ นักเขียน ผู้ควบคุมเครื่องจักร เสมียน เลขานุการ ผู้จัดการ กลุ่มสนับสนุน และอื่น ๆ ตั้งแต่ปี 1963 ถึง 1966 อาจมี man-years ถึง 5,000 ปีที่ทุ่มเทให้กับการออกแบบ การสร้าง และการทำเอกสาร ทีม 200 คนตามสมมติฐานของเราจะใช้เวลา 25 ปีเพื่อนำผลิตภัณฑ์มาสู่จุดที่เป็นอยู่ในปัจจุบัน ถ้าคนและเดือนสามารถแทนที่กันได้อย่างเท่าเทียม!
นี่คือปัญหาของแนวคิดทีมเล็กที่เฉียบคม: มันช้าเกินไปสำหรับระบบที่ใหญ่จริง ๆ ลองพิจารณางาน OS/360 ถ้าทำด้วยทีมเล็กที่เฉียบคม สมมติให้มีทีม 10 คน เพื่อหาค่าประมาณสูงสุด ให้พวกเขามี productivity มากกว่าโปรแกรมเมอร์ระดับกลางถึง 7 เท่าทั้งในด้านการเขียนโปรแกรมและการทำเอกสาร เพราะพวกเขาเฉียบคม สมมติให้ OS/360 ถูกสร้างโดยโปรแกรมเมอร์ระดับกลางเท่านั้น (ซึ่ง_ห่างไกล_จากความจริงมาก) ให้ค่าประมาณสูงสุดอีกครั้ง สมมติว่าปัจจัยการปรับปรุง productivity อีก 7 เท่ามาจากการสื่อสารที่ลดลงของทีมที่เล็กกว่า สมมติให้ทีม_ชุดเดิม_ทำงานนี้ตั้งแต่ต้นจนจบ เอาล่ะ 5000/(10 x 7 x 7) = 10 พวกเขาสามารถทำงาน 5,000 man-year ให้เสร็จใน 10 ปี แล้วผลิตภัณฑ์จะยังน่าสนใจอยู่หรือไม่หลังจากออกแบบมา 10 ปี? หรือมันจะล้าสมัยไปแล้วเพราะเทคโนโลยีซอฟต์แวร์ที่พัฒนาอย่างรวดเร็ว?
นี่เป็นภาวะกลืนไม่เข้าคายไม่ออกที่โหดร้าย เพื่อประสิทธิภาพและความสอดคล้องทางแนวคิด เราต้องการสมองดี ๆ สองสามคนในการออกแบบและสร้างระบบ แต่สำหรับระบบขนาดใหญ่ เราต้องการวิธีการนำกำลังคนจำนวนมากมาใช้เพื่อให้ผลิตภัณฑ์ออกมาทันเวลา แล้วความต้องการทั้งสองนี้จะประสานกันได้อย่างไร?
Mills's Proposal (ข้อเสนอของ Mills)
ข้อเสนอจาก Harlan Mills นำเสนอวิธีการแก้ปัญหาที่สดใหม่และสร้างสรรค์[2] Mills เสนอว่าแต่ละส่วนของงานใหญ่ควรถูกจัดการโดยทีม แต่ทีมนั้นควรถูกจัดระเบียบเหมือนทีมศัลยกรรม มากกว่าทีมเชือดหมู กล่าวคือ แทนที่สมาชิกแต่ละคนจะลงมือจัดการปัญหากันเอง คนคนหนึ่งจะเป็นคนลงมือหลัก และคนอื่น ๆ จะสนับสนุนเขาอย่างเต็มที่เพื่อเพิ่มประสิทธิภาพและ productivity ของเขา
ลองคิดดูเล็กน้อยก็จะเห็นว่าแนวคิดนี้ตอบโจทย์สิ่งที่ต้องการ ถ้ามันสามารถทำให้ใช้งานได้จริง สมองไม่กี่คนมีส่วนร่วมในการออกแบบและสร้าง แต่กลับใช้แรงงานจำนวนมากได้ มันจะใช้ได้จริงหรือ? ใครคือวิสัญญีแพทย์และพยาบาลในทีมโปรแกรมming และงานจะถูกแบ่งกันอย่างไร? ให้ผมผสม metaphor อย่างอิสระเพื่อเสนอว่าทีมแบบนี้จะทำงานอย่างไรถ้าขยายให้รวมการสนับสนุนทุกรูปแบบที่พอจะนึกถึง
The surgeon (ศัลยแพทย์). Mills เรียกเขาว่า chief programmer เขาเป็นคนกำหนด spec ด้านฟังก์ชันและประสิทธิภาพด้วยตนเอง ออกแบบโปรแกรม เขียนโค้ด ทดสอบ และเขียนเอกสารประกอบ เขาเขียนด้วยภาษาโปรแกรมที่มีโครงสร้างเช่น PL/I และสามารถเข้าถึงระบบคอมพิวเตอร์ที่ไม่เพียงแต่รัน test ของเขา แต่ยังเก็บเวอร์ชันต่าง ๆ ของโปรแกรมของเขา อัปเดตไฟล์ได้ง่าย และมี text editing สำหรับเอกสารของเขา เขาต้องการพรสวรรค์ที่ยอดเยี่ยม ประสบการณ์สิบปี และความรู้ด้านระบบและแอปพลิเคชันอย่างมาก ไม่ว่าจะเป็นคณิตศาสตร์ประยุกต์ การจัดการข้อมูลทางธุรกิจ หรืออะไรก็ตาม
The copilot (นักบินร่วม). เขาเป็น alter ego ของศัลยแพทย์ สามารถทำงานส่วนใดก็ได้ แต่มีประสบการณ์น้อยกว่า หน้าที่หลักของเขาคือการมีส่วนร่วมในการออกแบบในฐานะนักคิด ผู้ร่วมอภิปราย และผู้ประเมิน ศัลยแพทย์ลองไอเดียกับเขา แต่ไม่จำเป็นต้องทำตามคำแนะนำของเขา copilot มักจะเป็นตัวแทนของทีมในการหารือเกี่ยวกับฟังก์ชันและ interface กับทีมอื่น เขารู้จักโค้ดทั้งหมดอย่างลึกซึ้ง เขาค้นคว้ากลยุทธ์การออกแบบทางเลือก เขาทำหน้าที่เป็นหลักประกันเมื่อศัลยแพทย์ประสบเหตุการณ์ร้ายแรงอย่างชัดเจน เขาอาจเขียนโค้ดได้ แต่เขาไม่รับผิดชอบโค้ดส่วนใดเลย
The administrator (ผู้บริหาร). ศัลยแพทย์เป็นหัวหน้า และเขาต้องมีสิทธิ์ขาดในเรื่องบุคลากร การขึ้นเงินเดือน พื้นที่ทำงาน และอื่น ๆ แต่เขาแทบจะไม่ต้องใช้เวลากับเรื่องเหล่านี้เลย ดังนั้นเขาจึงต้องการผู้บริหารมืออาชีพที่จัดการเรื่องเงิน คน พื้นที่ และเครื่องจักร และเป็นคนประสานงานกับกลไกการบริหารขององค์กรที่เหลือ Baker แนะนำว่าผู้บริหารจะมีงานเต็มเวลาเฉพาะเมื่อโปรเจกต์มีข้อกำหนดด้านกฎหมาย สัญญา การรายงาน หรือการเงินที่มีนัยสำคัญเนื่องจากความสัมพันธ์ระหว่างผู้ใช้และผู้ผลิต มิฉะนั้น ผู้บริหารหนึ่งคนสามารถดูแลได้สองทีม
The editor (บรรณาธิการ). ศัลยแพทย์รับผิดชอบในการสร้างเอกสารประกอบ — เพื่อความชัดเจนสูงสุด เขาต้องเขียนมันเอง ซึ่งเป็นจริงทั้งสำหรับคำอธิบายภายนอกและภายใน อย่างไรก็ตาม บรรณาธิการจะนำร่างหรือต้นฉบับที่ศัลยแพทย์ผลิตขึ้น วิจารณ์ ปรับปรุง เพิ่มข้อมูลอ้างอิงและบรรณานุกรม ดูแลมันผ่านหลายเวอร์ชัน และควบคุมกลไกการผลิต
Two secretaries (เลขานุการสองคน). ผู้บริหารและบรรณาธิการแต่ละคนต้องการเลขานุการหนึ่งคน เลขานุการของผู้บริหารจะจัดการจดหมายโต้ตอบของโปรเจกต์และไฟล์ที่ไม่ใช่ส่วนของผลิตภัณฑ์
The program clerk (เสมียนโปรแกรม). เขารับผิดชอบในการดูแลบันทึกทางเทคนิคทั้งหมดของทีมใน programming-product library เสมียนคนนี้ได้รับการฝึกฝนเป็นเลขานุการและรับผิดชอบทั้งไฟล์ที่เครื่องอ่านได้และที่มนุษย์อ่านได้
ข้อมูลนำเข้าคอมพิวเตอร์ทั้งหมดจะไปที่เสมียน ซึ่งจะบันทึกและป้อนข้อมูลหากจำเป็น ผลลัพธ์ที่พิมพ์ออกมาจะกลับมาที่เขาเพื่อจัดเก็บและทำดัชนี การรันล่าสุดของโมเดลใด ๆ จะถูกเก็บไว้ในสมุดสถานะ ส่วนที่เก่ากว่าทั้งหมดจะถูกจัดเก็บในคลังตามลำดับเวลา
สิ่งที่สำคัญอย่างยิ่งต่อแนวคิดของ Mills คือการเปลี่ยนแปลงการเขียนโปรแกรม "จากศิลปะส่วนตัวสู่การปฏิบัติสาธารณะ" โดยทำให้_การรันคอมพิวเตอร์ทั้งหมด_มองเห็นได้แก่สมาชิกทุกคนในทีม และระบุว่าโปรแกรมและข้อมูลทั้งหมดเป็นสมบัติของทีม ไม่ใช่สมบัติส่วนตัว
ฟังก์ชันเฉพาะทางของเสมียนโปรแกรมช่วยลดภาระงานธุรการของโปรแกรมเมอร์ ทำให้งานที่มักถูกละเลยเหล่านี้เป็นระบบและมีประสิทธิภาพ และเพิ่มมูลค่าให้กับทรัพย์สินที่มีค่าที่สุดของทีม—นั่นคือผลงานที่ผลิตขึ้น อย่างชัดเจน แนวคิดที่อธิบายข้างต้นสมมติให้มีการประมวลผลแบบ batch เมื่อมีการใช้เทอร์มินัลแบบโต้ตอบ โดยเฉพาะแบบที่ไม่มีผลลัพธ์ hard-copy ฟังก์ชันของเสมียนโปรแกรมไม่ได้ลดลง แต่เปลี่ยนไป ตอนนี้เขาจะบันทึกการอัปเดตทั้งหมดของสำเนาโปรแกรมของทีมจากสำเนาทำงานส่วนตัว ยังคงจัดการ batch run ทั้งหมด และใช้ interactive facility ของตนเองเพื่อควบคุมความสมบูรณ์และความพร้อมใช้งานของผลิตภัณฑ์ที่กำลังเติบโต
The toolsmith (ช่างเครื่องมือ). ปัจจุบันบริการ file-editing, text-editing และ interactive debugging พร้อมใช้งานแล้ว ดังนั้นทีมแทบจะไม่จำเป็นต้องมีเครื่องจักรและทีมปฏิบัติการเครื่องจักรของตนเอง แต่บริการเหล่านี้ต้องพร้อมใช้งานด้วยการตอบสนองและความน่าเชื่อถือที่ดีเยี่ยม และศัลยแพทย์ต้องเป็นผู้ตัดสินแต่เพียงผู้เดียวว่าบริการที่เขามีอยู่นั้นเพียงพอหรือไม่ เขาต้องการ toolsmith ซึ่งรับผิดชอบในการทำให้แน่ใจว่าบริการพื้นฐานเพียงพอ และในการสร้าง บำรุงรักษา และอัปเกรดเครื่องมือพิเศษ — ส่วนใหญ่เป็นบริการคอมพิวเตอร์แบบโต้ตอบ — ที่ทีมของเขาต้องการ แต่ละทีมจะต้องมี toolsmith ของตนเอง ไม่ว่าบริการส่วนกลางจะดีเยี่ยมและเชื่อถือได้เพียงใดก็ตาม เพราะหน้าที่ของเขาคือดูแลเครื่องมือที่ศัลยแพทย์_ของเขา_ต้องการ โดยไม่คำนึงถึงความต้องการของทีมอื่น ผู้สร้างเครื่องมือมักจะสร้าง utilities เฉพาะทาง catalogued procedures และ macro libraries
The tester (ผู้ทดสอบ). ศัลยแพทย์จะต้องมีชุด test cases ที่เหมาะสมสำหรับทดสอบชิ้นส่วนของงานขณะที่เขาเขียน และสำหรับทดสอบทั้งระบบในภายหลัง ดังนั้น tester จึงเป็นทั้งคู่ปรับที่สร้าง system test cases จาก functional specs และเป็นผู้ช่วยที่สร้าง test data สำหรับการ debug ในประจำวัน เขาจะวางแผนลำดับการทดสอบและตั้งค่า scaffolding ที่จำเป็นสำหรับการทดสอบส่วนประกอบ
The language lawyer (ทนายภาษา). ตั้งแต่สมัย Algol เป็นต้นมา ผู้คนเริ่มตระหนักว่าระบบคอมพิวเตอร์ส่วนใหญ่มีคนหนึ่งหรือสองคนที่ชื่นชอบความเชี่ยวชาญในรายละเอียดปลีกย่อยของภาษาโปรแกรม และผู้เชี่ยวชาญเหล่านี้กลับกลายเป็นคนที่มีประโยชน์อย่างมากและถูกปรึกษาอย่างกว้างขวาง พรสวรรค์ในที่นี้ค่อนข้างแตกต่างจากของศัลยแพทย์ ซึ่งเป็นนักออกแบบระบบเป็นหลักและคิดในเชิง representation language lawyer สามารถหาวิธีที่เรียบร้อยและมีประสิทธิภาพในการใช้ภาษาเพื่อทำสิ่งที่ยาก ซับซ้อน หรือยุ่งยาก บ่อยครั้งที่เขาจะต้องศึกษาวิธีการที่ดีเล็กน้อย (สองสามวัน) language lawyer หนึ่งคนสามารถให้บริการศัลยแพทย์สองถึงสามคน
นี่คือวิธีที่คน 10 คนอาจมีส่วนร่วมในบทบาทที่แตกต่างและเชี่ยวชาญเฉพาะทางอย่างชัดเจนบนทีมโปรแกรมming ที่สร้างขึ้นบนโมเดลศัลยกรรม
How It Works (วิธีการทำงาน)
ทีมที่เพิ่งอธิบายไปตอบโจทย์ความต้องการที่กล่าวมาในหลายด้าน คนสิบคน เจ็ดคนในจำนวนนั้นเป็นมืออาชีพ กำลังทำงานบนปัญหา แต่ระบบกลับเป็นผลิตผลของสมองคนเดียว — หรืออย่างมากที่สุดสองคน ที่ทำงาน uno animo (เป็นหนึ่งเดียว)
ให้สังเกตความแตกต่างโดยเฉพาะระหว่างทีมโปรแกรมเมอร์สองคนที่จัดแบบดั้งเดิมกับทีมศัลยแพทย์-นักบินร่วม ประการแรก ในทีมแบบดั้งเดิม คู่หูจะแบ่งงานกัน และแต่ละคนรับผิดชอบการออกแบบและพัฒนาส่วนหนึ่งของงาน ในทีมศัลยกรรม ศัลยแพทย์และนักบินร่วมต่างรู้เห็นการออกแบบและโค้ดทั้งหมด ซึ่งช่วยประหยัดแรงงานในการจัดสรรพื้นที่ การเข้าถึงดิสก์ ฯลฯ และยังรับประกันความสอดคล้องทางแนวคิดของงานอีกด้วย
ประการที่สอง ในทีมแบบดั้งเดิม คู่หูเท่าเทียมกัน และความเห็นที่แตกต่างอย่างหลีกเลี่ยงไม่ได้ต้องถูกพูดคุยหรือประนีประนอม เนื่องจากงานและทรัพยากรถูกแบ่งกัน ความเห็นที่แตกต่างจึงถูกจำกัดอยู่ในกลยุทธ์โดยรวมและการเชื่อมต่อระหว่างส่วน แต่กลับถูกทำให้ซับซ้อนขึ้นด้วยความแตกต่างทางผลประโยชน์ — เช่น พื้นที่ของใครจะถูกใช้สำหรับ buffer ในทีมศัลยกรรม ไม่มีความแตกต่างทางผลประโยชน์ และความเห็นที่แตกต่างจะถูกตัดสินโดยศัลยแพทย์แต่เพียงผู้เดียว ความแตกต่างสองประการนี้ — การไม่แบ่งปัญหาและความสัมพันธ์แบบผู้บังคับบัญชา-ผู้ใต้บังคับบัญชา — ทำให้ทีมศัลยกรรมสามารถทำงาน uno animo (เป็นหนึ่งเดียว) ได้
แต่การเชี่ยวชาญเฉพาะทางในหน้าที่ของสมาชิกที่เหลือในทีมคือกุญแจสำคัญสู่ประสิทธิภาพ เพราะมันทำให้รูปแบบการสื่อสารระหว่างสมาชิกง่ายขึ้นอย่างมาก ดังที่ Fig. 3.1 แสดงให้เห็น
Figure 3.1. Communication patterns in 10-man programming teams (รูปที่ 3.1 รูปแบบการสื่อสารในทีมโปรแกรม 10 คน)
บทความของ Baker[3] รายงานเกี่ยวกับการทดสอบแนวคิดทีมนี้ในขนาดเล็กเพียงครั้งเดียว มันทำงานได้ตามที่คาดการณ์ไว้สำหรับกรณีนั้น ด้วยผลลัพธ์ที่ดีอย่างน่าทึ่ง
Scaling Up (การขยายขนาด)
ถึงตอนนี้ก็ยังดีอยู่ อย่างไรก็ตาม ปัญหาคือจะสร้างสิ่งที่ปัจจุบันต้องใช้ 5,000 man-years ได้อย่างไร ไม่ใช่สิ่งที่ใช้ 20 หรือ 30 man-years ทีม 10 คนสามารถมีประสิทธิภาพได้ไม่ว่าจะจัดระเบียบอย่างไร ถ้างาน_ทั้งหมด_อยู่ในขอบเขตของมัน แต่แนวคิดทีมศัลยกรรมจะถูกนำไปใช้กับงานใหญ่ที่มีคนหลายร้อยคนได้อย่างไร?
ความสำเร็จของกระบวนการขยายขนาดขึ้นอยู่กับข้อเท็จจริงที่ว่าความสอดคล้องทางแนวคิดของแต่ละชิ้นส่วนได้รับการปรับปรุงอย่างรุนแรง — นั่นคือจำนวนสมองที่กำหนดการออกแบบถูกหารด้วยเจ็ด ดังนั้นจึงเป็นไปได้ที่จะให้คน 200 คนทำงานกับปัญหา และเผชิญกับปัญหาในการประสานงานเพียง 20 สมอง นั่นคือสมองของศัลยแพทย์
สำหรับปัญหาการประสานงานนั้น อย่างไรก็ตาม ต้องใช้เทคนิคแยกต่างหาก และสิ่งเหล่านี้จะถูกกล่าวถึงในบทต่อ ๆ ไป ขอกล่าวไว้ ณ ที่นี้เพียงว่าระบบทั้งหมดก็ต้องมีความสอดคล้องทางแนวคิดเช่นกัน และนั่นต้องการ system architect ที่จะออกแบบทุกอย่างจากบนลงล่าง เพื่อทำให้งานนั้นจัดการได้ ต้องมีการแยกแยะอย่างชัดเจนระหว่างสถาปัตยกรรมและการนำไปปฏิบัติ และ system architect ต้องจำกัดตัวเองอย่างเคร่งครัดอยู่ที่สถาปัตยกรรมเท่านั้น อย่างไรก็ตาม บทบาทและเทคนิคดังกล่าวได้รับการพิสูจน์แล้วว่าเป็นไปได้ และแน่นอน มีประสิทธิผลอย่างมาก