بزرگترین اشتباه چند ابری که مردم مرتکب می شوند

برای بهینه سازی معماری چند ابری خود، بدانید که کسب و کار شما به طور خاص به چه چیزی نیاز دارد و از دام «فکر فروشنده» اجتناب کنید.

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

در یک کلمه: “فروشنده فکر کنید.” Vendorthink روشی است که به فروشندگان اجازه می دهد تا تصمیمات معماری شما را به جای برعکس هدایت کنند. هنگامی که یک فروشنده دیکته می کند که مشتری چگونه از فناوری خود برای رسیدگی به یک مورد استفاده سازمانی استفاده کند، مرحله برای خارج شدن چند ابری از ریل تنظیم می شود.

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

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

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

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

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

چگونه از vendorthink اجتناب می کنید؟ این به رهبری و پرسیدن سؤالات درست مربوط می شود تا اطمینان حاصل شود که تیم های معماری، توسعه و مهاجرت چند ابری همگی به روش هایی فکر می کنند که منجر به بهینه ترین راه حل شود. کار علیه شما میلیاردها دلار بازاریابی فروشنده است، و همچنین این واقعیت که بسیاری از معماران با فروشندگان آموزش می بینند تا گواهینامه های فروشنده محور را دریافت کنند. هیچ ایرادی ندارد مگر اینکه قضاوت شما برای تصمیم گیری کاملاً عینی را مختل کند.

Vendorthink یک اشتباه آسان برای اجتناب است. متأسفانه، کار اضافی زیادی را شامل می شود، اما در نهایت نتیجه خواهد داد.