ย้อนอดีตไปไม่นานนัก องค์กรไอทีได้ริเริ่มใช้ Service-Oriented Architecture (SOA) ควบรวมแอพพลิเคชันต่างๆ แต่ในปัจจุบัน บริษัทขนาดใหญ่หลายแห่งหันมาพึ่ง SOA ในการสร้างคอมโพเน็นต์ที่สามารถถูกควบรวม และเรียกใช้ซ้ำในรูปแบบเซอร์วิสข้ามแอพพลิเคชันกันบ้างแล้ว

สิ่งเหล่านี้ช่วยให้การปรับปรุงแอพพลิเคชันสะดวกรวดเร็วกว่าเดิม อีกทั้งช่วยลดเวลาพัฒนา เพิ่มคุณภาพการให้บริการลูกค้าและคู่ค้า และประหยัดสตางค์ได้เป็นจำนวนมาก

ที่กล่าวมายังคงเป็น SOA อยู่ แต่เป็น SOA ที่เบ่งกล้ามโตขึ้น

“คุณจะไม่ได้แต้มต่ออีกต่อไป หากยังดันทุรังเขียนแค่ตัวหุ้มเว็บเซอร์วิสครอบแอพพลิเคชันเก่า” Hamesh Yadav หัวหน้าทีมออกแบบสถาปัตยกรรมระบบของ Wells Fargo & Co. ในซานฟรานซิสโก และประธานร่วมของคณะทำงานด้าน SOA ขององค์การ The Open Group (www.opengroup.org) อธิบาย “เพราะในปัจจุบัน SOA จะถูกเน้นใช้แก้ปัญหาทางธุรกิจมากขึ้น”

“ถึงแม้ความนิยมใน SOA ที่เพิ่มขึ้นนำมาซึ่งปัญหาในการบริหารจัดการ รวมถึงความจำเป็นที่ต้องสร้างระเบียบในการควบคุมคุณภาพของวิธีจัดการเซอร์วิสหรือ Governance” เขากล่าว “แต่สุดท้ายแล้วคุณก็จะได้ระบบที่ซับซ้อนน้อยลง โดยทำให้สรรพสิ่งทำงานสัมพันธ์แน่นแฟ้นกว่าเดิม”

ที่บริษัท Massachusetts Mutual Life Insurance ในมลรัฐแมสซาชูเซตต์ โครงการ SOA ในปัจจุบันครอบคลุมเซอร์วิสกว่า 100 อย่างตั้งแต่งานประกันชีวิต ไปจนถึงงานบริหารสารสนเทศลูกค้า ซึ่ง Kinam Peter Kim รองประธานฝ่ายวางกลยุทธ์ SOA กล่าวว่า “เซอร์วิสเหล่านี้ได้รวมสารพัดแอพพลิเคชันจากหลายหน่วยธุรกิจที่ทำตลาดผลิตภัณฑ์ต่างๆ เข้าด้วยกัน โดยเราเลือกที่จะไม่หาอะไรทดแทนแอพพลิเคชันเดิมทั้งหมด แต่ให้หน่วยธุรกิจต่างๆ เลือกส่วนผสมของแชร์เซอร์วิสที่เรามีตามความเหมาะสมเอง”

Kim อธิบายว่า “สำหรับเราแล้ว SOA ไม่ใช่เทคโนโลยี แต่เป็นวิธีปรับปรุงธุรกิจของเราให้ทันสมัย และเป็นวิธีสร้างความยืดหยุ่นปรับเปลี่ยนได้แก่องค์กร”

เซอร์วิส SOA ที่ถูกออกแบบอย่างดีจะสามารถนำกลับมาใช้ในกระบวนการทางธุรกิจอัตโนมัติ และงานควบรวมระบบได้เรื่อยไปไม่รู้จบ ยกตัวอย่างฟังก์ชันธุรกิจต่างๆ ของ MassMutual เช่น ระบบรักษาความปลอดภัยจะได้รับการจัดเก็บใน Repository และมีความสอดคล้องกับนโยบายปกครองของแผนกไอที ซึ่งเป็นผู้ตัดสินใจว่าแอพพลิเคชันใดจะมีสิทธิ์ใช้แชร์เซอร์วิส

ในยามที่บริษัทฯ ตัดสินใจยกเครื่อง SOA ใหม่ในปี 2007 แผนกไอทีตระหนักดีว่าแทนที่จะเปลี่ยนโมเดลทางสถาปัตยกรรมยกชุด พวกเขาน่าจะเปลี่ยนไปใช้หนึ่งโมเดลกับหน่วยธุรกิจทั้งหมดก็ได้เหมือนกัน

“เราตั้งคำถามแนวๆ ว่า SOA มีความหมายอย่างไรต่อธุรกิจ” Don Carten ผู้ช่วยรองประธานฝ่ายเอ็นเทอร์ไพรส์เทคโนโลยีของ MassMutual เปิดเผย “เราคิดถึงกรรมวิธี งบลงทุน แนวทางปฏิบัติ เซอร์วิสอะไรที่บ้างที่เราใช้ จากนั้นก็สร้างทีมงานที่ดูแลโครงการ และสร้างเซอร์วิสต่างๆ โดยอิงมาตรฐานที่ยอมรับกันทั่วโลก”

กว้างขวาง... ลงลึกกว่าเดิม

“SOA กำลังอยู่ในกระแสนิยม และกลายเป็นส่วนประกอบของสิ่งอื่นอีกทอดหนึ่ง” Mike Gilpin นักวิเคราะห์ของฟอร์เรสเตอร์รีเสิร์ช แสดงความเห็น “บริษัทต่างๆ จะกำหนดรูปแบบเว็บเซอร์วิส เขียนโค้ดขึ้นมา แล้วส่งต่อไปยังแอพพลิเคชันเซอร์วิส”

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

ด้วย SOA สิ่งทั้งปวงจะได้รับการควบรวมกระชับมากขึ้น ช่วยให้บริษัทสามารถทำตลาด จัดหาบริการ และเรียกเก็บค่าบริการจากทุกแหล่งอย่างสะดวกสบาย

Gilpin อธิบายว่า ระบบเหล่านี้ทำงานบนเทคโนโลยีพื้นฐานที่แตกต่างกันได้ “แลนด์ไลน์อาจขับเคลื่อนบนเมนเฟรม ขณะที่บริการโมไบล์ทำงานบนแพลตฟอร์มจาวา ดังนั้น SOA จึงเป็นตัวก่อกำเนิดและลดต้นทุนค่าใช้จ่าย”

“อุตสาหกรรมการเงินก็เช่นกัน SOA จะสามารถทำให้ธนาคารอนุมัติเงินกู้รวดเร็วขึ้น หรือนำเสนอบริการได้โดยเผชิญอุปสรรคน้อยลง” เขากล่าว

SOA แทรกซึมไปทั่วทุกแอพพลิเคชัน

ในบริษัท Cigna Corp. เส้นทางของเทคโนโลยี SOA ช่างแตกต่างกับที่ MassMutual ทว่าผลลัพธ์ที่ได้นั้นคล้ายคลึงกัน บริษัทประกันสุขภาพในเมืองฟิลาเดลเฟียแห่งนี้กระโจนเข้าสู่ขบวน SOA ราวๆ ปี 2001 ซึ่งเป็นเวลาที่องค์กรจำนวนมากยังคงทดสอบเว็บเซอร์วิสในระดับแผนก แต่ Cigna กลับหาญกล้านำ SOA มาใช้กับระบบทั้งบริษัท ไม่ว่าจะเป็นซอฟต์แวร์คอลล์เซ็นเตอร์ตัวใหม่ หรือแอพพลิเคชันจัดการบัญชีลูกค้าก็ตาม

Stephen Bergeron ผู้อำนวยการฝ่ายสถาปัตยกรรมระบบอาวุโสของ Cigna กล่าวว่า “เรามีโครงสร้างพื้นฐานฮาร์ดแวร์และซอฟต์แวร์อยู่ในมือแล้ว และตอนนี้เรามี SOA แทรกซึมอยู่เกือบทุกอณูของแอพพลิเคชันที่สำคัญ”

เขากล่าวเสริมว่า Cigna Corp. อาศัย SOA ในเรื่องการสอดประสานกระบวนการ การให้บริการข้อมูล และการให้บริการทางธุรกิจ นอกเหนือจากงานอื่นๆ ที่ไม่ได้ระบุในที่นี้

คิดใหม่เรื่องการนำเสนอบริการ

Cigna Corp. ได้เปลี่ยนความคิดเรื่องวิธีที่หน่วยธุรกิจต่างๆ จะสามารถเข้าถึงและใช้แชร์แอพพลิเคชันเสียใหม่ ทั้งในเชิงของธุรกิจและไอที ด้วยเหตุที่แอพพลิเคชันทางธุรกิจจำนวนมากมีบางคุณสมบัติที่ทับซ้อนกันอยู่ จึงเป็นสิ่งสำคัญที่ต้องระบุว่าแต่ละเซอร์วิสตั้งใจสร้างขึ้นเพื่อทำหน้าที่อะไรก่อน แล้วจัดรูปแบบการใช้เซอร์วิสตามกันไป

ทุกวันนี้ Registry และ Repository ของแชร์เซอร์วิสใน Cigna Corp. ช่วยส่งเสริมการแบ่งปันข้อมูลในองค์กรอย่างยิ่ง โดย Registry จะเก็บข้อมูลว่าแอพพลิเคชันใดบ้างที่ควบรวมอยู่ใน SOA และโค้ดชุดใดบ้างที่แต่ละแอพพลิเคชันเข้าใช้ ส่วน Repository จะเก็บตัวโค้ดที่อนุญาตให้แอพพลิเคชันต่างๆ เข้าใช้

Gilpin อธิบายว่า “การใช้งานเซอร์วิสของแอพพลิเคชันแสดงถึงการยกระดับอีกขั้น ซึ่งต่างกับแอพพลิเคชันที่เขียนขึ้นมาเพื่อเซอร์วิส หรือแอพพลิเคชันที่ใช้เซอร์วิสแยกต่างหากจาก SOA”

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

คำถามที่ต่างจากเดิม

การยกระดับจากเว็บเซอร์วิสธรรมดาไปสู่ SOA ทั่วองค์กรย่อมก่อให้เกิดความซับซ้อนและความท้าทาย ซึ่งนำไปสู่การค้นหาว่าแอพพลิเคชันใดบ้างที่บริโภคเซอร์วิส และควรบริโภคอย่างไร ดังนั้น ผู้จัดการแผนกไอทีจึงต้องตั้งคำถามที่ต่างจากสมัยเทคโนโลยียุคเดิม

Sandra Rogers นักวิเคราะห์ของไอดีซีกล่าวว่า “มุมมองของ SOA ที่กว้างกว่าเว็บเซอร์วิส คือการเป็นทั้งแอพพลิเคชันและสภาพแวดลอมของระบบที่สามารถมอบความกระฉับกระเฉงแก่ธุรกิจ” แต่บทบาทที่กว้างขึ้นนี้ต้องการเซอร์วิสที่ออกแบบมาอย่างดี และผ่านการใคร่ครวญอย่างหนักในฐานะองค์ประกอบของกระบวนการทางธุรกิจ

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

ไม่ว่าคุณทำวิธีไหน จงอย่ามองข้ามขั้นตอนการวางแผนเด็ดขาด โดย Anne Thomas Manes นักวิเคราะห์ของเบอร์ตันกรุ๊ป แนะนำว่า SOA ที่ประสบความสำเร็จจะเกิดในบริษัทที่ยอมเปลี่ยนมุมมองในเรื่อง SOA และนำเสนอ SOA ในฐานะเทคโนโลยีที่เหมาะสมเท่านั้น

“การถกปัญหาเรื่อง SOA ควรย้ายไปอยู่ใต้ดินเสีย ทีมไอทีควรล้มเลิกความตั้งใจที่จะขาย SOA แก่ฝั่งธุรกิจ และหันไปประยุกต์ใช้หลักการของ SOA กับโครงการที่ตัวเองริเริ่มดีกว่า”

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

เธอย้ำว่า “แสดงให้เห็นว่า SOA ใช้งานได้... อย่ามัวแต่โม้”

ส่วน Kim แห่ง MassMutual เห็นด้วยว่า “สาเหตุที่เราประสบความสำเร็จ ก็เพราะเราวางมาตรฐานของกระบวนการทางสถาปัตยกรรมมาได้ 5 ถึง 6 ปีแล้ว โดยนักออกแบบมีความเข้าใจโลกของธุรกิจและเทคโนโลยี ขณะที่คณะกรรมการบริหารก็ให้ความสำคัญ และสนับสนุนโครงการอย่างดีเยี่ยม”

คิดผลตอบแทนการลงทุน... ปัญหาใหญ่

ทุกวันนี้บริษัทต่างๆ ยังคงประสบปัญหาการคิดผลตอบแทนการลงทุนสำหรับ SOA เนื่องจากหลายกรณีเป็นการวางเซอร์วิสขนาดใหญ่ในช่วงเวลาสั้นๆ จึงเป็นไปไม่ได้เลยที่จะแสดงให้เห็นวิธีประหยัดเงิน Manes จึงแนะนำให้ใช้มาตรวัด ROI ที่ฉีกแนว ยกตัวอย่างเช่น คุณอาจอธิบายว่า SOA ช่วยลดจำนวนนักพัฒนาอย่างไร ลดเวลาในการพัฒนาอย่างไร แม้กระทั่งในเรื่องการเร่งความเร็วออกสู่ตลาด หรือการลดความเสี่ยง เป็นต้น

Manes กล่าวว่า “คุณควรมองแอพพลิเคชันในแบบเดียวกับตลาดหุ้น หากมันไม่มีกำไร คุณก็ขายทิ้ง” และเป็นสิ่งสำคัญที่ต้องแสดงให้ประจักษ์ว่าเซอร์วิสนั้นๆ สามารถลดดาวน์ไทม์ เร่งกระบวนการเรียกชำระเงิน ลดเวลาที่เจ้าหน้าที่สนับสนุนลูกค้าเสียไปกับการแก้ปัญหาทางโทรศัพท์ได้จริง

“โดยเฉพาะในเศรษฐกิจเช่นนี้ บริษัททั้งหลายย่อมมีแนวโน้มจัดสรรงบแก่โครงการที่เห็นผลตอบแทนเป็นรูปธรรม มากกว่าโครงการที่มีสถาปัตยกรรมเชิงนามธรรมอันสวยงาม” เธอกล่าวเสริม

ส่วน Carten กล่าวว่า “ที่ MassMutual การหาเหตุปัจจัยสนับสนุนโครงการ SOA ขนาดใหญ่ จำเป็นต้องอาศัยการคิดใหม่พูดใหม่ในเรื่องเทคโนโลยี เกี่ยวกับประเด็นที่ SOA สามารถสร้างมาตรฐานแก่ธุรกิจอย่างไร”

สิ่งดังกล่าวอาจทำได้ลำบากพอสมควร เนื่องจากคุณต้องยอมรับในมาตรฐานก่อน แล้วค่อยพัฒนาบางอย่างในรูปแบบที่เวียนกลับมาใช้ซ้ำได้

หรือแม้มีการคิดใหม่พูดใหม่แล้ว แต่ความสำเร็จในโครงการ SOA ย่อมเกิดจากการกระทำ ไม่ใช่การคุยโตโอ้อวด ซึ่ง Carten กล่าวว่า “คุณจำเป็นต้องเดินออกข้างนอกประตูรั้ว และสร้างเซอร์วิสให้เห็นผลจริง”

Governance ยิ่งเป็นเรื่องสำคัญ

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

หนทางในการคิดถึงเรื่องดังกล่าว คือระบุหาว่านโยบายใดบ้างที่สามารถบังคับใช้ครอบคลุมหน่วยธุรกิจต่างๆ และประเด็นเกี่ยวกับ SOA Federation หรือการซิงโครไนซ์ก็เป็นแนวคิดที่สำคัญอีกประการในยามที่ SOA ขยายขอบเขตไปทั่วองค์กร “เมื่อผสานคุณสมบัตินี้เข้ากับการ Authenticate และ Authorize ผู้ใช้ในโดเมนหนึ่งจะสามารถล็อกออนเข้าไปยังอีกโดเมน และเอกลักษณ์ระบุตัวตนของเขาจะถูกส่งข้ามไประหว่างโดเมนทั้งสองได้ แม้โดเมนแรกสร้างขึ้นบน Microsoft Active Directory และโดเมนที่สองสร้างขึ้นบน Sun Identity Manager ก็ตาม” Gilpin อธิบาย

แต่ผู้จัดการแผนกไอทีจำเป็นต้องระวังให้ดี “ขณะที่คุณสร้าง SOA คุณต้องย้ำเตือนตัวเองอยู่เสมอว่า SOA นั้นไม่ใช่เทคโนโลยี” Bergeron แห่ง Cigna กล่าว “บ่อยครั้งที่แผนกไอทีเข้าใจผิดว่า SOA เป็นเทคโนโลยีที่สร้างขึ้นเพื่อเทคโนโลยี และสูญเสียการมองในแง่ธุรกิจที่จำเป็นในการขับเคลื่อนงานของเรา ด้วยผลิตภัณฑ์ เทคโนโลยี และมาตรฐานต่างๆ นานาในโลกของ SOA ช่างทำให้พวกเราไขว้เขวง่ายเสียนี่กระไร”