การผสานรวมแอปพลิเคชันระดับองค์กร

การบูรณาการแอปพลิเคชันระดับองค์กร ( EAI ) คือการใช้ หลักการทางสถาปัตยกรรมของ ซอฟต์แวร์ และระบบคอมพิวเตอร์เพื่อบูร ณาการชุดแอปพลิเคชันคอมพิวเตอร์ระดับองค์กร^{[ 1 ]}

การบูรณาการแอปพลิเคชันระดับองค์กรเป็นกรอบการบูรณาการที่ประกอบด้วยชุดเทคโนโลยีและบริการซึ่งประกอบเป็นมิดเดิลแวร์หรือ "กรอบมิดเดิลแวร์" เพื่อให้สามารถบูรณาการระบบและแอปพลิเคชันต่างๆ ทั่วทั้งองค์กรได้^{[ 1 ]}

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

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

ตามคำกล่าวของบริษัทวิจัยGartner : "[EAI คือ] การแบ่งปันข้อมูลและกระบวนการทางธุรกิจอย่างไม่จำกัดระหว่างแอปพลิเคชันหรือแหล่งข้อมูลที่เชื่อมต่อกันในองค์กร" ^{[ 2 ]}

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

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

ตัวอย่างเช่น จำนวนการเชื่อมต่อที่จำเป็นเพื่อให้เกิดการเชื่อมต่อแบบจุดต่อจุดที่สมบูรณ์แบบ โดยมี จุด nจุด จะคำนวณได้จากสูตร(ดูสัมประสิทธิ์ทวินาม ) ดังนั้น สำหรับแอปพลิเคชันสิบตัวที่จะบูรณาการแบบจุดต่อจุดอย่างสมบูรณ์จำเป็นต้องมีการเชื่อมต่อแบบจุดต่อจุดตามรูปแบบ การเติบโตแบบกำลังสอง${\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}}$${\displaystyle {\tfrac {10\times 9}{2}}=45}$

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

EAI ไม่ได้เป็นเพียงแค่การแบ่งปันข้อมูลระหว่างแอปพลิเคชันเท่านั้น แต่ยังมุ่งเน้นไปที่การแบ่งปันทั้งข้อมูลทางธุรกิจและกระบวนการทางธุรกิจด้วย นักวิเคราะห์มิดเดิลแวร์ที่ดูแล EAI มักจะพิจารณาระบบของระบบต่างๆ

EAI สามารถนำไปใช้ได้หลายวัตถุประสงค์:

• การบูรณาการข้อมูล : ช่วยให้มั่นใจได้ว่าข้อมูลในระบบต่างๆ มีความสอดคล้องกัน ซึ่งเรียกอีกอย่างว่าการบูรณาการข้อมูลระดับองค์กร (Enterprise Information Integrationหรือ EII)
• ความเป็นอิสระจากผู้จำหน่าย: ดึงนโยบายหรือกฎทางธุรกิจจากแอปพลิเคชันต่างๆ และนำไปใช้ในระบบ EAI เพื่อให้แม้ว่าแอปพลิเคชันทางธุรกิจตัวใดตัวหนึ่งจะถูกแทนที่ด้วยแอปพลิเคชันของผู้จำหน่ายรายอื่น ก็ไม่จำเป็นต้องนำกฎทางธุรกิจมาปรับใช้ใหม่
• ส่วนติดต่อผู้ใช้ทั่วไป: ระบบ EAI สามารถเป็นส่วนหน้าของกลุ่มแอปพลิเคชัน โดยจัดเตรียมส่วนติดต่อการเข้าถึงที่สม่ำเสมอเพียงหนึ่งเดียวสำหรับแอปพลิเคชันเหล่านั้น และป้องกันไม่ให้ผู้ใช้ต้องเรียนรู้การใช้งานซอฟต์แวร์แพ็กเกจต่างๆ

ส่วนนี้อธิบายถึงรูปแบบการออกแบบทั่วไปสำหรับการใช้งาน EAI รวมถึงรูปแบบการบูรณาการ การเข้าถึง และอายุการใช้งาน รูปแบบเหล่านี้เป็นรูปแบบนามธรรมและสามารถนำไปใช้ได้หลายวิธี นอกจากนี้ยังมีรูปแบบอื่นๆ อีกมากมายที่ใช้กันทั่วไปในอุตสาหกรรม ตั้งแต่รูปแบบการออกแบบนามธรรมระดับสูงไปจนถึงรูปแบบการใช้งานที่เฉพาะเจาะจงมาก^{[ 3 ]}

ระบบ EAI ใช้รูปแบบสองแบบ: ^{[ 4 ]}

การไกล่เกลี่ย (การสื่อสารภายใน)

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

สหพันธ์ (การสื่อสารระหว่างกัน)

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

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

EAI รองรับทั้งรูปแบบการเข้าถึงแบบอะซิงโครนัส (ส่งแล้วลืม) และแบบซิงโครนัส โดยแบบอะซิงโครนัสจะใช้ได้ทั่วไปในกรณีการเชื่อมต่อ และแบบซิงโครนัสจะใช้ได้ทั่วไปในกรณีการรวมระบบ

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

มีโครงสร้างเครือข่ายหลักสองแบบ คือแบบฮับและก้าน (hub-and-spoke ) และแบบบัส (bus ) แต่ละแบบมีข้อดีและข้อเสียแตกต่างกัน ในแบบฮับและก้าน ระบบ EAI จะอยู่ตรงกลาง (ฮับ) และโต้ตอบกับแอปพลิเคชันผ่านทางก้าน ในแบบบัส ระบบ EAI จะเป็นบัส (หรือถูกนำไปใช้เป็นโมดูลภายในบัสข้อความหรือมิดเดิลแวร์ที่เน้นการส่งข้อความ ที่มีอยู่แล้ว )

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

มีการใช้เทคโนโลยีหลายอย่างในการใช้งานแต่ละส่วนประกอบของระบบ EAI:

รถบัส/ศูนย์กลาง

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

การเชื่อมต่อแอปพลิเคชัน

บัส/ฮับเชื่อมต่อกับแอปพลิเคชันผ่านชุดอะแดปเตอร์ (หรือเรียกว่าตัวเชื่อมต่อ ) ซึ่งเป็นโปรแกรมที่รู้วิธีการโต้ตอบกับแอปพลิเคชันทางธุรกิจพื้นฐาน อะแดปเตอร์ทำการสื่อสารแบบทางเดียว (ทิศทางเดียว) โดยทำการร้องขอจากฮับไปยังแอปพลิเคชัน และแจ้งให้ฮับทราบเมื่อเกิดเหตุการณ์ที่น่าสนใจในแอปพลิเคชัน (เช่น การแทรกเรคอร์ดใหม่ การทำธุรกรรมเสร็จสมบูรณ์ เป็นต้น) อะแดปเตอร์อาจเฉพาะเจาะจงกับแอปพลิเคชัน (เช่น สร้างขึ้นโดยใช้ไลบรารีไคลเอ็นต์ของผู้จำหน่ายแอปพลิเคชัน) หรือเฉพาะเจาะจงกับกลุ่มของแอปพลิเคชัน (เช่น สามารถโต้ตอบกับแอปพลิเคชันใดก็ได้ผ่านโปรโตคอลการสื่อสารมาตรฐาน เช่นSOAP , SMTPหรือAction Message Format (AMF)) อะแดปเตอร์อาจอยู่ในพื้นที่กระบวนการเดียวกันกับบัส/ฮับ หรือทำงานในตำแหน่งระยะไกลและโต้ตอบกับฮับ/บัสผ่านโปรโตคอลมาตรฐานอุตสาหกรรม เช่น คิวข้อความ เว็บเซอร์วิส หรือแม้กระทั่งใช้โปรโตคอลที่เป็นกรรมสิทธิ์ ในโลกของ Java มาตรฐานเช่นJCAอนุญาตให้สร้างอะแดปเตอร์ในลักษณะที่เป็นกลางต่อผู้จำหน่าย

รูปแบบ และการแปลงข้อมูล

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

โมดูลการบูรณาการ

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

การสนับสนุนธุรกรรม

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

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

1. ตัวกลางแบบรวมศูนย์ที่จัดการด้านความปลอดภัย การเข้าถึง และการสื่อสาร สามารถทำได้ผ่านเซิร์ฟเวอร์การรวมระบบ (เช่นเซิร์ฟเวอร์การรวมระบบโซนของSchool Interoperability Framework (SIF) ) หรือผ่านซอฟต์แวร์ที่คล้ายกัน เช่น โมเดล Enterprise Service Bus (ESB) ที่ทำหน้าที่เป็นผู้จัดการบริการ
2. แบบจำลองข้อมูลอิสระที่อิงตามโครงสร้างข้อมูลมาตรฐาน หรือที่เรียกว่าแบบจำลองข้อมูลเชิงหลักการ (canonical data model ) ดูเหมือนว่า XML และการใช้สไตล์ชีต XML ได้กลายเป็นมาตรฐานโดยพฤตินัยและในบางกรณี ก็เป็นมาตรฐาน โดยนิตินัยสำหรับภาษาธุรกิจที่เป็นเอกภาพนี้
3. รูปแบบตัวเชื่อมต่อหรือเอเจนต์ ที่ซึ่งผู้ขาย แอปพลิเคชัน หรืออินเทอร์เฟซแต่ละรายสามารถสร้างส่วนประกอบเดียวที่สามารถสื่อสารกับแอปพลิเคชันนั้นได้โดยตรง และสื่อสารกับตัวกลางควบคุมได้
4. แบบจำลองระบบที่กำหนด API การไหลของข้อมูล และกฎการมีส่วนร่วมของระบบ เพื่อให้สามารถสร้างส่วนประกอบต่างๆ เพื่อเชื่อมต่อกับระบบได้อย่างเป็นมาตรฐาน

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

การบูร ณาการแอปพลิเคชันระดับองค์กร (Enterprise Application Integration: EAI) เกี่ยวข้องกับเทคโนโลยีมิดเดิลแวร์ เช่น มิดเดิลแวร์แบบเน้นข้อความ (Message-Oriented Middleware: MOM ) และเทคโนโลยีการแสดงข้อมูล เช่นXMLหรือJSONเทคโนโลยี EAI อื่นๆ เกี่ยวข้องกับการใช้เว็บเซอร์วิสเป็นส่วนหนึ่งของสถาปัตยกรรมแบบเน้นบริการ (Service-Oriented Architecture: SAR ) เพื่อเป็นวิธีการบูรณาการ โดยทั่วไปแล้ว การบูรณาการแอปพลิเคชันระดับองค์กรจะเน้นที่ข้อมูลเป็นหลัก ในอนาคตอันใกล้ จะรวมถึงการบูรณาการเนื้อหาและกระบวนการทางธุรกิจด้วย

ในปี พ.ศ. 2546 มีรายงานว่าโครงการ EAI ทั้งหมด 70% ล้มเหลว ความล้มเหลวส่วนใหญ่ไม่ได้เกิดจากตัวซอฟต์แวร์เองหรือปัญหาทางเทคนิค แต่เกิดจากปัญหาด้านการจัดการ Steve Craggs ประธาน Integration Consortium European ได้สรุปข้อผิดพลาดหลัก 7 ประการที่บริษัทต่างๆ พบเจอเมื่อใช้ระบบ EAI และอธิบายวิธีแก้ปัญหาเหล่านี้^{[ 5 ]}

1. การเปลี่ยนแปลงอย่างต่อเนื่อง: ธรรมชาติของ EAI นั้นมีความเปลี่ยนแปลงอยู่ตลอดเวลา และต้องการผู้จัดการโครงการที่มีความยืดหยุ่นเพื่อบริหารจัดการการนำไปใช้งาน
2. ปัญหาการขาดแคลนผู้เชี่ยวชาญด้าน EAI: EAI ต้องการความรู้ในหลายประเด็นและแง่มุมทางเทคนิค
3. มาตรฐานที่แข่งขันกัน: ในสาขา EAI นั้น ความขัดแย้งอยู่ที่ว่ามาตรฐาน EAI เองก็ไม่ได้เป็นสากล
4. EAI เป็นแนวคิดเชิงเครื่องมือ: EAI ไม่ใช่เครื่องมือ แต่เป็นระบบ และควรนำไปใช้ในลักษณะนั้น
5. การสร้างอินเทอร์เฟซเป็นศิลปะอย่างหนึ่ง การออกแบบทางวิศวกรรมเพียงอย่างเดียวไม่เพียงพอ จำเป็นต้องมีการเจรจากับฝ่ายผู้ใช้งานเพื่อให้ได้ข้อตกลงร่วมกันเกี่ยวกับผลลัพธ์สุดท้าย การขาดข้อตกลงร่วมกันเกี่ยวกับการออกแบบอินเทอร์เฟซจะนำไปสู่ความพยายามอย่างมากในการจับคู่ความต้องการข้อมูลระหว่างระบบต่างๆ
6. การสูญเสียรายละเอียด: ข้อมูลที่ดูเหมือนไม่สำคัญในตอนแรก อาจกลายเป็นข้อมูลสำคัญในภายหลัง
7. ความรับผิดชอบ: เนื่องจากมีหลายแผนกที่มีข้อกำหนดที่ขัดแย้งกัน จึงควรมีการกำหนดความรับผิดชอบที่ชัดเจนสำหรับโครงสร้างสุดท้ายของระบบ

ปัญหาอื่นๆ ที่อาจเกิดขึ้นได้ในพื้นที่เหล่านี้:

• ขาดการประสานงานส่วนกลางในการดำเนินงาน EAI ^{[ 6 ]}
• ข้อกำหนดที่เกิดขึ้นใหม่: การใช้งาน EAI ควรมีความยืดหยุ่นและเป็นแบบโมดูลาร์ เพื่อรองรับการเปลี่ยนแปลงในอนาคต
• ลัทธิกีดกันทางการค้า: แอปพลิเคชันที่กำลังนำข้อมูลมาผสานรวมมักเป็นของแผนกต่างๆ ที่มีเหตุผลทางเทคนิค วัฒนธรรม และการเมืองที่ไม่ต้องการแบ่งปันข้อมูลกับแผนกอื่นๆ

• กรอบสถาปัตยกรรมองค์กร
• กลยุทธ์สำหรับการบูรณาการแอปพลิเคชันระดับองค์กร
• การจัดการความหมายทางธุรกิจ
• การบูรณาการข้อมูล
• การบูรณาการข้อมูลระดับองค์กร
• การบูรณาการระดับองค์กร
• รูปแบบการบูรณาการระดับองค์กร
• บัสบริการองค์กร
• สถาปัตยกรรมอ้างอิงองค์กรทั่วไปและระเบียบวิธี
• อุปกรณ์บูรณาการ
• ศูนย์ความเชี่ยวชาญด้านการบูรณาการ
• แพลตฟอร์มการบูรณาการ
• การบูรณาการระบบ

• ระดับสุขภาพ 7
• โครงการริเริ่มความรู้แบบเปิด
• OSS ผ่าน Java
• กรอบการทำงานเพื่อความสามารถในการทำงานร่วมกันของโรงเรียน (SIF)