رشيقة يعلمنا المعنى الحقيقي للهندسة المعمارية

صورة

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

رشيقة وما يقوله عن العمارة


تم ذكر العمارة رسميًا في بيان Agile ، الذي ينص على أن أحد المبادئ الأساسية هو: "إن أفضل البنى والمتطلبات وقرارات التصميم تولد في فرق ذاتية التنظيم".
تظهر أفضل الهياكل والمتطلبات والتصميمات من فرق التنظيم الذاتي.
(من: مبادئ البيان الرشيق )

المشكلة ليست فقط أنها لا تعطي تعريفًا لما هي العمارة ، ولكن فقط من أين تأتي ، ولكن أيضًا أنها ساذجة إلى حد ما .

ليس لدى Agile مؤيدون جادون فقط (وأنا أعتبر نفسي من بينهم) ، ولكن أيضًا نصيبها العادل من المتعصبين الذين يميلون إلى الاعتقاد (ويجبرون في بعض الأحيان قيادتهم على الاعتقاد) أن "العمل على رشيقة" يمنحك بعض القدرة اللانهائية على التغيير و أنه يمكنك إجراء جميع أنواع التغييرات ، بما في ذلك التحويلات الكبيرة. حتى أن لدينا أطر عمل كبيرة إلى حد ما مثل إطار Agaled Agile Framework (SAFe) ، والذي يمكن تطبيقه للتغييرات بناءً على المبادئ المرنة لأعلى المستويات الاستراتيجية.

هذه الأطر لها شيء مشترك مع الأطر الشاملة التي تم إنشاؤها في وقت سابق (FEAF ، MODAF ، TOGAF ، وما إلى ذلك). لا أحد يستخدم كل شيء حقًا. عادة ما لا يفهم جميع أولئك الذين يعملون في سياقها الضيق نطاق الأطر بسهولة. يبدو لي أن أسس ممارسات العمل الحالية قد تم استنتاجها لإنشاء إطار كامل. على الرغم من أن "الحشو" لم يتم اختباره مطلقًا ، إلا أنه يتم بيع كل شيء بالكامل على أنه "أفضل ممارسة".

دعونا نلقي نظرة على TOGAF و SAFe ، فهم يعتمدون بشدة على عالم تطوير التطبيقات. ويتضح ذلك عندما يقوم TOGAF على أساس واحد من تعريفين للهندسة المعمارية على تعريف بنية برمجيات ISO.
– , , .
(: ISO/IEC/IEEE 42010:2011)

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

في حين يمكن رؤية الأطر الكبيرة بعين نقدية ، فإن مفهوم Agile نفسه (وإن لم يكن جديدًا) هو في الواقع إجابة عملية للغاية (على الأقل جزئيًا) للتعقيد ، وقبل كل شيء ، للتغير. رشيقة هي رد فعل لمعظم التغييرات والتحولات في المنظمات المعقدة اليوم. التعقيد لأن تكنولوجيا المعلومات سمحت بالتعقيد . التباين ، لأنه مقارنة بالمصانع المليئة بالمعدات الثقيلة ، من السهل جدًا تغيير تكنولوجيا المعلومات. لا يزال البرنامج ، وحتى الأجهزةليس لديها مثل هذه الخدمة ، على سبيل المثال ، مثل جدران المبنى. تنتج المنظمات المعقدة اليوم تغييرات مستقلة أكثر من المنظمات "الورقية" في الماضي. أصبح الشلال الذي يتميز بتصميم Big Up-Front Design (BUFD) غير عملي إلى درجة أنه أصبح من المستحيل تقريبًا في عالم اليوم الذي يحمل عبء تكنولوجيا المعلومات. وبالتالي ، نحصل على تطور موازٍ جماعي دائم في منظماتنا على أساس العديد من الفرق (الرشيقة) التي تعمل بالتوازي.
, - . - , , , . - — , — .
( , )



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



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

لكن التعريف الذي يناسب مشاعري هو أن مارتن فاولر ، في مقاله المعروف على نطاق واسع عام 2003 ، " من يحتاج إلى مهندس معماري؟"". هناك ، أنهى تعريف الهندسة المعمارية بأنها "أشياء يصعب تغييرها". هذا لا يختلف عن تعريف Grad Buch ، الذي قال:

كل العمارة هي قرارات التصميم ، ولكن ليست جميع قرارات التصميم هي الهندسة المعمارية. تمثل العمارة قرارات مهمة تشكل نظامًا حيث تقاس الأهمية بتكلفة التغيير.

(ملاحظة: الاقتباس الأكثر اكتمالا لديه نقطة جيدة حول "العلم والفن"). أعتقد أيضًا بقوة أن العمارة ، في النهاية ، ليست أكثر من قرارات تصميم ، وأن الرغبة في فصلها حقًا تأتي جزئيًا من "[الرغبة] في الحديث عن قرارات التصميم ، ولكن [الرغبة] في تضخيمها بحيث لقد بدوا مهمين "(فاولر). وهكذا، في لدينا عالم الهندسة المعمارية، يمكننا أن نقول:العمارة هي قرارات التصميم التي يصعب تغييرها . بالطبع ، من الصعب حقًا تغييرها فقط عندما تم تنفيذها. ستتحمل الورقة كل شيء ، وستتغير الحروف بسهولة (ما لم تكن في مناقشة معمارية جهنمية عمرها 6 أشهر). لكن الهندسة المعمارية ، كمقياس لأهمية قرارات التصميم ، هي تعريف جيد ، وأفضل بكثير من ISO ، ArchiMate ، TOGAF ، إلخ.

ومع ذلك ، هناك دقة مع خاصية "من الصعب التغيير".

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

العمارة - قرارات التصميم التي يصعب إزالتها تمامًا من عمليات التنفيذ.

(على الرغم من أن تقلص فاولر "صعب التغيير" في معظم الحالات). ملاحظة أخرى بخصوص "يصعب تغييرها" ، قد يكون من الصعب إزالتها بسبب الاعتماد على الآخرين ، وبالتالي فإن معنى كلمة "تنفيذ" واسع ، على سبيل المثال ، تغيير كل من الشركات المصنعة والمستهلكين للخدمة. يجب دائمًا اعتبار "ثقيل" من منظور مؤسستك ، وهو مثال جيد على سبب كون منطقة العمارة عادة ما تكون أوسع من منطقة الحل أو المشروع أو المنتج.
ملاحظة: 1) هذا التعريف لا يعتمد على تكنولوجيا المعلومات. 2) يمكن القول أنه بهذه الطريقة كشفت عن معنى كلمة "أساسية" في تعريف "العمارة" وفقًا لـ ISO.

رشيقة وعمارة ، نهايات مختلفة من نفس المقياس


اتضح وجود علاقة مثيرة للاهتمام للغاية بين عالم Agile وعالم الهندسة المعمارية. تم تصميم Agile لإجراء التغييرات قدر الإمكان ، لجعل التغييرات سهلة (أو على الأقل ليست صعبة ). ومن ناحية أخرى: الهندسة المعمارية ، كما لاحظنا ، هي حيث تكون التغييرات صعبة . بعبارة أخرى ، هم في الطرف الآخر من الطيف ؛ هم تأرجح أساسي في مؤسستك.

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

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

إذن ، أين نجد الهندسة المعمارية ، وأين يقع أجيل في ورطة؟ هناك العديد من الأمثلة الواضحة:

  1. feature/defect «», , . ( , , ESB ), . , . , , ( ), .
  2. Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
  3. Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

أعتذر عن استخدام المصطلحات اليابانية بحرية هنا. وهكذا ، يركز Agile على حقيقة أن الهندسة المعمارية هي كائن وليس ممارسة ، ولكن العقل يقول:

الهندسة المعمارية هي كل قرار تصميم مطبّق يجعل Agile صعبًا.

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

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

تعلم المزيد عن REF وممارسة العمارة والديون.في الجزء الثاني ، لكنني تذكرت مقطع الفيديو "لماذا هندسة المؤسسات" ، الذي أنشأناه قبل سنوات عديدة ، في الوقت الذي جعلنا الهندسة المعمارية أكثر مرونة في عالم BUFD:


استمع إلى طبيبك والمحامي


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

All Articles