بسیاری از سازمان ها هیچ استراتژی ابری ندارند یا فکر می کنند که استراتژی ابری دارند. این تحقیق 10 نکته برتر ما را برای فعال کردن رهبران معماری سازمانی و نوآوری فناوری برای ابداع استراتژیهای ابری توصیف میکند که مزایایی را که سازمانهایشان از خدمات ابری به دست میآورند، به حداکثر میرساند.
تقریباً هر سازمانی از محاسبات ابری استفاده می کند، اما بسیاری از آنها هنوز یک استراتژی ابری یا حتی یک برنامه پیاده سازی ابری ندارند. سازمانها نمیتوانند از مزایای استفاده از سرویسهای ابری بدون استراتژی ابری صحیح استفاده کنند. یک استراتژی ابری نقشی را که رایانش ابری باید در سازمان ایفا کند را بررسی و تعریف می کند. استراتژی ابری برنامه ای برای انتقال همه چیز به ابر نیست.
یک استراتژی ابری خوب باید مختصر و متشکل از 10 تا 20 صفحه یا اسلاید باشد. این باید مواردی را که در این تحقیق و در “کتاب آشپزی استراتژی ابری، 2019” مورد بحث قرار گرفت، پوشش دهد. این باید یک سند زنده باشد که به طور منظم به روز شود. استراتژی ابری باید توسط استراتژی تجاری هدایت شود و باید راهنمایی هایی را برای کسانی که آن را اجرا می کنند ارائه کند. این باید با دیگر تلاشهای استراتژیک همزیستی داشته باشد، نه اینکه سعی در انجام مجدد آنها داشته باشد (به «تدوین یک استراتژی ابری در چارچوب استراتژی کلی خود مراجعه کنید»).
اگر سند بیش از 20 صفحه باشد، احتمالاً یک استراتژی نیست. اگر شامل بسیاری از نمودارهای گانت و. چک لیست ها، احتمالاً یک طرح پیاده سازی ابری است که باید گام بعدی باشد. اگر در مورد نحوه انتقال برنامهها به خدمات وب آمازون (AWS) یا Microsoft Azure صحبت میکند، یک استراتژی ابری نیست.
سازمانهایی که استراتژیهای ابری ایجاد میکنند، اغلب اشتباهات زیادی در آنها مرتکب میشوند. در این بخش اشتباهاتی را نشان می دهد که اغلب در استراتژی های ابری می بینیم. این تحقیق نحوه اجتناب از آنها را توضیح می دهد.
در طول بررسی صدها سند استراتژی ابری، مشاهده کرده ایم که هر یک از 10 اشتباه اصلی فهرست شده به طور مکرر رخ می دهد. در زیر توصیه هایی وجود دارد که می تواند بهترین روش برای جلوگیری از این اشتباهات در نظر گرفته شود.
رایج ترین اشتباهی که سازمان ها با استراتژی محاسبات ابری خود مرتکب می شوند این است که تصور می کنند این استراتژی فقط مربوط به فناوری اطلاعات است. اما رایانش ابری فقط در مورد فناوری نیست. افراد خارج از فناوری اطلاعات دارای مهارت ها و دانش های مرتبط با استراتژی ابری هستند که متخصصان فناوری اطلاعات آن را ندارند. برای مثال، افرادی که در بخشهای منابع انسانی، حقوقی و مالی هستند، مهارتها و دانشهایی دارند که میتواند ورودی آنها را به یک استراتژی ابری ارزشمند کند. پذیرش ابر بر هر یک از این سازمان ها تأثیر خواهد گذاشت. آنها باید: (الف) آماده باشند. (ب) کمک به استراتژی کلی برای اطمینان از اتخاذ موفقیت آمیز. و (ج) به دنبال راههایی باشید که استفاده از ابر میتواند برای ناحیه عملکردی خاص آنها مفید باشد.
علاوه بر این، حاکمیت معمولاً بخشی از یک استراتژی ابری است، بنابراین منطقی است که از کسانی که بر آنها حکومت میکنید دعوت کنید تا در این استراتژی نیز نظر داشته باشند. این اشتباه را مرتکب نشوید که استراتژی خود را طراحی کنید و سپس سعی کنید آن را به کسب و کار “بفروشید”. اگر قبلاً یک استراتژی ابری فقط فناوری اطلاعات طراحی کردهاید، از وضعیت سند زنده استراتژی استفاده کنید تا در به روزرسانی برنامه ریزی شده بعدی، کسب و کار را درگیر کنید. هیچ وقت دیر نیست. کسب و کار و فناوری اطلاعات باید شرکای برابر در تعریف استراتژی ابری باشند. Cloud بر سایر حوزههای درون سازمان تأثیر میگذارد و آنها باید استراتژی ابر را نیز هدایت کنند.
معماران سازمانی و سایر افرادی که وظیفه ایجاد یک استراتژی ابری را بر عهده دارند، باید فعالانه به دنبال استفاده از ورودی، تخصص و دانش فراتر از فناوری اطلاعات باشند. یکی از راه های اطمینان از آن این است که اطمینان حاصل شود که تلاشها بر سطح استراتژیک واقعی متمرکز است (جایی که آن تخصص واقعاً مورد نیاز و قدردانی است) – نه عمیقاً در جزئیات فنی که علاقه و مشارکت مورد نیاز را به دست نمیآورد.
خروج ملاحظاتی را در مورد رهایی از تصمیمات ابری در صورت نیاز مشخص می کند. با این حال، بسیاری از سازمان ها معتقدند که نیازی به استراتژی خروج ندارند زیرا انتظار ندارند چیزی را از فضای ابری بازگردانند. اگرچه بازگشت برنامه از ابر به یک مرکز داده سنتی نادر است، اما داشتن یک استراتژی خروج بسیار مهم است، حتی اگر هرگز از آن استفاده نکنید. این تلاش باید امکان تغییر ارائه دهندگان را نیز در نظر بگیرد، نه صرفاً بازگرداندن بار کاری در محل. همچنین توجه داشته باشید که این یک بحث استراتژیک در این مرحله است. جزئیات خروج واقعی از یک سرویس خاص متفاوت خواهد بود و در تمرینات عملیاتی با جزئیات بیشتری در نظر گرفته می شود. برخی از تنظیم کننده ها، عمدتاً در اتحادیه اروپا و آنهایی که بر خدمات مالی متمرکز هستند، یک استراتژی خروج را الزامی میکنند. استراتژی خروج به دلایل زیادی حیاتی است، از جمله:
ایجاد یک استراتژی خروج دشوار است، که دلیل دیگری است که چرا بسیاری از افراد آن را ایجاد نمی کنند. این امر مستلزم بررسی و بحث در زمینه های بسیاری است. از بین سازمانهایی که استراتژی های خروج را ایجاد میکنند، بسیاری از آنها بر چگونگی رهایی از قرارداد با ارائهد هندگان ابری خود تمرکز میکنند. آنها بر شرایط و ضوابط و SLAS تمرکز می کنند. با این حال، علاوه بر مسائل قراردادی، باید موارد زیر را نیز تحلیل کنید:
یک استراتژی ابری، به طور پیشفرض، باید افزایش مقیاس را فعال کند، اما همچنین کاهش مقیاس را نیز فعال کند. بنابراین، علاوه بر “خروج”، یک “استراتژی کاهش مقیاس” نیز وجود دارد که در آب و هوای امروزی بسیار مفید است. برای مثال، قراردادهای SaaS معمولاً ثابت میشوند. قراردادهای سه ساله و نمونههای رزرو شده laaS با قیمت گذاری خوبی همراه هستند، اما اگر بیش از حد انجام شود میتواند محدودکننده باشد.
بسیاری از سازمان ها استراتژی ابری را با طرح پیاده سازی ابری (که به عنوان طرح پذیرش ابری یا طرح مهاجرت ابری نیز شناخته می شود) اشتباه می گیرند. اما یک استراتژی ابری باید اول باشد. این مرحله تصمیم گیری است که در آن تصمیم می گیرید نقش محاسبات ابری – در صورت وجود – در سازمان شما بازی کند. برنامه پیاده سازی ابری در مرحله بعدی قرار می گیرد و استراتژی ابر را به اجرا در می آورد.
برنامه ریزی استراتژیک از بالای سازمان شروع می شود (از مدیر عامل و هیئت مدیره، و اغلب در گزارش سالانه یافت می شود) و چشم انداز سازمان را توصیف می کند. یک استراتژی ابری بخشی از سطح بعدی در معماری برنامه ریزی استراتژیک سه لایه سازمان با سایر برنامه های استراتژیک مانند استراتژی مرکز داده، استراتژی امنیتی و استراتژی معماری است. استراتژی ابری باید با آن استراتژیهای دیگر و چشمانداز سازمان همسو باشد (به «تدوین استراتژی ابری در چارچوب استراتژی کلی خود مراجعه کنید») در یک دنیای ایدهآل، همسویی این تلاشهای استراتژیک در حال حاضر انجام میشود، اما در واقعیت، پروژه استراتژی ابری مناسب می تواند کاتالیزوری برای ایجاد ارتباطات و منطقی سازی مورد نیاز برای یک استراتژی فناوری اطلاعات یا فناوری حتی گسترده تر باشد.
اغلب یک استراتژی امنیتی موجود وجود دارد که ممکن است جاری باشد یا نباشد. استراتژی امنیتی ممکن است حتی بیان کند که سازمان نباید از محاسبات ابری استفاده کند. در این مورد، طراحی یک استراتژی ابری، استراتژی امنیتی را نقض می کند. همسویی در اینجا بسیار مهم است و اغلب شامل مذاکره بین طرف های مسئول می شود.
گاهی اوقات طرح اجرای ابر را یک استراتژی می نامند. اما اینطور نیست. احتمالاً بسیار طولانیتر از 20 صفحه و بسیار دقیق است، اگرچه ممکن است برخی از جنبههای استراتژی را در بر داشته باشد. اگر چنین سندی دارید، آن را دوباره اصلاح کنید. از آن برای شروع تشکیل دو سند جداگانه استفاده کنید: یک استراتژی ابری و یک طرح اجرای ابر.
اگر سند شما به مسائلی که در «کتاب آشپزی استراتژی ابری، 2019» پرداخته شده است، یک استراتژی ابری است. با این حال، اگر نحوه انتخاب ارائه دهندگان، انتقال بار کاری به فضای ابری و مدیریت استفاده از رایانش ابری را مورد بحث قرار دهد، این یک طرح پیاده سازی ابری است.
بسیاری از سازمانها معتقدند که اگر قبلاً از محاسبات ابری استفاده میکنند، برای طراحی یک استراتژی ابری دیر شده است. اما دیر شدن بهتر از هرگز نرسیدن است. ممکن است از ابر استفاده کنید اما واقعاً نمی دانید چرا. از خود بپرسید چرا از رایانش ابری استفاده می کنید و نقش آن در سازمان شما چیست. اگر بتوانید به این سوالات پاسخ دهید، حداقل به استراتژی ابری خود فکر کرده اید. اگر نمی توانید به این سؤالات پاسخ دهید، یا اگر پاسخ ها در جایی مستند نیست، باید یک استراتژی ابری طراحی کنید. این به این معنا نیست که همه چیز را از ابر بازگردانید و دوباره شروع کنید. استراتژی شما از جایی که هستید شروع می شود و آنچه را که سازمان شما قبلاً انجام داده است مورد توجه قرار می دهد. استفاده سازمان خود از رایانش ابری را ارزیابی کنید. بررسی و مستندسازی آن:
استراتژی ابری شما باید منعکس کننده چیزهایی باشد که آموخته اید و اطمینان حاصل کند که هیچ اشتباهی را که قبلا مرتکب شده اید تکرار نمی کنید. تبدیل استراتژی خود به یک سند زنده برای موفقیت آن حیاتی است.
استراتژی ابری را با “ما همه چیز را به سمت ابر منتقل می کنیم” یکسان نکنید. بسیاری از سازمان ها این اشتباه را مرتکب می شوند. این امر بسیاری را از ابداع استراتژی ابری باز می دارد زیرا فکر می کنند به این معنی است که مجبور خواهند شد برای همه چیز از رایانش ابری استفاده کنند.
هنگام طراحی استراتژی ذهن خود را باز نگه دارید – قبل از شروع به هیچ نتیجه ای نرسید. به همین دلیل، بهتر است که فردی غیر از یک متخصص ابر این استراتژی را طراحی کند. یک معمار سازمانی یک فرد ایده آل برای انجام این کار است. دیدگاه گسترده این نقش هنگام نگاه کردن به استراتژی ابر مفید است.
انتقال همه چیز به فضای ابری زمانی اتفاق میافتد که شرایط کاهش دهنده وجود داشته باشد، مانند اینکه باید با استراتژی مرکز داده برای خروج از کسب و کار مرکز داده در عرض دو سال هماهنگ شوید. در چنین شرایطی، استراتژی ابری شما باید با آن مطابقت داشته باشد. همچنین، یک استراتژی ابری فقط به جابجایی نیست – سوال همچنین این است که بارهای کاری و داده های جدید را کجا قرار دهیم.
بسیاری از سازمان ها استراتژی ابری خود را با استراتژی مرکز داده خود اشتباه می گیرند. آنها ممکن است قصد تعطیلی مرکز داده خود را داشته باشند و آن برنامه را استراتژی ابری خود بنامند. اما این یک استراتژی ابری نیست. استراتژی ابری و استراتژی مرکز داده خود را از هم جدا کنید. با این حال، اطمینان حاصل کنید که استراتژی ابری شما با استراتژی مرکز داده شما و هر برنامه استراتژیک دیگری که بر نقش رایانش ابری در سازمان شما تأثیر میگذارد، همراستا باشد و در آن نقش داشته باشد. تصمیمات استراتژی ابری بر اساس حجم کار، نه تصمیمات مرکز داده، حجم کاری است.
معمولاً سازمانها در ابتدا رویکرد «همه یا هیچ» را اتخاذ میکنند. اما این یک دید محدود از رایانش ابری را نشان می دهد. اگرچه ارائه دهندگان اصلی ابر شما را قادر می سازند تا مرکز داده خود را “بالا و جابجا کنید”، اما بدانید که این برای اجرای یک استراتژی مرکز داده بیشتر از یک استراتژی ابری کاربرد دارد. و معمولاً تمام مزایای یک محیط ابری را ارائه نمی دهد.
در صورتی که سازمان شما تصمیم به ادغام مراکز داده یا حذف آنها داشته باشد، به ویژه بسیار مهم است که استراتژی ابری خود را با استراتژی مرکز داده خود هماهنگ کنید. شما باید یک برنامه مهاجرت ابری بسازید (برای حجم کاری که به فضای ابری میرود) و خانهای برای هر چیز دیگری (از جمله برونسپاریکنندگان مرکز داده، ارائهدهندگان هممکانی و غیره) پیدا کنید. همه چیز نمی تواند به راحتی به یک ارائه دهنده ابر عمومی برود. برخی از چیزها، مانند بارهای کاری که روی رایانه های بزرگ و مینی رایانه ها اجرا می شوند، معمولاً مجازی سازی نمی شوند. ممکن است لازم باشد برخی چیزها را به یک ارائه دهنده کولوکیشن یا برون سپاری مرکز داده منتقل کنید. ممکن است لازم باشد یک مرکز داده کوچک داشته باشید. اطمینان حاصل کنید که استراتژی ابری شما با چنین الزاماتی مطابقت دارد و به شما در اجرای آن کمک می کند.
استراتژی شما برای استفاده از رایانش ابری نباید این باشد که “مدیرعامل چنین گفته است.” بسیاری از سازمانها محاسبات ابری را اتخاذ میکنند زیرا مدیر عامل، مدیر عامل یا رئیس یک واحد تجاری معتقدند که انجام این کار باعث صرفهجویی در هزینهها میشود. این یک اشتباه بسیار رایج و یکی از بسیاری از افسانه هایی است که همچنان در دنیای ابری وجود دارد (به «بازبینی 10 اسطوره برتر ابر برای سال 2020» مراجعه کنید). با این حال، محاسبات ابری همیشه باعث صرفه جویی در هزینه ها نمی شود و این هدف به تنهایی نباید اساس یک استراتژی ابری را تشکیل دهد. در عوض، بهترین راه برای اقدام این است که دستورالعمل اجرایی را به عنوان حمایت مالی برای توسعه یک استراتژی ابری نگاه کنیم، نه به خودی خود به عنوان یک استراتژی ابری.
استراتژی خود را بر اساس دستیابی به نتایج کسب و کار هدف و الزامات تجاری قرار دهید. هنگام صحبت با افراد در مورد انتقال حجم کاری به فضای ابری، همیشه ارتباط خود را با مسائل تجاری حفظ کنید و مطمئن شوید که چرا حجم کاری به ابر منتقل می شود و هدف چیست. معمولاً هدف دستیابی به موارد زیر است:
گاهی اوقات ممکن است نتوانید به هر دو دست یابید، بنابراین باید عامل محرک حرکت به سمت ابر را بررسی کنید. در حالی که ممکن است هر دو مورد دلخواه باشند، اولویت بندی ضروری است (به «استراتژی ابری شما باید دووجهی باشد» مراجعه کنید).
چابکی می تواند به معنای کاهش مقیاس باشد. کاهش مقیاس در برخی موارد می تواند به همان اندازه مهم باشد. اغلب، این موضوع باعث بحث در مورد مسائل مربوط به کشش و اشتراک گذاری می شود – ویژگی های ابر گاهی اوقات به خطر می افتد. توسعه استراتژی ابری تمرینی برای مبادله است.
برخی از سازمان ها خود را یک فروشگاه می دانند. در این موارد، آنها ممکن است به سادگی از پیشنهادات ابری آن فروشنده پیروی کنند تا یک استراتژی ابری تک فروشنده را دنبال کنند. اما این نه تنها یک استراتژی واقعی نیست، بلکه انواع متعدد سرویس های ابری و این واقعیت را که اکثر فروشندگان همه خدمات را ارائه نمی دهند – به خصوص در سطح SaaS – نیز در نظر نمی گیرد. با این حال، رایانش ابری فقط زیرساختی به عنوان یک سرویس نیست. این شامل PaaS و پیشنهادات یکپارچه laaS و PaaS است. این شامل راهحلهای SaaS مانند Workday، Salesforce، Box و Office 365 است. تقریباً غیرممکن است که همه سرویسهای ابری خود را از یک فروشنده تهیه کنید، اگر دید گستردهای از رایانش ابری داشته باشید. اگرچه فروشندگانی مانند آیبیام، مایکروسافت، اوراکل و SAP پیشنهادات زیادی را ارائه میکنند که شامل laaS به SaaS میشود، اما ممکن است برای همه آنها بهترین نباشند.
برای بهره برداری از محاسبات ابری، یک استراتژی ابری طراحی کنید که شامل گزینه های مختلف است:
اکثر سازمان ها با یک ارائه دهنده laaS ابری شروع به کار می کنند. آنها چیزهای زیادی را به آن ارائه دهنده منتقل می کنند و معمولا راضی هستند. از آنجایی که آنها معمولاً قبل از شروع یک استراتژی ابری ابداع نکرده اند، به تدریج شروع به فکر کردن در مورد عواقب وابستگی بیش از حد به یک ارائه دهنده می کنند. سپس به چیزهایی مانند استراتژی خروج و اصولی مانند چند ابری فکر می کنند.
اگر قبلاً 10 تا 15 پروژه را با یک ارائهدهنده ابر انجام دادهاید، یک رویکرد مبتنی بر تدارکات ممکن است تشویق افراد برای قرار دادن پروژههای دیگر با ارائهدهنده متفاوت برای رقابت در سازمان شما در استفاده از خدمات ابری باشد.
اگرچه ممکن است از ارائه دهنده ابری که با آن شروع کرده اید راضی باشید، فروشندگان دیگر ممکن است برای انواع خاصی از حجم کاری بهتر باشند. این باعث می شود از یک رویکرد کاربردی یا بهترین روش استفاده شود. برای مثال، اگر فکر میکنید که یک ارائهدهنده خاص ممکن است انتخاب خوبی برای بارهای کاری مربوط به یادگیری ماشینی و تجزیه و تحلیل باشد، ممکن است از این رویکرد استفاده کنید و سعی کنید آن نوع حجم کاری را به سمت آن فروشنده هدایت کنید.
ممکن است شما یک محیط چند ابری داشته باشید، شاید در نتیجه ادغام و اکتساب. اگر چنین است، یک رویکرد مدیریت چند ابری را ابداع کنید، که با “تک شیشه ای” شروع کنید تا بتوانید مدیریت این محیط های مختلف را از فروشندگان مختلف آغاز کنید.
آخرین چیزی که می خواهید یک استراتژی ابری است که به صورت رایگان توسط یک ارائه دهنده ابر برای شما انجام می شود. در عوض، از اشخاص ثالث – حتی ارائه دهنده ابر – برای پیاده سازی استفاده کنید. این می تواند یک راه مقرون به صرفه برای به دست آوردن مهارت های کمیاب ابری مورد نیاز سازمان شما باشد.
ارائه دهندگان ممکن است استراتژی های ابری را برای مشتریان بر اساس انتقال از 30 درصد حجم کاری خود در فضای ابری به 40 درصد در سال آینده، برای مشتریان تبلیغ کنند. چنین اقداماتی معمولاً با استراتژی یک ارائه دهنده بیشتر از استراتژی شما همسو هستند – شما نباید استراتژی ابری را بر اساس آنها قرار دهید. تنها زمانی که باید از چنین اقداماتی استفاده کنید این است که یک استراتژی مرکز داده دارید که مثلاً میگوید باید دو سال دیگر از مرکز داده خارج شوید. در چنین مواردی، این نوع اقدامات می تواند مفید باشد.
با کار کردن با “کتاب آشپزی استراتژی ابری، 2019″، استراتژی خود را طراحی کنید. گارتنر اینجاست تا از شما حمایت کند. ما می توانیم از طریق خدمات استعلام خود به طور مداوم با شما کار کنیم.
ابتدا ابر (یا همان طور که دولت ایالات متحده، مبتکر این اصطلاح، اکنون آن را «هوشمند ابری» مینامد) یک اصل عالی برای بسیاری از سازمانها است. شما باید آن را برای گنجاندن در استراتژی ابری خود در نظر بگیرید. رویکرد Cloud-first به این معنی است که اگر شخصی درخواست سرمایهگذاری کند و معیارهای مربوطه را برآورده کند، مکان پیشفرض برای ساخت یا قرار دادن این چیز جدید در ابر عمومی است. آنها به دلیل خوبی نیاز دارند تا آن را در جای دیگری قرار دهند. اما اصل اول ابر نباید مردم را مجبور به استفاده از ابر کند. این یک سیاست فقط ابری است.
با این حال، صرف بیان اینکه سازمان ابتدا ابری است یا ابر هوشمند است، یک استراتژی کل ابری نیست. این تنها یک جنبه آن است. هنگام طراحی استراتژی خود، توصیه های «کتاب آشپزی استراتژی ابری، 2019» را دنبال کنید.
منبع: www.gartner.
آخرین دیدگاهها