مقايسه "مدل هاي معماري سازماني" با "فراورده هاي توسعه نرم افزار" – جان زكمن

اخيرا مشاهده كرده ام كه بين " فراورده هاي(مدل ها) معماري سازماني" با " فراورده هاي فرايند توليد و توسعه نرم افزار" تداخلي صورت گرفته و گروهي قادر به تمايز بين اين دو مفهوم نيستند. دلايل زيادي براي اين موضوع وجود دارد، يك دليل مربوط به عصر گذشته(عصر صنعت) است كه هنوز معماري سازماني معنا نداشت، بطوريكه برخي افراد معماري را يك توصيف سطح بالا از سيستم يا موضوعي منطقي در تقابل با جنبه فيزيكي مي دانستند و يا عده اي آنرا همان ابزار و لوازم مي پنداشتند و سرانجام گروهي هم معماري را همان اصول كار قلمداد مي كردند. اما دليل اصلي براي تداخل دو مفهوم، شباهت محصولات به يكديگر بود.

ابتدا به بررسي بيشتر معماري سازماني مي پردازيم. معماري سازماني مجموعه اي از فراورده هاي توصيفي(مدل) پايه است كه حاوي زيربنا و شالوده كل سازمان است. اين توصيف براي اينكه ساده، قابل فهم و خلاصه باشد به صورت تصويري (اشكال) به نمايش در مي‌آيد، تصوركنيد بجاي هر مدل تصويري، مي بايست به حجم زيادي از متن حاوي توضيحات و مشخصات رجوع مي كرديد، مسلما كاري سخت و خسته كننده بود.
مزاياي اين مدلها سبب مي شود به اين سمت برويم كه تمام اين مدلها (چارچوب زكمن) را بصورت دقيق و صريح توليد كنيم، چرا كه اين مدلها مي توانند پيچيدگي و تغييرات سازمانهاي بزرگ امروزي را مهار كنند. البته در حال حاضر، تمام اين مدلها ممكن است توليد نشوند. توجه به اين نكته ضروري است كه اين مدلها بايد توصيفي از "عملكرد كل سازمان" باشند و نه مربوط به يك "پياده سازي" خاص. به همين دليل است كه اين مدلها را "شالوده" سازمان گويند چراكه از تركيب و الحاق انها مي توان براي هر كاربردي (پياده سازي) استفاده كرد.
حال نگاهي به فراورده هاي توسعه نرم افزار مي اندازيم. اين محصولات كه مي توانند مدل هم باشند، به عنوان ورودي يا خروجي، طي فرايند توليد و توسعه نرم افزار براي يك كاركرد(پياده سازي) خاص استفاده مي شوند. از اين فراورده ها نمي توان در ديگر بخش هاي سازمان يا ديگر پياده سازي ها استفاده كرد. همچنين با تغيير در بخش مربوطه، اين فراورده ها هم بايد تغيير كنند. سئوال مهم اين است كه فراورده هاي توسعه نرم افزار از مدلهاي معماري سازماني مشتق شده اند و يا به صورت اختصاصي براي كاركرد خاص خود تهيه شده اند؟
اگر فراورده هاي توسعه نرم افزار، مشتق شده باشند، در اينصورت هر زمان كه بخواهيم مي توانيم از مدلهاي پايه اي تركيب جديدي را تهيه كنيم، امكان استفاده مجدد بالا مي رود و تعامل پذيري بين فراورده ها تضمين مي شود(چون همگي از مدل هاي پايه مشتق شده اند). در غير اينصورت(براي كاركرد هاي خاص تهيه شده باشند)، استفاده مجدد از انها براي ساير پياده سازيهاي سازمان ممكن نيست، اصلاح و تغيير آنها مساوي با توليد مجدد است و تعامل پذيري با ساير كاركردها تضمين نمي شود.
بهتر است قبل از ادامه بحث، مفهوم "استفاده مجدد" را روشن كنيم و ابهام آن را بر طرف كنيم. منظور از قابليت استفاده مجدد يك شيء، استعمال آن در "زمينه" و "حوضه" ديگر نيست، يعني قرار نيست فراورده هاي قابل استفاده مجدد، در سازمانها و كاركردهاي مختلف استفاده شوند، بلكه فقط در همان سازمان و همان كاركرد مربوط مي توانند قابل استفاده مجدد باشند. براي مثال، يك كارگاه توليد كاربراتور را در نظر بگيريد، آيا مي توان انتظار داشت كه محصولات اين كارگاه براي انواع مدلهاي ماشين فورد يا "فيات" يا ... قابل استفاده باشد؟ مسلما نه! كاربراتوري كه شما مي سازيد فقط مناسب يك نوع موتور مي باشد، پس "استفاده مجدد" چه مفهومي دارد؟ پاسخ اين است كه "قابليت استفاده مجدد" مربوط مي شود به چگونگي ساخت كاربراتور، اگر كاربراتور از سوار كردن(الحاق) عناصر پايه ساخته شود، تغييري مختصر در هر كدام از عناصر پايه، مي تواند كاربراتور را براي نوع موتور جديدي قابل استفاده كند بدون انكه كل خط توليد دچار تغيير و تحول شود، اما اگر كاربراتور بصورت يكدست ساخته شود تغييري اندك در آن مساوي با ساخت مجدد قالب(توليد مجدد) خواهد بود.
در خصوص اطلاعات نيز همين امر صادق است، اگر داده(يا فرايند يا عملكرد يا ساير موارد) براي يك كاركرد خاص توليد شده باشند، نمي توان آنها را در كاركرد هاي ديگر استفاده كرد، ولي اگر داده از تركيب و الحاق عناصر پايه معماري سازماني حاصل شده باشد، با تركيبات جديد مي توان كاركرد ها و پياده سازي هاي ديگر را نيز پوشش داد.
اما چالش اصلي مربوط به اين موضوع است كه چگونه مي توان فهميد يك مدل مشخص، از مدلهاي پايه اي معماري سازماني است يا يك مدل تك منظوره براي يك پياده سازي خاص.
اولين تست، تطبيق اين مدل با سلولهاي چارچوب زكمن است. بايد ببينيم آيا اين مدل دقيقا منطبق بر يكي از سلولهاي چارچوب است يا كه از تركيب چند سلول به دست امده است، به عبارت ديگر آيا مدل مورد نظر يك متغيير دارد(هر سلول يك متغيير است) يا چند متغيير؟
مدل تك متغيير به يكي از اشكال زير است:
مدلي از اشياء به صورت: شيء- رابطه – شيء (مدل معنائي)
مدلي از فرايندها به صورت: ورودي – فرايند – خروجي (مدل تبديل)
مدلي از مكانها به صورت: گره – مسير – گره (مدل شبكه يا اتصال)
مدلي از اشخاص به صورت: شخص – مسئوليت – شخص (مدل جريان كار)
مدلي از رخدادهاي زماني به صورت : رخداد – سيكل زماني- رخداد (مدل پويا)
مدلي از انگيزه به صورت: اهداف – روش ها- اهداف (مدل قوانين حرفه)

يك مدل تركيبي(با چند متغيير) از چندين مدل پايه (تك متغيير) تشكيل شده، براي مثال يك مدل تركيبي مي تواند شامل اطلاعاتي باشد كه توسط مسيرهايي به مكان هائي منتقل مي شود و فرايندهائي روي ان اعمال مي شود تا ... . پس اگر مدل مفروض، چند متغيير داشت، به طور قطع مربوط به فراورده هاي فرايند توسعه نرم افزار براي يك پياده سازي خاص بوده است.
تست بعدي مربوط مي شود به عناصر سازنده مدل است. بايد چك كنيم كه آيا عناصر سازنده و اوليه مدل ما از سلولهاي چارچوب بوده اند يا نه؟ يك مثال متداول مدلي است شامل اطلاعات، تعاريف و روابط بين آنها و فرايندي كه از اين اطلاعات استفاده مي كند. حال بايد تست كنيم كه "اطلاعات" مدل از يكي از مدلهاي پايه چارچوب استخراج شده يا كه مربوط به اطلاعات يك پياده سازي خاص است كه با فرايندهاي دخيل، تركيب شده؟
توجه كنيد كه فراورده هاي توسعه نرم افزار نه تنها زائد نيستند كه بسيار مفيد و ضروري هستند، اما جزو مدلهاي پايه نمي باشند. در عوض اين فراورده ها اگر مشتق از مدلهاي پايه سازمان باشند، داراي مزاياي زيادي هستند كه اشاره خواهد شد. در عوض اگر فراورده ها مشتق شده نباشند و بصورت انفرادي براي هر كاركرد(پياده سازي) خاص تهيه شوند مشكلات زير به وجودمي ايد:
انها تا زماني مفيد هستند كه تغييري اتفاق نيفتد، به محض تغيير در فرايندها(يا اطلاعات يا اشخاص يا ..) بايد فراورده را دور انداخته و نمونه جديدي را منطبق با وضع جديد از نو "توليد" كنيم.
فراورده ها ممكن است شما را گمراه كنند! چرا كه گاهي با مدل هاي پايه اشتباه مي شوند، در حاليكه فراورده هاي توسه نرم افزار، قابل استفاده مجدد نيستند، تمام جنبه ها و حوزه هاي سازمان را پوشش نمي دهند و خلاصه عنصر پايه براي مشتق شدن ديگر مدلها نيستند.
پيچيده هستند، چراكه داراي تعدادي شيء و رابطه هستند بدون اينكه عناصر اوليه اشياء و روابط مشخص باشد.
ديد شما را محدود مي كنند، مدل هايي هستند كه مي توانند داراي جايگزين هاي بهتري نيز باشند، ولي چون مدلهاي پايه موجود نيستند، حدس تركيبات ممكن از انها ممكن نيست.

تست آخر اينكه آيا مجموع مدل هاي مفروض تمام جنبه ها و حوزه هاي سازمان را در بر مي گيرد؟ اگر مدلهاي معماري براي محدوده اي از سازمان تهيه شده باشند، يا اگر بعد از ساخت آنها محدوده سازمان گسترش يابد، آنگاه اين مدل ها فقط در محدوده مذكور قابل استفاده مجدد مي باشند. مفهوم محدوده سازمان بسيار مهم است چرا كه چالش اصلي ما مربوط به "سازمان" است نه "سيستم ها". پس مشخص نمودن حوزه و محدوده سازمان و ساخت مدلهاي پايه براساس ديد سرتاسري به سازمان باعث بهره وري در زمان و هزينه شده، قابليت استفاده مجدد و تعامل پذيري را تضمين مي كند. هر سازمان مي بايست با ايجاد معماري سازماني به توليد تمامي مدل هاي پايه كه ديدي سرتاسري و همه جانبه از سازمان ارائه مي كنند، اقدام كند. اما مشكل اينجاست كه مديران زماني به اهميت اين موضوع پي مي برند كه با مشكلي برخورد كرده و نياز فوري و سريع به مدلهاي پايه دارند، اما مدلهاي پايه موجود نيستند و تهيه سريع انها هم ممكن نيست.
در اينجا لازم است توضيحاتي در خصوص چارچوب معماري سازماني بدهيم. چارچوب وسيله اي براي طبقه بندي و مدل هاي پايه سازمان است. بعضي به غلط مي خواهند محصولات توسعه نرم افزار را نيز در در چارچوب قرار دهند، در حاليكه چارچوب، انباره اي از هر چيز دلبخواه نيست! اگر قصد داريد محصولات كاري فرايند توسعه نرم افزار براي يك پياده سازي را طبقه بندي و مرتب كنيد مي توانيد از ابزار هاي مخصوص آن استفاده كنيد.

خلاصه مقاله:
براي "عصر صنعت" كه هدف آن اتوماسيون كارها و جايگزيني انسان با ماشين بود، چالش اصلي "سيستم ها" بودند و نياز ما "فراورده هاي فرايند توسعه نرم افزار" بود، در حاليكه در "عصر اطلاعات" چالش ما مهار پيچيدگي و تغييرات "سازمان" است و سازمانهاي موفق براي كاهش هزينه و زمان، انعطاف پذيري و تعامل پذيري نياز به "معماري سازماني" دارند. معماري سازماني شامل مجموعه كاملي از مدلهاي پايه است كه تمام جنبه ها و حوزه هاي سازمان را توصيف مي كنند و به عبارتي "شالوده" سازمان قلمداد مي شوند.
فراورده هاي توسعه نرم افزار با مدل هاي پايه معماري سازماني تفاوت دارند. معماري مجموعه اي از مدل هاي پايه است كه به عنوان عناصر اوليه شناخته مي شوند، در حاليكه فراورده هاي توسعه نرم افزار، مجموعه اي از تركيبات مدل هاي پايه براي كاركرد هاي خاص هستند.
هر دوي فراورده هاي توسعه نرم افزار و مدلهاي پايه ضروري و حتي مرتبط با هم هستند، ولي فراورده ها هرگز نمي توانند جايگزيني براي مدل هاي پايه باشند.
مطالب بیشتر در خصوص معماری سازمانی