Frameworx

إطار المعلومات (المعروف رسميًا باسم نموذج المعلومات/البيانات المشترك أو SID) هو نموذج بيانات مرجعي موحد يوفر مجموعة واحدة من المصطلحات لوصف عناصر الأعمال في مجال الاتصالات . يهدف هذا الإطار إلى تمكين الأفراد في مختلف الأقسام والشركات والمواقع الجغرافية من استخدام المصطلحات نفسها لوصف العناصر والممارسات والعلاقات الواقعية ذاتها. وهو جزء من برنامج Frameworx.

يوفر إطار المعلومات، باعتباره نموذج معلومات Frameworx ، نموذجًا مرجعيًا للمعلومات/البيانات ومفردات مشتركة للمعلومات/البيانات من منظور الأعمال والأنظمة. ويستخدم إطار المعلومات لغة النمذجة الموحدة (UML) لصياغة احتياجات كل جهة معنية بشكل رسمي.

يوفر إطار المعلومات لغةً مشتركةً للتعبير عن اهتمامات المجموعات الأربع الرئيسية من أصحاب المصلحة، والممثلة بوجهات نظر Frameworx، وهي: الأعمال، والنظام، والتنفيذ، والنشر، كما هو مُحدد في دورة حياة Frameworx. وباستخدامه بالتزامن مع إطار عمليات الأعمال (eTOM) ووصف عمليات وأنشطة الأعمال، وخريطة تطبيقات الاتصالات، يُتيح إطار المعلومات الربط بين فرق الأعمال وفرق تقنية المعلومات داخل المؤسسة، وذلك من خلال توفير تعريفات مفهومة للأعمال، وفي الوقت نفسه دقيقة بما يكفي لاستخدامها في تطوير البرمجيات.

يستلهم نموذج إطار المعلومات من مجموعة متنوعة من مصادر الصناعة، لكن أصوله الرئيسية هي بنية المعلومات المشتركة للتحالف (ACIA) التي أنشأها فريق بقيادة بيل بروك من AT&T ومجموعة BT ونموذج الشبكات المُمكّنة للدليل - الجيل التالي (DEN-ng) الذي أنشأه جون ستراسنر.

عند إطلاقه لأول مرة عام 2000، غطى نموذج إطار المعلومات مجال الأعمال (أنظمة دعم الأعمال) بشكل جيد، وكذلك مجال إدارة الأجهزة، ولكنه كان قاصراً في قدرته على تمثيل الشبكات المنطقية وسعتها. ويجري العمل على معالجة هذه النواقص من خلال مراجعة النموذج ليشمل مفاهيم مثل الطوبولوجيا، إلا أن تاريخ النموذج أدى إلى ضعف استخدامه في بعض مجالات الاتصالات، مثل إدارة المخزون.

عند ربط أنظمة دعم العمليات (OSSs) ببعضها، تتوزع العمليات التجارية التي تدعمها عبر البنية التحتية لتكنولوجيا المعلومات. في الواقع، تبدأ العملية بالتطبيق (أ)، الذي يعالج بعض البيانات، ثم يعلم أنه يجب عليه استدعاء التطبيق (ب)، الذي يقوم بدوره ببعض المعالجة، ثم يستدعي التطبيق (ج)، وهكذا. نتيجةً لذلك، يصعب للغاية تحديد مسار أي من هذه العمليات (على سبيل المثال، إذا كانت العملية تهدف إلى تلقي طلب عميل، فهل التطبيق (أ) أم (ب) أم (ج) هو الذي يتولى معالجة هذا الطلب حاليًا؟)، بل ويزداد الأمر صعوبةً عند محاولة تغيير العملية نظرًا لطبيعتها الموزعة.

تقترح Frameworx إدارة العملية كجزء من البنية التحتية المركزية، باستخدام محرك سير عمل مسؤول عن التحكم في تدفق العمليات التجارية بين التطبيقات. وبالتالي، يبدأ محرك سير العمل عمليةً في التطبيق (أ)، ثم يعيد التحكم إلى محرك سير العمل، الذي بدوره يستدعي التطبيق (ب)، وهكذا. بهذه الطريقة، يُمكن دائمًا تحديد موقع أي تدفق عملية، نظرًا لتحكم محرك سير العمل المركزي به، كما يُمكن إجراء تعديلات على العملية باستخدام أدوات تعريف العمليات الخاصة بالمحرك. من الواضح أن بعض تدفقات العمليات ذات المستوى الأدنى ستكون مُضمنة في التطبيقات الفردية، ولكن يجب أن يكون ذلك دون مستوى المعالجة ذات الأهمية التجارية (أي دون المستوى الذي تُطبق فيه سياسات وقواعد العمل). تساعدنا منهجيات اعتماد Frameworx في التعامل مع نطاق التفضيلات غير الموزعة خطيًا، مما يُتيح فرصةً لتحسين الطريقة المُناسبة التي يقبلها العميل بلا شك.

يعني مصطلح "الترابط الضعيف" أن كل تطبيق مستقل نسبيًا عن التطبيقات الأخرى في النظام ككل. وبالتالي، في بيئة ذات ترابط ضعيف، يمكن تعديل تطبيق واحد دون أن يؤثر هذا التعديل بالضرورة على التطبيقات الأخرى. وفي أقصى حالاته، قد يُنظر إلى هذا على أنه يُتيح إمكانية "التوصيل والتشغيل" للتطبيقات، حيث تكون مستقلة لدرجة تسمح بتغييرها دون التأثير على سلوك النظام ككل. إلا أن هذا التطرف يُعتبر حالةً نادرةً في الوقت الراهن.

يؤكد "النظام الموزع" أن Frameworx لا يعتمد على مزود خدمة اتصالات (CSP) يستخدم تطبيقًا واحدًا متجانسًا لإدارة جميع أنشطته، ولكنه يستخدم بدلاً من ذلك مجموعة من التطبيقات المتكاملة والمتعاونة.

يتطلب دمج أنظمة دعم العمليات (OSS) تبادل البيانات بين التطبيقات. ولضمان فعالية هذا التبادل، يجب أن يفهم كل تطبيق كيفية فهم/تفسير التطبيقات الأخرى لجزء البيانات المُشتركة، أو أن يكون هناك نموذج موحد لهذه البيانات. لفهم ذلك، لنفترض تطبيقًا لمعالجة الطلبات قام بإدخال طلب عميل، ويحتاج الآن إلى إرسال فاتورة باستخدام التطبيق (ب) (نظام فوترة). سيحتوي التطبيق (أ) على سجل لعنوان العميل، وبالتالي عليه التأكد من أن التطبيق (ب) يرسل الفاتورة إلى هذا العنوان. يتطلب نقل هذه البيانات بين النظامين ببساطة تنسيقًا موحدًا لمعلومات العنوان - أي أن يتوقع كل نظام نفس عدد أسطر العنوان، وأن يكون طول كل سطر متساويًا. هذا واضح تمامًا. لكن تخيل الصعوبة التي ستنشأ إذا كان تطبيق الطلبات يعمل على منتجات تتكون من حزم من المنتجات الفرعية (مثل منتج وصول إلى الإنترنت عريض النطاق يتكون من خط نحاسي، ومودم، ومجموعة من المرشحات، ومحول نطاق عريض)، بينما يتوقع تطبيق الفوترة سطر منتج/طلب واحد فقط. إن محاولة تحويل المنتجات الهرمية إلى منتجات غير هرمية دون فقدان المعلومات أمرٌ غير ممكن. يوفر نموذج معلومات موحد للبيانات المشتركة بين التطبيقات حلاً لهذه المشكلة. يُطلق على حل TMF لهذا الغرض اسم نموذج المعلومات/البيانات المشترك (SID).

خلال منتصف ثمانينيات القرن الماضي، طُوّرت أنظمة دعم العمليات الحاسوبية كتطبيقات مستقلة. إلا أنه في أوائل التسعينيات، اتضح أن استخدامها كتطبيقات معزولة تمامًا غير فعال، إذ يؤدي، على سبيل المثال، إلى تلقي الطلبات على نظام، ثم إعادة إدخال البيانات في نظام آخر لتكوين معدات الشبكة ذات الصلة. وقد أظهرت الدراسات إمكانية تحقيق مكاسب كبيرة في الكفاءة من خلال ربط أنظمة دعم العمليات المستقلة معًا، مما يسمح بميزات مثل "التزويد التلقائي"، حيث يمكن تقديم الطلب عبر الإنترنت، ليتم تزويد المعدات تلقائيًا دون أي تدخل بشري.

لكن بالنسبة للمشغلين الكبار الذين يمتلكون مئات من أنظمة دعم العمليات المنفصلة، ​​أصبح انتشار واجهات الربط مشكلة خطيرة. إذ يحتاج كل نظام دعم عمليات إلى التواصل مع العديد من الأنظمة الأخرى، مما يؤدي إلى زيادة عدد واجهات الربط بمربع عدد أنظمة دعم العمليات.

يصف إطار عمل Frameworx استخدام بنية اتصالات مشتركة (CCI). في هذا النموذج، تتفاعل أنظمة دعم العمليات (OSSs) مع بنية الاتصالات المشتركة (CCI) بدلاً من التفاعل المباشر فيما بينها. وبذلك، تسمح بنية الاتصالات المشتركة (CCI) للتطبيقات بالعمل معًا باستخدامها لربطها ببعضها. وبهذه الطريقة، يحتاج كل تطبيق إلى واجهة واحدة فقط (مع بنية الاتصالات المشتركة) بدلاً من واجهات متعددة (مع التطبيقات الأخرى). وبالتالي، ينخفض ​​التعقيد إلى مستوى واحد من الرتبة n، بدلاً من ^n² .

قد تقدم مؤسسة الاتصالات الكندية خدمات أخرى أيضاً، بما في ذلك الأمن وترجمة البيانات وما إلى ذلك.

بالنظر إلى الوصف أعلاه لكيفية تفاعل التطبيقات مع CCI، فمن الواضح أننا بحاجة إلى طريقة لتوثيق هذه الواجهات، سواء من حيث التقنية المستخدمة (على سبيل المثال، هل هي Java/JMS أم خدمات الويب/SOAP؟) ولكن أيضًا من حيث وظائف التطبيق، والبيانات المستخدمة، والشروط المسبقة واللاحقة، وما إلى ذلك. توفر مواصفات عقد Frameworx وسيلة لتوثيق هذه الواجهات، وبالتالي فهي واجهات محددة بموجب العقد.

يمكن اعتبار عقود Frameworx بمثابة امتدادات لمواصفات واجهة برمجة التطبيقات (API).

يُعد eTOM (خريطة عمليات الاتصالات المحسّنة، تُنطق إي-توم) إطار عمل عمليات الأعمال الخاص بـ Frameworx.

معلومات Frameworx هي نموذج المعلومات/البيانات المشتركة (SID).

يهدف نموذج دورة حياة Frameworx إلى تحديد استخدام ونشر Frameworx داخل المؤسسة، ويوفر إطار عمل لاستخدام SID وeTOM وبنية Frameworx. يستند النموذج إلى أعمال سابقة هامة، بما في ذلك إطار عمل Zachman ، و Kernighan ، و Yourdon ، وهندسة النماذج الموجهة لمجموعة إدارة الكائنات . تقسم دورة حياة Frameworx تطوير الأنظمة إلى أربع مراحل: المتطلبات، وتصميم النظام، والتنفيذ، والتشغيل.

كما ذُكر سابقًا، يُعدّ عقد Frameworx الوحدة الأساسية للتوافق التشغيلي في نظام Frameworx. ويُعدّ التوافق التشغيلي مهمًا لكلٍّ من وجهات النظر الأربع المحددة في دورة حياة Frameworx. فعلى سبيل المثال، يُستخدم العقد لتحديد الخدمة المطلوب تقديمها، بالإضافة إلى تحديد المعلومات والبرمجيات اللازمة لتنفيذها. كما يُستخدم العقد أيضًا لمراقبة الخدمة وإدارتها وصيانتها، ولضمان الوفاء بأي التزامات خارجية للعقد (مثل اتفاقية مستوى الخدمة)، ولتحديد الإجراءات الواجب اتخاذها في حال انتهاكها.

يُعد إطار التطبيقات (المعروف رسميًا باسم خريطة تطبيقات الاتصالات (TAM)) أحد العناصر الأساسية لـ Frameworx. وهو يُراعي دور ووظائف التطبيقات المختلفة التي تُوفر إمكانيات نظام دعم العمليات (OSS) ونظام دعم الأعمال (BSS ).

وبذلك، فإنه يمكّن من كتابة وثائق الشراء بالرجوع إلى الإطار، مما يوفر بيانات واضحة لا لبس فيها عن الوظائف المطلوبة لأي تطبيق معين، وتحديد التداخلات الوظيفية للتطبيقات الحالية، مما يسهل الترشيد وتحديد الثغرات الوظيفية.

إن مستوى التفكيك الوظيفي يسمح بتحقيق هذه الفوائد دون أن يكون مفرطاً في التقييد.

يتبنى منتدى إدارة العلامات التجارية تعريفًا دقيقًا للعمليات والبيانات. يوفر إطار التطبيقات طريقة رسمية لتجميع الوظائف والبيانات في مكونات معترف بها، والتي يمكن اعتبارها قابلة للتوريد إما كتطبيقات أو خدمات. يمكن أن يكون التطبيق أو الخدمة (مثل خدمات الويب) برنامجًا عامًا نسبيًا يُنفذ وظائف/عمليات ويتعامل مع البيانات أو يستخدمها. في حياتنا اليومية، نرى تطبيقات مثل معالجات النصوص أو برامج البريد الإلكتروني؛ وفي مصطلحات البرمجيات مفتوحة المصدر، نعتبر التطبيق مكونًا من مكونات إدارة علاقات العملاء، أو نظام فوترة، أو حلًا لإدارة المخزون - مع العلم أنه يمكن تجزئة هذه المكونات إلى حد ما - على سبيل المثال، يتضمن نظام الفوترة عددًا من التطبيقات الأصغر، مثل محرك تقييم.

يُعرَّف "التطبيق" بأنه مجموعة من عنصر برمجي واحد أو أكثر، تتضمن وظائف وبيانات وتدفقات أعمال وقواعد وواجهات محددة جيدًا. ويشمل ذلك نموذج بيانات، للبيانات المستخدمة في التفاعل مع التطبيق وداخله، وسياسات، لإدارة موارد التطبيق الخارجية والداخلية، ونموذج تدفق، للوظائف داخل التطبيق، ومواصفات تعاقدية للواجهات الخارجية المرئية للوظائف داخل التطبيق.

يمكن تنفيذ التطبيقات كحزم قابلة للنشر ويمكن شراؤها من سوق الأنظمة.

لا يُعد إطار التطبيقات جزءًا من تعريفات إطار المعلومات أو إطار عمليات الأعمال (eTOM)، ولكنه يرتبط بكليهما بطريقة سهلة الفهم، كما يوفر أيضًا ربطًا بينهما.