คู่มือ 10 ขั้นตอนก้าวสู่ SOA

คู่มือ 10 ขั้นตอนก้าวสู่ Service Oriented Architecture SOA

SOA เป็นแนวความคิด ไม่ใช่เทคโนโลยี

ในความเป็นจริง SOA (service-oriented architecture) นั้นสร้างขึ้นบนเลเยอร์ของโปรโตคอลที่ใช้กำหนดรูปแบบของเว็บเซอร์วิส เพียงแต่มันไม่ได้ถูกจำกัดที่เลเยอร์ของโปรโตคอลเท่านั้น มันได้ร่างภาพ XML, SOAP และ WSDL ออกไปไกลเฉกเช่นกับที่เกิดขึ้นกับแนวคิดของการรีเอนจิเนียริ่งในภาคธุรกิจต่างๆ การวางตำแหน่งของกรอบการทำงานที่อยู่บนพื้นฐาน SOA ซึ่งเป็นเซอร์วิสที่ต้องสร้าง มอบหมายผู้รับผิดชอบ จัดการ และจัดให้ทำงานได้อย่างสอดคล้องกันเพื่อเสาะหาโครงสร้างพื้นฐานทางทางไอทีที่ทันสมัยและมีความตื่นตัวมากขึ้นเพื่อตอบสนองต่อความต้องการทางธุรกิจที่เปลี่ยนแปลงตลอดเวลา

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

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

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

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

ขั้นตอนที่หนึ่ง

จงคิดการณ์ให้ใหญ่ แต่จงเริ่มต้นจากจุดเล็กๆ

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

“พวกเราค่อนข้างโชคดีที่ไม่จำเป็นต้องขายแนวความคิดเรื่อง SOA แต่อย่างใด” Ben Moreland ผู้ช่วยผู้อำนวยการฝ่ายบริการพื้นฐานที่ Hartford ซึ่งนำ SOA เข้ามาหลายปีก่อน “รองประธานอาวุโสของเรา John Chu ตระหนักดีถึงข้อดีและคุณค่าของ SOA อยู่แล้ว”

วิสัยทัศน์ที่มีการแลกเปลี่ยนให้กันนี้อาจดูกว้างครอบคลุมทุกส่วน แต่จะนำไปสู่การเริ่มต้นที่จุดเล็กๆ จุดหนี่งเสมอ “อย่าพยายามทำโครงงานประเภท ‘ต้มมหาสมุทรให้เดือด’” Ed Horst รองประธานฝ่ายการตลาดที่ AmberPoint ให้คำแนะนำในฐานะผู้เคยสังเกตการณ์เห็นความผิดพลาดจากการวางแผนที่มุ่งมั่นมากเกินไป “ผมคิดว่าโครงงานริเริ่มที่สัมฤทธิ์ผลมากที่สุดที่เราเคยเห็นคือโครงงานที่มีขนาดเล็ก ที่มีเซอร์วิสเพียงหกถึงสิบงานที่ผนวกองค์ประกอบสองสามอย่างเข้าด้วยกัน และใช้เวลาดำเนินการให้เสร็จสิ้นประมาณหกเดือน

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

โครงงานข้างต้นอาจให้ผลตอบแทนที่ลดน้อยลงไป แต่ SOA จะให้คุณค่าสูงสุด (และจะยิ่งเพิ่มขยายมากขึ้นในอนาคต) เมื่อคุณเริ่มต้นวาดกล่องสี่เหลี่ยมล้อมรอบกระบวนการทางธุรกิจที่เกี่ยวข้องกันชุดหนึ่งที่จำเป็นต้องมีการสตรีมมิ่งข้อมูล มากกว่าจะจู่โจมปัญหาทางเทคนิคก่อน Scott Thomson นักสถาปัตยกรรมอาวุโสของ H&R block มีประสบการณ์ในการเลือกใช้แนวทางดังกล่าว “พวกเราจำเป็นต้องทำใจให้สงบลงจากการตีความหมายของข้อมูล และหันไปสร้างเซอร์วิสบนพี้นฐานของข้อมูลเหล่านี้แทน เนื่องจากพวกเราทำได้เพียงแต่สอบถามว่า ธุรกิจของเรามีปัญหาอะไรบ้างที่พยายามแก้ไขอยู่ และขีดความสามารถในการประยุกต์เรื่องใดบ้างที่มีปัญหาเชิงธุรกิจที่กระทบต่อส่วนงานอื่นของบริษัท

Jean-Michel Van Lippevelde นักออกแบบสถาปัตยกรรมระบบที่ Accelior Consulting ก็ได้ข้อสรุปเดียวกัน “จงแก้ปัญหาจากบนสู่ล่างจากมุมมองของกระบวนการทางธุรกิจ” ผลลัพธ์ที่ได้สามารถมองเห็นได้ชัดเจนมาก ดังที่ Accelior’s engagement กับบริษัท ING Lease Belgium ซึ่งตั้งเป้าไว้ที่การผนวก กระบวนการร้องขอสำหรับออกใบเสนอราคาเข้าไปในการร่างใบสัญญาโดยอัตโนมัติ ก่อนหน้านี้กระบวนการดังกล่าวกินเวลาหนึ่งวัน แต่หลังจากที่ทำให้กระบวนการไหลลื่นขึ้น ด้วยการเล็งเห็นความสำคัญของบริการต่างๆ และนำระบบอัตโนมัติมาทดแทนขั้นตอนที่ใช้แรงงานคน ทำให้สามารถลดเวลารอคอยของลูกค้าได้หลายนาที

ขั้นตอนที่สอง

ใช้กระดานไวท์บอร์ด

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

“พวกเราเริ่มต้นการร่างแผนภูมิกระบวนการทำงานด้วยการประชุมกับองค์กรรัฐแต่ละกลุ่มที่เป็นอิสระต่อกัน” Dan Thomas ผู้อำนวยการหลักสูตร DC Stat ที่สำนักงานของ CTO ในรัฐโคลัมเบีย โครงงานที่เต็มไปด้วยความกระตือรือร้นกำลังผูก data warehouse ของหน่วยงานรัฐบาลกว่า 65 แห่งในรัฐโคลัมเบียทำให้เหล่าวุฒิสมาชิกทำงานได้อย่างโปร่งใสยิ่งขึ้นด้วยข่าวสารเพื่อการตัดสินใจเชิงนโยบายที่หลั่งไหลเข้ามาเกือบทุกนาที

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

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

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

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

ขั้นตอนที่สาม

สำรวจสภาวะแวดล้อมขององค์กรคุณ

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

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

SOA มีความเกี่ยวข้องกับเทคโนโลยีกลุ่มหนึ่งที่ทวีจำนวนมากขึ้นเรื่อยๆ สิ่งที่ต้องเตรียมคือ เครื่องมือสำหรับสร้างหรือตรวจสอบเซอร์วิสเหล่านั้น, ค่ารีจีสตรีต่างๆ ที่เกี่ยวข้อง โครงสร้างพื้นฐานแมสแสจสื่อสารที่วางไว้สำหรับเซอร์วิสและแอพพลิเคชันต่างๆ ไว้ใช้ในการติดต่อสื่อสารกัน วิธีการต่างๆ ที่ใช้ผนวกเซอร์วิสต่างๆ เข้าด้วยกัน และการจัดการเซอร์วิสบางประเภทที่เกี่ยวข้องกับตัวกลางเลเยอร์การสื่อสารต่างๆ งานบริหารเครือข่ายในระดับแอพพลิเคชันอาจเข้ามามีบทบาทด้วยเหมือนกัน ดังเช่นแอพพลิเคชันประเภท BPM (Business Process Management) และ BAM (Business Activity Monitoring) คุณอาจต้องเหนื่อยสักหน่อยในการมองหาอินเทอร์เฟซของเว็บเซอร์วิสสำหรับแอพพลิเคชันขององค์กรคุณ

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

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

“พวกเราย้ายแฟ้มข้อมูลผลิตภัณฑ์ไปสู่ SOA เนื่องจากลูกค้าเราต้องการแบบนั้น” Dwain Kinghorn ซีทีโอของ Altiris, ผู้ผลิตแพลตฟอร์มการจัดการด้านความปลอดภัย เครือข่ายและสินทรัพย์รายใหญ่ กล่าว “มันทำให้ลูกค้าเรามีอิสระในการเลือกการบริหารจัดการในแบบต่างๆ ของเรา พวกเขาสามารถเลือกหยิบข้อมูลการจัดการที่ต้องการทีละชิ้นและรวมกันเข้าบนอินเทอร์เฟซการจัดการแบบ SOA ในจอเดียวกัน พวกเขาอาจพัฒนาอินเทอร์เฟซติดต่องานของเขาเองก็ได้”

ขั้นตอนที่สี่

เริ่มต้นเชื่อมต่อกับเซอร์วิสตัวแรกของคุณ

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

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

Scott Thompson จาก H&R Block ได้เรียนรู้คุณค่าของแนวคิดแบบเมล็ดหยาบอย่างยากลำบาก “ผมคิดไว้ในตอนเริ่มต้นออกแบบ พวกเราพยายามพัฒนาเซอร์วิสโดยการปรับแต่งในระดับเชิงวัตถุมากกว่าเป็นงานบริการของธุรกิจอย่างแท้จริง ทำให้ความสามารถนำกลับมาใช้ได้ของเซอร์วิสที่สร้างขึ้นไม่สูงเท่าที่เราหวังไว้” เขากล่าว “ดังนั้นเราจึงย้อนกลับไปทำการออกแบบเซอร์วิสของเราใหม่ให้สามารถนำกลับมาใช้ใหม่ได้มากขึ้น ไม่เพียงแต่เฉพาะในโครงงานนี้เท่านั้นแต่ยังต้องมีการปรับแต่งด้วยวัตถุประสงค์ทางธุรกิจที่เซอร์วิสต่างๆ ถูกออกแบบให้มารองรับ”

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

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

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

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

ขั้นตอนที่ห้า

เลือกและติดตั้งรีจิสทรีหรือคลังจัดเก็บ

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

ทว่าขณะที่จำนวนเซอร์วิสและแอพพลิเคชันที่ใช้เซอร์วิสเพิ่มขึ้นเรื่อยๆ คุณจำเป็นต้องใช้รีจิสทรีที่ถูกต้อง “พวกเราเลือก UDDI รีจิสทรีในปี 2003 และนำไปใช้ในการผลิตปี 2004” Ben Moreland จาก Hartford กล่าว “พวกเราใช้รีจิสทรีตัวนี้เพราะความสามารถลักษณะ dynamic binding ซึ่งทำให้เรามีการเชื่อมโยงระหว่างฝั่งยูสเซอร์และผู้สร้างเซอร์วิสอย่างยืดหยุ่น”

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

การเลือกรีจิสทรีอาจเป็นการตัดสินใจครั้งแรกสุดในการเลือกซื้ออุปกรณ์อยู่ภายใต้ข้อกำหนดของ SOA และอาจเป็นครั้งแรกที่คุณต้องเผชิญหน้ากับการตัดสินใจเลือกระหว่างข้อเสนอที่ผู้ผลิตแต่ละรายกับโซลูชั่นของผู้ผลิต SOA ชั้นยอด ผู้ผลิตแพลตฟอร์มรายใหญ่ทั้งหมดเช่น บีอีเอซิสเต็มส์ ไอบีเอ็ม ไมโครซอฟท์ ออราเคิล และซันจะมีรีจิสทรีและคลังข้อมูลของพวกเขาเอง ทว่าผู้ผลิตซอฟต์แวร์เฉพาะทางโดยตรงที่ประสบความสำเร็จไม่ว่าจะเป็น Above All Software, Flashline, Infravio, SOA Software, และ Systinet โดยทั้งหมด ต่างก็แสดงให้เห็นถึงการผสมผสานความสามารถในด้านต่างๆ ได้อย่างกลมกลืน คุณได้พบกับเครื่องมือต่างๆ มากมายไม่ว่าจะเป็นการแสดงผลความสัมพันธ์ระหว่าง WSDL กับเซอร์วิสต่างๆ ในแบบกราฟิก ระบบรักษาความปลอดภัยด้วยรหัสส่วนบุคคลเพื่อจำกัดสิทธิ์การเข้าถึงเซอร์วิสต่างๆ กลไกควบคุมที่ช่วยจัดการนโยบายของเซอร์วิสต่างๆ และอื่นๆ อีกมากมาย

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

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

ขั้นตอนที่หก

เริ่มประสานกับการกำกับดูแล

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

การกำกับดูแลนั้นอาจสามารถนิยามได้ชัดเจนว่าเป็นการผสมผสานของระเบียนวิธีในการดำเนินงานต่างๆ เช่นว่า ใครมีส่วนต้องรับผิดชอบในเซอร์วิสใด เมื่อมีเหตุการณ์ใดเกิดขึ้น เมื่อใดที่การรับประกันคุณภาพไม่ครอบคลุมถึงปัญหาต่างๆ และอื่นๆ รวมทั้งการจัดการเกี่ยวกับคำนิยามในอินเทอร์เฟซของเซอร์วิสต่างๆ คำนิยามเหล่านี้จะแฝงตัวอยู่ในผังองค์กรไอทีที่จะค่อยๆ เปลี่ยนรูปแบบอันเนื่องจากผลกระทบของ SOA อย่างคาดไม่ถึง “วิธีที่ดีที่สุดในการพิจารณาอินเทอร์เฟซของเซอร์วิสคุณก็คือมองว่าพวกมันถูกออกแบบจากธุรกิจคุณหรือไม่” Randy Heffner รองประธานบริษัท Forrester Research กล่าว “พวกมันควรที่จะได้รับการเอาใจใส่และกำกับดูแลพอๆ กับเวลาที่คุณออกแบบธุรกิจของคุณ”

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

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

Moreland ให้กรณีตัวอย่างหนึ่งของปัญหาที่หากมีการกำกับดูแลที่ดีจะสามารถหลีกเลี่ยงได้ เมื่อไม่นานมานี้ หน่วยธุรกิจหนึ่งของ Hartford ที่ได้เผยแพร่เซอร์วิสที่มีประโยชน์ตัวหนึ่งในฟอร์มของ SOAP ที่เหมาะสม ขอบข่ายอื่นของธุรกิจได้ประยุกต์เซอร์วิสดังกล่าวไปใช้ อีกทั้งยังขอร้องให้เซอร์วิสคืนค่าข้อมูลเพิ่มเติมกลับมาในรูป XML “เจ้าของเซอร์วิสตัวแรกกล่าวว่า ‘ผมไม่มีเงินทุน งบประมาณหรือทรัพยากรที่จะทำอย่างนั้น ผมยังต้องทำอีกหลายอย่าง’” Moreland ย้อนกลับไปถึงเหตุการณ์ในอดีต ในกรณีดังกล่าวเขากล่าวว่าการกำกับดูแลที่ดีนั้นจะระบุได้ถึงเซอร์วิสที่มีปัญหานั้นที่ควรจะถูกดูแลโดยทีมงานที่ทุ่มเทกับการดูแลปรับปรุงมันเพื่อองค์กรทั้งหมด

ขั้นตอนที่เจ็ด

วางแผนระบบความปลอดภัยของคุณ

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

“คนมากมายมีความรู้สึกว่า ‘เมื่อผมทำอะไรภายในไฟล์วอลล์ ภายใต้บริเวณเครือข่ายจำกัดสิทธิ์หรืออะไรก็ตาม ผมรู้สึกปลอดภัยแม้ว่าจะปราศจากระบบรักษาความปลอดภัยที่ซับซ้อนในสภาพแวดล้อมของเซอร์วิสผม’” Heffner จาก Forrester กล่าว “เมื่อทุกคนพูดว่า ‘ผมต้องทำบางสิ่งบางอย่างเกี่ยวกับความปลอดภัย’ มักหมายถึงการเชื่อมต่อภายนอก”

แม้ว่า SOA จะย้ายจุดสนใจไปสู่สถาปัตยกรรมภายใน การผนวกกิจการแบบ B to B ของหุ้นส่วนเป็นการขยายตัวโดยธรรมชาติ และในหลายกรณีก็คือผลประโยชน์หลัก โซลูชั่นในการทำงานข้ามไฟล์วอล์ลสองฝั่งอาจทำได้ง่ายๆ โดยใช้การเชื่อมต่อแบบ SSL ทั้งสองข้าง แต่ก่อนที่คุณจะข้ามไปสู่ข้อสรุปทางเทคโนโลยีใดๆ Heffner ให้คำแนะนำว่าการตัดสินใจครั้งแรกของคุณคือการบอกว่าองค์กรของคุณเป็นแบบ Hub หรือ Spoke

Heffner กล่าวว่า Hub เปรียบได้กับกฎหมาย “ถ้าคุณคือ Walmart ในฐานะที่เป็น Hub คุณเพียงแค่บอกว่าสถาปัตยกรรมจะออกมาในรูปแบบใด เนื่องจากทุกคนต้องทำตามที่คุณบอก” ขณะที่ Spoke “คุณต้องพิจารณาว่าหุ้นส่วนของคุณ ใครบ้างที่คุณต้องติดต่อด้วย สถาปัตยกรรมความปลอดภัยแบบใดที่กำลังทำอยู่ และเมื่อตัดสินใจกำหนดว่ากลยุทธ์ความปลอดภัยของขอบเขตภายนอก ดังนั้นคุณจึงต้องมีเกตเวย์ที่มีระบบความปลอดภัยแบบ XML ซึ่งสามารถกำหนดให้สิทธิการเข้าถึงและสิทธิการใช้งานในระดับนั้นๆ” หรือในความปลอดภัยระดับที่ลึกลงไปที่ซึ่งสิทธิการเข้าถึงอยู่ในรูปเอกสาร XML ขณะที่พวกมันเคลื่อนที่ไปมาภายในองค์กร

โชคดีที่วงการอุตสาหกรรมต่างเห็นพ้องต้องกันในเรื่องกรอบการทำงานพื้นฐานสำหรับการรักษาความปลอดภัยแมสแสจ XML ที่อยู่เหนือเวลาขณะที่พวกมันกำลังเดินทางอยู่: WS-Security ซึ่งอาจเป็นข้อกำหนดเว็บเซอร์วิสที่ใช้บ่อยที่สุดหลังจาก SOAP และ WSDL ทุกวันนี้องค์กรต่างๆ มากมายได้รวม WS-Security กับ SAML tokens เพื่อประกาศตัวตนของผู้ใช้ตลอดจนทุกขั้นตอนของการโอนถ่ายข้อมูล ซึ่งเป็นโซลูชั่นที่มีประโยชน์มากสำหรับองค์กรที่ให้บริการทางด้านการเงิน

ข้อกำหนดทางด้านความปลอดภัยมากมายที่อยู่ในขั้นตอนการพัฒนา WS-Trust เป็นส่วนขยายของ WS-Security ที่ยืนยันว่าผู้ร้องขอเซอร์วิสได้รับสิทธิการใช้ก่อนที่ security token จะได้การตอบรับ WS-SecureConversation นำข้อมูล trust ที่ดึงออกมาจากระบบยืนยันตัวตนที่ได้รับการยอมรับ (positive authentication) ส่งไปยังกลุ่มแมสแสจต่างๆ แล้ว WS-SecurityPolicy จะอนุญาตให้เซอร์วิสสามารถแลกเปลี่ยนนโยบายความปลอดภัยและเจรจากับระบบยืนยันตัวตน (authentication) และระบบยืนยันสิทธิการใช้งาน (authorization) โดยปราศจากการแทรกแซงของยูสเซอร์ อย่างไรก็ตามข้อกำหนดทั้งสามตัวนี้ที่มีใช้กันอย่างแพร่หลายในปัจจุบันนั้นยังไม่มีตัวใดเลยที่ครอบคลุมเพียงพอสำหรับโลกของการสื่อสารแมสแสจ XML ข้ามโดเมน
“สำหรับเราแล้ว นี่คืออีกขอบเขตงานหนึ่งที่เรากำลังทุ่มเทอย่างเต็มกำลังความสามารถจนกว่ามาตรฐานใหม่และการประยุกต์ใช้จะเกิดขึ้นและทำให้งานต่างๆ ง่ายขึ้น” Bob Laird หัวหน้าทีมออกแบบระบบไอทีที่ MCI กล่าว ในเวลาเดียวกัน Laird กำลังให้ความสนใจกับระบบป้องกันการโจมตีจากภายนอก อันเป็นความพยายามที่จะผสมผสานการสร้างตัวจัดการความปลอดภัยโครงสร้างพื้นฐานที่คอยระมัดระวังการไหลของการจราจรและการโอนถ่ายข้อมูลใหม่ๆ และการลงทุนกับฮาร์ดแวร์เชิงป้องกันของ SOA เช่น ไฟล์วอลล์ XML จาก Sarvega

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

ขั้นตอนที่แปด

วางโครงสร้างพื้นฐานระบบสื่อสารแมสแสจ

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

ESB (Enterprise Service Buses) และ EAI middleware จากพันธมิตรทางธุรกิจอย่างเช่น Tibco หรือ webMethods และเซิร์ฟเวอร์แอพพลิเคชันจากบีอีเอ ไอบีเอ็ม และออราเคิล ขยายขีดความสามารถด้วยการผนวกโปรแกรมเสริมที่ทำหน้าที่สื่อสารแมสแสจแบบอะซิงโครนัสที่ไว้ใจได้ ซึ่งจะรองรับครอบคลุมโปรโตคอลสื่อสารแมสแสจทั้งหมดรวมทั้ง SOAP, JMS (Java Message Service), และ MQ (Message Queuing) และซึ่งได้เพิ่มตัวแปลงแอพพลิเคชันสำหรับระบบดั้งเดิม อย่างไรก็ตามในปัจจุบันโซลูชั่นแต่ละตัวมีวิธีการของตัวเองในการยืนยันว่าแมสแสจได้มาถึงแล้ว ซึ่งเป็นสภาพการณ์ที่ไม่ค่อยจะมีการเปลี่ยนแปลงแม้จะมีมาตรฐานการตรวจจับข้อมูลที่กว้างเช่น WS-ReliableMessaging

ESB รับผิดชอบขอบเขตการทำงานที่ยังมีความคลุมเครืออยู่ ขณะที่ Ben Moreland จาก Harford กล่าวว่า “ถ้าคุณมีนักออกแบบระบบ 10 คนอยู่ด้วยกัน คุณอาจได้รับคำนิยาม ESB ถึง 11 แบบ บางคนบอกว่ามันเป็นรูปแบบทางสถาปัตยกรรม ขณะที่อีกคนหนึ่งบอกว่ามันคือผลิตภัณฑ์เดี่ยวตัวหนึ่ง คนอื่นที่เหลือก็อาจบอกว่าเป็นชุดผลิตภัณฑ์กลุ่มหนึ่ง” แม้แต่ในหมู่ผลิตภัณฑ์ของ ESB ที่ทางห้องทดสอบของเราได้ลองทดสอบก็ยังประหลาดใจที่พบว่าผลิตภัณฑ์เหล่านี้มีความหลากหลายมาก

ผู้คนส่วนใหญ่มักมีแนวโน้มตามธรรมชาติที่จะยึดติดกับสิ่งที่พวกเขามีอยู่เดิม Bob Laird ที่ MCI แบ่งปันประสบการณ์ให้ฟังเป็นกรณีตัวอย่าง “พวกเราตัดสินใจร่วมกันที่จะใช้ WebSphere เนื่องจากเราได้ติดตั้ง IBM MQ อยู่แล้ว ซึ่งฟังแล้วดูสมเหตุผล ประกอบกับมันทำให้นักพัฒนาระบบของเราปรับตัวสู่แนวคิดของ SOA ได้สะดวกขึ้นด้วยเครื่องมือที่พวกเขาคุ้นเคย”

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

ทว่ามีเรื่องเล่าบางเรื่องโดยเฉพาะจากร้านค้าขนาดเล็กที่ได้ลดความสนใจลงจากเดิมที่เคยใช้ผู้ค้ารายเดียว “สำหรับเราแล้ว ความยืดหยุ่นเป็นสิ่งที่สำคัญที่สุด” Paul Lindo ผู้ชำนาญการพัฒนาระบบมานานกว่า 13 ปีที่ Federal Reserve และในตอนนี้ดำรงตำแหน่งเป็นซีไอโอบริษัทพัฒนาระบบเล็กๆ ในนิวยอร์ก “สิ่งที่คุณจะได้จากระบบสื่อสารแมสแสจเช่น MQ คือเทคโนโลยีตัวเก่าเอามาปรับปรุงใหม่ด้วยแนวคิดใหม่ของ SOA สำหรับพวกเราแล้วการยึดติดกับมาตรฐานของเว็บเซอร์วิสเป็นเรื่องที่สมเหตุผลมากกว่า”

Laird จาก MCI ยอมรับว่าการพึ่งไอบีเอ็มไปจำกัดทางเลือกในระยะยาว แต่เขาก็เต็มใจที่จะยอมรับมันแลกกับการที่สามารถเริ่มต้น SOA ได้ในวันนี้, พอใจกับการมีต้นทุนแพลตฟอร์มเริ่มต้นที่ต่ำ และทำให้โครงงาน SOA ของเขาเจริญเติบโตไปพร้อมๆ กับชุดผลิตภัณฑ์ของไอบีเอ็ม “และได้โปรดอย่างคิดว่าพวกเราหลับหูหลับตายอมใช้เครื่องมือที่เก่าๆ โทรมๆ” Laird ชี้แจงว่า MCI ท้าทายให้นักพัฒนาระบบของเขาให้ลองใช้เครื่องมืออื่นๆ ที่ไม่ใช่ของไอบีเอ็มตั้งแต่มันเริ่มวางตลาด ซึ่งกลายเป็นที่นิยมในการจัดซื้อในปริมาณน้อยๆ ในตอนแรกและจับรวมไว้ในโครงการเฉพาะกิจต่างๆ ในภายหลัง ถ้าพวกมันผ่านการทดสอบ พวกมันจะให้ผลตอบแทนอย่างมหาศาล “ด้วยวิธีนี้ เรายังคงรักษาให้มีการเปิดกว้างทางความคิดขณะที่สามารถหลีกเลี่ยงปัญหาความไม่สอดคล้องกับระบบโดยรวมได้”
“บริษัทส่วนมากที่ใช้งานระบบมิดเดิ้ลแวร์ที่เน้นการสื่อสารแมสแสจอยู่นั้นไม่ได้ออกแรงเท่ากับกับที่พวกเขาเคยมีเนื่องจากมันไม่มีเหตุผลที่จะใช้แบบโครงสร้างข่ายงานสื่อสารแมสแสจแบบโรบัส ที่มีหลายบริษัทอยู่ในตำแหน่งเดียวกัน” Stack จาก Flashline กล่าว “ดังนั้นเว้นแต่ว่าคุณจะไม่ต้องการมีสิ่งดังกล่าว ดูเหมือนว่าโซลูชั่น MOM (Message-Oriented Middleware) จะกำลังกลายเป็นเซอร์วิสการสื่อสารแมสแสจที่น่าเชื่อถือ และส่วนใหญ่ยังประกาศความตั้งใจในการสนับสนุนโปรโตคอลการสื่อสารแมสแสจที่เชื่อถือได้

ผู้บริหารด้านเทคโนโลยีที่สมาคมเกี่ยวการเงินเป็นหลักเสนอการสนับสนุนมุมมองแบบนี้ โซลูชั่นของเขาเกี่ยวกับการสื่อสารแมสแสจแบบอะซิงโครนัสเป็นผลิตภัณฑ์ของ EAI ที่นอกจากออกแบบสร้างขึ้นเป็นอย่างดีแล้วยังมี binary throughput ที่จำเป็นสำหรับการโอนถ่ายข้อมูลปริมาณมากๆ เมื่อถูกถามความเห็นเกี่ยวกับ ESB เขาตอบกลับด้วยคำถามว่า “ทำไมผมจะต้องไปหาโซลูชั่น JMS ที่มีขนาดเล็กตัวอื่นอีกในเมื่อผมมีโซลูชั่นที่ทรงประสิทธิภาพตัวหนึ่งอยู่แล้ว?”

ขั้นตอนที่เก้า

ติดตั้งระบบบริหารจัดการเซอร์วิส

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

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

การจัดการเซอร์วิสกำลังพัฒนามาตรฐานขึ้นอย่างช้าภายใต้การอนุมัติ WSDM (Web Service Distributed Management) จาก OASIS เมื่อเดือนมีนาคมที่ผ่านมา ข้อกำหนดที่สอง WS-Management ซึ่งคาบเกี่ยวเล็กน้อยกับ WSDM แต่มุ่งความสนใจไปที่การจัดการฮาร์ดแวร์เครือข่ายมากกว่าการสื่อสารแมสแสจในระดับแอพพลิเคชัน ซึ่งถูกเสนอโดยทีมงานเฉพาะกิจด้านการบริหารจัดการเชิงกระจายศูนย์ (Distributed Management Task Force) โดยความร่วมมือของอินเทล ไมโครซอฟท์ และซัน ไมโครซิสเต็ม เมื่อเดินมิถุนายนที่ผ่านมา แต่ปัจจุบันในการใช้งานจริงส่วนมากแล้วคุณจำเป็นต้องใช้โซลูชั่นการจัดการบริหารเว็บเซอร์วิสกับการใช้งาน SOA ของคุณในกรณีที่คุณต้องการควบคุมการดำเนินงานแบบรวมศูนย์ เช่นที่ Bob Laird ของ MCI กล่าวว่า “ในตอนนี้มันกลายเป็นเรื่องที่มีความยุ่งเหยิงซับซ้อนแล้ว และพวกเราก็ทำได้แค่ลองผิดลองถูกไปเรื่อย”

เหล่าบรรดาผู้ผลิตซอฟต์แวร์ทางด้านนี้โดยตรงประกอบไปด้วย Actional, AmberPoint, Blue Titan, และ SOA software ที่เป็นผู้นำเสนอระบบจัดการบริหารเว็บเซอร์วิส แต่ผู้ผลิตระบบการจัดการเครือข่ายขนาดใหญ่กำลังรับช่วงต่อ เช่น บีเอ็มซี ซีเอ เอชพี ไอบีเอ็ม และโนเวลล์ ต่างก็ให้การสนับสนุน WSDM และอยู่ในขั้นตอนสถานะของการร่วมมือกันสร้างระบบจัดการเว็บเซอร์วิสตามข้อเสนอของพวกเขา ทางหนึ่งเป็นการกำเนิดของ AON (Application-Oriented Networking) ของ Cisco ที่ควรจะออกมาเป็นผลิตภัณฑ์ทางด้านเครือข่ายในอีกไม่ช้าพร้อมความสามารถทางด้านการจัดการเซอร์วิสด้วย

Scott Thompson ของ H&R Block กล่าว “พวกเราใช้ AmberPoint” แม้ว่าเขาจะยอมรับว่า เขาได้ค้นพบในเวลาต่อมาว่า โซลูชั่นดังกล่าวมีข้อจำกัดในเรื่องวิธีการที่ไม่ค่อยเป็นมาตรฐานเท่าไหร่ “พวกเรากำลังอยู่ในขั้นเริ่มหัดเดิน” เขากล่าว “เริ่มต้นด้วยระบบตรวจสอบการจัดการในระดับเซอร์วิสพื้นฐาน หลังจากนั้นพวกเราก็หันมาตรวจสอบเหตุการณ์ที่ไม่ปกติ แต่ในความเป็นจริงแล้วเราต้องการที่จะปรับปรุงตัวแบบของเราให้สามารถจัดการฟังก์ชั่นในส่วนของการเข้ารหัส การถอดรหัสข้อมูล การตรวจสอบสิทธิ และการให้สิทธิการเข้าถึงทรัพยากรของระบบ”

Ben Moreland ของ Hartford ให้ความเห็นว่า “ความสามารถในการตรวจพบเมื่อเกิดความผิดพลาดแบบ SLA หรือความผิดพลาดในส่วนของเซอร์วิส และความสามารถเพื่อผลักดันนโยบายต่างๆ” เป็นเหตุผลที่องค์กรเขาเลือกใช้เครื่องมือการจัดการบริหารเว็บเซอร์วิส

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

ขั้นตอนที่สิบ

พิจารณาการประสานการทำงานให้สอดคล้องกัน

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

Randy Heffner จาก Forrester Research เสนอแนวทางปฎิบัติบางประการ “จุดเริ่มต้นในการพิจารณาเกี่ยวกับความสอดคล้องนั้น ผมมีคำร้องประการเดียวคือ...ผมสามารถทำให้งานในหน่วยธุรกิจเสร็จสมบูรณ์ได้อย่างไร” เขาถาม “ถ้าคำตอบคือ ‘เอาละ ผมได้ทำหลายสิ่งให้เกิดขึ้นมาตามลำดับโดยมีแอพพลิเคชันหลายตัวที่อยู่ภายใต้งานเหลานั้น’ เมื่อนั้นแสดงว่าคุณกำลังอยู่สภาพแวดล้อมของการทำงานที่สอดประสานกัน” Heffner เสริมว่า การสอดประสานนั้นต้องการความอดทนในการค้นหาสิ่งที่ซ่อนอยู่ “เนื่องจากมีหลายสิ่งหลายอย่างที่คุณจำเป็นต้องทำในแอพพลิเคชันระดับที่ต่ำกว่า คุณแน่ใจได้เลยว่าจะไม่มีทางทำให้เกิดความสอดคล้องได้ในเวลาเสี้ยววินาที หรือแต่ในเวลา 5 วินาที”

ปัจจุบัน BPEL (Business Process Execution Language) ได้ให้วิธีการที่เป็นมาครฐานในการประสานการทำงานให้สอดคล้องกัน แม้ว่าโซลูชั่นทางด้าน BPM (Business Process Management) ที่ให้โครงสร้างความสอดคล้องในการทำงานที่เพียงพอมาหลายปีแล้ว “การสอดประสานคือความพยายามที่จะรวบรวมหลักเกณฑ์ของ BPM” Lindo ผู้ทำงานในองค์กรพัฒนาระบบในนิวยอร์คกล่าว “และนั่นเป็นความซับซ้อนจนคาดไม่ถึง ถ้าคุณนำมันไปใช้ในอุตสาหกรรมบางอย่างเช่น อุตสาหกรรมการผลิต คุณสามารถทุ่มเทความสนใจเพียงพอให้การจัดการแนวคิดดังกล่าวเป็นไปได้ ในการจัดการธุรกิจทั่วๆ ไป ความเกี่ยวพันต่างๆ นั้นซับซ้อนเกินกว่าที่จะจับรวมเป็นโครงงานจากมุมมองของการเขียนรหัสคำสั่งหรือออกแบบอินเทอร์เฟซติดต่ออันเป็นงานทำได้เชื่องช้าอย่างมาก”

Heffner จาก Forrest ร่างภาพความแตกต่างให้เห็นชัดเจนยิ่งขึ้นระหว่างความสอดประสานของเซอร์วิสต่างๆกับ BPM ซึ่งมีรากฐานมาจากการสร้างตัวแบบขั้นตอนการทำงานตั้งแต่เริ่มต้นจนสิ้นสุด “ทั้งสองส่วนยังเชื่อมต่อกันได้ไม่ดีเท่าไหร่” เขากล่าวขึ้น “ในภาษาของการสร้างตัวแบบ,... ไม่มีทางที่จะมีมุมมองของกระบวนการทำงานที่สมบูรณ์ทั้งหมดที่ผมบอกได้ว่า ‘ตกลงผมเห็นด้วย, จับขั้นตอนดังกล่าวใส่ลงใน BPEL ได้เลย’ ผมยังไม่เคยได้ทำอย่างว่าเลยสักครั้ง”

ในความเห็นของ Stack จาก Flashline ความผิดพลาดในการปรับแต่งเพิ่มความสะดวกให้กับการปฎิสัมพันธ์กับผู้ใช้งานเป็นจุดอ่อนที่สุดของ BPEL “เมื่อวงการอุตสาหกรรมกำลังพยายามนำ BPEL เข้ามาใช้เมื่อปีกลาย ผมคิดว่าการตัดสินใจที่จะทำโดยให้มีความสอดประสานการแบบเครื่องจักรไปยังเครื่องจักรเท่านั้นเป็นความผิดอย่างใหญ่หลวง” Stack กล่าวไว้ “พวกเราไม่มีลูกค้าคนใดเลยที่ใช้ BPEL ในทุกขั้นตอนเพียงแต่ใช้เพราะคิดว่าอยากทดลองหรือเป็นเรื่องเล็กน้อย” เขาเสริม รวมทั้งลูกค้าที่ใช้เว็บเซอร์วิสที่ซับซ้อนมากเช่น Sabre และ Countrywide

Ben Moreland จาก Hartford มองเห็นศักยภาพของส่วนขยายจากข้อกำหนด BPEL ที่มาจากการเสนอร่วมกันของ IBM และ SAP “เวลาผ่านไป เรามี BPEL4People ซึ่งเป็นมาตรฐานที่ผู้ผลิตรายใหญ่สองแห่งได้ร่วมกันผลักดันให้เกิดขึ้นมา เนื่องจากพวกเขาตระหนักถึงประสิทธิภาพของขั้นตอนการไหลของงานภายในข้อกำหนดของ BPEL” เขาอธิบาย “ผมคิดว่าในสองเลเยอร์ดังกล่าวคือ ความสอดประสานของ BPEL กับนั้นตอนการไหลของงาน BPM กำลังผนวกเข้าด้วยกันแล้ว”

ในเวลาเดียวกัน มันก็ไม่ได้กระทบต่อการเสาะหาโซลูชั่นทาง BPM ที่เหมาะสม ดังที่ Scott Thompson แห่ง H&R Block ได้ค้นพบ เป็นเรื่องที่น่าขันที่การทำงานกับเครื่องมือทาง BPM ของ Tibco จะช่วยให้ SOA เพิ่มประโยชน์ในบริษัทนี้ “กระทั่งเราได้เริ่มประสานการทำงานของเซอร์วิสที่หลากหลายเข้าด้วยกันไปสู่กระบวนการทางธุรกิจแล้ว เราไม่ได้มีการปรับแต่ง SOA ที่เห็นได้ชัดแต่อย่างใด” เขากล่าว “มันเป็นมากกว่าโครงการทางด้านไอทีระดับล่างเท่านั้น”

ก้าวอย่างสู่อนาคต

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

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

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

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

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

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