TOGAF یک چارچوب سازمانی باز. این چارچوب خود یک مجموعه مستند از دانش است که شامل یک روش‌شناسی دقیق و مجموعه‌ای از ابزارهای پشتیبانی برای توسعه معماری‌های سازمانی می‌باشد. TOGAF 9.2 آخرین نسخه این چارچوب است.
- TOGAF توسط اعضای گروه باز (The Open Group) توسعه و نگهداری می‌شود که در تیمی به نام فروم معماری (Architecture Forum) کار می‌کنند. توسعه اولیه نسخه 1 TOGAF در سال 1995 انجام شد و نسخه‌های بعدی TOGAF این مجموعه دانش را گسترش و بهبود بخشیده‌اند.
- TOGAF از طریق تلاش‌های مشترک بیش از 300 عضو فروم معماری که نماینده برخی از شرکت‌ها و سازمان‌های پیشرو جهان هستند، توسعه یافته است – بنابراین این یک خلاصه عالی از شیوه‌های عمومی معماری سازمانی است.
- توسعه و نگهداری یک معماری سازمانی یک فرآیند پیچیده است که شامل ذینفعان و فرآیندهای تصمیم‌گیری متعدد می‌باشد. TOGAF با مستند کردن مشخصات معماری سازمانی، فرآیندها و محصولات کاری کمک می‌کند.
- با استفاده از TOGAF، سازمان‌ها می‌توانند یک معماری سازمانی منسجم توسعه دهند که نیازهای ذینفعان را منعکس کند، بهترین شیوه‌ها را اتخاذ کند و به نیازهای فعلی و نیازهای تجاری پیش‌بینی‌شده آینده توجه کند.
ADM چیست؟
روش‌شناسی توسعه معماری – که اغلب به عنوان اختصاری برای ADM شناخته می‌شود – یک فرآیند دقیق و مرحله به مرحله برای توسعه یا تغییر یک معماری سازمانی است.
ADM 10 مرحله را توصیف می‌کند که چرخه توسعه معماری را پوشش می‌دهد.
این مراحل عبارتند از:
- مرحله مقدماتی
- مرحله A: چشم‌انداز معماری
- مرحله B: معماری کسب‌وکار
- مرحله C: معماری سیستم‌های اطلاعاتی
- مرحله D: معماری فنی
- مرحله E: فرصت‌ها و راه‌حل‌ها
- مرحله F: برنامه‌ریزی مهاجرت
- مرحله G: پیاده‌سازی حاکمیت
- مرحله H: مدیریت تغییر معماری
- مدیریت الزامات معماری ADM
مرحله مقدماتی:
هدف اصلی مرحله مقدماتی شناسایی و تعیین قابلیت‌های معماری مورد نیاز سازمان است.
یک بخش کلیدی از این شناسایی این است که چه کاری باید انجام شود و چگونه باید آن را پیاده‌سازی کرد.به عنوان مثال، خروجی اصلی یک درخواست کار معماری استکه الزامات را مشخص می‌کند و تصمیم می‌گیرد که چه دامنه، ساختار، ابزار یا چارچوب معماری برای پشتیبانی از این کار نیاز است.
در این مرحله، TOGAF به گونه‌ای تنظیم می‌شود که نیازهای تکرار آینده ADM را برآورده کند. ما اصول بنیادی را تعریف می‌کنیم، توانایی معماری سازمانی و کسب‌وکار را برای ایجاد تغییرات مورد نیاز ارزیابی می‌کنیم و TOGAF را با سایر چارچوب‌های مدیریتی ادغام می‌کنیم. در این مرحله اقداماتی برای محدود کردن سازمان‌های تحت تأثیر تغییر پیشنهادی، شناسایی چارچوب حاکمیت و پشتیبانی صحیح، تعریف و ایجاد تیم و سازمان EA، شناسایی و ایجاد اصول معماری، سفارشی‌سازی TOGAF و سایر چارچوب‌ها و پیاده‌سازی ابزارها وجود دارد. در پایان این مرحله، تیم EA باید آماده باشد تا یک تکرار از چرخه ADM را دنبال کند. این به این دلیل است که مرحله مقدماتی در بالای نمودار ADM و خارج از حلقه اصلی مراحل A تا H نشان داده شده است.
مرحله A: چشم‌انداز معماری:
مرحله A یک بیانیه معماری واضح از کار ارائه می‌دهد که در تکرارهای ADM ارائه خواهد شد. همچنین یک چشم‌انداز از معماری سازمانی پیشنهادی ارائه می‌دهد. این حس جهت‌گیری در هدایت کار ADM در طول تکرار بسیار حیاتی است. این بیانیه کار معماریروش‌های کاری برای توسعه و پیاده‌سازی معماری که در چشم‌انداز معماری مشخص شده است را تعریف می‌کند. این چشم‌انداز است که خواسته‌های سطح بالا برای قابلیت‌ها و ارزش تجاری که معماری سازمانی پیشنهادی ارائه خواهد داد را فراهم می‌کند. با شروع از یک درخواست کار ساختمانی، مرحله A یک ابزار (این چشم‌انداز) برای فروش مزایای قابلیت پیشنهادی به ذینفعان و تصمیم‌گیرندگان درون کسب‌وکار ارائه می‌دهد. سناریوهای تجاری برای درک نیازهای تجاری و کمک به روشن کردن الزامات معماری که توسط عملکرد مورد نیاز است، استفاده می‌شود. این در بیانیه کار معماری مستند شده است که برای ایجاد توافق به منظور حمایت از معماری نهایی استفاده می‌شود. توافق زمانی حاصل می‌شود که سازمان حامی سند را امضا کند.
مراحل در مرحله A تماماً درباره تبدیل یک درخواست کار ساختمانی به یک بیانیه کار معماری واضح و اطمینان از این است که کسب‌وکار قادر، آماده، مایل و متعهد به ایجاد تغییرات معماری لازم است. این شامل ایجاد پروژه معماری، از جمله تعریف دامنه آن، و همچنین شناسایی و توضیح اصول معماری و کسب‌وکار است. مرحله A ذینفعان و نگرانی‌ها و الزامات آنها را شناسایی می‌کند و اهداف، محرک‌ها و محدودیت‌های کسب‌وکار را در مرحله مقدماتی شناسایی می‌کند. برای اطمینان از موفقیت، همچنین قابلیت‌های کسب‌وکار را ارزیابی می‌کند، آمادگی تحول کسب‌وکار را ارزیابی می‌کند و به هرگونه ریسک تحول رسیدگی می‌کند.
مرحله B: معماری کسب‌وکار:
TOGAF معماری سازمانی را به عنوان راهی برای بهبود قابلیت‌های کسب‌وکار در نظر می‌گیرد – به همین دلیل است که اولین مرحله توسعه معماری به معماری کسب‌وکار .
ADM از یک دیدگاه کسب‌وکار شروع می‌شود – نیازهای قوی کسب‌وکار در درخواست کار معماریدر مرحله مقدماتی و بیشتر به کار معماریو چشم‌انداز معماری بیانیهدر مرحله A.
یک هدف کلیدی در مرحله معماری کسب‌وکار، توسعه یک معماری کسب‌وکار هدف است که نشان می‌دهد چگونه سازمان چشم‌انداز معماری را تحقق می‌بخشد و به درخواست‌های کار معماری پاسخ می‌دهد. هدف دوم آن این است که ابتدا اجزای نقشه‌راه معماری کاندیدا را شناسایی کند تا شکاف بین معماری کسب‌وکار پایه و هدف را پر کند. TOGAF دانش معماری کسب‌وکار را به عنوان پیش‌نیاز کار معماری در سایر حوزه‌ها مانند داده‌ها، برنامه‌ها و فناوری در نظر می‌گیرد. معماری کسب‌وکار همچنین ارزش تجاری و بازگشت سرمایه تلاش‌های معماری را به ذینفعان کلیدی نشان می‌دهد. مدل‌های کسب‌وکار، مانند مدل‌های فعالیت یا فرآیند، مدل‌های مورد استفاده و کلاس، یا نمودارهای اتصال گره،
مراحل مشابهی برای هر سه مرحله توسعه معماری (B، C و D) دنبال می‌شود. مهم است که از هر مدل مرجع موجود استفاده مجدد شود و تمام خروجی‌ها برای پاسخگویی به دیدگاه‌های ذینفعان سفارشی‌سازی شوند. سپس معمار یک توصیف پایه و هدف از معماری کسب‌وکار توسعه می‌دهد و یک تحلیل شکاف انجام می‌دهد تا تعیین کند چگونه از یکی به دیگری منتقل شود.
مرحله C: معماری سیستم‌های اطلاعاتی:
TOGAF مرحله C – معماری سیستم‌های اطلاعاتی – را به دو بخش تقسیم می‌کند که توسعه داده‌ها و برنامه معماری‌ها. مستندات TOGAF یک فصل مقدماتی کوتاه دارد که هر دو حوزه را پوشش می‌دهد و سپس فصل‌های جداگانه‌ای برای داده‌ها و برنامه‌ها دارد. مانند سایر مراحل توسعه معماری (B&D)، هدف توسعه یک معماری سیستم اطلاعات هدف برای داده‌ها و برنامه‌ها است و شناسایی اجزای نقشه‌راه معماری کاندیدا بر اساس شکاف‌های بین معماری‌های پایه و هدف.
مرحله C همیشه شامل ترکیبی از معماری داده و برنامه است. مهم نیست که در کدام ترتیب ارائه شود، به شرطی که هر دو شامل شوند – برای هر دو رویکرد طرفدارانی وجود دارد. مراحل برای داده‌ها و برنامه‌ها بسیار مشابه است – مدل‌های مرجع، دیدگاه‌ها و ابزارها را انتخاب کنید؛ یک پایه توسعه دهید و سپس یک توصیف معماری پیدا کنید، یک تحلیل شکاف انجام دهید و اجزای نقشه‌راه کاندیدا را تعریف کنید؛ و به هر تأثیر در زمینه معماری رسیدگی کنید. پس از یک بررسی رسمی ذینفعان، معماری نهایی شد و یک سند تعریف معماری ایجاد شد.
تفاوت اصلی بین داده‌ها و برنامه‌ها موضوع است که در استفاده از مدل‌های مرجع، تکنیک‌ها و نمایش‌های معماری مختلف منعکس می‌شود. به عنوان مثال، معماری داده ممکن است از نمودارهای موجودیت-رابطه یا نمودارهای کلاس استفاده کند، در حالی که معماری برنامه ممکن است از نمودارهای ارتباطی برنامه یا نمودارهای مهندسی نرم‌افزار استفاده کند.
مرحله D: معماری فنی:
مرحله D مرحله‌ای از TOGAF است که معماری فنی برای پروژه معماری را توسعه می‌دهد. معماری فناوری ساختار و تعامل خدمات پلتفرم و اجزای فناوری منطقی و فیزیکی را توصیف می‌کند. مرحله D معماری فناوری هدف را توسعه می‌دهد که از اجزای داده و برنامه (توسعه یافته در مرحله C) پشتیبانی می‌کند و اجزای کسب‌وکار را امکان‌پذیر می‌سازد.
معماری‌های توسعه یافته در مراحل B، C و D برای تحقق چشم‌انداز معماری ترکیب می‌شوند – به نگرانی‌ها و درخواست‌های ذینفعان برای کارهای ساختمانی رسیدگی می‌کنند. مانند سایر مراحل توسعه معماری، مرحله D اجزای نقشه‌راه معماری کاندیدا را شناسایی می‌کند تا انتقال از پایه به هدف را امکان‌پذیر کند. مراحل در مرحله D تقریباً مشابه مراحل B و C هستند – تفاوت اصلی این است که تمرکز اکنون بر فناوری است. بنابراین، این شامل مدل‌های مرجع فنی و استانداردها یا اندازه‌گیری‌های فنی است – مانند عملکرد، قابلیت نگهداری، مکان و تأخیر یا در دسترس بودن.
شناسایی خروجی‌ها و تحویل‌ها برای کمک به ساخت معماری فنی که واقعاً از سیستم اطلاعات و معماری کسب‌وکار پشتیبانی می‌کند، مهم است. به دست آوردن دامنه مناسب می‌تواند بازگشت سرمایه را تسریع کند، در حالی که دامنه بیش از حد مانع از پیاده‌سازی موفق خواهد شد. این درباره استقرار خود فناوری نیست، بلکه درباره توسعه معماری فنی است که واقعاً به چشم‌انداز معماری و درخواست‌های کاری پاسخ می‌دهد.
مرحله E: فرصت‌ها و راه‌حل‌ها:
مرحله E نام خود را می‌گیرد – به دنبال فرصت‌هایی برای ارائه معماری هدف از طریق پیاده‌سازی یک راه‌حل خاص است. مرحله E اولین نسخه کامل از نقشه‌راه معماری را با ترکیب تحلیل‌ها و توصیه‌های مراحل توسعه ساختمان – B، C و D تولید می‌کند.
این مرحله بر روی چگونگی ارائه طرح متمرکز است. بنابراین، به ایجاد یک نقشه‌راه معماری نگاه می‌کند و بسته‌های کاری را در یک جدول زمانی برای دستیابی به معماری هدف فهرست می‌کند. زمانی که تغییر به قدری بزرگ باشد که امکان انتقال مستقیم از معماری پایه به معماری هدف وجود نداشته باشد، مرحله E منجر به یک رویکرد تدریجی می‌شود که شامل معماری‌های میانی یا انتقالی است. مرحله E تغییرات معماری مورد نیاز را به برنامه‌ها و پروژه‌های سرمایه‌گذاری با تأمین مالی و منابع برای اجرای بسته‌های کاری و ارائه معماری‌های انتقالی و هدفی نقشه‌برداری می‌کند. ورودی به این مرحله تقریباً همه چیزهایی است که از مراحل قبلی خروجی شده است. این مراحل آن خروجی‌ها را می‌گیرد؛ آنها را تجمیع می‌کند، وابستگی‌ها را تحلیل می‌کند و تفاوت‌ها را آشتی می‌دهد؛ و تأیید می‌کند که سازمان قادر به ایجاد تغییرات است. مرحله E الزامات، مستندات معماری و نقشه‌راه معماری را تصحیح و به‌روزرسانی می‌کند. یک خروجی کلیدی، اولین گام در یک برنامه پیاده‌سازی و مهاجرت است.
مرحله F: برنامه‌ریزی مهاجرت:
مراحل اولیه ADM نیاز به تغییرات معماری را شناسایی کرده و سپس معماری‌های کسب‌وکار، داده، برنامه و فنی را برای پشتیبانی از این نیاز توسعه می‌دهند. مرحله دوم سپس یک برنامه‌ریزی سطح بالا را توسعه می‌دهد. برنامه پیاده‌سازی و مهاجرت برای بهره‌برداری از فرصت‌های سرمایه‌گذاری و شناسایی راه‌حل‌های خاص. هدف معماری . مرحله F جزئیات را نهایی می‌کند برنامه پیاده‌سازی و مهاجرت ، و همچنین نقشه‌راه معماری نهایی.
همچنین اطمینان حاصل می‌کند که برنامه با رویکرد مدیریت تغییر استفاده شده در داخل سازمان و با سایر برنامه‌ها در سبد تغییر هم‌راستا است. در نهایت، مرحله F اطمینان حاصل می‌کند که ذینفعان کلیدی به طور کامل ارزش کسب‌وکار، هزینه بسته کاری و معماری انتقالی و آینده را درک می‌کنند. در حالی که مراحل اولیه ADM به شدت تحت هدایت تیم معماری سازمانی هستند، مراحل از E تا H نیاز به همکاری با سایر عوامل تغییر دارند. مرحله F به‌طور خاص نیاز دارد که چهار چارچوب مدیریتی به‌طور نزدیک با هم کار کنند تا برنامه پیاده‌سازی و اسکان مجدد موفق باشد. چهار حوزه عبارتند از:
- برنامه کسب‌وکار
- معماری سازمانی
- مدیریت سبد
- مدیریت پروژه
با همکاری، این چهار حوزه باید کار را اولویت‌بندی کنند و از معیارهایی مانند اندازه‌گیری عملکرد، بازگشت سرمایه، ارزش کسب‌وکار، عوامل موفقیت حیاتی، اندازه‌گیری‌های اثربخشی و تناسب استراتژیک استفاده کنند.
مرحله G: پیاده‌سازی حاکمیت:
توسعه و پیاده‌سازی واقعی به‌طور همزمان با مرحله G انجام می‌شود. مرحله G اطمینان حاصل می‌کند که پروژه پیاده‌سازی و همچنین سایر پروژه‌های در حال انجام با معماری تعریف شده مطابقت دارند.
به‌طور معمول، معماری هدف به‌عنوان یک سری انتقال‌ها توسعه می‌یابد تا ارزش کسب‌وکار و مزایا را هر چه سریع‌تر تحقق بخشد و ریسک را در برنامه تحول کاهش دهد. هر تحول نمایانگر یک گام به سمت شرکت هدف است و منافع کسب‌وکار خود را تحقق می‌بخشد.
زمانی که به مرحله G می‌رسیم، معماری توسعه یافته است (در مرحله A تا D)، فرصت‌ها و راه‌حل‌ها برای ارائه معماری شناسایی شده‌اند (در مرحله E)، و یک برنامه پیاده‌سازی و مهاجرت دقیق تکمیل شده است (در مرحله F). بنابراین، نقش تیم معماری مرحله G نظارت بر پیاده‌سازی معماری است. این کار با تأیید دامنه و اولویت استقرار، هدایت توسعه و استقرار راه‌حل و انجام بررسی‌های انطباق انجام می‌شود. اسناد قرارداد معماری برای هدایت تغییرات معماری استفاده می‌شوند. این اسناد در ابتدای مرحله G تولید شده و توسط عملکرد معماری و افرادی که مسئول پیاده‌سازی هستند تأیید می‌شود و مکانیزمی برای ارزیابی انطباق حاکمیت معماری است.
مرحله H: مدیریت تغییر معماری:
هیچ چیز دقیقاً طبق برنامه پیش نمی‌رود – همیشه الزامات جدید و نیاز به تغییر معماری وجود خواهد داشت. مرحله H فرآیند مدیریت تغییر را برای مدیریت تغییرات معماری به‌صورت یکپارچه و معماری توصیف می‌کند. اغلب، این نیاز به نظارت مداوم بر درخواست‌های حاکمیتی، فناوری‌های جدید یا تغییرات در محیط کسب‌وکار دارد.
این فرآیند باید از معماری سازمانی پیاده‌سازی شده به‌عنوان یک محیط پویا که می‌تواند به‌طور انعطاف‌پذیر و سریع در پاسخ به این تغییرات تکامل یابد، پشتیبانی کند. در مرحله H، بسیار مهم است که نهاد حاکم معیارهایی را برای قضاوت در مورد اینکه آیا یک درخواست تغییر نیاز به یک به‌روزرسانی ساده معماری دارد یا اینکه آیا نیاز به آغاز یک چرخه جدید از روش توسعه معماری (ADM) دارد، تعیین کند. مهم است که از «زیرکشیدن زیبا» اجتناب شود، بنابراین تغییرات باید مستقیماً با ارزش کسب‌وکار مرتبط باشند. نحوه استفاده از معماری سازمانی مهم‌ترین بخش از چرخه توسعه معماری است، بنابراین نظارت بر رشد و کاهش کسب‌وکار در مرحله H حیاتی است. در نهایت، معماری سازمانی که دیروز برای یک سازمان کار می‌کرد، دیگر از عملکردهای فعلی یا آینده پشتیبانی نمی‌کند. خروجی‌های درخواست تغییر از مرحله H می‌توانند به‌عنوان ساده‌سازی – معمولاً ناشی از نیاز به کاهش سرمایه‌گذاری؛ تغییر تدریجی – مورد نیاز برای به‌دست آوردن ارزش اضافی از سرمایه‌گذاری موجود؛ یا تغییر طراحی، که ناشی از نیاز به افزایش سرمایه‌گذاری و ایجاد ارزش جدید است، طبقه‌بندی شوند.
مدیریت الزامات معماری:
الزامات در هر مرحله از ADM تولید، تحلیل و بررسی می‌شوند. مرحله مدیریت الزامات فرآیند مدیریت این الزامات معماری در طول ADM را توصیف می‌کند. مرحله مدیریت الزامات قلب ADM است – به همین دلیل در مرکز دایره برش ADM نشان داده شده است. این مرحله فرآیند مدیریت الزامات و چگونگی ارتباط آن با سایر مراحل ADM را توصیف می‌کند. الزامات ایستا نیستند – آنها به‌طور پویا در حین تکمیل هر مرحله از ADM و بین چرخه‌های ADM تکامل می‌یابند. الزامات معماری سازمان و تغییرات بعدی آن الزامات شناسایی، ذخیره و ورودی و خروجی مرتبط با مراحل ADM و بین چرخه‌های ADM خواهند بود. مدیریت تغییرات در تقاضا حیاتی است. معماری با عدم قطعیت و تغییر سروکار دارد – «منطقه خاکستری» بین انتظارات ذینفعان و امکانات! بنابراین، الزامات معماری همیشه در معرض تغییر هستند. علاوه بر این، معماری شامل بسیاری از عوامل و محدودیت‌هایی است که فراتر از کنترل کسب‌وکار هستند – مانند تغییر شرایط بازار یا قوانین جدید – که می‌توانند تغییرات در تقاضا را به روش‌های غیرمنتظره ایجاد کنند. TOGAF تأکید می‌کند که فرآیند مدیریت الزامات خود به الزامات رسیدگی نمی‌کند، حل نمی‌کند یا اولویت‌بندی نمی‌کند، زیرا این کار در مرحله مربوطه ADM انجام می‌شود. مرحله مدیریت الزامات به سادگی فرآیند مدیریت الزامات در طول ADM است. بنابراین، الزامات معماری همیشه در معرض تغییر هستند. علاوه بر این، معماری شامل بسیاری از عوامل و محدودیت‌هایی است که فراتر از کنترل کسب‌وکار هستند – مانند تغییر شرایط بازار یا قوانین جدید – که می‌توانند تغییرات در تقاضا را به روش‌های غیرمنتظره ایجاد کنند. TOGAF تأکید می‌کند که فرآیند مدیریت الزامات خود به الزامات رسیدگی نمی‌کند، حل نمی‌کند یا اولویت‌بندی نمی‌کند، زیرا این کار در مرحله مربوطه ADM انجام می‌شود. مرحله مدیریت الزامات به سادگی فرآیند مدیریت الزامات در طول ADM است. بنابراین، الزامات معماری همیشه در معرض تغییر هستند. علاوه بر این، معماری شامل بسیاری از عوامل و محدودیت‌هایی است که فراتر از کنترل کسب‌وکار هستند – مانند تغییر شرایط بازار یا قوانین جدید – که همه اینها تغییرات در تقاضا را به روش‌های غیرمنتظره ایجاد می‌کنند. TOGAF تأکید می‌کند که فرآیند مدیریت الزامات خود به الزامات رسیدگی نمی‌کند، حل نمی‌کند یا اولویت‌بندی نمی‌کند، زیرا این کار در مرحله مربوطه ADM انجام می‌شود. مرحله مدیریت الزامات به سادگی فرآیند مدیریت الزامات در طول ADM است. TOGAF تأکید می‌کند که فرآیند مدیریت الزامات خود به الزامات رسیدگی نمی‌کند، حل نمی‌کند یا اولویت‌بندی نمی‌کند، زیرا این کار در مرحله مربوطه ADM انجام می‌شود. مرحله مدیریت الزامات به سادگی فرآیند مدیریت الزامات در طول ADM است.
(منبع: TOGAF ADM: چیست و چرا اینقدر مهم است؟)
TOGAF
- TOGAF چیست؟
- آموزش TOGAF ADM
- چارچوب TOGAF 9.1 – یک راهنمای جامع
- نرم‌افزار TOGAF برای معماری سازمانی
- بهترین نرم‌افزار TOGAF
ArchiMate 3
- ArchiMate چیست؟
- راهنمای کامل دیدگاه‌های ArchiMate
- به‌روزرسانی ArchiMate 3
- چه خبرهایی در ArchiMate 3 وجود دارد؟
- استفاده از ابزار ArchiMate با TOGAF ADM
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.