Solution Architect: ทำไมซอฟต์แวร์ดีๆ หลายตัวทำงานร่วมกันถึงกลายเป็นโซลูชันที่แย่
ย้อนกลับไปสมัยคนไอทีนิยมไปเดินห้างพันธุ์ทิพย์ (จะย้อนไปให้รู้อายุทำไม) นอกจากฮาร์ดแวร์หลายชนิดวางเรียงรายซ้อนกันจนถึงเพดานแล้ว เราจะเห็นซอฟต์แวร์เป็นกล่องๆ วางขายเต็มไปหมด ส่วนหนึ่งจะเป็นซอฟต์แวร์แบบ “ครบวงจร” เช่น ระบบบริหารจัดการร้านอาหารแบบครบวงจร ระบบจัดการคลังสินค้าแบบครบวงจร ระบบงานสหกรณ์แบบครบวงจร บลา บลา บลา… ระบบแบบครบวงจรแปลว่าเป็นทุกอย่างให้ธุรกิจนั้นตั้งแต่สากกะเบือยันเรือรบ (เปรียบเปรยครับ ซอฟต์แวร์นี้ไม่ได้ทำให้เกิดสากกะเบือหรือไปประกอบเรือรบในธุรกิจของคุณ) แบบที่คุณใช้ซอฟต์แวร์ของเขาแล้วจบเลย ไม่ต้องไปหาซื้อซอฟต์แวร์อื่นๆ มาใช้ประกอบกัน
การใช้คำว่า “ครบวงจร” คงไม่เกินจริงไปนักสำหรับธุรกิจขนาดเล็ก ระบบแบบครบวงจรช่วยให้การนำเทคโนโลยีมา Optimize ขั้นตอนให้ทำได้ง่าย ทั้งยังช่วยลดต้นทุนของบริษัทไปพร้อมกับเพิ่มประสิทธิภาพในการทำธุรกิจ ผมเคยเห็นระบบที่ทำตั้งแต่สั่งของเข้า จัดการสต็อกวัตถุดิบ บันทึกสูตรของผลิตภัณฑ์ จัดการไลน์การผลิต บันทึกข้อมูลลูกค้า รับออเดอร์ของลูกค้า ออกใบสั่งซื้อ ใบเสร็จ จัดการข้อมูลขนส่ง ลงบัญชี ออกรายงานสรุปยอดขาย ฯลฯ ที่ออกแบบมาอย่างดีเพื่อให้พนักงานในแต่ละฝ่ายของบริษัททำงานร่วมกันอยู่บนระบบเดียว ขั้นตอนมากมายเหล่านี้ถูก Optimized ให้มีเฉพาะขั้นตอนที่จำเป็น มีการจัดเก็บข้อมูลไม่ซ้ำซ้อนกัน (แหงละ เล่นมีอยู่ระบบเดียวนี่หว่า) หน้าจอหรือรายงานแต่ละหน้ามีจุดประสงค์ที่ชัดเจน ผู้ใช้งานระบบเข้าใจได้ง่าย และที่แน่ๆ มีชื่อผู้ใช้และรหัสผ่านชุดเดียวให้จำ
ในองค์กรขนาดใหญ่ การทำระบบครบวงจรอย่างที่กล่าวมาทำได้ยากขึ้น และเมื่อองค์กรมีขนาดใหญ่ขึ้น เส้นแบ่งโครงสร้างขององค์กรก็มีความชัดเจนขึ้นตามไปด้วย ในองค์กรที่เล็กกว่า คนคนเดียวอาจทำได้หลายตำแหน่ง สำหรับองค์กรขนาดใหญ่ ฝ่ายงานแต่ละฝ่ายต้องมีบทบาทหน้าที่ชัดเจน ซึ่งรวมไปถึงเรื่องของงบประมาณ แต่ละฝ่ายงานอาจมีงบประมาณที่ถูกจัดสรรมาเป็นของตน สามารถทำการจัดซื้อจัดหาระบบงานหรือเทคโนโลยีใดๆ ที่เล็งเห็นว่าจะสามารถเพิ่มประสิทธิภาพในการทำงานของฝ่ายตนเองได้อย่างมีอิสระ
ใช่ครับ หลายคนอาจจะต้องร้องอ๋อ มันเกิดเป็น ไซโล (Silos)
ที่ไม่ใช่ ไฮโล (High-low)!!!
และก็ไม่ได้เป็น ไมโล (Milo)!!!
ไซโลก็เหมือนความรัก พอไซโลปุ๊ป จะมองเห็นแต่ตรงนั้นครับ มองไม่เห็นสิ่งรอบข้างเลย 555 คำถามคือหากแต่ละฝ่ายต่างจัดหาซอฟต์แวร์หรือระบบงานไอทีที่เจ๋งและดีมาช่วยงานในฝ่ายตนแล้ว จะกลับทำให้บริษัทมีปัญหามากขึ้นไหม รู้สึกว่าการทำงานไม่คล่องตัว ไม่รวดเร็วอย่างที่คิด ยิ่งซื้อยิ่งหาของดีมาเพิ่ม ยิ่งทำงานยากขึ้น คำตอบคือมีแน่นอนครับ (ถ้าคำตอบคือไม่มี บทความนี้จะจบลงตรงนี้แบบงงๆ) ซึ่งจะคล้ายกับสิ่งที่เรียกว่า “ Technical Debt ” ในโค้ดของเราชาว Developer ต่างกันตรงที่มันเกิดขึ้นในบริบทที่ใหญ่กว่ามาก คือเกิดบนขั้นตอนการทำธุรกิจของบริษัท
ผมเคยเขียนบทความสั้นๆ เกี่ยวกับ Evolutionary Architect ไว้ กล่าวถึงหน้าที่ความรับผิดชอบของคนที่ทำงานในตำแหน่งตระกูล Architect ที่มีหลากหลาย ในบทความนั้นผมลืมเขียนไปนิดนึงว่าในบางบริบท Role ของ Architect กับ Technical Lead ก็เป็นสิ่งเดียวกัน ยกตัวอย่างในบริษัทแล้วกันนะครับ เมื่อ Architect คนหนึ่งทำงานอยู่ในทีมๆ เดียว เขาเป็นผู้วาง Technology Stack ออกแบบโครงสร้างของระบบ วางแนวทางการเขียนโปรแกรม ดูแลควบคุมคุณภาพของโค้ด เพื่อให้มั่นใจว่าทีมพัฒนาจะสร้างแอปพลิเคชันที่ยอดเยี่ยม และส่งขึ้นโปรดักชันให้กับฝ่ายธุรกิจได้ใช้งานตามแผนอย่างราบรื่น เราเรียกเขาว่า Technical Lead แต่ในสถานการณ์ที่เขาต้องทำงานกับหลากหลายทีมพัฒนา หลายแอปพลิเคชัน หลายฝ่ายงาน หรืออาจจะเป็นในระดับที่เกี่ยวข้องกับทุกคนในองค์กร เพื่อที่จะทำให้ระบบงานหรือโปรแกรมทำงานร่วมกันเป็นโซลูชันที่ดีได้ เขาจะแปลงร่างเป็น Solution Architect
Solution Architect ที่ดีจะต้องนำทีมก้าวข้ามไซโล และทำให้ซอฟต์แวร์ต่างๆ ทำงานร่วมกันอย่างมีประสิทธิภาพเพื่อตอบโจทย์ทางธุรกิจอย่างครบวงจร
(ถ้าคุณเริ่มสนใจตำแหน่งนี้ คลิกลิงก์ด้านล่างได้เลย)
ทำไมซอฟต์แวร์ดีๆ หลายตัวมาทำงานร่วมกันแล้วกลายเป็นโซลูชันที่แย่?
1. Duplication
ในกระบวนการทางธุรกิจตั้งแต่ต้นจนจบ หรือที่เราเรียกติดปากว่า E2E (End-to-End) Processes ที่ซับซ้อนและมีขั้นตอนจำนวนมากมักจะมีส่วนซ้ำซ้อนหรือคล้ายกัน ซึ่งจะติดไปอยู่ในซอฟต์แวร์หรือระบบงานไอที ผู้ใช้ระบบ ตลอดจน Developer และ Operations ก็จะทำงานซ้ำซ้อนกันไปด้วย Solution Architect จึงจะต้องออกแบบโซลูชันที่หลีกเลี่ยงความซ้ำซ้อนอันไม่จำเป็น ดึงเอาความคล้ายกันที่กระจัดกระจายให้ออกมาอยู่ที่เดียวกันและทำงานได้แบบยืดหยุ่นแทน
2. Unnecessary Moves
ใน E2E Software Architecture มักมีขั้นตอนที่ไม่จำเป็น หรืออาจจะเป็นระบบที่ไม่ใช้งานแล้วปะปนอยู่ Solution Architect จะต้องหาวิธีการ Optimize ขั้นตอนเหล่านั้นให้ง่ายขึ้น รวดเร็วขึ้น โดยที่ยังคงความถูกต้องเหมือนเดิม นึกถึงจอมยุทธหรือตัวละครในการ์ตูนที่มีการเคลื่อนไหวที่เสียเปล่ามากมาย จะไม่สามารถสู้ชนะพระเอกที่ขัดเกลาท่าร่างจนรัดกุมไร้ช่องโหว่ได้ (แม้ว่าตอนแรกพระเอกมักจะง่อยๆ และแพ้มาก่อนก็ตาม)
3. Inefficient Integration
เมื่อแต่ละไซโลใช้ระบบที่ดี แต่ไม่ได้คิดถึงการส่งงานต่อระหว่างกันมากเพียงพอ การเชื่อมต่อระหว่างไซโลจึงมักจะเริ่มต้นด้วยการใช้ Manual Process หรือวิธีที่ไม่มีประสิทธิภาพ โดย Solution Architect จะต้องคว้าโอกาสในเปลี่ยน Manual Integration เป็น System Integration ที่มีประสิทธิภาพให้ได้
ผมเคยอ่านหนังสือเล่มหนึ่งที่ผู้แต่งเขาเล่าถึงการเล่น SimCity ว่าเวลาจะสร้างเมืองให้เจ๋ง เราต้องทำสิ่งที่เรียกว่า Zoning ก่อน คือการวางผังเมืองในภาพใหญ่ว่าแอเรียใดจะทำอะไร แอเรียใดอยู่ติดกับแอเรียใดถึงจะดี เช่น แอเรียของโรงงานอุตสาหกรรม แอเรียสำหรับทำการเกษตร แอเรียของบ้านคนธรรมดา ฯลฯ และจากนั้นให้ออกแบบการเชื่อมต่อ การคมนาคม สาธารณูปโภคระหว่างแอเรียด้วยกันให้ดี เสร็จแล้วค่อยมาสนใจในรายละเอียดว่าเราจะสร้างอะไรภายในแต่ละแอเรีย เราสามารถนำวิธีการที่กล่าวมานี้มาใช้กับ IT Architecture ได้ครับ (ผมเล่นเกมส์เยอะมาก แต่ผมไม่เคยเล่น SimCity เลย จำได้ว่ามีแผ่นกับเขาเหมือนกัน แต่ก็ไม่เคยเปิดมาเล่นสักครั้ง)
4. Production w/o Operations
ทุกคนมุ่งหน้าเอาระบบขึ้นโปรดักชัน แต่ลืมคิดไปว่าหลังจากขึ้นโปรดักชันแล้วต้องมี Operations อะไรบ้าง เพื่อให้ระบบทำงานได้อย่างราบรื่น ตลอดจนคำนึงถึงความสามารถในการออกเวอร์ชันใหม่ว่าทำได้เร็วเพียงใด การอัพเกรดระบบให้มีความสามารถเพิ่มขึ้นในภายหลังจะมีขั้นตอนอย่างไร อันนี้ตรงกับที่ผมเขียนไว้ในบท Evolutionary Architect เล่าถึงสิ่งที่คุณแซมกล่าวเอาไว้ในหนังสือของเขาว่าซอฟต์แวร์ไม่เพียงเป็นบ้านของ End Users แต่ยังเป็นบ้านของ Developer กับ Operations ด้วย ดังนั้นเป็นหน้าที่ของ Architect ที่จะออกแบบบ้านให้ทุกคนอยู่ได้อย่างสบาย (จุดนี้ Cloud กับ DevOps จะเข้ามาช่วยได้เยอะ)
5. Framed Mindset
กรอบที่เราทำงานครับ บ่อยครั้งที่คนไอทีทำงานด้วยการรับความต้องการของผู้ใช้งาน (Requirement Gathering) มาพัฒนาเป็นแอพลิเคชันแบบตรงไปตรงมา ซึ่งผมพบว่าในการทำงาน การวิเคราะห์ (Requirement Analysis) จะหายไป หรือทำในระดับที่ตึ้นและแคบเกินไป ยกตัวอย่างเช่น ระบบหนึ่งต้องประมวลผลตามวันหยุดธนาคาร พอทีมงานไปเก็บ Requirements กับ User สุดท้ายเราได้ออกมาเป็นหน้าจอที่ให้ผู้ใช้งานเพิ่ม ลด แก้ไข (CRUD) วันหยุดธนาคารในแต่ละปี เพราะ User บอกเรามาแบบนั้น เราก็อาจจะนำไปพัฒนาอยู่ในแอพลิเคชันของเราทันที แบบนี้งานอาจจะเสร็จ แต่เราได้โซลูชันที่ดีหรือยังนะ? ในจักรวาลคู่ขนาน หากเราถามผู้ใช้งานระบบว่าเขานำข้อมูลวันหยุดธนาคารมาจากไหน เราอาจจะทราบว่าเขานำมาจากเว็บไซต์ของธนาคารแห่งประเทศไทย และถ้าเราลองเข้าไปที่เว็บดังกล่าว ก็จะพบ API ไว้ให้เราดึงข้อมูลวันหยุดธนาคารมาได้แบบฟรีๆ เป็นต้น เห็นไหมครับ เรามีทางเลือกในการออกแบบโซลูชันแล้ว (แค่ตัวอย่างง่ายๆ พอให้เห็นภาพนะครับ ชีวิตจริงมันดราม่ากว่านี้เยอะ ฮือๆ)
จุดสำคัญคือในภาคธุรกิจ คนทำงานหรือ Business Users ของเราจะต้องทำงานให้สำเร็จแบบ End-to-End จึงจะสามารถปิดจ๊อบทางธุรกิจได้สำเร็จ แต่ในภาคไอทีมีเหตุผลมากมายที่ทำให้เรามักอยู่ในกรอบ เช่น งานเร่ง คนไม่พอ สกิลไม่ได้ และที่ร้ายแรงคือ เราอยู่ในไซโลจนเคยชินครับ หากเราชาวไอทีมองไม่เห็นภาพ End-to-End ในแบบเดียวกับภาคธุรกิจ ก็คงเป็นการยากที่องค์กรทั้งหมดจะพุ่งทะยานออกไปได้ ผมนึกถึงตอนตรวจสุขภาพประจำปีของบริษัท จะมีโต๊ะที่มีเบอร์กำกับอยู่หลายตัว พนักงานจะต้องไปตรวจนั่นนี่ให้ครบทุกโต๊ะ แล้วมีอยู่ปีหนึ่งที่พนักงานไปอยู่กันที่โต๊ะเบอร์ 3 เยอะสุดๆ เพื่อรอเจาะเลือด ในขณะที่โต๊ะเบอร์อื่นแทบจะไม่มีคนเลย พอระบบหนึ่งในธุรกิจสเกลไม่พอ เราที่เป็นลูกค้าก็ย่อมได้รับประสบการณ์ที่แย่ไปด้วย
บางทีเรารู้สึกว่าแค่นำ Requirements ของ Users มาพัฒนาออกมาเป็นระบบงานไอทีได้ก็ประสบความสำเร็จแล้ว นั่นถือว่าถูกต้องสำหรับน้องๆ Developer ที่กำลังสะสมความรู้และประสบการณ์ หรือผู้ที่มุ่งไปในสาย Specialist ที่ใช้ความถนัดด้านใดด้านหนึ่งของตนเองเพื่อทำงานหรือสร้างผลิตภัณฑ์เฉพาะทาง แต่สำหรับ Solution Architect นั้น เรามีหน้าที่ที่จะมองให้ออกว่าเราอยู่จุดใดในภาพใหญ่ของธุรกิจ ออกแบบ Zoning และพัฒนา Integration ให้แข็งแกร่ง ช่วยให้ทุกคนในทีมตระหนักว่าเขาเป็นส่วนหนึ่งของสายพาน ให้การทำงานในเชิงลึกส่งเสริมการทำงานในภาพกว้าง ผมเรียกว่าเป็น E2E Mindset
มาถึงตรงนี้ขอกลับมาถามชาว Developer กันหน่อย รู้สึกคุ้นๆ ไหมครับ หน้าที่ของ Solution Architect คล้ายกับการ “Refactoring Codes” เพื่อชำระ Technical Debts นั่นเอง แต่เรากำลัง Refactor ในบริบทที่ใหญ่ขึ้น เรา Refactor End-to-End IT Applications
ปิดท้ายกันด้วยภาพที่แนบมาด้วยครับ เป็นภาพที่ผมวาดขึ้นจากการไปนั่งคุยกับพี่คนหนึ่งในภาคธุรกิจเมื่อหลายปีมาแล้ว (ต้องขอลบตัวหนังสือออกจากภาพหน่อยนะครับ) ว่าเวลามีออเดอร์หนึ่งเข้ามา เขาจะต้องทำอะไร ยุ่งเกี่ยวกับระบบใด มีใครบ้างที่ต้องทำงานเกี่ยวข้องกับออเดอร์นั้น จนกระทั่งเขาสามารถปิดออเดอร์ได้โดยสมบูรณ์ ในตอนนั้นผมอยู่ในทีมพัฒนาตัว Core System ตรงกลางของภาพครับ สิ่งที่โปรเจคเราทำตอนนั้นคือพัฒนาระบบ Core System ให้เสร็จตาม Business Requirements และพัฒนา System Interfaces ไปที่ระบบอื่นๆ ที่เป็น Direct Integration (กล่องสีเหลือง) เท่านั้นครับ จากภาพเราจะเห็นว่ามีสิ่งอื่นๆ ไม่ว่าจะเป็นคน ระบบ และกระบวนการต่างๆ ที่เข้ามาเกี่ยวข้องอีกมากมายกว่าพี่เขาจะจัดการธุรกิจให้จบได้ โชคดีที่ผมถอนตัวมาจากโปรเจคนั้นได้ก่อน 555 อันนี้เป็นมุกนะครับ
เล่ามาตั้งนาน คิดว่าท่านผู้อ่านคงจะเห็นความท้าทายของ Solution Architect กันบ้างไม่มากก็น้อย ขอบคุณทุกท่านที่อ่านจนจบ พบกันใหมโอกาสหน้าครับ
