TOGAF (چارچوب معماری گروه باز) یک چارچوب سازمانی باز است. این چارچوب خود یک مجموعه به خوبی مستند از دانش است که شامل روش‌های جزئی و یک مجموعه ابزارهای پشتیبانی برای توسعه معماری سازمانی است. TOGAF 9.2 آخرین نسخه این چارچوب است.
- TOGAF توسط اعضای گروه باز توسعه و نگهداری می‌شود و در یک تیم به نام فوروم معماری کار می‌کند. اولین توسعه TOGAF نسخه 1 در سال 1995 انجام شد و نسخه‌های بعدی TOGAF این سیستم را گسترش و بهبود دادند.
- TOGAF از طریق تلاش‌های مشترک بیش از 300 عضو فوروم معماری که نماینده برخی از بهترین شرکت‌ها و سازمان‌های جهانی هستند، توسعه یافته است – بنابراین یک خلاصه خوب از شیوه‌های کلی معماری سازمانی است.
- توسعه و نگهداری یک معماری سازمانی یک فرایند پیچیده است که شامل بسیاری از ذینفعان و فرایندهای تصمیم‌گیری است. TOGAF با مستندسازی مشخصات معماری سازمانی، فرایندها و محصولات کاری معماری کمک می‌کند.
- با استفاده از TOGAF، سازمان‌ها می‌توانند یک معماری سازمانی یکپارچگی توسعه دهند که نیازهای ذینفعان را بازتاب دهد، بهترین شیوه‌ها را به کار بگیرد و به درستی نیازهای کنونی و تصور شده تجاری در آینده را در نظر بگیرد.
TOGAF از کجا می‌آید؟
TOGAF از چارچوب معماری فناوری مدیریت اطلاعات وزارت دفاع ایالات متحده (TAFIM) سرچشمه گرفته است. TOGAF 1.0 پس از سال‌ها کاوش در سال 1995 به طور رسمی منتشر شد، با اجازه از وزارت دفاع ایالات متحده و کمک سرمایه گذاری بزرگ دولت ایالات متحده. TOGAF تا کنون نه نسخه را منتشر کرده است، TOGAF 9 (آخرین نسخه TOGAF 9.2 است).
چرا TOGAF؟
معماری فناوری اطلاعات باید به طور نزدیک اهداف تجاری سازمان را بازتاب دهد. در واقع، تکنیک‌های خاص (سناریوهای تجاری) باید برای اطمینان از اینکه اهداف تجاری توسط معمار فناوری اطلاعات به درستی درک شده و در معماری فناوری اطلاعات توسعه یافته با استفاده از TOGAF بازتاب شوند، استفاده شوند. با استفاده از TOGAF.
در اینجا دلایلی ارائه می‌شود که باید از ADM TOGAF برای توسعه معماری استفاده کنیم:
- یک روش کلی جامع
- مکمل، نه رقیب با چارچوب‌های دیگر
- به طور گسترده در بازار پذیرفته شده
- قابل تنظیم برای پاسخگویی به نیازهای یک سازمان و صنعت
- در دسترس با مجوز ابدی رایگان
- استاندارد باز خنثایی از نظر فروشنده، ابزار و فناوری
- جلوگیری از ابداع مجدد چرخ
- هماهنگی بین فناوری اطلاعات و تجارت
- مبتنی بر بهترین شیوه‌ها
- امکان شرکت در تکامل چارچوب
ADM چیست؟
روش توسعه معماری (ADM) برای توسعه معماری سازمانی استفاده می‌شود که به نیازهای تجاری و فناوری اطلاعات یک سازمان پاسخ می‌دهد. ADM TOGAF نتیجه مداوم مشارکت‌های یک تعداد زیادی از کارشناسان معماری برای رسیدگی به اهداف زیر است:
- این روش را برای توسعه و مدیریت چرخه حیات معماری سازمانی توصیف می‌کند و هسته ADM TOGAF را تشکیل می‌دهد.
- می‌تواند به نیازهای سازمان تنظیم شود و سپس برای مدیریت اجرای فعالیت‌های برنامه‌ریزی معماری استفاده می‌شود.
روش توسعه معماری-که اغلب با سرواژه ADM شناخته می‌شود-یک فرایند گام به گام جزئی است که برای توسعه یا تغییر معماری یک سازمان استفاده می‌شود.
ADM 10 مرحله را توصیف می‌کند که چرخه توسعه معماری را پوشش می‌دهد.
این مراحل عبارتند از:
- مرحله آماده‌سازی
- فاز A: چشم‌انداز معماری
- فاز B: معماری تجاری
- فاز C: معماری سیستم اطلاعاتی
- فاز D: معماری فنی
- فاز E: فرصت‌ها و راه‌حل‌ها
- فاز F: برنامه‌ریزی مهاجرت
- مرحله G: حاکمیت اجرایی
- فاز H: مدیریت تغییرات معماری
- مدیریت نیازمندی‌ها
ورودی و خروجی ADM
TOGAF مجموعه‌ای از محصولات ورودی و خروجی از هر فاز را ارائه می‌دهد:
- اینها پیشنهادات هستند و نیاز به پیروی دقیق نیستند
- هر محصول تولید شده باید نسخه‌بندی شود تا نشان دهد که تغییری رخ داده است
- شماره‌گذاری نسخه نیز یک پیشنهاد است و نیاز به پیروی نیست
محصولات
یک محصول کاری که به طور قراردادی تعریف شده و سپس توسط ذینفعان بررسی، تأیید و امضا می‌شود. این محصول عموماً در پایان یک پروژه بایگانی می‌شود یا به یک مخزن معماری به عنوان مدل مرجع انتقال می‌یابد.
مرحله اولیه:
هدف اصلی مرحله اولیه تعیین و برقراری توانایی‌های معماری لازم سازمان است.
یکی از بخش‌های کلیدی تعیین این است که چه کاری باید انجام شود و چگونه اجرا شود. برای مثال، خروجی اصلی یک درخواست کار معماری است که نیازمندی‌ها را توصیف می‌کند و تعیین می‌کند که چه حوزه، ساختار، ابزار یا چارچوب معماری برای پشتیبانی از این کار لازم است.
در این مرحله، TOGAF به طور خاص برای پاسخگویی به نیازهای بعدی چرخه‌های ADM تنظیم می‌شود. ما اصول اساسی را تعریف می‌کنیم، توانایی ساختار سازمانی و تجاری را برای انجام تغییرات لازم ارزیابی می‌کنیم و TOGAF را با چارچوب‌های مدیریتی دیگر یکپارچگی می‌دهیم. گام‌هایی در این مرحله وجود دارد تا سازمان را که از تغییرات پیشنهادی تأثیر می‌پذیرد محدود کند، حاکمیت و چارچوب پشتیبانی صحیح را تأیید کند، تیم و سازمان معماری سازمانی را تعریف و برقرار کند، اصول معماری را تعیین و برقرار کند، TOGAF و هر چارچوب دیگری را سفارشی کند و ابزارها را پیاده‌سازی کند. در پایان این فاز، تیم معماری سازمانی باید آماده باشد تا چرخه‌های تکراری 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 شناسایی، ذخیره و ورودی و خروجی مربوط به آنها خواهند بود. کار با تغییرات در نیازمندی‌ها بسیار مهم است. معماری با بی‌قراری و تغییر مبارزه می‌کند – “منطقه خاکستری” بین انتظارات ذینفعان و امکانات! بنابراین، نیازمندی‌های معماری همیشه در حال تغییر است.
علاوه بر این، معماری شامل بسیاری از عوامل راننده و محدودیت‌هایی است که خارج از کنترل سازمان است – مانند تغییر شرایط بازار یا قوانین جدید – که می‌توانند به طور غیرمنتظره در نیازمندی‌ها تغییر ایجاد کنند.
TOGAF بر این نکته تأکید می‌کند که فرایند مدیریت نیازمندی‌ها خود با حل، رفع یا اولویت بندی نیازمندی‌ها سروکار ندارد، زیرا این کار در فاز مربوط ADM انجام می‌شود. فاز مدیریت نیازمندی‌ها فقط فرایند مدیریت نیازمندی‌ها در طول ADM است.
فاز آماده‌سازی ADM
فعالیت‌های آماده‌سازی و شروع لازم برای ایجاد یک توانایی معماری شامل سفارشی کردن TOGAF و تعریف معماری
محصولات خروجی:
- اصول معماری
- مخزن معماری
- اصول تجاری، اهداف تجاری و راننده‌های تجاری
- مدل سازمانی برای معماری سازمانی
- درخواست برای کار معماری
- چارچوب معماری سفارشی
فاز A ADM: چشم‌انداز معماری
فاز اولیه یک چرخه توسعه معماری. شامل اطلاعات در مورد تعریف حوزه ابتکار توسعه معماری، شناسایی ذینفعان، ایجاد چشم‌انداز معماری و دریافت تأیید برای ادامه توسعه معماری است.
محصولات خروجی:
- اصول معماری
- نقشه راه معماری
- چشم‌انداز معماری
- اصول تجاری، اهداف تجاری و راننده‌های تجاری
- ارزیابی توانایی
- برنامه ارتباطی
- بیانیه کار معماری
- چارچوب معماری سفارشی
فاز B ADM: معماری تجاری
معماری تجاری: توسعه معماری تجاری برای پشتیبانی از چشم‌انداز معماری موافق
محصولات خروجی:
- سند تعریف معماری
- اصول معماری
- مشخصات نیازمندی‌های معماری
- نقشه راه معماری
- اصول تجاری، اهداف تجاری و راننده‌های تجاری
- بیانیه کار معماری
فاز C ADM: معماری سیستم‌های اطلاعاتی
معماری سیستم‌های اطلاعاتی: توسعه معماری سیستم‌های اطلاعاتی برای پشتیبانی از چشم‌انداز معماری موافق
- سند تعریف معماری
- اصول معماری
- مشخصات نیازمندی‌های معماری
- نقشه راه معماری
- بیانیه کار معماری
فاز D ADM: معماری فناوری
معماری فناوری: توسعه معماری فناوری برای پشتیبانی از چشم‌انداز معماری موافق
محصولات خروجی:
- سند تعریف معماری
- اصول معماری
- مشخصات نیازمندی‌های معماری
- نقشه راه معماری
- بیانیه کار معماری
فاز E ADM: فرصت‌ها و راه‌حل‌ها
فرصت‌ها و راه‌حل‌ها برنامه‌ریزی پیاده‌سازی اولیه و شناسایی وسایل ارائه برای معماری تعریف شده در فازهای قبلی را انجام می‌دهد
محصولات خروجی:
- سند تعریف معماری
- مشخصات نیازمندی‌های معماری
- نقشه راه معماری
- چشم‌انداز معماری
- ارزیابی توانایی
- برنامه پیاده‌سازی و مهاجرت
- بیانیه کار معماری
فاز F ADM: برنامه‌ریزی مهاجرت
برنامه‌ریزی مهاجرت چگونگی حرکت از معماری پایه به معماری‌های هدف را با تکمیل یک برنامه پیاده‌سازی و مهاجرت جزئی پاسخ می‌دهد
- بلوک‌های ساخت معماری
- سند تعریف معماری
- مشخصات نیازمندی‌های معماری
- نقشه راه معماری
- درخواست تغییر برنامه پیاده‌سازی و مهاجرت
- برنامه حاکمیت پیاده‌سازی
- درخواست برای کار معماری
- بیانیه کار معماری
فاز G ADM: حاکمیت پیاده‌سازی
حاکمیت پیاده‌سازی نظارت معماری بر پیاده‌سازی را ارائه می‌دهد
محصولات خروجی:
- درخواست تغییر
- ارزیابی انطباق
- بلوک‌های ساخت راه‌حل
- بیانیه کار معماری
فاز H ADM: مدیریت تغییرات معماری
مدیریت تغییرات معماری روش‌هایی را برای مدیریت تغییرات در معماری جدید تعریف می‌کند. مدیریت نیازمندی‌ها فرایند مدیریت نیازمندی‌های معماری را در طول ADM بررسی می‌کند
خلاصه
ADM یک روش کلی جامع است
- یک توالی را برای مختلف فازها و گام‌های دخیل در توسعه معماری پیشنهاد می‌کند
- یک روش تکراری است
- از سایر بخش‌های TOGAF برای دارایی‌ها و فرایندها استفاده می‌کند
- می‌توان با محصولات دیگر از چارچوب‌های دیگر استفاده شد
در اینجا بررسی کلی TOGAF ADM برای هر فاز توسعه به نمایش گرفته شده است:
- بیشتر در مورد راهنمای TOGAF ADM
- بیشتر در مورد قالب‌های TOGAF به موقع
- بیشتر در مورد ابزارهای ArchiMate
- امتحان کنید Visual Paradigm رایگان
مراجع مقدماتی 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 繁體中文.