Micro Business Architecture

DinoQ Entrepreneur Platform 2016/01 ( info@dinoq.com )

ในปัจจุบันระบบขององค์กรขนาดใหญ่(Enterprise Application) มีความซับซ้อน และมีส่วนประกอบต่างๆ เป็นจำนวนมาก เช่น ระบบงานบุคคล (Human resource system), ระบบงานบัญชี (Accounting system) รวมถึงระบบที่ถูกพัฒนาเฉพาะของธุรกิจเพื่อให้บริการลูกค้า ยิ่งบริษัทมีขนาดใหญ่ขึ้น มีผลิตภัณฑ์ หลากหลายขึ้น หรือมีบริษัทลูกและฝ่ายงานมากขึ้นเท่าใด ความหลากหลายและซับซ้อนของระบบงานก็จะเพิ่มขึ้นเป็นเงาตามตัว นอกจากนั้นการควบคุมจัดการข้อมูลของบริษัทก็จะทำได้ยากตามความซับซ้อนนั้นด้วย

โดยปกติบริษัทที่มีการจัดการระบบเทคโนโลยีสารสนเทศน์ที่ดีจะมีการจัดตั้งหน่วยงานเทคโนโลยีสารสนเทศน์ (IT, Information Technology Department) ส่วนกลางขึ้นมา โดยอาจมีการแบ่งย่อยเป็นระดับปฏิบัติการ และระดับกลยุทย์

ซึ่งระดับปฏิบัติการได้แก่ ส่วนงานที่ดูแลการออกแบบ, พัฒนาระบบ และหน่วยงานที่ดูแลควบคุมระบบให้สามารถทำงานตอบสนองการดำเนินงานของธุรกิจได้อย่างสม่ำเสมอ ไม่ขาดตอน

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

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

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

ฮาๆ แค่เกริ่นก็เล่นเอางงแล้ว จะบอกว่าโครงสร้างเกี่ยวกับระบบเทคโนโลยีสารสนเทศน์ ส่วนใหญ่ของบริษัทใหญ่ๆ ออกแบบได้งงจริงๆ

เอาหล่ะ เข้าเรื่องๆ

การออกแบบสถาปัตยกรรมระบบเทคโนโลยีสารสนเทศน์ ขององค์กรใหญ่ๆโดยมากจะยึดหลักการออกแบบ แบบรวมศูนย์ (Centralize System Design) กล่าวคือจะมีการออกแบบให้ทรัพยากรณ์ ส่วนกลางของระบบอยู่ที่ที่เดียวในแต่ละด้าน เช่น ระบบรายงาน (Report System), ระบบการเก็บเอกสาร (Document Management), ระบบคลังข้อมูล (Data Warehouse), ระบบเก็บข้อมูลลูกค้า (Customer Information System), ระบบจ่ายเงิน (Payment System) เป็นต้น

ปัญหาของการออกแบบระบบแบบนี้คือ … ราคาแพง?

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

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

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

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

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

น้อมนำธรรมชาติสู่เทคโนโลยี

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

ความลับของอาณาจักเหล่านี้มีหลักเกณฑ์ง่าย 2 ข้อคือ การกำหนดหน้าที่ให้เหมาะกับความสามารถของสมาชิกให้ชัดเจนเรียบง่าย และมีการสื่อสารกันอย่างมีกลยุทย์ที่ฉลาดเฉลียว

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

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

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

กระบวนการหาอาหารเปรียบเทียบได้กับกระบวนการทำงานหนึ่งๆของธุรกิจ ซึ่งโปรแกรมระบบงานหนึ่งๆของธุรกิจอาจจะประกอบไปด้วย กระบวนการทำงานเดียว หรือหลายๆกระบวนการทำงานที่มีความเกียวข้องกันสูง

หลักสำคัญที่เราได้ก็คือ หน้าที่และการสื่อสาร

จะได้ว่า ระบบหนึ่งๆต้องมีความชัดเจนในการทำงานเพียงพอ ต้องสามารถอยู่ด้วยตัวมันเองได้ (สามารถทำงานจบในตัวของมันเองได้) และต้องมีการทำงานที่เฉพาะเจาะจงเพียงอย่างเดียวเท่านั้น ขอเรียกว่า แอพพลิเคชันทางธุรกิจขนาดไมโคร (Micro Business Application)
แอพพลิเคชันทางธุรกิจขนาดไมโคร (Micro Business Application) คือ แอพพลิเคชันที่สมบูรณ์ที่จะประกอบด้วย ฐานข้อมูล (Database) ส่วนติดต่อผู้ใช้ (User interface) ลอจิก (Application Logic) และเว็บเซอร์วิส (Web service) ที่ให้บริการในธุรกิจด้านหนึ่งด้านใดโดยเฉพาะ

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

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

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

แบบแรก เป็นการพัฒนาแอพพลิเคชันแบบโดยแนวคิดแบบโมโนไลธิค (Monolithic) ซึ่งจะยกตัวอย่างเป็นแอพพลิเคชันการขายสินค้าผ่านหน้าเว็บ จะได้ว่า

ส่วนนี้แสดงถึงลอจิกของแอพพลิเคชันที่เขียนเป็นฟังก์ชันงานต่างๆ เช่น ระบบจัดการสินค้า ระบบจ่ายเงิน ระบบจัดการลูกค้า โดยผลิตภัณฑ์จะมี 2 ชนิด (ฟังก์ชันมีอย่างละ 2 รูป)

ส่วนนี้จะแสดงถึงระบบฐานข้อมูลของแต่ละระบบแยกกันในระดับตารางข้อมูล

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

จะเห็นว่าการพัฒนาแอพพลิเคชันแบบโดยแนวคิดแบบโมโนไลธิคนี้ จะเกิดโปรแกรมเดียวที่ใหญ่มาก ประกอบด้วยโปรแกรมย่อยจำนวนมาก ทำให้การพัฒนามีความซับซ้อน และเมื่อธุรกิจมีการเปลี่ยนแปลงจะกระทบทั้งโปรแกรม

แบบที่สอง การพัฒนาแอพพลิเคชันแบบโดยแนวคิดแบบไมโครเซอร์วิส (Microservice)

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

ส่วนที่เป็นระบบฐานข้อมูลของแต่ละระบบแยกกันในระดับฐานข้อมูล

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

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

แบบที่สาม การพัฒนาแอพพลิเคชันแบบโดยแนวคิดแบบแอพพลิเคชันทางธุรกิจขนาดไมโคร (Micro Business Application)

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

ยกตัวอย่างเช่น ระบบ A จะสนับสนุน ผลิตภัณฑ์ A ซึ่งลูกค้าของ ผลิตภัณฑ์ A ก็จะอยู่ใน ระบบ A

ระบบ B จะสนับสนุน ผลิตภัณฑ์ B ซึ่งลูกค้าของ ผลิตภัณฑ์ B ก็จะอยู่ใน ระบบ B

หากต้องการข้อมูลทั้งหมดต้องร้องขอเว็บเซอร์วิสไปที่ทั้งระบบ A และ ระบบ B

หากมีลูกค้ามาลงทะเบียนที่ระบบ B และต้องการรู้ว่าเป็นลูกค้าระบบ A หรือไม่ต้องร้องขอเว็บเซอร์วิสไปที่ระบบ A เป็นต้น

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

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

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

และบางกรณีผลิตภัณฑ์หรือบริการ อาจเปลี่ยนเป็นกลุ่มของผลิตภัณฑ์หรือบริการก็ได้ซึ่งการกำหนดภาพรวมของระบบเหล่านี้ จะต้องตรงกับภาพของการดำเนินธุรกิจ

การขับเคลื่อนจากรูปแบบของธุรกิจ (Business Model Driven) เป็นหัวใจหลักในการออกแบบระบบแบบนี้โดยจะเป็นตัวกำหนด ว่าแอพพลิเคชันขนาดไมโคร (Micro Application) จะมีอะไรบ้าง และรูปแบบการสื่อสารจะเป็นอย่างไร โดยยึดถือรูปแบบของธุรกิจเท่าที่มีการทำงานจริงในปัจจุบันเท่านั้น เผื่อผลักดันให้ระบบเสร็จเร็วที่สุด

จากข้อมูลข้างต้นสามารถสรุปเกี่ยวกับการพัฒนาแอพพลิเคชันตามแนวทางของแอพพลิเคชันทางธุรกิจขนาดไมโคร (Micro Business Application) ได้ดังนี้ คือ

  • เป็นแอพพลิเคชั่นทางธุรกิจแบบกระจายกระบวนการทำงาน โดยแอพพลิเคชั่นใดๆจะสามารถทำงานบนตัวรันไทม์หลายๆตัวได้ (Distributed micro business apps and services)
  • มีโครงสร้างของข้อมูลแบบกระจายอยู่ในหลายๆแอพพลิเคชั่น โดยจะมีทั้งส่วนที่เหมือนกัน(ซ้ำกัน) และต่างกันในแต่ละแอพพลิเคชั่น จุดมุ่งหมายคือให้แต่ละแอพพลิเคชั่นมีการทำงานที่สมบูรณ์ สามารถอยู่ได้ด้วยตัวมันเอง (De-centralize business data model)
  • เป็นแอพพลิเคชั่นของธุรกิจที่สนับสนุนหน่วยธุรกิจที่เล็กที่สุด โดยอาจเป็นผลิตภัณฑ์ หรือบริการใดๆ ของธุรกิจนั้นๆ (Micro business application identification)
  • เป็นแอพพลิเคชั่นที่พัฒนาจากความต้องการของหน่วยธุรกิจที่เรียบง่าย และชัดเจน รวมถึงมีการพัฒนาปรับแก้ตามแผนโครงสร้างของกระบวนการทางธุรกิจโดยแบ่งตามขอบเขต ความต้องการของหน่วยธุรกิจที่เล็กที่สุด (Simple requirement to start and go to small cycle growth loop)
  • เป็นแอพพลิเคชั่นที่เน้นการสื่อสารระหว่างแอพพลิเคชั่นกันเอง โดยมีหลักกลยุทย์ในการสื่อสารที่ฉลาดเฉลียว (Smart application communication strategy)
  • การสื่อสารระหว่างแอพพลิเคชั่นต้องมีนัยยะทางธุรกิจ ไม่ใช่ข้อมูลดิบ (Micro business apps with semantic data communication)
  • การประมวลผลข้อมูล หรือการออกรายงานรวมขององค์กร จะเกิดจากผลรวมของการกระจายตัวทำงานในแต่ละแอพพลิเคชั่น โดยจะเห็นว่าการออกแบบด้วยหลักการนี้จะมีการทำงานที่คล้ายๆกันในหลายๆแอพพลิเคชั่น และเหมือนเดิมที่กล่าวมาคือในโลกการทำงานจริงจะไม่มีการทำงานของแอพพลิเคชั่นที่เหมือนกันทั้ง 100% โดยผลของความต่างจะส่งผลกระทบต่อการดูแลรักษาแบบเท่าทวีตามจำนวนที่ซ้ำกันหากนำมารวมกันไว้ (Distributed data processing and reporting on micro business apps)
  • และการออกแบบดังที่กล่าวมานี้ จะส่งผลกระทบให้ระบบดังต่อไปนี้หายไปจากองค์กร (หรือถูกใช้งานในรูปแบบใหม่) ได้แก่ Report Server, Enterprise Servce Bus (ESB), Data Warehouse, Extract Transfer Load (ETL) Tool, Workflow / Business Process Management (BPM), Enterprise Content Management (ECM) และอื่นๆ (หายไปก็น่าจะดี แพงๆทั้งนั้น)
  • ท้ายสุด การทำงานบนแอพพลิเคชันแบบโดยแนวคิดแบบแอพลิเคชันทางธุรกิจขนาดไมโคร จะบังคับให้เข้าถึงจากทางเว็บบราวน์เซอร์เท่านั้น เพื่อความปลอดภัยของข้อมูล และลดการควบคุมการใช้งานฝั่งไคลเอนท์ (ขอเสริมนิดในข้อนี้ อยากจะทำการลดเครื่องมือในแง่มุมการควบคุมเรื่องความปลอดภัย ไม่ว่าจะเป็นในแง่ Infrastructure ที่ต้องมี Firewall, Access Log หรืออื่นๆ แง่การควบคุมเรื่องไคลเอนท์ ที่ต้องมี Domian account, DLP Data Loss Prevension หรืออื่นๆ สิ่งที่ผมอยากได้คือ ไม่สนในเครือข่าย หรือเครื่องไคลเอนท์ เพียงใช้แค่เว็บบราวเซอร์ในการเข้าใช้ระบบ และสามารถผ่านการล็อกอินมาก็เพียงพอแล้ว)

ในบทความบทต่อๆไป ผมจะแสดงให้เห็นถึง ตัวอย่างการออกแบบแอพลิเคชันโดยแนวคิดแบบแอพลิเคชันทางธุรกิจขนาดไมโคร (Micro Business Application) ในโลกธุรกิจจริงๆ จะเป็นอย่างไร โปรดติดตาม นะครับ

ดูบทความอื่นๆ กดลิ้งค์เลยครับ