هدف از معماری سازمانی

مقدمه‌ای بر چشم‌انداز معماری سازمانی

چارچوب TOGAF از مفهومی به نام «چشم‌انداز معماری سازمانی» (EA Landscape) استفاده می‌کند تا به مجموعه کامل توصیف‌های مربوط به معماری سازمانی (EA) اشاره کند. این راهنما چشم‌انداز معماری سازمانی را از خود معماری سازمانی متمایز می‌کند، زیرا در یک چشم‌انداز جامع معماری سازمانی، یک توصیف واحد وجود نخواهد داشت. در هر مقطع زمانی، یک سازمان معمولی چندین معماری توصیف‌شده خواهد داشت. برخی از این معماری‌ها نیازهای بسیار خاصی را برطرف می‌کنند؛ برخی دیگر عمومی‌تر هستند. بعضی به جزئیات می‌پردازند و برخی تصویر کلی را ارائه می‌دهند. برخی موضوعات یکسانی را در حالت‌های مختلف (وضعیت کنونی، هدف، و انتقالی) یا دوره‌های زمانی متفاوت بررسی می‌کنند. برای مدیریت این پیچیدگی، استاندارد TOGAF چارچوبی برای سازمان‌دهی چشم‌انداز معماری سازمانی ارائه می‌دهد. چشم‌انداز معماری سازمانی، مرز تمام معماری‌های بالقوه را همراه با محدودیت‌ها و راهنمایی‌های مرتبط مشخص می‌کند.

ویژگی‌های متعددی می‌توانند برای سازمان‌دهی چشم‌انداز معماری سازمانی استفاده شوند. یک مفهوم اساسی که باید درک شود این است که هر ابتکاری برای توسعه و نگهداری معماری سازمانی، بخشی از چشم‌انداز معماری سازمانی را پر می‌کند. با گذشت زمان و از طریق اقدامات متعدد، چشم‌انداز معماری سازمانی پر شده و به‌روز می‌شود. بسیاری از توضیحات درباره تکرار در چارچوب TOGAF برای پرداختن به این نکته طراحی شده‌اند.

به جای در نظر گرفتن تکرار به‌عنوان بازترتیب و حلقه‌زدن در روش توسعه معماری (ADM)، مفهوم پروژه معماری در TOGAF را با مفهوم چشم‌انداز معماری سازمانی ترکیب کنید. هر پروژه معماری به‌طور آگاهانه فقط بخشی از چشم‌انداز معماری سازمانی را که برای رفع نیاز فعلی کافی است، توسعه می‌دهد. این توسعه در چارچوب معماری‌های قبلی انجام می‌شود که کار کنونی را هدایت یا محدود می‌کنند. هر پروژه معماری، اجزایی را در چشم‌انداز معماری سازمانی ایجاد، اصلاح و احتمالاً تغییر می‌دهد.

وقتی چشم‌انداز معماری سازمانی پر شود، حاوی توصیف، محدودیت‌ها یا راهنمایی‌هایی است که می‌توان از آن‌ها استفاده کرد. بدون انجام جمع‌آوری مکرر اطلاعات، تحلیل، بازبینی و تأیید، متخصص (پرکتیشنر) نمی‌تواند با اطمینان پیش برود. تصمیمات، راهنمایی‌ها و محدودیت‌های موجود، توسعه معماری کنونی را آگاه می‌سازند. بهترین عمل، جمع‌آوری اطلاعات و تحلیل را به حداقل لازم برای پاسخ به سؤال مورد نظر محدود می‌کند. تلاش صرف‌شده برای معماری سازمانی زمانی بیشترین ارزش را بازمی‌گرداند که از معماری سازمانی استفاده شود. معماری سازمانی تا زمانی که معمار کار خود را «تمام» نکند، قابل استفاده نیست. تمام توسعه معماری باید در برابر زمان ورود به بازار (TTM) ارزیابی شود. پر کردن فقط بخش‌های مورد نیاز چشم‌انداز معماری سازمانی و پیروی از محدودیت‌ها و راهنمایی‌های موجود، TTM را تسریع می‌کند.

چهار ویژگی مستقل رایج، چارچوب چشم‌انداز معماری سازمانی را شکل می‌دهند:

گستردگی (Breadth): موضوعی که یک پروژه معماری پوشش می‌دهد. گستردگی ممکن است گیج‌کننده به نظر برسد، زیرا می‌تواند به طیف وسیعی از موضوعات اشاره داشته باشد. به‌عنوان مثال، حوزه، سازمان و ابتکار را در نظر بگیرید. گستردگی می‌تواند سلسله‌مراتبی از موضوعات خاص باشد. برای مثال، یک سازمان می‌تواند از طریق سلسله‌مراتب سازمانی تجزیه شود. موضوعات انعطاف‌پذیر هستند. برای مثال، پرداختن به یک ابتکار خاص شامل تمام سازمان‌های تحت تأثیر خواهد بود و یک سازمان تمام ابتکارات تحت تأثیر را در بر می‌گیرد. گستردگی یکی از مهم‌ترین ابعاد تعیین محدوده است. این به متخصص زمینه تحلیل خود را ارائه می‌دهد.

سطح جزئیات (Level of Detail): سطح جزئیات باید خود-توضیح باشد. به‌راحتی می‌توان در دام کاوش و شرح مداوم در محدوده یک حوزه، سازمان یا ابتکار افتاد. با توسعه معماری‌ها، به اندازه‌ای که برای پاسخ به سؤال مورد نظر لازم است، شرح دهید. پاسخی که به اندازه کافی خوب باشد تا از یک تصمیم پشتیبانی کند یا جهت‌گیری را هدایت کند، برای پیشرفت کافی است. همیشه به کمترین جزئیات مورد نیاز برای تحقق هدف پروژه معماری توسعه دهید. همیشه در نظر داشته باشید که کار بر روی معماری با جزئیات بیشتر توسط معماری با جزئیات کمتر یا معماری برتر هدایت و محدود می‌شود. در نهایت، هرچه جزئیات بیشتری لازم باشد، TTM طولانی‌تر خواهد بود. جمع‌آوری، تحلیل، توصیف و تأیید جزئیات زمان‌بر است.

شکل 1: ویژگی‌های چشم‌انداز معماری سازمانی

زمان: هر پروژه توسعه معماری دارای یک افق برنامه‌ریزی خواهد بود؛ نقطه‌ای در زمان که انتظار دارید به معماری هدف (Target Architecture) برسید. زمان چالش‌هایی ایجاد می‌کند زیرا آینده در حال تغییر است. به طور معمول، هرچه افق برنامه‌ریزی طولانی‌تر باشد، معماری کمتر جزئیات دارد. این اغلب درست است اما یک قاعده جهانی ارائه نمی‌دهد. در نهایت، باید دقت شود در مواردی که یک یا چند معماری انتقالی قبل از رسیدن به افق برنامه‌ریزی وجود دارد. معماری با جزئیات بیشتر باید به دقت با راهنمایی‌ها و محدودیت‌های فعال در آن نقطه زمانی مطابقت داشته باشد. این می‌تواند چالش‌برانگیز باشد زیرا راهنمایی‌ها و محدودیت‌ها در حالت‌های انتقالی مختلف تغییر می‌کنند.

تازگی (Recency): هر توصیف، مشخصات و دیدگاه معماری در یک نقطه زمانی ایجاد شده است. آن‌ها همیشه با هدفی ساخته می‌شوند، با توجه به حداقل جمع‌آوری اطلاعات و تحلیل برای پاسخ به سؤال مورد نظر. همه معماری‌های سازمانی با گذر زمان قدیمی می‌شوند، گاهی به آرامی و گاهی به طور ناگهانی. تازگی نشانه‌ای است که ممکن است معماری سازمانی قبلی نیاز به بازبینی داشته باشد و یا تأیید مجدد شود یا جایگزین گردد. یک مخزن خوب می‌تواند بین معماری در حال توسعه، معماری تأییدشده، معماری محقق‌شده و معماری تأیید مجدد شده تمایز قائل شود. در طول دوره توسعه، معماری ممکن است بسیار به‌روز باشد، اما برای مدیریت معتبر نباشد. بدون تأیید، باید صرفاً به‌عنوان سرنخ در نظر گرفته شود. تازگی می‌تواند به‌عنوان عاملی برای سازمان‌دهی معماری‌های تاریخی استفاده شود.

نقطه اساسی این است که باید تشخیص داد محتوای چشم‌انداز معماری سازمانی تنها در صورت نیاز توسعه می‌یابد. پس از تأیید، این محتوا تمام توسعه‌های بعدی معماری سازمانی و استفاده از آن را محدود می‌کند. برای بحث گسترده‌تر درباره زمان، توالی و چرخه کسب‌وکار، به بخش 5.3 مراجعه کنید.

ابعاد چشم‌انداز معماری سازمانی به ما کمک می‌کنند تا درباره معماری سازمانی فکر کنیم. به خاطر داشته باشید که در اکثر موارد، ساختن یک ساده‌سازی که معتبر نباشد آسان است. پروژه‌های معماری، مکعب‌های منظمی مشابه آنچه در شکل 2 نشان داده شده نیستند. یک نمایش واقعی بیشتر شبیه یک جوجه‌تیغی دریایی خواهد بود – مرکزی یکپارچه اما با خارهایی که در همه جهت‌ها بیرون زده‌اند.

شکل 2: چشم‌انداز معماری سازمانی با یک پروژه معماری

با نگاه به شکل 2، نکته اساسی این است که پروژه معماری بخش خاصی از چشم‌انداز معماری سازمانی را پوشش می‌دهد – بخشی که از نظر گستردگی، افق برنامه‌ریزی و سطح جزئیات تعریف شده است. ممکن است کارهای قبلی در این محدوده از قبل وجود داشته باشد. این مثال نه کم‌دقت‌ترین و نه پرجزئیات‌ترین لایه‌ها را پوشش می‌دهد، و نه همه دوره‌های زمانی یا موضوعات را شامل می‌شود. بلکه این مثال به بخش خاصی از چشم‌انداز می‌پردازد. پروژه معماری نمونه، بخشی از چشم‌انداز معماری سازمانی را پر می‌کند یا به‌روزرسانی می‌کند. از آنجا که کارهای سطح بالاتری وجود دارد، تمام فعالیت‌ها در پروژه معماری تابع معماری برتر خواهد بود. این مثال در سطح خاصی از جزئیات متوقف می‌شود، بنابراین متخصص (پرکتیشنر) باید سطح جزئیات را محدود کند. در نهایت، این مثال در چارچوب افق برنامه‌ریزی کل سازمان قرار دارد و توسط آنچه در این افق می‌توان و باید انجام شود، محدود می‌شود.

زندگی ما را پیچیده‌تر می‌کند این واقعیت که معماری برتر ممکن است به صورت یک هدف تحقق‌نیافته، یک حالت انتقالی تحقق‌نیافته، یا یک وضعیت کنونی تحقق‌یافته وجود داشته باشد. همیشه باید در نظر داشت که در جایی که تغییر صریحی در معماری برتر وجود ندارد، وضعیت کنونی احتمالاً همچنان معتبر است. در نهایت، این پروژه معماری زیرمجموعه‌ای از گستردگی بالقوه محدوده چشم‌انداز معماری سازمانی است. زمان ورود به بازار (TTM) ویژگی کلیدی یک معماری مفید است؛ متخصصان باید به محدوده (گستردگی، زمان، جزئیات) آنچه از آن‌ها خواسته شده پایبند بمانند. کار خارج از محدوده ممکن است جالب باشد، حتی شاید در آینده مورد نیاز شود، اما در چارچوب این ابتکار معماری قرار ندارد.

انرژی و کارایی یک تیم معماری سازمانی زمانی کاهش می‌یابد که سعی کند با انجام بیش از حد در هر گفت‌وگویی حضور داشته باشد. ساختار درخواست کار معماری در TOGAF، که به‌عنوان ورودی فاز A وجود دارد، برای محدود کردن پروژه معماری کنونی طراحی شده است. درخواست کار معماری به تیم معماری سازمانی می‌گوید که در چارچوب چشم‌انداز معماری سازمانی موجود، سازمان به دنبال یک معماری هدف است که مجموعه خاصی از موضوعات را با سطح جزئیات لازم، و در افق برنامه‌ریزی مشخصی که قابل دستیابی باشد، پوشش دهد. خروجی اساسی پروژه معماری، پر کردن، جایگزینی یا تأیید مجدد محتوای چشم‌انداز معماری سازمانی است. هنگامی که ذی‌نفعان هدف را بپذیرند، تمام کارهای بعدی معماری سازمانی، برنامه‌ریزی تغییر و اجرای تغییر توسط معماری تأییدشده مدیریت می‌شود.

برگرفته از: https://pubs.opengroup.org/togaf-standard/adm-practitioners/adm-practitioners_3.html