با یک معماری ابری منطقی شروع کنید

بسیاری از اشتباهات فناوری اطلاعات به برنامه ریزی ناکافی و عجله در معماری فیزیکی بازمی گردد. بیایید به اصول اولیه بازگردیم.

در طول حرفه‌ام به‌عنوان یک متخصص و معلم معماری ابری و معماری عمومی سازمانی، بر تمایز بین معماری‌های منطقی و فیزیکی تمرکز کرده‌ام.

این راز نیست که آنها شامل چه چیزی می شوند: یک معماری منطقی ساختاری از مفاهیم فناوری است که از فناوری ها یا مارک های خاصی نام نمی برد، در حالی که یک معماری فیزیکی حاوی فناوری ها و مارک های خاص است.

هنگامی که معماری رایانش ابری را طراحی می کنم، ابتدا می پرسم چه مشکلاتی باید حل شوند. سپس تعیین می کنم که یک راه حل قابل قبول به چه چیزی نیاز دارد. در مرحله بعد، مواردی را که باید بخشی از معماری باشند و روابط آنها با یکدیگر فهرست می‌کنم: پایگاه‌های داده، میان‌افزار، رمزگذاری، ذخیره‌سازی، محاسبات، توسعه برنامه‌ها و غیره. مشکلات کلی.

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

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

این بزرگترین اشتباهی است که معماران این روزها مرتکب می شوند: چیدن ابرهای عمومی قبل از اینکه مشکل را بدانند و بفهمند. این اغلب با پایگاه‌های داده مبتنی بر ابر اتفاق می‌افتد که مارک‌های میان‌افزار، سیستم‌های هوش تجاری، ابزارهای مدیریت پایگاه داده و غیره را محدود می‌کنند. محدود کردن انتخاب‌های شما در مراحل اولیه برنامه‌ریزی تقریباً همیشه به یک اشتباه تبدیل می‌شود.

متأسفانه، شرکت‌ها اغلب با معماری ابری کار می‌کنند. “این کار می کند” یک راه حل بهینه را توصیف نمی کند. معماری عملکردی و در عین حال کمتر بهینه ارزش بسیار کمتری نسبت به معماری که از فناوری مناسب برای حل مشکلات تجاری خاص در دست استفاده می کند، ارائه می دهد.

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

به عبارت دیگر، فناوری های مفهومی در معماری منطقی را به فناوری های واقعی در فیزیکی ترسیم کنید. معماری فیزیکی به گزینه نهایی راه حل تبدیل می شود، اما قبل از اینکه به هر نوع استقرار بروید، این فناوری هنوز باید با آزمایش تأیید شود.

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

همچنین، معماران ابری باید از مفاهیم کلی فناوری و همچنین فناوری‌های واقعی که می‌توانند با این مفاهیم نقشه‌برداری کنند، دانش کاری داشته باشند.

اگر قبل از متعهد شدن به فناوری خاصی برنامه ریزی معماری منطقی انجام دهید، تصمیمات بهتری خواهید گرفت. این همچنین عامل “معماران مردم هستند” را حذف می کند زیرا اکثر معماران ترجیحات و علاقه مندی های فناوری دارند. آنها می توانند برای یک ارائه دهنده ابر خاص، پایگاه داده، رویکرد امنیتی و غیره تعصب داشته باشند، که در نهایت راه حلی است که کار می کند اما بسیار گران تر از یک بهینه سازی شده است.

به خاطر داشته باشید که هدف شما به عنوان یک معمار ابر – یا به عنوان هر کسی که راه حل های تجاری را از فناوری تعریف می کند – ایجاد راه حلی است که بیشترین ارزش را به کسب و کار بازگرداند. ابتدا از رویکرد معماری منطقی استفاده کنید تا به خودتان شانس بیشتری برای رسیدن به آن هدف بدهید.