ซิป้า พัฒนาระบบ One Stop Services ด้วย SOA

ซิป้า พัฒนาระบบ One Stop Services ด้วย SOA Service Oriented Architecture

ซิป้าสร้างระบบ One Stop Service บูรณาการบริการของหน่วยงานราชการ นำหลักการของ Services-Oriented Architecture (SOA) เข้ามาช่วยเชื่อมโยงข้อมูลระหว่างหน่วยงานราชการต่างๆ ของภาครัฐ ช่วยลดความซ้ำซ้อนของข้อมูล เพิ่มประสิทธิภาพในการให้บริการประชาชน

นายมนู อรดีดลเชษฐ์ ผู้อำนวยการ สำนักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ (องค์การมหาชน) กระทรวงเทคโนโลยีสารสนเทศและการสื่อสาร กล่าวว่า SOA จะเป็นสถาปัตยกรรมซอฟต์แวร์ที่สำคัญของอุตสาหกรรมซอฟต์แวร์นับจากนี้ไป ซึ่งไม่เพียงแต่นำไปใช้เพื่อบูรณาการข้อมูลขององค์กร และงานภาครัฐ แต่ยังเป็นแนวทางการสร้างระบบซอฟต์แวร์แบบ Service-based ที่เน้นเรื่องการนำมาใช้ใหม่และความคล่องตัวในการปรับเปลี่ยนซอฟต์แวร์ให้ทันสถานการณ์
โครงการ One Stop Service เป็นหนึ่งในโครงการ e-government โดยมี IBM Websphere Application Server 6.0 บริหารจัดการที่ระบบกลางเชื่อมโยงข้อมูลจากหน่วยงานต่างๆ ผ่านระบบอินเทอร์เน็ตซึ่งเมื่อโครงการดังกล่าวเสร็จสิ้น จะทำให้ผู้มาใช้บริการสามารถใช้บริการหลายๆ อย่างได้พร้อมกันในครั้งเดียว ช่วยลดเวลาในการให้บริการของผู้มาใช้บริการได้อย่างมาก
ในเบื้องต้นได้มีการเชื่อมโยงข้อมูลกับหน่วยงานที่เข้าร่วมโครงการนำร่อง อาทิ ระบบการให้บริการสาธารณูปโภคทั้งประเทศ ได้แก่ ไฟฟ้า น้ำประปา โทรศัพท์ ธนาคาร, ระบบสาธารณสุข โรงพยาบาลภูเก็ต, ระบบการศึกษาโรงเรียนภูเก็ต, ระบบตรวจคนเข้าเมืองภูเก็ต, ระบบจัดหางานภูเก็ต และระบบศาล-ตำรวจภูเก็ต เข้าไว้ด้วยกัน

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

ทั้งนี้ การ์ทเนอร์ได้คาดการณ์เอาไว้ว่า ในปี พ.ศ.2551 จะมีองค์กรธุรกิจมากกว่า 60% จากองค์กรทั้งหมดทั่วโลกพัฒนาระบบโดยใช้ SOA ซึ่งจะเป็นหลักการสำคัญในการสร้างระบบโครงสร้างพื้นฐานไอที

ธ.ทหารไทยนำร่อง วางหลัก SOA สู่ การให้บริการธุรกรรมแห่งอนาคต

ธ.ทหารไทยนำร่อง วางหลัก Service Oriented Architecture SOA สู่ การให้บริการธุรกรรมแห่งอนาคต

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

ผู้ช่วยกรรมการผู้จัดการใหญ่สายงานเทคโนโลยี ธนาคารทหารไทย กล่าวต่อไปว่า การปรับกระบวนการทำงานตามหลักการของ SOA ครั้งนี้ ธนาคารเลือกใช้ IBM WebSphere เป็นมิดเดิลแวร์หลัก ในการเพิ่มประสิทธิภาพการพัฒนาแอพพลิเคชั่นสำหรับหลายส่วนงาน อาทิ ระบบ Cash Management ที่ต้องมีการพัฒนาในส่วนของการเชื่อมต่อกับระบบหลังบ้านหลายระบบงาน ที่ประมวลผลอยู่บนหลากหลายแพลตฟอร์ม ระบบ ROSCs (Report on the Observance of Standards and Codes) ที่ต้องพัฒนาให้แล้วเสร็จทันตามกำหนดเวลาของทางการ ปปง. และ บริการโอนเงินข้ามธนาคารผ่านเคาน์เตอร์สาขา (Inter-bank Transfer via Teller) เป็นต้น

นางสาวสายพิน กล่าวด้วยว่า การปรับกระบวนการทำงานและระบบไอทีตามหลักการ SOA ช่วยให้ธนาคารสามารถพัฒนาแอพพลิเคชั่นใหม่ๆ หรือปรับปรุงแอพพลิเคชั่นที่ใช้งานอยู่เดิม สามารถทำงานเชื่อมต่อกันกับระบบเดิมที่มีอยู่หลากหลายเข้าด้วยกันอย่างมีประสิทธิภาพ โดยไม่มีข้อจำกัดด้านแพลตฟอร์ม ภาษาในการพัฒนาโปรแกรม ระบบปฏิบัติการ หรือแม้กระทั่งประเภทของเครื่อง นอกจากนี้ การพัฒนาแอพพลิเคชั่นบน IBM WebSphere Solution ตามหลักการของ SOA สามารถนำ Service เดิมที่พัฒนาใช้งานอยู่แล้วกลับมาใช้กับระบบงานใหม่ (Reusability) ได้โดยไม่ต้องเสียเวลาและค่าใช้จ่ายในการพัฒนาใหม่ทุกครั้ง ทำให้ประหยัดเวลา ค่าใช้จ่าย และสามารถใช้งานได้อย่างรวดเร็ว มีความถูกต้องและมีความปลอดภัยสูง

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

คู่มือ 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 ครั้งแรกจะสร้างความเชื่อมโยงในการสื่อสารระหว่างฝ่ายไอทีกับส่วนธุรกิจ และในบางกรณี การเริ่มต้นจะส่งผลกระทบต่อโครงสร้างองค์กรโดยรวมขณะที่ผู้คนเติบโตขึ้นด้วยความเข้าใจว่าวิถีทางของเซอร์วิสสามารถขจัดการทำงานที่ซ้ำซ้อนและลดเวลาในการพัฒนาระบบงานได้อย่างไร โดยนัยนี้อนาคตนั้นได้เริ่มเดินทางมาถึงแล้ว

บริหารจัดการแบบ SOA : กฎของการแข่งขันในธุรกิจ

บริหารจัดการแบบ Service Oriented Architecture SOA : กฎของการแข่งขันในธุรกิจ

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

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

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

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

ชีวิตที่ขึ้นอยู่กับกฏ

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

การพัฒนาและการบังคับให้เป็นไปตามกฎของนโยบาย SOA และระเบียบปฎิบัติเป็นไปโดยชื่อ การบริหารจัดการ(Governance)แบบ SOA การบริหาร การจัดการและสถาปัตยกรรมที่ออกแบบจะไปพร้อมกัน ในวิธีเดียวกันกับการสร้างโค้ด, มาตรฐาน และแม้แต่วิธีการตรวจสอบกระบวนการต่าง ๆ เพื่อให้ทุกอย่างเป็นไปตามกรอบที่วางเอาไว้ และSOA Governance นั้นก็จะเป็นส่วนนอกที่ครอบทั้งในเรื่องจองการออกแบบและสถาปัตยกรรมต่าง ๆ เอาไว้ทั้งหมดอีกเช่นกัน

“ถ้าหากไม่มีการบริหารจัดการแบบ SOA คุณก็จะลงเอยแบบ Web services ที่เป็น DLL แย่ ๆ ออกมา” Roman Stanek หัวหน้าการออกแบบซอฟต์แวร์และผู้ก่อตั้ง Systinet ผู้ให้บริการเกี่ยวกับ SOA กล่าว “การบริหารจัดการแบบ SOA ช่วยให้เกิดความแน่นอนในการดำเนินงาน ความสามารถในการคาดการณ์ และทำให้สามารถสร้างแอพพลิเคชันขนาดใหญ่จากงานในส่วนเล็กๆออกมาได้”

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

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

การกำหนดนโยบายให้เป็นที่พอใจ

จากข้อมูลของ Systinet’s Stanek ระบุว่าการจะให้ได้ผลในการบริหารจัดการนั้นขึ้นอยู่กับกระบวนการปฏิบัติงาน ที่ใช้สร้างนโยบายออกมา หรืออธิบายได้ว่า เป็นวิธีที่คุณใช้ทำ, สื่อสาร และกำหนดตัวเลือกที่บังคับใช้

การบริหารจัดการแบบ SOA ที่ดีเป็นการปฏิบัติที่เหมือนกับการมาประชุมกันของคนจำนวนมาก ๆ มากกว่าเป็นการทำการแบบเผด็จการ “สิ่งผิดพลาดที่ใหญ่ที่สุดขององค์กรที่ได้ทำคือการขาดการติดต่อสื่อสารทำความเข้าใจกันอย่างเพียงพอและขาดการทำงานร่วมกัน” จากคำกล่าวของ Burton’s Manes

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

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

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

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

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

นโยบายที่ 1

นโยบายสามารถมีผลกระทบต่อทุกมุมมองด้านระยะเวลาของโปรแกรม รวมถึงการออกแบบ การนำไปใช้งาน และการปฏิบัติการ ตัวอย่างเช่น นโยบายในขณะออกแบบอาจเป็นการเริ่มการสะสมของชื่อเพื่อวัตถุประสงค์เฉพาะต่างๆ ที่เกี่ยวกับบริษัท (Corporate namespace) ส่วนนโยบายการนำไปใช้งานอาจต้องการให้โปรแกรมของระดับผลิตภัณฑ์ตรงตามความต้องการที่กำหนดไว้โดยองค์กร WS-I(Web Service Interoperability) นโยบายการปฏิบัติการอาจต้องการให้โปรแกรมทั้งหมดที่นำมาใช้ประโยชน์ได้รับการจัดการและใช้ระบบพื้นฐานความปลอดภัยของบริษัท

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

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

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

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

สิ่งที่มีคุณค่าของการบริหารจัดการที่ยังคงเป็นข้อโต้เถียง

กระบวนการบริหารจัดการ (Governance) จะสร้างนโยบายต่างๆ แผนการเกี่ยวกับ XML เอกสารเกี่ยวกับWSDL การจัดเตรียมเอกสารต่างๆ และประดิษฐ์กรรมอื่นๆ และสิ่งเหล่านี้จะถูกแจกจ่ายให้กับผู้สนใจ

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

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

ผู้ค้าบางรายเสนอสิ่งที่พวกเขาเรียกว่า “คลัง (Repositories)” การลงทะเบียนที่ใช้เป็นที่เก็บข้อมูลที่มีการเปลี่ยนแปลงได้สำหรับบริการต่างๆ ที่ยิ่งกว่าเอกสารที่เกี่ยวกับ WSDL เพราะว่าการลงทะเบียนและคลังข้อมูลนั้นมีความสำคัญต่อกระบวนการพัฒนา ลองดูซอฟต์แวร์ที่สามารถผสมผสานได้อย่างดียิ่งกับสภาพแวดล้อมในการพัฒนาของคุณ ตัวอย่างเช่น ถ้าคุณคือ Eclipse Shop ก็ต้องมั่นใจว่าคุณเลือกการลงทะเบียนที่มี plug-in สำหรับ Eclipse

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

นโยบายการแสดงระยะเวลานั้นมีประสิทธิภาพที่สุดก็ต่อเมื่อมันสามารถแสดงให้เห็นได้ด้วยระบบ WSM (Web services management) อาทิ ระบบของ Actional AmberPoint, Blue Titan, หรือซอฟต์แวร์ SOA ระบบ WSM ส่วนมากจะสื่อถึงสภาพของการถูกบังคับให้กระทำบนซอง SOAP ภายในระยะเวลาที่กำหนด ตัวอย่างเช่น WSM สามารถทำให้มั่นใจได้ว่าบริการต่างๆ ใช้ตัวแบบความปลอดภัยเป็นการเฉพาะ หรือ เอกสาร XML ที่แนบมานั้นสอดคล้องกับแผนการเฉพาะ

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

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

วางกฏในการทำงาน

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

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

การจัดการโครงการของกิจการมักเป็น One-stop shop สำหรับการบังคับใช้นโยบาย ผู้จัดการโครงการสามารถนำโครงการไปสู่การยินยอมปฏิบัติตามโดยปราศจากการบังคับเข้มงวด เทคนิควิธีอื่นๆ รวมถึงการทบทวนโครงการโดยร่างการบริหารจัดการแนวคิดเกี่ยวกับ SOA ก่อนที่จะนำกองทุนออกมา

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

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

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

การร่างสัญญา (Crafting Contracts)

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

“สัญญาต่างๆ จะนำวงจรชีวิตทั้งของผู้บริโภคและผู้ผลิตมารวมเข้าด้วยกัน” สตาเน็คจากซิสติเน็ตอธิบาย “สัญญาเป็นจุดที่ใช้อ้างอิงในการอธิบายความต้องการของทั้งสองฝ่าย” สัญญาไม่ใช่ข้อตกลงระดับการบริการ (Service-level agreement) แบบทางเดียว แต่สัญญาอาจกำหนดพฤติกรรมของผู้บริโภคที่สามารถยอมรับได้ก็เพื่อว่าผู้ประกอบการด้านโปรแกรมสามารถวางแผนการบริโภค แนวทางก็คือให้ผู้ผลิตเฝ้าติดตามและคาดคะเนความต้องการของผู้บริโภค

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

การเริ่มต้นในแนวทางที่ถูกต้อง

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

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

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

เพราะแนวคิดเกี่ยวกับ SOA เป็นการกระจายอำนาจโดยปกติวิสัย การบริหารจัดการ (Governance) คือความแตกต่างระหว่างความสำเร็จกับความสับสนวุ่นวาย ตามที่เมนได้กล่าวไว้ “การทำโครงการ Web service เล็กๆ จำนวนมากโดยมิได้บริหารจัดการนั้น ยังไงก็ไม่ใช่ SOA แต่เป็นแค่ของเล่นเท่านั้น”

ข้อปฏิบัติสำคัญในสำหรับการบริหารจัดการ SOA ที่ดี

การบริหารงานการจัดการแบบ SOA เป็นการอยู่ร่วมกันในสังคมแบบธรรมชาติ เป็นการเปิดโอกาสให้มีการพุดคุยกันอย่างต่อเนื่องระหว่าวผู้พัฒนาและผู้ออกแบบ

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

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

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

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

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

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

SOA กับ Web Services เหมือนหรือแตกต่างกันอย่างไร

Service Oriented Architecture SOA กับ Web Services เหมือนหรือแตกต่างกันอย่างไร

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

คุณเคยได้ยินเรื่องเล่าเกี่ยวกับ SOA บ้างหรือเปล่า?

คุณเคยได้ยินเรื่องเล่าเกี่ยวกับ Service Oriented Architecture SOA บ้างหรือเปล่า?

จากคำถามที่ว่า Service Oriented Architecture หรือ SOA นั้นเป็นกลยุทธ์ทางด้านธุรกิจ ชุดเว็บเซอร์วิส หรือว่าเป็นผีในตำนานที่ชอบซ่อนอยู่ใต้เตียงของพนักงานฝ่ายไอทีในตอนกลางคืนกันแน่?

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

ต่อไปนี้คือ เรื่องเล่า 5 เรื่องเกี่ยวกับ SOA ที่มีการพูดถึงกันมาก ซึ่งเราจะชี้ให้เห็นถึงข้อเท็จจริงที่เกี่ยวข้องในแต่ละประเด็น:

1. ราคาสูง

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

2. บุคคลลึกลับ

SOA ถูกตรวจพบขณะกำลังซ่อนตัวอยู่ที่เบาะด้านหลังรถของผู้จัดการฝ่ายไอที เมื่อผู้จัดการฝ่าย

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

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

3. SOA เป็นความรับผิดชอบของพนักงานฝ่ายไอที

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

4. ลูกกวาดป๊อปร็อค น้ำอัดลม และซอฟต์แวร์โอเพ่นซอร์ส

การผนวกรวมแอพพลิเคชันแบบปิด (Proprietary) เข้ากับซอฟต์แวร์โอเพ่นซอร์ส (open source) บนสถาปัตยกรรม SOA ของคุณ นับว่าเป็นส่วนผสมที่มีอานุภาพทำลายล้างเทียบเท่ากับการใส่ลูดกวาด

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

5. คุณยังคงได้เกรด A อยู่ดี แม้ว่าคุณจะสอบตกก็ตาม

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

กรอบงานของธุรกิจที่ใช้ หลัก SOA เพื่อรองรับความไม่แน่นอน

กรอบงานของธุรกิจที่ใช้ หลัก Service Oriented Architecture SOA เพื่อรองรับความไม่แน่นอน

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

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

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

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

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

การพัฒนาข้อตกลงการบริการ(Service Agreement Development) : เพื่อทำให้การบริการอยู่ในระดับที่น่ามั่นใจของคุณภาพและผลลัพธ์ของการบริการ กิจการต่าง ๆ จะต้องมีการทำงานในส่วนของการออกข้อรายละเอียดของข้อตกลงของการบริการกับบริการของโพรไวเดอร์สำหรับเทอมและสภาวะของระดับการบริการสัญญาและค่าธรรมเนียมที่เกี่ยวข้องกับบริการ
การออกแบบส่วนประกอบทั้งหมดของการบริการ (Service Composition Design) : ด้วยการเจาะจงข้อตกลงของการบริการ กิจการสามารถออกแบบว่าวิธีการบริการควรจะประกอบด้วยสิ่งใดเพื่อบรรลุจุดประสงค์ของธุรกิจของการบริการที่ประกอบขึ้นมา การออกแบบอาจจะกำหนดโดยเริ่มต้นเป็น Roadmap เป็นแผนการทำงานคร่าว ๆ ของการดำเนินการบริการที่มีอยู่ การเริ่มต้นการออกแบบจะต้องมีการวิเคราะห์และกำหนดด้วยการประเมินผลในทางบวกและข้อควรคำนึงถึงต่าง ๆ

การประเมินค่าส่วนประกอบต่าง ๆ ของการบริการ (Service Composition Evaluation) : ผลลัพธ์ของการบริการจะต้องถูกจับและวิเคราะห์ในแง่ของต้นทุนและกำไรทางด้านเศรษฐศาสตร์ การออกแบบส่วนประกอบของการบริการจะถูกประเมินค่าโดยยึดหลักของเศรษฐศาสตร์ในคุณค่าของการลดต้นทุน, ประสิทธิภาพที่พัฒนาขึ้น และคุณค่าทางกลยุทธ์ทั้งหมด แสดงเป็น functional กับ non functional
การจัดการการปฏิบัติงานของบริการ (Service Operation Management) : ในท้ายที่สุด ระหว่างที่มีการปฏิบัติงานจริง ลักษณะต่าง ๆ ของการบริการจะต้องถูกจัดการโดยกิจการ ข้อยกเว้นจะต้องถูกจัดการลงและคุณภาพของการบริการจะถูกควบคุมและจัดการ
การบริการแบบไม่แน่นอนในบริการต่าง ๆ

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

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

สถาปัตยกรรมบริการเชิงรุก (Service Oriented Architecture: SOA)

สถาปัตยกรรมบริการเชิงรุก (Service Oriented Architecture: SOA)

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

องค์ประกอบที่สำคัญของ SOA
องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้
1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้
2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)
3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้
4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ
5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ

ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้ องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้

องค์ประกอบต่อไปนี้เป็นองค์ประกอบที่จำเป็น เพื่อให้สามารถเรียกใช้บริการอื่นๆ ได้ ดังนี้1. เซอร์วิส (Service) กลุ่มของอินเตอร์เฟสที่ระบุฟังก์ชันต่างๆ ที่สามารถให้ระบบอื่นสามารถเรียกใช้บริการได้2. ผู้ให้บริการ (Service Provider) กลุ่มของคอมโพเนนต์ที่สามารถทำฟังก์ชันที่เป็นบริการตามที่กำหนดไว้เป็นเซอร์วิส (Service Specification)3. ผู้รับบริการ (Service Consumer or Requestor) ระบบอื่นๆ ที่เรียกใช้เซอร์วิสซึ่งระบบอื่นๆ อาจจะเป็นเซอร์วิสที่เรียกใช้เซอร์วิสด้วยกันก็ได้4. ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิสและค้นหาสถานที่ตั้งของผู้ให้บริการ (Service Locator) เป็นผู้ให้บริการประเภทหนึ่ง ซึ่งมีหน้าที่ลงทะเบียนรายละเอียดเกี่ยวกับผู้ให้บริการ (Service Registry) และคอยให้บริการข้อมูลรายละเอียดที่จำเป็นสำหรับการเรียกใช้บริการ5. ตัวแทนติดต่อระหว่างผู้รับบริการและผู้ให้บริการ (Service Broker) ทำหน้าที่ช่วยติดต่อส่งคำร้องขอบริการจากผู้รับบริการไปยังกลุ่มของผู้ให้บริการ เพื่อเพิ่มความสะดวกในการติดต่อเรียกใช้บริการ ขั้นตอนการทำงานร่วมกันระหว่างผู้รับบริการ ผู้ให้บริการ ตัวแทน และผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส เพื่อให้ผู้รับบริการสามารถเรียกใช้เซอร์วิสที่ต้องการได้

จากรูปเริ่มต้นที่การประกาศแจ้งการให้บริการ (Publish) เมื่อผู้ให้บริการต้องการประกาศแจ้งให้ผู้อื่นทราบและสามารถเรียกใช้บริการได้ ผู้ให้บริการจะต้องนำรายละเอียดการให้บริการ (Service Description) มาลงทะเบียนเก็บไว้ ที่ผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส (Service Registry) เพื่อให้ผู้ต้องการรับบริการได้มาค้นหาและเรียกใช้

เมื่อผู้รับบริการต้องการเรียกใช้บริการจะต้องเริ่มจากการค้นหาบริการที่ต้องการ (Find) ว่ามีผู้ให้บริการใดบ้างที่ให้บริการตามที่ตนต้องการ ซึ่งผู้ให้บริการข้อมูลรายละเอียดของเซอร์วิส จะเป็นผู้ค้นคืน รายละเอียดของผู้ให้บริการที่จำเป็นสำหรับติดต่อขอรับบริการเชื่อมต่อไปยังผู้ให้บริการและเรียกใช้ (Bind and Invoke) หลังจากผู้รับบริการได้รายละเอียดของผู้ให้บริการจะทำการเชื่อมต่อไปยังผู้ให้บริการ ตามที่อยู่ด้วยวิธีการติดต่อสื่อสาร (Transport Protocol) เพื่อส่งคำร้องขอบริการ ตามรายละเอียดวิธีการเรียกใช้บริการและผลของการให้บริการจะถูกส่งกลับมายังผู้ร้องขอบริการด้วยวิธีการและมีรายละเอียดตามที่กำหนดเช่นกัน

ตัวอย่างการนำ SOA มาประยุกต์ใช้
ตัวอย่างที่นำมาเสนอ คือ เฟรมเวิร์กสถาปัตยกรรมบริการเชิงรุกสำหรับ Mobile Services (A Services-Oriented Architecture Framework for Mobile Services) ซึ่งมีวัตถุประสงค์ก็คือ การนำ SOA มาเข้ามาใช้เพื่อช่วยในการออกแบบ mobile service ที่มี service ที่หลากหลายและให้ service เหล่านั้นสามารถทำงานร่วมกันได้

จากรูปที่ 2 จะเป็นการแสดงมุมมองใหม่ของ SOA ที่รองรับ mobile service ตั้งแต่ component หลักของ mobile service ซึ่งแต่ละ service จะมีเป็นของตัวเอง รวมถึงการแสดง component ที่เป็น mobility controller โดยมีลำดับขั้นตอนการทำงานดังนี้ เริ่มจากตัว service ได้ทำการลงทะเบียนไว้ที่ service directory เพื่อเป็นการบ่งบอกว่าจะให้ใช้ service อะไรได้บ้าง และเมื่อ service consumer ต้องการใช้บริการ ก็จะไปค้นหา service ที่ต้องการในตัว service directory ซึ่งในตัว service จะบอกว่าสามารถเรียกใช้ได้ที่ไหน และมีวิธีใช้อย่างไร เมื่อได้ service ที่ต้องการแล้วตัว service consumer ก็ทำการร้องขอใช้บริการไปที่ตัว service ซึ่งตัว service ก็จะให้บริการนั้นเลยโดยใช้ component ของตัวเอง แต่ถ้าต้องการใช้ component อื่นร่วมด้วย ตัว service ก็ให้ตัว Mobility Controller เป็นตัวจัดการ และตัว Mobility Controller ก็จะไปค้นหา service ที่ต้องการมา และก็นำมาใช้ร่วมกัน

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

ที่มา:

:Roadmap to SOA สำหรับหน่วยงานราชการ กรณีศึกษา One Stop Services, สำนักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ (องค์การมหาชน)
:http://www-128.ibm.com/developerworks/webservices/newto/#1
:Do van Thanh Telenor & Norwegian University of
Scienceand Technology email: thanh-van.do@telenor.com
:Ivar Jorstad Norwegian University of Science and
Technology email: ivar@ongx.org

JBoss บุกตลาด SOA ด้วย jBPM และ JBoss ESB

JBoss บุกตลาด Service Oriented Architecture SOA ด้วย jBPM และ JBoss ESB

JBoss ลุย SOA เต็มตัว ด้วยซอฟต์แวร์ jBPM(Java Business Process Management) สนับสนุน BPEL 1.1 และ 1.2
และจะออก ESB(Enterprise Service Bus) beta version ในสัปดาห์นี้

jBPM เป็นแพลตฟอร์มสำหรับ workflow, การจัดการกระบวนการทางธุรกิจ(Business Process Management:BPM) และการประสานงาน
ของกระบวนการ(Process Orchestration) นอกจากนี้ยังสนับสนุน jPDL(jBPM Process Definition Language) ด้วย
BPM มีความสำคัญยิ่งกับ SOA เพราะ SOA เป็นการทำงานร่วมกันของกระบวนการทางธุรกิจ และการสร้าง service ให้ผู้อื่นเรียกใช้

JBoss อ้างว่า มีการดาว์โหลด jBPM เพิ่มขึ้นถึง 3 เท่าจากปีที่แล้ว ปัจจุบันมีการดาวน์โหลด 20,000 ครั้งต่อเดือน BPEL 1.1 จะถูกเพิ่มใน jBPM ในเดือนกันยายน ส่วน BPEL 2.0 อยู่ระหว่างการอนุมัติจาก OASIS

นักวิเคราะห์ กล่าวว่า การสนับสนุน BPEL และการออก ESB เป็นเรื่องจำเป็นอย่างมากของ JBoss ในปัจจุบันนี้ซอฟต์แวร์สนับสนุน SOA เป็นสิ่ง
สำคัญมาก การมีแค่ Application Server ไม่พอเสียแล้วสำหรับตอนนี้ JBoss ต้องมีโครงสร้างพื้นฐานที่รองรับเซอร์วิสที่ใช้ในสภาพแวดล้อมขององค์กร
JBoss กำลังตามหลังผู้พัฒนา open source เจ้าอื่นอย่าง Apache ซึ่งตอนนี้ก็มี ServiceMix(http://servicemix.org) การออก JBossESB และ jBPM เป็นเรื่องที่ JBoss ต้องทำเพื่อความอยู่รอด นอกจากนี้การสนับสนุน BPEL ก็ไม่ใช่เรื่องใหม่อะไร และยังทำให้ BPM engine ของ JBoss ซับซ้อนยิ่งขึ้น เพราะมันไม่ได้รองรับ BPEL ตั้งแต่ต้น

JBoss ESB ตอนนี้เป็น Beta version จะออก final version ภายในปีนี้ JBoss ESB จะเป็นเหมือนกาวที่เชื่อมเซอร์วิสต่างๆ ให้ทำงานร่วมกันได้เพื่อ สร้าง SOA application ดาวน์โหลดได้ที่ http://labs.jboss.com/portal/jbossesb/downloads

Oracle ออก Oracle SOA suite Developer Preview

Oracle ออก Oracle Service Oriented Architecture SOA suite Developer Preview

Oracle ออก developer preview ให้นักพัฒนาได้ดาวน์โหลด Oracle SOA suite ไปลองใช้กัน

Oracle SOA suite เป็นคอมโพเนนต์ที่ประกอบด้วยโครงสร้างพื้นฐานสำหรับ สร้าง, deploy และจัดการเซอร์วิส โดยประกอบไปด้วย
-Integrated Service Environment (ISE) : สำหรับพัฒนาเซอร์วิส โดยใช้ JDeveloper, BPEL และ ESB designer
-Oracle BPEL Process Manager : ช่วยประสานงานเซอร์วิสในการสร้างกระบวนการทางธุรกิจ
-ESB : เพื่อติดต่อกับระบบ IT เดิมขององค์กร และระบบขององค์กรอื่น
-Oracle Business Rules : เป็น rule engine สำหรับใช้กฎธุรกิจในการตัดสินใจ สนับสนุนการแยกกฎธุรกิจออกจากกระบวนการทำงาน
-Oracle Business Activity Monitoring : มีหน้าที่ตรวจสอบเซอร์วิส และเหตุการณ์ต่างๆ โดยทำงานเป็นแบบ real-time
-Oracle Web Services Manager : จัดการด้านความปลอดภัย เช่น การพิสูจน์ตัวจริง(authentication),การให้อำนาจ(authorization) และการเข้ารหัส เป็นต้น

ในเวอร์ชัน developer preview จะมี UDDI registry กับ Oracle Application Server 10g Release 3 เพิ่มมาให้ด้วย
นอกจากนี้ Oracle ยังออก developer preview ของ JDeveloper และ Oracle J2EE Container (OC4J) สนับสนุน EJB 3.0 และ JPA

ผลสำรวจชี้ SOA ไม่ค่อยได้รับความสนใจในเอเชีย

ผลสำรวจชี้ Service Oriented Architecture SOA ไม่ค่อยได้รับความสนใจในเอเชีย

Springboard(www.springboardresearch.com) ทำการสำรวจ CIO และผู้รับผิดชอบ IT ขององค์กรต่างๆ 2,615 คนในประเทศออสเตรเลีย จีน อินเดีย และสิงคโปร์ พบว่ามีเพียง 21% เท่านั้นที่สนใจ SOA จากผลการสำรวจยังพบอีกว่า IBM เป็นผู้นำด้าน IT เหนือกว่า vendor เจ้าอื่น โดย 50% ขององค์กรที่วางแผนจะสร้าง SOA บอกว่า IBM เป็นตัวเลือกที่ดีสุดที่จะช่วยบริษัทในการย้ายจากระบบเดิมไปเป็น SOA
Springboard พบว่าองค์กรที่กำลังพัฒนา SOA ส่วนใหญ่หรือ 54% ใช้ SOA เพื่อการรวมแอพพลิเคชันต่างๆ เข้าไว้ด้วยกัน อีก 27% ใช้ SOA เพื่อรองรับเว็บเซอร์วิส และเว็บแอพพลิเคชัน อีก 9%ใช้เพื่อการการรวม และใช้ข้อมูลร่วมกันในองค์กร และสุดท้ายอีก 9% ใช้เพื่อสร้างเซอร์วิสที่ใช้ร่วมกันในองค์กร

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

ผลสำรวจชี้โปรเจ็กต์ SOA น่าผิดหวังถึง 1 ใน 4

ผลสำรวจชี้โปรเจ็กต์ Service Oriented Architecture SOA น่าผิดหวังถึง 1 ใน 4

จากการสำรวจของ InformationWeek พบว่าการสร้าง SOA ยาก และใช้เวลากับเงินมากกว่าที่คาดการณ์ไว้ (อย่างน้อยก็ใช้เวลากับเงินมากกว่าที่ vendor ที่บอกเรา)

จากการสำรวจผู้เชี่ยวชาญด้านเทคโนโลยี และธุรกิจขององค์กร 273 องค์กร พบว่ามี 73% ที่อยู่ระหว่างการพัฒนาเว็บเซอร์วิส หรือ SOA โดย 24% หรือ 1 ใน 4 ของกลุ่มนี้บอกว่าโปรเจ็กต์ให้้ผลลัพธ์ต่ำกว่าที่คาดไว้ โดย 55% บอกว่าเกิดจากความซับซ้อนที่เพิ่มขึ้นอย่างมากในระบบ IT และ 41% บอกว่ามาจากต้นทุนมากกว่าที่คาดการณ์ไว้มาก
จาก 73% ข้างต้นมีเพียง 7% ที่บอกว่าผลลัพธ์ที่ได้ดีกว่าที่ตั้งเป้าไว้ ส่วนอีก 69% ที่เหลือยังไม่ได้ประเมินผลลัพธ์จาก SOA

อย่างไรก็ดี ยังไม่มีใครมาหยุดความร้อนแรงของ SOA ได้ บริษัท 2 ใน 3 เริ่มศึกษา SOA และ 45% บอกว่าโปรเจ็กต์ SOA สำคัญอย่างมากต่อเป้าหมายทางธุรกิจ โดย 55% หวังว่า SOA จะช่วยเพิ่มประสิทธิภาพในการติดต่อกับ business partner และ 40% หวังจะนำมาช่วยเพิ่มความเร็วในการออกผลิตภัณฑ์ของบริษัท

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

Review หนังสือ SOA ของ Thomas Erl

Review หนังสือ SOA ของ Thomas Erl

ช่วงนี้ผมมีความจำเป็นต้องศึกษาเรื่อง SOA อย่างลึกซึ้งครับ,
จึงได้ไปค้นหาดูว่าใน amazon มีเล่มไหนน่าสนใจบ้าง
เล่มแรกครับที่เจอ คือ
Service-Oriented Architecture: Concepts, Technology, and Design
ของ Thomas Erl เกือบ 800 หน้า

เนื้อหาหนักแน่น ครบถ้วน! ข้อดีที่สุดของเล่มนี้ที่ผมชอบก็คือการเขียนถึง SOA Life Cycle:

การวางแผน (Planning)
การวิเคราะห์ระบบ (Analysis)
เทคโนโลยีที่เกี่ยวข้องในการ implement (Technology)
และการออกแบบ (Design)
ซึ่งเล่มอื่น ๆ จะไม่ลงรายละเอียดถึงขนาดนี้

และที่สำคัญมีการนำ case study ที่เกิดขึ้นจริงมาแทรกอยู่ในทุก ๆ บทที่เกี่ยวข้อง แต่ถ้าใครคาดหวังว่าจะมีสอนการ coding ในเล่มนี้, ไม่มีครับ!
แต่จะอ้างถึงในส่วนเทคโนโลยีที่เกี่ยวข้องเท่านั้น เพื่อให้เข้าใจในแนวคิด

ผู้แต่งใช้เวลาถึงปีเศษ ๆ กว่าจะเขียนเล่มนี้จบ ตีพิมพ์ครั้งแรกเมื่อปี 2005, ในสมัยที่ผู้คนยังกล่าวถึง SOA ไม่มากอย่างทุกวันนี้ (เล่มที่ผมซื้อเป็นการพิมพ์ครั้งที่ 6) ผมจึงตัดสินใจเลือกซื้อเล่มนี้เป็นเล่มแรก, ได้ไปสืบหาดูมีขายที่ศูนย์หนังสือจุฬา ฯ และ IT Book House ราคาประมาณ 1,8XX บาท
วันก่อนผมแวะไปที่ห้องสมุดมารวยของตลาดหลักทรัพย์แห่งประเทศไทย ก็มีให้ยืมเล่มนี้เช่นกัน

เจาะแก่น SOA ตอนที่ 3 BPEL

เจาะแก่น Service Oriented Architecture SOA ตอนที่ 3 BPEL

จากบทความก่อนหน้า ผมบอกว่า web service (WS) ก็คล้าย method แต่ว่าถูกดึงออกมาอยู่ข้างนอกลอย ๆ
ที่นี้เราจะทำอย่างไร เพื่อเรียกใช้มันเพื่อสร้าง application หรือ business process ที่ประกอบด้วย web service หลาย อัน

ก่อนอื่นขอแบ่งประเภทของเว็บเซอร์วิสเป็น 2 ประเภท

1. Atomic web service - เว็บเซอร์วิสทำงานด้วยตัวเอง ไม่จำเป็นต้องพึ่งพาเว็บเซอร์วิส
2. Composite web service - เว็บเซอร์วิสที่ต้องเรียกใช้เว็บเซอร์วิสอื่น เพื่อสร้าง service ของตัวเอง

จากนั้นเราแบ่งจุดประสงค์ของการเรียกใช้ WS เป็น 2 แบบ

1. เรียกใช้ เพราะเราต้องใช้จริงๆ ผู้เรียกมักเป็นend user client เช่น ผู้ใช้ส่งข้อมูลไปยัง WS ของบริษัททัวร์ เพื่อซื้อ packageทัวร์
2. เรียกใช้ เพราะจะไปให้คนอื่นใช้ต่อ ก็คือ Composite WS นั่นละ ต้องเรียกใช้หลายๆ WS มาประกอบกันเพื่อสร้าง service ของตัวเอง
เช่น WS ของบริษัททัวร์ เรียกใช้ WS ของโรงแรมเพื่อจองห้อง, สายการบินเพื่อจองตั๋ว และธนาคารเพื่อตัดยอดเงิน

การเรียกใช้ web service มี 2 วิธีหลักๆ ได้แก่

1. ใช้ Web service client API เช่น WSIF, WSE เป็นต้น ก็คือเราเขียน application (ด้วยJava หรือ .NET) ของเราไปตามปกติ เมื่อถึงเวลาต้องเรียกใช้ WS ก็เรียกใช้ API แทน เหมือนกับการเขียนโปรแกรมปกติทั่วไป วิธีนี้เหมาะกับ end user client ที่เป็นผู้ใช้ปลายทางจริงๆ เพราะไม่ค่อยมีการเปลี่ยนแปลงบ่อย และมักเรียกเพียงไม่กี่ service อย่างไรก็ตามวิธีนี้ไม่เหมาะกับการสร้าง Composite WS เพราะเรามักใช้ Composite WS เพื่อสร้าง business process (business process คือ บริการที่เห็นหรือสัมผัสได้โดยตรงจากผู้ใช้หรือลูกค้า และให้ผลตอบแทนกับองค์กร นั่นก็คือservice นอกสุดที่ให้บริการลูกค้าโดยตรงนั่นเอง) ซึ่งมี business logic ซึ่งอาจเปลี่ยนแปลงบ่อยๆ นอกจากนี้ business goal ของการสร้างapplication ด้วย WS ก็เพื่อความคล่องตัว (agility) ปรับเปลี่ยนง่าย จะได้สอดคล้องกับสภาพธุรกิจปัจจุบันที่มีการแข่งขันสูง ดังนั้นการผูกแต่ละ WS ไว้ด้วยการ coding แบบเก่านั้น จึงไม่เหมาะกับการสร้าง business process ด้วย WS ตามหลักการของ SOA

2. ใช้ WS ตัวกลาง (mediator) มาเรียกใช้ sub-WS นั่นคือใช้ BPEL (Business Process Execution Language) นั่นเอง
การจะสร้าง business process หรือ composite WS จาก BPEL ต้องประกอบด้วย 2 ส่วน ได้แก่
2.1 BPEL file - BPEL เป็นภาษาที่ไว้ใช้กำหนด business process ซึ่งจริงๆ แล้ว เป็นภาษา xml
ลักษณะของ BPEL คือ เป็น procedural language คล้ายกับ flow chart ทำหน้าที่กำหนดว่าจะเรียก WS ไหน, เมื่อไหร่ และอาจเก็บตัวแปรด้วย การทำงานจะไปข้างหน้าเรื่อย ๆ จนจบไฟล์ (ลองนึกถึง file build.xml ของ Ant อาจเข้าใจ การทำงานคล้ายอย่างงั้นเลย)
2.2 BPEL engine คือ ตัวที่จะมาอ่าน BPEL ที่เราเขียน และ สร้าง composite WS ให้ทำงานตามที่กำหนดใน BPEL นั่นเอง (คล้าย Ant tool ที่อ่าน build.xml) client ที่เรียกใช้จะเห็น composite WS ที่สร้างขึ้นเป็นเหมือน WS ทั่วไป BPEL engine ปัจจุบันก็เช่นBPEL manager ของ oracle ซึ่ง vendor ส่วนใหญ่จะมี BPEL designer ติดมาด้วย เพื่อสร้างและแปลง flow chart เป็น bpel (อย่างที่บอกว่าbpel เป็นภาษาที่เหมือน flow chart อยู่แล้ว ไม่มีแยก function มี control flow แค่switch-case, loop และก็อย่างอื่นอีกนิดหน่อย สามารถดูตัวอย่างได้ที่ link อ้างอิง)

นอกจากนี้ BPEL ยังสนับสนุนการทำงานแบบ concurrent, asynchronous และ exception handling ด้วย อย่างไรก็ตาม BPEL ก็คือ procedural language ที่ไว้ใช้สร้าง Composite web service โดยการระบุการเรียกใช้ WS อื่นๆ เพื่อสนับสนุนแนวความคิดของ SOA นั่นเอง

เจาะแก่น SOA ตอนที่ 2 WebService กับ SOA

เจาะแก่น SOA ตอนที่ 2 WebService กับ Service Oriented Architecture SOA
จากภาคแรก ผมเกริ่นเกี่ยวกับ SOA เอาไว้ ในตอนที่ 2 นี้ผมจะเขียนความเกี่ยวข้องระหว่าง SOA กัน web services

ที่ SOA เป็นพูดถึงกันมากส่วนหนึ่งก็เพราะ web services นั่นเอง ความจริง SOA ไม่ใช่ของใหม่ ถ้าเราสังเกตลักษณะของ service จะมีส่วน implementation แยกกับ interface เสมอ เพื่อลด coupling ระหว่าง service กับผู้เรียก ซึ่งแนวคิดนี้มีใน J2EE (RMI), CORBA และ COM อยู่แล้ว นั่นคือเราสามารถใช้ RMI technology (ซึ่งเป็น distributed technology) ทำ SOA ได้

แต่ว่า จุดขายที่สำคัญของ web services คือ platform independent ผู้เรียกกับ service ไม่จำเป็นต้องเป็น platform เดียวกัน (java application เรียกใช้ .NET service) ซึ่งต่างจาก RMI ที่ต้องเป็น java หรือ CORBA ที่ต้องเป็น Java หรือ C++

ในปัจจุบันถ้า web services คือหัวใจของ SOA, XML ก็คือเส้นเลือดหล่อเลี้ยงหัวใจ เพราะ XML ทำให้ Web services เป็น platform independent technology ซึ่งช่วยให้สามารถ communicate ระหว่าง B2B หรือ new system กับ legacy system ที่เป็นต่างภาษา หรือ platform ได้

XML เป็น markup language มีลักษณะเป็น text ใครก็เปิดอ่านได้ และอ่านรู้รื่องได้ไม่ยาก ขอให้ผู้เรียกกับ service เข้าใจ xml ก็เป็น web services ได้แล้ว ซึ่ง technology ที่เกี่ยวกับ web services ส่วนใหญ่เกี่ยวข้องกับ XML ทั้งนั้น เช่น WSDL, SOAP, BPEL

SOA กับ web services จะเป็นเครื่องมือสำคัญในการพัฒนา enterprise application ในอนาคต ด้วยจุดเด่น คือ
1. loose coupling
2. ความคล่องตัว ปรับเปลี่ยนง่าย
3. high reusability
4. ที่สำคัญช่วยลด cost ในการ mainteinence

ตามหลักการแล้ว web service สามารถเรียกข้ามองค์กร (cross organization)ได้ แต่ว่า spec บางอย่างของ Web services ยังไม่นิ่ง เช่น security, trasaction, และ QoS ต่าง ๆ ดังนั้น การใช้ SOA ส่วนใหญ่จึงเป็นการเรียกใช้ web service ภายในองค์กรของตัวเองเท่านั้น
สิ่งที่ทำได้ตอนนี้ คือ เกาะติดความก้าวหน้าของ SOA และพิจารณาความเสี่ยงเมื่อนำ SOA มาใช้อย่างรอบคอบ เพราะ SOA ก็มีต้นทุนสูง, learning curve พอสมควร และที่สำคัญจะได้ไม่เป็นเหยื่อคำโฆษณาของเหล่า vendor นั่นเอง

เจาะแก่น SOA ตอนที่ 1 เริ่มต้น

เจาะแก่น Service Oriented Architecture SOA ตอนที่ 1 เริ่มต้น

วันนี้ขอเขียนเรื่องที่กำลังพูดถึงกันมากอยู่ขณะนี้ คือ เรื่อง SOA ครับ บทความนี้ผมจะแนะนำให้ทุกคนรู้จัก SOA ครับ SOA (Service Oriented Architecture) เป็นรูปแบบในการออกแบบระบบ (system) หรือ โปรแกรมประยุกต์ (application) แบบหนึ่ง อย่าง object oriented เวลาออกแบบระบบ เราจะมองเป็น object หรือ class แยกแยะระบบออกมาเป็น class และความสัมพันธ์ (relations) แต่ SOA จะมองระบบ ประกอบด้วยการทำงานหรือบริการ (service) ต่างๆ

แล้ว service คืออะไรล่ะ?
service ก็คล้าย function หรือ method นั่นแหละ คือมีหน้าที่ทำอะไรสักอย่าง ถึงเวลาเราก็เรียกใช้ แต่ service มีลักษณะ high level และเป็นมุมมองเชิงธุรกิจมากกว่า เช่น มองระบบธนาคารประกอบด้วยบริการถอน withdrawal service, บริการฝาก deposit service แทนที่จะมองเป็น class Customer หรือ class Teller ที่มี operation withdrawal หรือ deposit

สิ่งที่ service ทำได้ แต่ method ทั่วไปทำไม่ได้ คือ distributed system นั่นคือแต่ละ service สามารถถูกเรียกจากต่างระบบ, host หรือ JVM กันได้ แต่ละ service มีอิสระต่อกัน ไม่ได้กระจุกติดกันอยู่ใน application หรือ jar file หนึ่ง พูดง่าย ๆ service ก็คือ method ที่ถูกดึงมาไว้ข้างนอกนั่นเอง

ข้อดีของ service คือ loose coupling และสามารถใช้ร่วมกันได้ บางคนอาจเถียงว่า method ก็สามารถใช้ร่วมกันได้ แต่ service สามารถใช้ร่วมกันระดับ application ครับ เช่น ธนาคาร A มี Deposit service ธนาคาร B, C สามารถเขียน application มาเรียกใช้ Deposit service ของธนาคาร A ได้ นั่นคือเป็นการ reuse ระดับ high-level ขึ้นมาอีก

SOA ขับเคลื่อนองค์กรสู่บริการ เทรนด์ใหม่ที่ต้องปรับตัว

Service Oriented Architecture SOA ขับเคลื่อนองค์กรสู่บริการ เทรนด์ใหม่ที่ต้องปรับตัว

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

ทว่าระบบต่างๆที่กระจายอยู่ตามร้านให้บริการ และคอลเซ็นเตอร์นั้น ต้องพึ่งระบบไอทีจากส่วนกลางในการให้บริการ

ดังนั้น ระบบไอทีหลังบ้านจึงจำเป็นต้องสนับสนุนการทำงานที่ขยายเพิ่มขึ้น !!!

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

SOA กระทบโครงสร้างไอทีขององค์กร

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

คำแรก Service-Oriented เป็น Software ที่ไม่ใช่ซอฟต์แวร์ แพ็คเกจ แต่เป็นซอฟต์แวร์ตัวเล็ก ทำงานเฉพาะด้าน ขึ้นอยู่กับว่าจะแบ่งเป็นบริการอะไรบ้าง

คำที่สอง Architecture คือการออกแบบ โดยจะมององค์กรโดยรวมว่าต้องการบริการอะไรบ้าง ก็จะแบ่งบริการนั้นๆออกเป็นส่วนย่อยๆ

ทั้งนี้ หลายคนมองว่า SOA คือ web service แต่จริงๆแล้วไม่ใช่เพราะ web service เป็นแค่เครื่องมือในการใช้งาน

ดังนั้น SOA จึงไม่ใช่สินค้า หาซื้อไม่ได้ แต่มันคือแนวคิดที่ต้องสร้างเองในองค์กร

สำหรับสินค้าที่เกี่ยวข้องกับ SOA ประกอบด้วย 4 ส่วนคือ 1. Enterprise Service Bus เป็นโครงข่ายสำคัญในการขับเคลื่อน SOA ทั้งหมด เป็นการเชื่อมต่อระหว่างแอพพลิเคชัน

2.Design-Time Governance เป็น ดาต้า เบส กลางช่วยรวบรวมว่าองค์กรมีบริการอะไรบ้าง และช่วยนำบริการออกไปยังหน่วยงานและควบคุมบริการให้เหมาะสมกับองค์กรด้วย

3.Run-Time management เป็นตัวจัดการ ทำอย่างไรให้บริการทำงานสอดคล้องกับ SOA ที่ตั้งไว้ และ 4.Security Gateway ในที่นี้ไม่ได้หมายถึง Firewall ที่เป็นเน็ตเวิร์ก แต่เป็น Application Firewall ที่เข้าใจ คำสั่ง XML นอกจากนี้ต้องมี Application Delivery Control ช่วยเร่งความเร็วในการทำงานของ SOA ด้วย

เมื่อนำแนวคิด SOA เข้ามาใช้ แอพพลิเคชันแบบเก่าต้องถูกรื้อใหม่

จากแนวคิดเรื่อง SOA ทำให้เกิดการทำ Software as a service (SaaS) และ web 2.0 ขึ้น

SaaS คือ แอพพลิเคชัน แต่ไม่ใช่ แอพพลิเคชันตัวใหญ่ มีหน้าทีทำงานเฉพาะด้านในด้านหนึ่ง โดยการใช้งานของผู้ใช้ ไม่จำเป็นต้องเป็นเจ้าของแอพพลิเคชัน สามารถขอเช่าใช้งาน โดยมี Vender หรือหน่วยงานที่เกี่ยวข้องเป็นผู้ดูแลรักษา

การ์ทเนอร์ คาดการณ์ในปี 2010 ซอฟต์แวร์ทุกอย่างจะเป็น SaaS ในสัดส่วน 25%

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

ตัวอย่างของสิ่งที่เกิดขึ้นจากแนวคิด web 2.0 ที่เห็นในตลาด ได้แก่ Blog ที่เจ้าของและสมาชิกเข้ามาแลกเปลี่ยนข้อมูลกันได้ ทำนองเดียวกับ Wikipedia หรือ Google Adsearch ที่ผู้ใช้สามารถเข้าไปควบคุมการทำงานว่าต้องการได้รับบริการรูปแบบใด




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

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

นอกจากนี้ เนื่องจาก SOA ใช้ web service เป็นเครื่องมือ ที่วิ่งอยู่บน Protocal XML ดังนั้นจึงเป็นมิตรกับมนุษย์ นั่นหมายถึงคนสามารถเข้าไปอ่านข้อมูลได้เพียงรู้ ชื่อผู้ใช้งาน ไม่เหมือนภาษาคอมพิวเตอร์แบบสมัยก่อน

ดังนั้นแต่ละช่องของซอฟต์แวร์ที่คุยกันจึงมีช่องว่างด้านความปลอดภัย ถูกโจมตีง่าย !!!

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

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

องค์กรใช้ไอทีในการขับเคลื่อนธุรกิจ ไม่ควรพลาดในการนำแนวคิด SOA ไปใช้ในองค์กร!!!

Microsoft Highlights “Real-World” Approach to SOA at SOA & Business Process Conference

Microsoft Highlights “Real-World” Approach to SOA at SOA & Business Process Conference

Microsoft showcases customer successes, guidance and road map for an incremental approach to service-oriented architecture based on over half a decade of customer engagements.

At the Microsoft SOA & Business Process Conference, Microsoft Corp. today highlighted customers that have successfully deployed service-oriented architecture (SOA) solutions by taking a “real-world” approach, and announced updated guidance and upcoming advances in its interoperability and technology road map to extend its commitment to “real-world” SOA solutions.

Today’s conference highlights some of the world’s largest and most successful service-oriented architecture SOA deployments, including those at Commonwealth Bank of Australia, Dell Inc., CitiGroup and Sandvik. In addition, customers such as Clear Channel Communications Inc., HP and Jet Blue Airways joined more than 700 participating customers and industry partners to share best practices on achieving success with service-oriented architecture SOA by adopting an approach that focuses on the business problem at hand and strong architecture at the solution level. This “real-world” approach departs from the industry norm of applying a high-risk, heavy, “top-down” strategy to SOA implementations that starts with major enterprisewide infrastructure investments that often fail to show results in a relevant timeframe or offer a compelling return on investment. Instead, the “real-world” approach to SOA advocated by Microsoft and practiced in successful customer service-oriented architecture SOA deployments relies on achieving rapid success around a focused business problem, which can result in broader SOA implementations.

Recent independent surveys of CIOs from Goldman Sachs & Co.* and Merrill Lynch & Co.** show Microsoft leading in mindshare and customer preference with its approach to SOA service-oriented architecture. Goldman Sach’s IT spending survey placed Microsoft in a clear leadership position as the vendor of choice in assisting the “move to SOA/Web services.” Separately, Merrill Lynch’s recent survey of CIOs ranked Microsoft the “most important provider of Web services/SOA software (applications and infrastructure).”

“Real-World” SOA service-oriented architecture

Microsoft’s “real-world” approach to SOA was initiated more than seven years ago with the introduction of the .NET platform that continues to set the industry bar as the first native Web services-based platform built from the ground up. Further, the platform goes beyond service orientation to address capabilities such as federated data, identity and access, and integrated user experience across diverse applications, with guidance available on the MSDN® Architecture Center (http://msdn.microsoft.com/architecture). Coupled with a strong focus on interoperability through work with partners and standards bodies (such as the Web Services Interoperability Organization), Microsoft has additionally worked hard to support service-oriented approaches in heterogeneous environments.

“Microsoft understands that building enterprise architectures for technology’s sake doesn’t benefit customers with a need to solve business challenges with technology,” said Ron Schmelzer, senior analyst at ZapThink LLC. “SOA service-oriented architecture isn’t about finding a single infrastructure product that addresses all of your technology challenges, but instead about using architectural guidelines and practices to enable the creation and ongoing management of a new breed of agile applications. Microsoft and its customers are demonstrating great progress in this area and sharing their learnings at this week’s SOA & Business Process conference.”

Siemens AG is one example of a customer that has realized significant results from this approach to service-oriented architecture SOA implementation. During the past two years, the company has implemented a mission-critical infrastructure for SOA and business process management that enables its IT operational processes to support 400,000 employees worldwide. This has increased Siemens’ business productivity and reduced its deployment time of new processes by 83 percent.

“Contrary to industry hype around the need for large-scale architectures, Siemens AG is finding extreme value in a more incremental approach to service-oriented architecture SOA as advocated by Microsoft,” said Thomas Buse, section manager in Siemens ITO, Concepts and Processes at Siemens AG. “Through our Microsoft SOA implementation, we will implement over 400 new business processes with a frequency of four to eight new processes every six to 12 weeks, which allows us the agility to solve business problems and seize opportunities as we identify them.”

Upcoming Advancements

Microsoft today highlighted a road map of current and ongoing investments. This included new guidance on how to deliver Enterprise Service Bus (ESB) functionality to simplify and accelerate the development of service-oriented architectures. In addition, customers will be able to take advantage of IBM midrange and mainframe integration solutions via BizTalk Adapter for Host Systems, which will be shipped this calendar year in BizTalk® Server Enterprise and Standard editions, designed to help customers connect applications, data sources, messaging and security systems between IBM mainframe and mid-range systems and Microsoft® Windows® environments.

Microsoft also underscored upcoming advancements with Microsoft’s Office Business Application strategy, made possible by new platform capabilities in the 2007 Microsoft Office system. This further enables customers to realize the “real-world” value from their service-oriented architecture SOA implementations by enabling information workers to use the familiar Microsoft Office and SharePoint® Server environments for accessing services and interacting with business applications.

“Unlike enterprise infrastructure-centric approaches, Microsoft’s core technologies for ‘real-world’ SOA, including the .NET Framework 3.0, 2007 Microsoft Office System and BizTalk Server 2006, are poised to unlock ‘real-world’ value from existing assets in the enterprise, by bridging the world of structured and unstructured process,” said John deVadoss, director of Architecture Strategy at Microsoft. “Over the past half a decade we’ve seen that the biggest and most successful service-oriented architecture SOA deployments are by customers that have started small and have iteratively built broader success. Given the industry dialogue around large-scale SOA implementations not delivering the promised return, the goal of today’s conference is to share real-world customer references and the lessons learned with this approach to rapid time-to-value.”

Founded in 1975, Microsoft (Nasdaq “MSFT”) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at http://www.microsoft.com/presspass on Microsoft’s corporate information pages. Web links, telephone numbers and titles were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may contact Microsoft’s Rapid Response Team or other appropriate contacts listed at http://www.microsoft.com/presspass/contactpr.mspx.

Microsoft Advocates Real-World Approach to SOA for Increased Business Value

Microsoft Advocates Real-World Approach to SOA for Increased Business Value

Q&A: How businesses can incrementally leverage Service Oriented Architectures (SOA) and Web services to address business challenges

Service orientation is a means for building distributed systems. At its most abstract level, service orientation views everything – from the mainframe application to the printer to the shipping-dock clerk to the overnight delivery company—as a service provider. Service providers expose capabilities through interfaces, and service-oriented architecture maps these capabilities and interfaces so they can be orchestrated into processes. The service model is "fractal": the newly formed process is a service itself, exposing a new, aggregated capability.

While there are different perspectives on Service Oriented Architectures (SOA), there is widespread agreement that it is not a product or a technology but an approach, a style of architecture that uses the service model to enable integration across diverse systems, encapsulating the idiosyncrasies of diverse and often proprietary platforms, technologies and protocols.

Microsoft this week hosted its annual Service Oriented Architectures SOA and Business Processes Conference in Redmond, where customers and industry partners met to discuss a "real-world" approach to SOA Service Oriented Architectures, and how it can be used to solve troubling business challenges. PressPass spoke with John deVadoss, director of Architecture Strategy at Microsoft, about the company’s SOA-related work and how its support of Web services has helped make Service Orientation mainstream. DeVadoss’ team is responsible for Microsoft’s Architecture Strategy and helping customers, and partners create business value from their technology investments

PressPass: Why should a business person or an IT professional care about SOA, and do they share the same view of Service Oriented Architectures SOA’s importance and its role in business?

DeVadoss: The first and probably the most important thing to note is that Service Oriented Architectures are a means to an end. At its most strategic level, Service Oriented Architectures SOA enables IT to meet the changing demands of businesses and to exploit new business opportunities. To developers and architects, service orientation is a means for creating loosely-coupled, distributed systems and applications. To the IT manager, service orientation is a means for effectively integrating the diverse systems typical of modern enterprise data centers. By providing a model for aggregating the information and business logic of multiple systems, service orientation allows diverse and redundant systems to be addressed through a common, coherent set of interfaces. To the CIO, service orientation is a means for protecting existing IT investments without inhibiting the deployment of new capabilities. By encapsulating a business application behind capability-based interfaces, the model allows controlled access to mission-critical applications, and creates the opportunity for continuous improvement of the implementation behind that interface. But keep in mind that the end goal is create value for the business.

PressPass: What is unique about Microsoft’s approach to Service Oriented Architectures SOA, and why does Microsoft recommend a different approach from what is currently the industry norm?

DeVadoss: There is really no such thing as an industry norm – especially for the loosely defined architecture style that is Service Oriented Architectures SOA.

There is, however, a preponderance of what I call the top-down, big-bang mega approach – which is often guilty of trying to "do SOA" as opposed to delivering business value. The fundamental problem with the big-bang mega approaches to SOA is that they almost always end up being out-of-sync with the needs of the business. This approach has been a key factor in fueling industry discussions around the lack of alignment between business and IT on the topic of SOA Service Oriented Architectures.

Microsoft advocates a real-world approach to SOA – one that exploits rapid iterations of design, implementation and re-evaluation – resulting in solutions that are more closely aligned with changing business conditions.

The real-world approach to Service Oriented Architectures SOA also emphasizes time-to-value. In the business world, time-to-value is a critical value measurement, even more important than return on investment (ROI). ROI is a long-term goal. Any project, regardless of how poorly organized, how over-budget, and how miserably aligned with the business requirements can claim a good ROI, as long as the project costs are amortized over a long-enough period of time. The question is, can the business survive long enough to realize the return? With our real-world approach to SOA, time-to-value is much more immediate.

There are a number of things that set Microsoft apart from many others in the industry. We were an industry leader with respect to creating and evangelizing the Web services model, in creating and driving industry-wide adoption of the standards that make Service Oriented Architectures SOA real. I would argue that our broad platform and tool support has truly made Service Orientation mainstream.

Today, however, I want to highlight one area that is critical to the business – where we are the undisputed leader – and that is in empowering people to bridge the world of structured and unstructured processes. The question is often asked: what do you get after you have an SOA? The reality is that the rubber meets the road when you have consumption of the services – with our innovations in Microsoft Office SharePoint Server 2007, .NET Framework 3.0 and BizTalk Server we are poised to empower the masses to bridge the transactional and the collaborative capabilities, empowering people to drive business success.

PressPass: It sounds like there are a lot of things to consider. What is Microsoft’s guidance to customers on how to implement a Service Oriented Architectures SOA strategy?

DeVadoss: It is quite simple really. We think of this as the Expose/Compose/Consume model.

First, you need to service-enable your existing assets. Service Oriented Architectures SOA is not about rip and replace, it is about leveraging your existing assets.

Second, it is about composing these services – people call this orchestration or choreography, and sometimes workflow – but the key idea is that you have the infrastructure to empower your people, employees, customers and consumers, to use the services in the real-world.

At this point you have an Service Oriented Architectures SOA – but it is still infrastructure, it is still plumbing. The rubber meets the road when you enable consumption of the services, and so you have what we think of the consume layer.

There are cross-cutting concerns such as security, management and governance – but that is pretty much all you have in the real-world Service Oriented Architectures SOA implementations.

With respect to how you start –

1. Make sure that you have sound business drivers. Oftentimes we see customers struggle to justify their SOA projects – it is almost always because they are trying to "do SOA" as opposed to addressing a business need.

2. Top-down, big-bang mega approaches do not work in the real-world. Bottom-up approaches are not manageable. But there is an approach that we see successful customers adopt – what we call the middle-out approach. These customers all have something in common--they start with clear business challenges and focus on creating business value

3. Try to avoid subscribing to what I call "the build it and they will come" approach. They spend 18 months to 30 months building a services infrastructure, and eventually, when they reach the service consumption layer or what is called the user-experience layer, they find that the business has moved on. That what they have built is something that made sense for the business at a point in time in the past, but by the time their solution was ready for prime-time, their business needs had changed and their investments were all for none. We recommend customers partition their use cases into small sets and build out the entire use case end-to-end, from the data through to the consumption. You don’t learn by planning – you learn by doing. Partitioning your functionality helps you track changing business needs much more effectively.

4. Demonstrate value in rapid iterations. Time-to-value is a critical metric, a healthy metric. The trust-me approach is not a healthy model for customers that want to be successful leveraging SOA.

5. Last, but not the least, successful customers use what we call a "snowball" approach. How do you build a big snowball? You start with a small snowball. This is probably the most important take away with respect to leveraging SOA to drive business value.

PressPass: How long has Microsoft been involved in the SOA space?

DeVadoss: It was September 1999 when Microsoft first announced the Web services model and kicked off a wave of innovation that has fundamentally changed the application architecture landscape. Beginning with version 1.0 of the .NET Framework, our investments in tools together with the intrinsic support for Web services in our platform have helped make Service Orientation mainstream.

Microsoft recognized that the economics of Web services had the potential to make Service Orientation practical and working with other vendors such as IBM and BEA, we invested in authoring a set of specifications referred to collectively as the WS-* architecture.

Shortly thereafter, in order to promote interoperability across platforms, operating systems and programming languages Microsoft worked with IBM to develop the Web services Interoperability Organization (WS-I). Since it was created, WS-I has grown to roughly 150 member companies and has created Web services that address areas such as interoperability, security and the reliability of messaging.

PressPass: How have customers been responding to this real-world approach to SOA?

DeVadoss: To be honest, it was our customers that helped us refine this model and get it to where it is today. Across the board, successful customers are those that leverage a real-world approach to SOA. Customers and partners realize that big-science projects don’t create value for the business. The "build it and they will come" approach to SOA has failed the business – customers and partners understand that you don’t learn by planning for months and often years, but rather that you learn by doing.

We are proving that it is the incremental, iterative, real-world approach that helps you correct your course and deliver value to the business in a meaningful way.

Microsoft: The SOA road less traveled

Microsoft: The SOA road less traveled by Rich Seeley

When talking to analysts who cover service-oriented architecture and are studying Microsoft's approach to service oriented architecture SOA, a one word description emerges: "different."

Microsoft is operating in a different service oriented architecture SOA world from other major software vendors, such as IBM, BEA Systems Inc. and the newly conglomerated webMethods/Software AG, analysts say.

"They've always been kind of a different company, and they're staying true to that," said Bradley F. Shimmin, principal analyst of application infrastructure for Current Analysis, who recently met with Microsoft to discuss their approach to SOA service oriented architecture.

"Microsoft tends to market things very differently," said Ron Schmelzer, senior analyst with ZapThink LLC., who is researching Microsoft's approach to service oriented architecture SOA. "They never have things that are in the same product categories as everybody else. They've been very resistant to any sort of Gartner three-letter acronym. You should give them a hand for doing that."

As an example, Shimmin said, "They are enabling service oriented architecture SOA but they don't have an service oriented architecture SOA suite." But while avoiding some standard SOA product categories, analysts find Microsoft moving forward in the service oriented architecture SOA space, although pretty much within their own .NET world with BizTalk server sometimes serving as a hub of sorts.

The analysts point out that Microsoft doesn't have an ESB but offers ESB guidelines and capabilities. Microsoft doesn't support the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications, which offer similar functionality to .NET. Microsoft is not offering Business Process Management (BPM), which is this year's hot topic in SOA, although it is aggressively pursuing workflow technology. , Shimmin said Microsoft has 10 partners that focus on BPM. He is also bemused that Microsoft recently announced .NET support for Business Process Execution Language (BPEL) 1.1 while most SOA vendors are already supporting the newly adopted BPEL 2.0. He said he was told BPEL 2.0 is on the roadmap for later in the year.

"It's another example of how they work within their own universe," he said.

Schmelzer doesn't like portraying Microsoft as if it were in an alternative matrix with .NET as compared with the players in the Java world such as IBM. He said criticism that everything Microsoft does related to SOA is .NET centric, misses the point, or just reflects a Java-bias.

"If you went to IBM and said you want WebSphere but they have to deploy it on the .NET platform," Schmelzer said. "The answer is no. WebSphere is a Java thing. IBM is just as much Java centric in their approach as Microsoft is .NET centric in their approach."

What Microsoft is doing within their .NET world makes sense for their customers and developers, the two analysts agreed.

For example, even though BizTalk is not being marketed as an enterprise service bus, the analysts found mature functionality for supporting SOA in the venerable product.

"They're selling boatloads of BizTalk," noted Jason Bloomberg, senior analyst with ZapThink, "and many of those customers are leveraging it in service oriented architecture SOA initiatives, for example." Anne Thomas Manes, research director at the Burton Group Inc., cited BizTalk as the number one offering in Microsoft's SOA efforts.

In what may be a matter of having an ESB by another name, Shimmin said, "BizTalk is going to remain their integration server. That's really what it's good at. But, as you know, an integration server that handles brokering and messaging and transformation, which is what BizTalk does, is a key facet of an ESB. It's kind of splitting hairs. It's just another example of how Microsoft operates in its own continuum."

BizTalk pre-dates the service oriented architecture SOA marketing hype, but has matured to fit into the service-oriented approach, Schmelzer said. "BizTalk was originally a business-to-business document exchange platform when it first came out," he explained. "It's evolved quite a bit. You could think of it as integration middleware or as a composite service delivery platform. It basically serves the role that you would use a WebSphere Business Integrator for, or maybe the functionality that webMethods and Software AG are providing."

Schmelzer said Windows Communication Foundation (WCF) is the other key to providing functionality also known as ESB.

"Microsoft would certainly position BizTalk as providing some of the capabilities that people may be looking for in ESBs," he said, "although they'd also include the rest of the WCF framework. Microsoft sees the ESB not as a product but as a pattern. You can achieve all the things you want to achieve in an ESB from the Microsoft family of solutions."

Beyond BizTalk and WCF, Schmelzer noted that Microsoft's Connected Services Framework and the Well-Enabled Service are two other pieces of its service oriented architecture SOA puzzle. "The Connected Services Framework is really a collection of service products and technologies, and the Well-Enabled Service is basically their positioning on what a SOA platform should provide for services. It covers security, reliability, management, governance and other technologies. The Connected Services Framework, the Well-Enabled Service, and the products provided with BizTalk and Windows Communications Foundation as well as Windows Workflow Foundation, and Windows Presentation Foundation, that's the basis of their enterprise SOA service oriented architecture assets."

Shimmin said workflow is one of the strengths of the Microsoft approach to service oriented architecture SOA.

"If there's one thing about them that I feel they get," he said, "it's that processes are human based. They all start and end with people. I think that's reflected in their overall approach to SOA."

Microsoft's desktop dominance in the small-to-medium business (SMB) market makes it's approach to SOA appealing to companies outside the Fortune 1000 that may not be able to afford a major vendor's suite, and lack the IT skills to assemble free open source software into an SOA, Shimmin said.

"Microsoft's not ever going to be like BEA, Tibco, or webMethods/Software AG, trying to create an entire suite, everything from the tooling up to BAM/BPM with governance on top of that, and be everything for building a service oriented architecture SOA-based infrastructure," he said. "What they realize is they have a really strong presence on the desktop and through the desktop presence they're intimately tied into a lot of business processes that go on inside companies they do business with – the SMB market in particular. With that realization, they actually are on to something with that in terms of 'people-ready,' process friendly SOA."

Schmelzer also sees Microsoft's SOA service oriented architecture play being mainly for the companies that already rely on Microsoft for their business software.

He said, "Microsoft's counterweight to companies that would be looking at an IBM or BEA solution is obviously centered around the BizTalk product line and the Windows Communications Foundation (WCF) and all the products and technologies enabled by that, plus all the assets they bring to the development table around Visual Studio and all the things that would facilitate the creation of enterprise services."

"Microsoft has an ecosystem and they have a value proposition that's very solid for that ecosystem," Schmelzer said. "What Microsoft has for what it's doing is very good. It is what it is."

Q&A: Microsoft and Service-Oriented Technology

Q&A: Microsoft and Service-Oriented Technology

Steve Martin, director of product management for the Connected Systems Division at Microsoft, talks about shaping his company's SOA service oriented architecture strategy.

August 2007 • by Ed Scannell and Chris Kanaracus

If you ask Steve Martin, director of product management for Microsoft's Connected Systems Division, how he likes his job, he'll tell you with little hesitancy he has one of the best gigs at Microsoft.

It may also prove to be one of the most important strategically. The team Martin oversees is smack dab in the middle of many of the technologies Microsoft hopes to build its service-oriented initiatives around.

Martin sat down with Redmond Editor Ed Scannell and Chris Kanaracus, news editor of Redmond Developer News, to talk about a range of topics, including Microsoft's under-the-radar approach to the Service-Oriented Architecture (SOA) market, what he believes is the next major evolution in service-oriented technology and why Microsoft will be on the leading edge of it.

Over the past few years Microsoft has appeared reluctant to talk much about Service-Oriented Architecture, or even to use the phrase. What should people read into this?

The only thing they should read into this is that we're trying to remain above the hype. But increasingly over the last several years we're giving prescriptive guidance on not just the "how to do service orientation," but about observing the kinds of applications people are developing, including composite or service oriented architecture SOA apps. We ask them: Are those apps core business practices, things that help differentiate their organizations? Or are you really using service oriented architecture SOA just to wrap legacy investments and expose them in a service-oriented way to do essentially a new generation of EAI [Enterprise Application Integration]? Either is fine, but we think most organizations in the last several years have focused on using a service-oriented approach to solve intra-organizational connectivity issues. There's plenty of value there. But the next frontier for service orientation is the cross-section of service oriented architecture SOA and BPM [Business Process Management].

Why do you think this intersection represents the next major evolution for developers?

From our perspective, SOA is a "how." It's a way to accomplish something, and BPM is a "what." service oriented architecture SOA isn't very interesting by itself if it's just being a new version of EAI. It could be better, faster, cheaper -- and there's great economy in that. But with service orientation you have access to applications in a high-fidelity way, and that's the BPM side of things. The types of apps we see users building now that sit on top of SOA service oriented architecture are things that truly differentiate the business and aren't things they can buy off the shelf. They are their organization's secret sauce.

What makes Microsoft's service-oriented strategy different from your major competitors, such as IBM Corp. and Oracle Corp.?

A couple of things. As I said, we've always talked about SOA as a how, not a what. So the first guidance we give users is that service oriented architecture SOA for SOA's sake is probably doomed. You need to be able to articulate in 30 seconds the business problem you're trying to solve. If you can't do that, then you're already in a hole. You must be very pragmatic about what you're going to do and how you're going to use SOA to solve a particular problem. Within that pragmatism we coach people to take a "middle-out approach." Don't assume everything that goes into your organization must be services-oriented. Make good use of service orientation where it makes sense for either cost savings through reuse or in places where you're truly going to differentiate the business.

What are Microsoft's basic building blocks for service oriented architecture SOA -- now and in the future -- for building a comprehensive end-to-end solution?

That's hard to answer, although I can answer from an architectural standpoint. We think about the tools that create the services themselves, we think about having a robust runtime to make sure you're getting solid performance, and we think about the adherence to the Web specifications to ensure interoperability. But we also think about how we can help users solve a lot of the management and governance issues with tools like System Center. I don't know if we've been as clear with users about how to tie this into the other pieces of their infrastructure as we could have been. But we're giving that guidance now.

How open will your service oriented architecture SOA strategy be? Some developers and users have reservations given the range of new and old technologies they'll have to mix and match.

We've fully embraced the Web services specifications and the standards associated with that. In addition, we're starting to offer more guidance on how to use Windows Communication Foundation for building applications. Not just the WS-* stuff, but offering prescriptive guidance on some of the standards being adopted on the lighter-weight side.

Can you talk about how you'll evolve BizTalk Services and what role they can play?

We'll continue to incubate BizTalk Services. It's absolutely our intent to ensure that BizTalk Services is, at the right moment in time, a commercial offering people can take advantage of. We think we've built the world's first ISB [Internet services bus]: taking the functionality you get in an ESB [enterprise service bus] but making it work at Internet scope. One of our axioms is: Any time in history where the Internet has met the enterprise, the Internet always wins. Always. An ESB working at Internet scope means firewall-friendly messaging, building an app with the assumption that that app lives in multiple DNSes, assuming that identity could be inside or outside the firewall-then we can drive a lot of benefit for users and that's what we're doing with BizTalk Services. We think it's one of the best-kept secrets in the service oriented architecture SOA world.

Some users have a concern that Microsoft's SOA service oriented architecture strategy will be too tied to licensing of its core products, forcing them to buy bread-and-butter products in order to implement a complete SOA.

I've heard from users talking about a similar point. If you took our stack that you need to build a complex SOA with full management, customers quickly find that we're not only the most productive but also the most cost effective. You can compare our numbers for the technologies, and we'd advocate in building that complex service oriented architecture SOA app against IBM or Oracle or anyone else. Our middleware offering -- even for complex scenarios in BizTalk Server -- on average sells for about one-seventh the cost of our competitors' offerings.

What's the best story you have here for CxO-level people in terms of ROI over the short term for SOA service oriented architecture?

Well, one thing is the focus on core processes and using service orientation to build highly agile composite apps -- the things that can differentiate the business and require a great deal of customization and ongoing care and management. That's one area that's critical for CIOs to really understand.

Some people think Microsoft is weak on the governance portion of SOA.

We're working hard to understand what the user requirements are. I think there's a lot to do today with the technology that we have. We've done a lot of work with partners on it. A lot of what you hear when you pick apart that governance onion is people wanting prescriptive guidance on how to do something, and we're working with partners on that.

The version of BizTalk coming out after the R2 version will be built from the ground up on Windows Workflow Foundation. How do you see that improving Microsoft's SOA strategy?

We made a big bet on .NET with BizTalk Server 2004, when we began to leverage Visual Studio as the native design environment. Now that .NET Framework 3.0 has shipped and has some good technology in it for workflow and for messaging, we feel the technology is very compelling and is something we want to utilize in future versions of the product. But right now we're focused on getting R2 shipped and making sure that's the highest-quality release.

Ed Scannell is the editor of Redmond magazine. Chris Kanaracus is the news editor of Redmond Developer News magazine. You can contact Ed Scannell about "Q&A: Microsoft and Service-Oriented Technology" at editor@redmondmag.com.

Microsoft Does Have a SOA Strategy

Microsoft Does Have a SOA Strategy

Redmond was conspicuously absent as the SOA Service-Oriented Architecture hype exploded -- turns out it had a plan after all.

August 2007 • by Ed Scannell and Chris Kanaracus

Microsoft has never been inclined to play by the rules. For the past 32 years, the company has maintained the cocky pose of its legendary founder, Bill Gates, aggressively challenging entrenched technology standards -- even some its own customer base wants to see flourish side by side with Windows.

Microsoft's ruthless campaign against open source software and, with somewhat less vengeance, its reluctance to join the Software as a Service (SaaS) movement are the latest examples. Only after years of bloody public jousting did Microsoft finally seek ways to peacefully coexist with the open source world through deals like the one signed with Novell Inc. last November. And it did acknowledge the market presence of SaaS when it introduced the Live versions of Windows and Office, both of which are still incubating.

SOA Takes the Stage
Enter Service-Oriented Architecture (SOA), which for several years has been developing into a transformative force in enterprise IT. SOA, as a concept, has been embraced by Microsoft's usual cadre of competitors, most notably IBM Corp. and Oracle Corp. It has made its way onto the radar screens of the more forward-thinking IT shops, and established standards groups are shaping the rules by which to play.

But true to character, Microsoft again appears to be crafting its own rules and vision. The company has so far declined to participate in certain key emerging industry standards relevant to SOA. It has a different perspective on what SOA is and a different approach for crystallizing its vision. Microsoft has even shown a certain reluctance toward using the term itself, choosing instead to talk about its "services-oriented" or "service-enabled" approach.

The more vocal critics claim Microsoft's approach to SOA not only goes against the technical grain of competitors, but may also not be in the best interests of customers. They believe the company's approach is too tied to pushing sales of its core desktop and server products, which are more expensive, complex and proprietary than alternative offerings.

"Microsoft is primarily concerned with its [own] business strategy. It wants to continue to produce these fantastic profits but that runs counter to what many IT shops are focused on, which is cost-reduction, simplification, consolidation and modernization," says Dana Gardner, principal analyst with Interarbor Solutions LLC in Gilford, N.H.

Gardner and other industry observers charge that Microsoft's business model too strictly requires users to buy into its bread-and-butter operating systems, applications, run-time environment and tools before they can start piecing together a customized SOA that best serves their needs.

But top Microsoft executives disagree with such assessments. They say all the basic building blocks of the company's services-oriented plan can be mixed and matched with a wide range of competing technologies, that the resulting SOA-enabled applications will offer the agility needed to flourish in the fast-paced Web 2.0 world, and that they can do so cost effectively compared to competitors.

"It was clear that if the services-oriented world was to coexist with the real world, we needed to move data efficiently around the organization in a way that was transport-agnostic. This is why we invested in Windows Communications Foundation [WCF]," says Steve Martin, director of product management for Microsoft's Connected Systems Division. WCF is Microsoft's Web services stack shipped as part of the .NET Framework 3.0.

Besides the ability to move data around easily, Microsoft is placing an emphasis on the agility of the SOA-enabled applications. The reason, according to Martin, is that most custom applications live between six and 15 years in an organization, while service-oriented applications live three to six months.

"This is what you're investing in when you take a services-oriented approach -- the ability to rapidly evolve an application because you need to change things in near-real time," Martin says.

'Good, Better and Best'
Microsoft is not selling a big, fat SOA stack, Martin argues. Instead, the company is taking its "traditional" technical approach to the SOA market -- one that is focused on empowering individuals, he says.

IT shops can simply use WCF to service-enable their existing systems, he says. Or they could go further and use Microsoft's best selling Visual Studio suite of tools to build new services. A third and optional step, he says, would be for users to then combine these assets with BizTalk Server, which allows them to wrap legacy technologies with the new class of services. Giving users and developers these options to start small and flexibly build capabilities as their business requires them is Microsoft's "good, better and best" approach to the SOA market.

"People should be able to fly at the altitude that is most appropriate for them," Martin says.

Another central technical element to Microsoft's services-oriented strategy is virtualization. David Greschler, director of virtualization strategy at Microsoft, says virtualizing applications may be the best way to SOA-enable many of Microsoft's best-selling applications.

"It's important in an SOA-enabled world that we think about how to move these applications into that world," he told Redmond in an interview after his keynote address at the SOAWorld 2007 show in late June. "One way to do that is to virtualize them. By tying those apps to policies, by en-abling them to be delivered in real time to whatever device needs them, we've taken the same characteristics that one would see with a Web app and made most any Windows app Web-enabled. It can be part of an SOA-like strategy."

But for all of Martin's talk about the company's ability to provide SOA a la carte, Microsoft is also taking some stabs at a market IBM and others have long ruled: the world of high-performance back-end megasystems that power verticals like the financial services industry.

In June, the company released .NET StockTrader, a trading application based on ASP.NET and WCF. Microsoft highlighted its ability to interoperate with IBM's WebSphere Trade 6.1 sample app and released benchmarking results that showed significant performance improvements over Trade 6.1.

Forrester Research Inc. analyst John Rymer says it's clear that Microsoft wants to show that it's a viable alternative to products such as WebSphere -- and not a supporting player. "Obviously, they're trying to sell it. The problem is IBM is seen as enterprise and they're not," he says.

Rymer says the .NET StockTrader benchmark tests were well-documented, but like any benchmarking, the results should not be swallowed whole. That said, Microsoft is now well-positioned to become a stronger player in enterprise systems, according to Rymer.

Microsoft is backing up its technical investments in this market by bringing on high-powered talent, and from its archrival no less. Earlier this year, it scooped up former IBM Fellow and Chief Architect Donald Ferguson, who's generally credited with turning WebSphere into the success it is today. While his role at Microsoft has not been made clear by the company, Ferguson -- someone long-steeped in the SOA tea -- figures to have a hand in shaping the company's services-oriented strategies in a way that could exploit any potential IBM weakness.

Fatal Flaws?
On the surface, then, Microsoft does seem to have a straightforward and fairly substantive SOA strategy, one Martin details in depth for Redmond (see "Microsoft and Service-Oriented Technology"). But industry observers stress that there are clear limits to it.

Forrester analyst Randy Heffner says that as a company, Microsoft's philosophy is to be "standards-based at the edge. But when you talk about standards that affect internally how things go, then Microsoft doesn't play in that ecosystem nearly as much."

An example of this is Microsoft's decision not to join a phalanx of other vendors -- including IBM -- in endorsing a pair of potentially key standards for SOA: the Service Component Architecture (SCA) and Service Data Object (SDO) specifications. Both are still in development under the watch of the OASIS standards body.

Such standards are too closely tied to rival technologies and platforms for Microsoft's taste, Heffner says: "That would be a hard pill to swallow. Microsoft doesn't want to do the tools that will help people use some other platforms."

Asked directly why Microsoft hasn't joined SCA and SDO, Martin somewhat deflects the question, saying, "SCA is a great endorsement of the work we have done on the Windows communications side. It tells us that others think the strategy of building a set of technologies that are transport payload-agnostic was the right way to go."

While Martin and his colleagues at Microsoft may have crafted an array of SOA-enabling technologies, it's an open question how many enterprise customers are prepared to immediately embrace them. Eric Manley, a consultant who's working on SOA-related initiatives for a Fortune 500 company, says his company is still preoccupied with purely human concerns.

"We're getting there. We've got a lot of point-to-point implementations. I think the bigger challenge is getting over more of the governance, who decides what," he says.

Manley says his company currently has groups working to determine exactly what a runtime environment should look like. Once that's determined, he can start to define the minimal requirements in order to get into that environment, and what the service-level agreements should be.

"Each project is kind of funded from its own money, so [different departments] are very apprehensive about building something that somebody else could consume. You start out with the deck stacked against you," he says.

Manley says that so far, there are only scattered instances where SOA-related efforts have resulted in reusable services.

Like many IT shops, Manley's company is several years behind Microsoft in terms of the underlying technology being used. He says only now is his company moving from the 1.1 version of the .NET Framework to 2.0. He adds that his current environment also includes a healthy amount of IBM's WebSphere technology, although the client machines are predominantly Windows boxes. His biggest challenge, however, is not technology-related but centers more on organizational and social changes.

"Whether it's .NET, Java, Oracle, SAP, who cares? It's working through the governance and who pays for and decides what that is-really, to me in my world [that's] the real challenge," he says.

Some believe the inherent flexibility of SOA-based software, in addition to the perceived greater financial incentive to diversify to multiple platforms, makes more sense for companies like IBM and Oracle than for Microsoft.

"With SOA [Oracle and SAP] can take existing services and components from one set of business apps over to a ripe vertical market and reuse 70 or 80 percent of them and then tailor the remaining 20 or 30 percent to that specific industry. Suddenly, SOA makes a whole lot of sense for ISVs," Gardner says.

Survival of the Fittest
Now that Microsoft's services-oriented strategy is finally crystallizing, there are two ways to think about the future: Is Redmond simply too late to become a major SOA player? Or will the company emerge fairly unscathed from the sector's initial growing pains, poised to become a viable alternative?

Heffner, for one, is not betting his entire bankroll. "They will survive," he says. "Will they get as much penetration in the enterprise as they want? ... I don't [see them becoming] Java killers any more than they've been in the past."

But it may not be necessary to for Microsoft to go lion hunting when it can go trawling for fish instead. Microsoft has a history of going after high-volume, low margin markets, and with SOA still a high-end, high-margin business, the company may simply be sitting and waiting for the commoditized market to materialize with the arrival of low-cost SOA-based tools and platforms.
But whatever the hunting weapon Microsoft chooses for this expedition, there's a good chance the route it takes won't be on a map.

Ed Scannell is the editor of Redmond magazine. Chris Kanaracus is the news editor of Redmond Developer News magazine. You can contact Ed Scannell about "Microsoft Does Have a SOA Strategy" at editor@redmondmag.com.

SOA in Banking - Fifth Third Bancorp - IBM SOA Customer

Fifth Third banks on automated processes and flexible systems to deliver world-class reliability - SOA in Banking - IBM SOA Customer

“IBM’s role is to help us find new solutions every day that enable us to reach our objectives more efficiently and cost effectively. We don’t view IBM as a vendor, but as an extension of our organization. - Jim Scott, CTO, Fifth Third Bank

Customer: Fifth Third Bancorp - IBM SOA Customer
Deployment Country: United States
Industry: Banking - SOA in Banking
Solution: Business-to-Business, Business Continuity, Business Process Management, Data Warehouse, Database Management, Enabling Business Flexibility, Innovation that matters, Optimizing IT, SOA Service Oriented Architecture, Systems & Network Management

Overview - SOA in Banking
Fifth Third Processing Solutions—one of the largest electronic payments processors—needs to ensure that its systems will always be there for its customers.

Business need: SOA in Banking - Fifth Third wanted a more flexible IT infrastructure to meet today’s peaks and tomorrow’s growth—all with maximum efficiency.

Solution: SOA in Banking - Fifth Third is transforming its infrastructure by adding autonomic and virtualization capabilities which deliver both resiliency and consistently high performance.

Benefits: SOA in Banking -Increased system resiliency via autonomic and proactive infrastructure management -“Tens of millions” in overall cost savings associated with IBM-related transformation initiatives.

SOA in Banking - TransFonD - IBM SOA Customer

TransFonD brings Romania’s national banking system into the electronic era with IBM infrastructure solution - SOA in Banking - IBM SOA Customer

"With our service oriented architecture, TransFonD can leverage reusable code components, enabling the same services to function within many applications, saving time to value for our new solutions." - Marian Simion, IT Director, TransFonD

Customer: TransFonD S.A. - IBM SOA Customer
Deployment Country: Romania
IBM Business Partner: S&T Romania
Industry: Banking - SOA in Banking
Solution: Enabling Business Flexibility, SOA Service Oriented Architecture, Small & Medium Business

Overview - SOA in Banking
Since the fall of communism in 1989, Romania has undergone numerous development programs to modernize its government, privatize its industries and make its financial institutions more efficient. For assistance in joining the European Union (EU), Romania has tapped EU funding for several projects, and none has had more dramatic consequences than the development of an electronic interbank payment system. TransFonD S.A. carried out the project with IBM’s assistance.

Business need: SOA in Banking - To compete in the European Union, Romania needed to upgrade its banking IT infrastructure and implement an electronic interbank payment solution

Solution: SOA in Banking - Scalable, flexible, service oriented architecture and messaging software integrates interbank electronic payment system with core back-end processing applications and data of its member banks, processing up to 300,000 transactions per day in automatic clearing house application alone

Benefits: SOA in Banking - Faster processing of up to 7 billion EUR (8.6 billion USD) per day in funds; reduction of settlement period from two days to real time; 67% reduction of fees compared with paper-based system; improved security and liquidity management in Romania’s banking system; simplified work processes

SOA in Banking - Storebrand - IBM SOA Customer

Storebrand improves agility by integrating business processes with IBM solution - SOA in Banking - IBM SOA Customer

"In combination with our service oriented architecture, IBM DB2 9 can help us achieve, with far greater ease, our goal of using information on demand to readily respond to market changes and customer demand." - Thore Thomassen, Senior Enterprise Architect, Storebrand Group

Customer: Storebrand - IBM SOA Customer
Deployment Country: Norway
Industry: Banking, Financial Markets, Insurance - SOA in Banking
Solution: Business Process Management, Customer Relationship Management, Database Management, Enabling Business Flexibility, Information On Demand, SOA Service Oriented Architecture, Web Services

Overview - SOA in Banking
With roots dating back to 1767 and fiscal year 2004 profits of 2.4 billion NOK (358 million USD), Storebrand Group is Norway’s oldest and one of its biggest financial services companies, and a leading player throughout Scandinavia. The company provides life insurance, pension products, commercial retail banking and asset management to many of Norway’s largest companies as well as to private individuals, municipalities and public sector entities.

Business need: SOA in Banking - Improve business agility, ability to make timely and informed business decisions and provide better customer service

Solution: SOA in Banking - Implement a service oriented architecture based on IBM DB2® and IBM WebSphere® solutions, including IBM DB2 9 data server

Benefits: SOA in Banking - Expected ability to handle five times as many customers; reduced order processing time; faster time to market with new products and product combinations; improved customer service through 24x7 online access and ability to view all orders; richer ability to query stored customer and product data for business insight; dramatically reduced time, complexity and cost to conduct database queries; improved productivity for programmers

SOA in Banking - netASPx - IBM SOA Customer

netASPx delivers new value to customers with IBM middleware - SOA in Banking - IBM SOA Customer

"By incorporating IBM technology, netASPx is able to deliver a wide range of benefits to its customers. We’re able to provide and manage ERP applications at a scale and service level that are unprecedented in the market." - Chance Veasey, Vice President of Operations, netASPx

Customer: netASPx - IBM SOA Customer
Deployment Country: United States
Industry: Banking, Computer Services, Healthcare, Insurance, Retail - SOA in Banking
Solution: Enabling Business Flexibility, Enterprise Resource Planning, SOA Service Oriented Architecture, Small & Medium Business

Overview - SOA in Banking
netASPx is an innovator in the delivery of “software as a service.” The company provides Managed Applications Services (MAS) for enterprise resource planning and workforce management solutions. netASPx automates these functions for customers at lower cost, higher service levels and with less risk than would result if customers maintained an in-house team.

Business need: SOA in Banking - Respond to customers’ demands for scalability, performance and high availability, with the cost-effectiveness of a hosted solution

Solution: SOA in Banking - Incorporation of IBM middleware, security and server technology into a hosted ERP application

Benefits: SOA in Banking - netASPx, IBM SOA customer, can better serve customers who could not afford a clustered environment; ability for customers to focus on high-value work without needing to maintain infrastructure; improved performance will enable customers to migrate to Web solution and save costs for themselves and for netASPx

SOA in Banking - Banco de Chile

Banco de Chile reduces application deployment cost with IBM integration solution - SOA in Banking - IBM SOA Customer

"The WebSphere Message Broker solution is part of a business initiative to streamline processes and solutions, and provide our customers with stellar service, while increasing our revenue." - Ruben Farias Sasia, Senior Vice President, Technological Development, Banco de Chile

Customer: Banco de Chile - IBM SOA Customer
Deployment Country: Chile
Industry: Banking - SOA in Banking
Solution: Business Integration, Enabling Business Flexibility, SOA Service Oriented Architecture

Overview - SOA in Banking
Based in Santiago, Chile, Banco de Chile provides commercial banking services to a diverse customer base that includes large corporations, small and mid-sized businesses and individuals. The bank’s 9,000 employees deliver financial products and services through a nationwide network of nearly 250 branches, more than 1,000 ATMs and additional electronic distribution channels.

Business need: SOA in Banking - Enhance competitiveness by enabling a faster, simpler and more flexible infrastructure that could support new business processes targeted at improving customer service for bank customers

Solution: SOA in Banking - IBM software solution to connect and integrate new application development environment with existing back-end systems

Benefits: SOA in Banking - Reduced application development time and maintenance costs; improved response time to changing business requirements; flexible application infrastructure enabled the bank’s IT staff to focus on other line-of-business requirements, improving overall service while reducing the need to hire and train additional personnel

SOA in Banking - HypoVereinsbank connects systems

Service oriented architecture SOA in Banking - HypoVereinsbank connects systems, offering new services

“The ESB provides a flexible infrastructure for HVB's agile investment banking. Our business is changing very fast, and the ESB enables us to support upcoming business opportunities immediately by connecting new market places and new dealing systems to our existing system landscape. The ESB accelerates the adaption of new business processes and the launch of new products and services.” - Michael Dietze, Head of Business Development, HypoVereinsbank AG

Customer: HypoVereinsbank AG - IBM SOA Customer
Deployment Country: Germany
Industry: Banking - SOA in Banking
Solution: Business Performance Transformation, Enabling Business Flexibility, Information On Demand, Openness, SOA Service Oriented Architecture, Systems & Network Management, Transforming IT

Overview - SOA in Banking
A leading bank in Germany reduces the time required to develop new integration scenarios by 35 percent and improves its time to market for new services when it engages IBM Global Business Services and IBM Business Partner Steria Mummert Consulting to implement an enterprise service bus solution based on IBM WebSphere and IBM Tivoli software.

Business need: SOA in Banking - The Corporates & Markets line of business (LOB) of HVB needed to improve its ability to offer new services to its customers. The LOB's IT department, known as HVB Information Services GmbH couldn't respond quickly to capitalize on market opportunities, meet customer demands or fully support its business strategies. The LOB needed to integrate its IT infrastructure to improve its ability to address customer demands and respond to market opportunities.

Solution: SOA in Banking - With help from IBM Global Business Services, IBM Software Group and IBM Business Partner Steria Mummert Consulting, the HVB Information Services GmbH department deployed an enterprise service bus (ESB) infrastructure based on IBM Tivoli and IBM WebSphere software. The integration solution acts as a cost-effective connection environment that simplifies the trading process and offers HVB a competitive advantage by decreasing its time to market for new products and services.

Benefits: SOA in Banking - HVB achieved a 35 percent reduction in the time required to design and implement integration scenarios used to link existing and new applications with internal and external information systems. The solution enables HVB to quickly and easily become connected to the Euronext stock exchange. Time savings has led to more affordable implementation and operations costs as well as an improved ROI and time to market.

SOA in Banking - To stay ahead of the competition, RouteOne develops a strong service-oriented architecture using IBM WebSphere software

SOA in Banking - To stay ahead of the competition, RouteOne develops a strong service-oriented architecture SOA using IBM WebSphere software.

“Using the WebSphere solution, we are able to respond quickly to meet evolving customer require­ments, putting us a step ahead of the competition.” - T.N. Subramaniam, Chief Architect &Director of Technology, RouteOne

Customer: RouteOne, LLC - IBM SOA Customer
Deployment Country: United States
Industry: Automotive, Banking - SOA in Banking
Solution: Enabling Business Flexibility, Openness, Service Oriented Architecture, Small & Medium Business, Transforming IT

Overview - SOA in Banking
RouteOne offers a revolutionary real-time, Web-based system that enables automobile dealers to manage the credit application process from multiple financial sources. The RouteOne system integrates with numerous participating financing companies, and it aggregates all financing sources into a single point for auto dealers.

Business need: SOA in Banking - RouteOne was looking to upgrade its application platform to an open-standards based architecture so that it could support more users and integrate with diverse partners. In addition, the company wanted to differentiate its system within the automotive marketplace by implementing a service-oriented architecture (SOA) and leveraging Web services to build a more flexible system that could respond quickly to users’ changing needs.

Solution: SOA in Banking - RouteOne built a robust SOA for its credit application management system using IBM WebSphere® and IBM DataPower® software.

Benefits: SOA in Banking - Provides a robust service oriented architecture SOA infrastructure to deliver an open, integrated, Web-acces­sible solution for customers • Enables RouteOne to reuse services, build business rules and adopt best prac­tices to bring services to market more quickly than the competition • Offers flexibility to meet evolving customer requirements and support more users • Able to scale to a very large number of concurrent users

SOA in Banking - EBS Building Society gains competitive edge with new channel

Service Oriented Architecture SOA in Banking - EBS Building Society gains competitive edge with new channel

“With our service oriented architecture, we have the ability to build services as standardized components that can be reused and combined to address changing business goals. We realized we could better compete with anyone regardless of size because this ability enables us to bring new innovative services to market faster.” - –David Yeates, Senior Manager, IT architecture, EBS Building Society

Customer: EBS Building Society - IBM SOA Customer
Deployment Country: Ireland
Industry: Banking - SOA in Banking
Solution: Business Continuity, Business Resiliency, Enabling Business Flexibility, Service Oriented Architecture SOA, Small & Medium Business

Overview - SOA in Banking
A building society based on cooperative mutual principles, EBS has been offering home financing to its members since 1935 and today commands in excess of a 10 percent share of the 26 billion EUR (31 billion USD) Irish home loan market.

Business need: SOA in Banking - EBS has traditionally operated exclusively through its network of branches and franchised agents. But the market for home loans in Ireland has been transformed by a new breed of independent mortgage brokers who now account for 40 percent of the market. To respond to this marketplace change, EBS needed a channel to reach these brokers.

Solution: SOA in Banking - EBS had prepared an infrastructure for this innovation, which would connect the company directly to brokers’ in-house systems, by previously laying the ground­work for service orientation using IBM WebSphere® Application Server Network Deployment and IBM Rational® Application Developer for WebSphere. A service oriented architecture (SOA) provides significant business value by exposing exist­ing systems as “services”—without having to write extensive code or scrap previous investments.

Results: SOA in Banking - New online channel for reaching broker community that enables brokers to connect seamlessly with EBS from within their own companies’ online business systems

Benefits: SOA in Banking -Mortgage application processed in just hours compared with 2-3 days taken by competitors; independent mortgage broker channel now accounts for substantial portion of EBS’s business after only 6 months, far exceeding expectations; new channel added without significantly increasing staff levels

SOA in Banking - Pay By Touch: Revolutionizing retail through biometrics

Service Oriented Architecture SOA in Banking - Pay By Touch: Revolutionizing retail through biometrics

"The retail use is the initial foray, but think about it...once this technology gets to a certain penetration point, consumers will want to see it being used everywhere, and the technology lends itself to all sorts of different environments." - Ryan Ross, vice president of business development, Pay By Touch

Customer: Pay By Touch - IBM SOA Customer
Deployment Country: United States
IBM Business Partner: Silicon Valley Systech
Industry: Banking, Retail - SOA in Banking
Solution: Business-to-Business, Business Integration, Empowering People, Enabling Business Flexibility, Innovation that matters, Operational Management, Optimizing IT, Security, SOA Service Oriented Architecture, Small & Medium Business

Overview - SOA in Banking
Pay By Touch, a San Francisco-based service provider, is a company that has taken two existing technologies and combined them to create a new service that has the potential to fundamentally change the way consumers think about paying for goods and services.

Business need: SOA in Banking - Pay By Touch had put together two existing capabilities—biometric recognition and electronic financial transactions—to create a groundbreaking new retail payment service. The company needed a highly scalable, secure and easy-to-integrate platform to support its rapidly growing operations.

Solution: SOA in Banking - Pay By Touch implemented a service-oriented architecture that helps the company integrate the diverse systems of companies that it acquires while remaining highly scalable to accommodate strong customer growth. The company is also collaborating with IBM to build Pay By Touch capabilities into IBM's leading point-of-sale software solution, making it easier for stores to take advantage of the service.

Benefits: SOA in Banking - 25 percent reduction in the cost of integrating acquired companies • 30 percent increase in the productivity of IT staff • 15 percent reduction in total cost of ownership

SOA in Banking - People’s Bank enhances customer service with IBM WebSphere software solution.

Service Oriented Architecture SOA in Banking - People’s Bank enhances customer service with IBM WebSphere software solution - IBM SOA Customer

“IBM WebSphere software allows us to save time and money by reusing applications, and by avoiding the costs of building new connectivity and integration into each new solution we deploy.” - —Jaci Coleman, Chief Information Officer, People’s Bank

Customer: People's Bank - IBM SOA Customer
Deployment Country: United States
Industry: Banking - SOA in Banking
Solution: Enabling Business Flexibility, SOA Service Oriented Architecture, Transforming IT

Overview - SOA in Banking
One of the principal challenges facing banks today is to remain focused on meeting customer needs in an increasingly competitive landscape. For People’s Bank—one of the largest independent banks in Connecticut, with assets of 11 billion USD—providing customers with personalized service has been a core value since its founding in the nineteenth century. The bank strives to deliver financial services that “revolve around you” at its more than 155 branches.

Business need: SOA in Banking - Bank tellers lacked a single, unified view of the customer and had to enter codes and toggle between screens to perform basic tasks, causing delays and inhibiting their ability to cross-sell and up-sell customers

Solution: SOA in Banking - People’s Bank teamed with IBM to create an SOA, integrating the back-end financial applications with front-end sales and service applications; this solution unifies and connects applications across the enterprise and provides the ability to focus on customer needs, not the IT infrastructure

Benefits: SOA in Banking - 400% improvement in response times; improved teller productivity; reduced teller training costs; upgraded customer service; increased up-selling and cross-selling; enhanced business agility and time to market; reduced long-range costs for application development and integration

SOA in Banking - St.George Bank - IBM SOA customer

Service oriented architecture SOA in Banking - St.George Bank saves 15 million USD through re-use of key business functions with IBM WebSphere solution - IBM SOA customer

A pragmatic and profitable approach to building a flexible bank and introducing new products

“We no longer want to invest the time and resources in two- or three-year initiatives. Business is changing so fast these days that we can’t afford to roll something into production that represents the thinking of three years ago.” - —Greg Booker, Head of Group Architecture, St.George Bank

Customer: St.George Bank - IBM SOA Customer
Deployment Country: Australia
Industry: Banking, Financial Markets - SOA in Banking
Solution: Enabling Business Flexibility, SOA Service Oriented Architecture

Overview - SOA in Banking
Growth by acquisition can help banks gain a larger share of the marketplace, but it can also lead to challenges associated with greater process and technology complexity. This, in turn, can threaten customer service and satisfaction. This is exactly what happened at St.George Bank, Australia’s fifth largest retail bank, during the middle and late 1990s when several regional savings and loan banks, as well as Barclay’s, came together under the St.George Bank umbrella.

Business need: SOA in Banking
St.George was focused on a large-scale integration of four separate banks. During this time, the bank focused many of its resources on standardizing its technology and weaving together disparate platforms using a point-to-point method of integration. As the bank came out of the year 2000, it found that the tightly coupled systems and siloed information platforms developed in this process needed to be integrated to ensure flexibility, tight cost control and speed to market for new applications.

Solution: SOA in Banking
St.George bank implemented a service oriented architecture (SOA) that re-uses business functions and loosely couples them to back-end systems with a messaging middleware solution from IBM

Benefits: SOA in Banking
Saved an estimated 20 million AUD (15 million USD) by re-using 47% of its key business functions; realized payback in less than a year for new personal lending customer application system; customer satisfaction rating has rebounded to 75% from approximately 55% prior to the solution

IBM SOA Customer - SOA in Banking - Wüstenrot & Württembergische AG

IBM SOA Customer - Service Oriented Architecture SOA in Banking - Wüstenrot & Württembergische AG - Creating a high-tech pipeline for traditional mail

Customer: Wüstenrot & Württembergische AG - IBM SOA Customer - SOA in Banking
Deployment Country: Germany
Industry: Banking, Financial Markets, Insurance
Solution: Enabling Business Flexibility, Service Oriented Architecture

Overview - SOA in Banking
With standard post still a key means of correspondence, Wüstenrot & Württembergische AG (W&W), IBM SOA Customer - Service Oriented Architecture SOA in Banking, sought to improve its mail delivery process. The existing system involved manually routing mail from a central location to regions and, from there, out to individual offices for distribution to the right department and person. The whole process was long, complicated and costly – frustrating for both the company and its customers.

Business need: W&W, IBM SOA Customer - Service Oriented Architecture SOA in Banking, needed to implement an automated, paperless mail distribution solution to reduce the mail delivery cycle, improve efficiency and cut administration costs. The company also wanted to leverage a service-oriented architecture (SOA) that would offer reusable components and a strategic platform for future automation projects.

Solution: The solution includes a back-end document repository, automated workflows, a mail processing application and an easy-to-use interface. The new application environment automatically stores and distributes incoming mail and enables back-office employees to access a list of duties and responsibilities via an electronic workbasket.

Benefits: The company has enjoyed improved efficiency and customer service; mail is now processed and delivered within two hours. The solution has increased productivity by outlining outlines tasks and priorities and making workload balancing and management easier. A standard platform has been installed for future automation projects.

Case Study - SOA in Banking
Based in Stuttgart, Germany, Wüstenrot & Württembergische AG, IBM SOA Customer - Service Oriented Architecture SOA in Banking, is a large financial services company serving about 6.5 million private customers around the world. The company offers building loan contracts, retirement products, home loans, insurance, pension funds and more through a number of subsidiaries. W&W employs approximately 11,000 people.

Business Challenge
W&W’s customers frequently send important documents via postal mail. Incoming mail was initially collected in the Central Services department. Employees in that department then distributed the mail to regional processing groups. From there, distribution teams and group managers distributed the mail to the appropriate internal departments, where it was finally processed and delivered to the recipient. This mail cycle extended the time it took to accomplish simple business transactions, resulting in poor service that left customers dissatisfied. What's more, administration costs were high due to the lack of automation. And the company had no way to make changes to the manual process or integrate it with applications running on multiple platforms.

W&W needed an automated, paperless mail distribution solution to reduce mail delivery time and save money.

Solution - SOA in Banking
IBM Global Business Services led the project management, designed and built the mail processing solution. The solution includes a back-end document repository, automated workflows, a mail processing application and an easy-to-use interface. The new application environment automatically stores and distributes incoming mail and enables back-office employees to access a list of their duties and responsibilities via an electronic workbasket, which presents a time-sensitive view of upcoming tasks.
The IBM software used in the solution included:

IBM DB2 Content Manager for AIX V8.3 software, which the company uses to store and archive all paper documents in electronic format, including 30 million tagged image file (TIF) documents and 10 million advanced function presentation (AFP) documents.
IBM WebSphere Information Integrator Content Edition V8.3 software, which serves as the interface for client applications that access the Content Manager repository.
IBM WebSphere Process Server V6.0 software, which provides the runtime environment for the new automated mail distribution process and integrates various software components to form a streamlined, reusable SOA.
IBM WebSphere Business Modeler V6.0 software, which provides an easy-to-use modeling environment so that W&W can design optimized business processes.
IBM WebSphere Studio Application Developer Integration Edition V6.0 software, which provided the development environment the company used to build the new processing application that distributes electronic documents to employees.
The time frame for the project was based on a one-month conceptual phase, a three-month implementation phase and a three-month test phase. When it is completely in production, the new automated mail distribution system will accommodate 1,500 users.

Benefits - SOA in Banking
IBM created and deployed an automated, paperless mail distribution solution for W&W based on a robust SOA environment. With this solution, the company has eliminated its long and complicated manual mail distribution process, resulting in reduced times for mail delivery. Previously, it took between four and seven hours for mail to reach the appropriate recipient. With the new IBM solution, it usually takes less than two hours. This improvement leads to increased customer service levels. In addition, the IBM solution provides workflows for other back-office tasks, resulting in improved workloads and simplified employee management processes. And since the solution is based on a reusable SOA environment, the company now has a platform in place on which to develop future automation projects.

Products and Services Used - SOA in Banking
IBM products and services that were used in this case study.
Software: DB2 Content Manager, WebSphere Business Modeler, WebSphere Process Server, WebSphere Integration Developer
Services: GBS SOA Management Services, IBM Global Business Services, IBM Software Service for WebSphere

IBM SOA Customer - SOA in Banking - KBC Bank

IBM SOA Customer - Service Oriented Architecture SOA in Banking - KBC Bank
Improving customer service by automating content management

"Claims managers can now concentrate on their primary job, rather than on searching for information. As a result, KBC expects not only to save money, but to improve internal efficiencies and boost customer satisfaction." - Pierre Sleewaegen, KBC program manager

Customer: KBC Bank - IBM SOA Customer - Service Oriented Architecture SOA in Banking
ployment Country: Belgium
Industry: Banking, Insurance
Solution: Enabling Business Flexibility, Service Oriented Architecture

Overview - SOA in Banking
KBC's insurance division needed to make it faster and easier for customers and business partners to obtain accurate, up-to-date information about insurance claims. It also wanted to drive better collaboration among its back office, business partners and customers.

Business need: KBC needed to move from paper archives to a more automated, electronic approach. The company knew it had to build its new customer-centric strategy on a well-established IT architecture framework, with clear policies and reusable components.

Solution: The framework, built on a service-oriented architecture (SOA), enables KBC’s partners to access and update the electronic claim files, while KBC Claims Handlers and KBC Insurance agents can follow the status of their claims via the Web-based interface.

Benefits: This solution enables Web-based customer self-service and speeds claims processing by allowing updating by partners. Expected time savings varies from 2.5% for KBC Claim Handlers to 10% for administrative personnel.

Case Study - SOA in Banking
KBC Group is a financial services company that offers retail banking and insurance, asset management, and corporate and market services. It is one of the top three insurers in Belgium and has a presence in more than 30 countries worldwide. The company's 45,000 employees reach nine million customers through a wide network of branches, subsidiaries and representative offices. KBC has the ambition to be an independent, medium-sized, multi-channel bank insurer, serving private persons and small and medium sized enterprises in selected European countries, with expertise in asset management and the financial markets, and the aim of achieving high profitability targets through efficiency, customer centricity, employee-friendly policies and sound risk management.

Business Challenge: SOA in Banking
KBC's insurance division needed to improve claims handling cost-efficiency by automating workflows and utilizing electronic - rather than paper - archives. It also wanted to enable customer self-service and drive better collaboration. To efficiently handle unstructured content and support collaboration among its back office, channels, business partners and customers, KBC knew it had to build a strategy on a well-established IT architecture framework, associated policies and reusable components.

KBC ICT, the company’s IT support unit, began looking for an approach which would facilitate extensive collaboration among auto repairers, damage experts, legal advisors, insurance agents, brokers and customers. By using Web-based channels and distribution channel agents to give customers easily accessible, up-to-date information, KBC felt that it could significantly improve customer services.

Solution: SOA in Banking
KBC ICT and KBC together engaged IBM Global Services as well as IBM Software Services for Information Management (ISSIM) to develop a content management framework for its claims management division. The solution integrates with the existing application architecture and utilizes IBM DB2 Content Manager software. The ISSIM group also provided knowledge transfer to KBC related to the new environment's software, framework and operating model, and acted as a liaison between the KBC support groups and the DB2 Content Manager support center in Boeblingen, Germany. KBC chose IBM DB2 Content Manager for Sun Solaris V8.3 software as the content management standard for its entire group. Utilizing the new framework, which is built on a service-oriented architecture (SOA), KBC's current and new business applications can access content management-related services to perform many routine tasks.

IBM Global Business Services developed and deployed the content management group framework and implemented new business processes. The new processes included:

Processes for adding of documents such as scanning, e-mail, and upload
Access to documents allocated to claim files to which they are allowed by the SA claim handling application such as View, Manage, Annotate and Output.
IBM Global Technology Services implemented the framework's infrastructure and operational services, while IBM Global Business Services - Application Management Services provided application development and support.

Benefits: SOA in Banking
With the new content management framework from IBM, KBC expects to improve customer services, making it faster and easier for customers to obtain accurate, up-to-date information about insurance claims. Because the solution uses electronically managed claims files, it drives better internal efficiencies and lower costs. Claims managers will be able to concentrate on their primary work rather than looking for documentation or information. KBC expects to improve the quality and quantity of claims management overall, improving customer satisfaction. Similar savings will be realized by implementing the content management framework at KBC's other companies in the Czech Republic in 2007 and later at Warta, Poland in 2008.

The solution also enables better collaboration between the company's back office, channels, business partners and customers. Insurance agents and participating companies, such as car repairers and claim experts, will be able to access and update the electronic claim files. Expected time savings varies from 2.5% for KBC Claim Handlers to 10% for administrative personnel.

Products and Services Used - SOA in Banking
IBM products and services that were used in this case study.
Services: GBS Application Development / Wireless Applications, IBM Global Business Services, IBM Integrated Technology Services

IBM SOA Customer - SOA in Banking - Oberbank AG

IBM SOA Customer - SOA in Banking - Oberbank AG
Improving service and expanding markets with a comprehensive banking platform

"Growth brings challenges, which is why we selected IBM and i-flex. They are both experienced partners that understand our needs and the needs of our customers." - Bernhard Reiter, Manager, Organization Department, Oberbank AG

Customer: Oberbank AG - IBM SOA Customer - SOA in Banking
Deployment Country: Austria
Industry: Bank