مدرن سازی معماری نرم افزار در کسب و کارها

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

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

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

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

• آیا می‌خواهید محصولاتی جدید تولید کرده و در بازارهای جدید ورود کنید یا قصد دارید نفوذ خود را در بازارهای موجود ازطریق افزایش کیفیت محصولات افزایش دهید؟
• آیا دغدغه شما، سرعت نوآوری است؟
• آیا قصد دارید هزینه‌های عملیاتی را کاهش دهید؟
• آیا می‌خواهید مقیاس‌پذیریِ سیستم را، برای اطمینان از عملکرد صحیح آن در هنگام رشد سریع تعداد کاربران بهبود ببخشید؟

به خاطر داشته باشید که توجیه و مسیر تجاریِ کامل برای کل سفرِ مدرن سازی معماری نرم افزار در کسب و کارها، در ابتدای کار نیاز نیست. براساس روش های مدرن سازی معماری نرم افزار، اولین گام را می‌توان تنها در سه ماه انجام داد. مثلاً می‌توانید در عرض سه ماه، اولین میکروسرویس را از یک نرم‌افزار یکپارچه استخراج کنید؛ در حالی که ابتکار دیگری در بخش دیگری از کسب و کار درحال شکل‌گیری است.

دلایل کسب‌ و کاری برای مدرن سازی معماری نرم افزار در کسب و کارها

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

• بنابراین منصفانه است که بگوییم نگران از دست دادن زمین در برابر رقبای سریع نیستید و ما باید ۱۰۰٪ روی کاهش هزینه‌های عملیاتی تمرکز کنیم؟
• بزرگترین تهدیدهایی که از خارج از سازمان می‌بینید، چه چیز‌هایی هستند؟ مانند رقبای سریع‌تر یا تغییر نحوه هزینه کردنِ مصرف کننده؟
• محصول ما چقدر منحصربه‌فرد است؟
• آیا فکر می‌کنید که می‌توان آن را به‌راحتی توسط شرکت‌های دیگر دوباره ایجاد کرد؟

عقب ماندن از رقبای سریع

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

موفقیت، اینرسی ایجاد می‌کند و هرچقدر در گذشته موفق‌تر بوده‌ باشیم، اینرسی افزایش می‌یابد.

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

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

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

در قسمت‌های آینده در مورد Wardley Mapping صحبت خواهیم کرد. Wardley Mapping بر تکامل چشم‌اندازهای کسب و کار و شناسایی بخش‌هایی تمرکز می‌کند که مزیت‌هایی را در آینده ایجاد خواهد کرد و یا احتمال بروز اختلال و مشکل در آن بخش‌ها وجود دارد. متأسفانه، رهبرانِ کسب و کار معمولاً به مدرن سازی معماری نرم افزار در کسب و کارها ، زمانی که ریسکی در بازه‌ی زمانی خیلی نزدیک آن‌ها را تهدید نمی‌کند، توجه نمی‌کنند. آن‌ها فکر می‌کنند که چرا باید پول سرمایه‌گذاری کرده یا ارائه ویژگی‌های جدید را کند کنند، در حالی که هیچ خطر فوری‌ای وجود ندارد؟ این یک شکل رایج از اینرسی است که Wardley Mapping با تمرکز بر تکاملِ طولانی‌مدت به آن می‌پردازد.

• یک مثال واقعی: رهبر بازار خدمات مالی

سازمانی از من خواست که با CTO در فرایند مدرن سازی معماری همکاری کنم. کار در این زمینه برای من بسیار جذاب بود. آن‌ها بیش از یک دهه در بازار پیشرو بودند و همیشه در صدر رتبه‌بندی‌های صنعت قرار داشتند. این امر باعث ایجاد اینرسی شده بود. وقتی به گوشه و کنار شرکت نگاه می‌شد، یک ذهیت در آن جاری بود: هر بهینه‌سازی‌ای باید در جهت ثبات، امنیت و اجتناب از خطرات باشد. آن‌ها فکر می‌کردند تا زمانی که سیستم آنلاین بوده و مشتریان بتوانند از آن استفاده کنند، به لطف برندِ بسیار معتبر خود، پیشتاز و رهبرِ بازار باقی خواهند ماند. در حالی که نتایج کسب و کاری خوب بود، داخلِ سازمان عملکرد ضعیفی داشت. عواملی مانند سیاست‌های امنیتی سخت، فرآیندهای توسعه بسیار محدودکننده، سرمایه‌گذاریِ اندک در بازپرداختِ بدهی‌های فنی و سبک مدیریت از بالا به پایین، منجر به ایجاد محیطی شده بود که در آن، مهندسان دائماً سر خود را به دیوار کوبیده و سعی می‌کردند کارهای ساده‌ای را به‌سختی انجام دهند. به وضوح ارتباط بین تیم‌های توسعه و عملیات ضعیف بود.

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

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

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

• یک مثال واقعی: Open Table

این مثال در مدرن سازی معماری نرم افزار در کسب و کارها از زبان آقای Orlando Perri بیان شده است که بین سال‌های ۲۰۱۰ تا ۲۰۱۵ در OpenTable مشغول به کار بوده است.

در سال ۲۰۱۱ شرکت OpenTable در زمینه رزرواسیون رستوران، پرچم‌دار بازار بود و رقیب چندانی نداشت. اما شرایط با ورود رقیبانی مثل Yelp کم کم تغییر کرد. ایده‌های زیادی در OpenTable بود تا آن‌ها را کماکان پرچم‌دار بازار نگه دارد اما گلوگاه‌هایی در مهندسی وجود داشت. رقیبان با سرعت زیادی ویژگی‌هایی را به سازمان‌‎های خود اضافه می‌کردند، در حالی که خلاقیت به خرج دادن و اضافه کردن آن به نرم‌افزار موجود در OpenTable، به کندی پیش می‌رفت. در آن زمان بیش از صد نفر مهندس در OpenTable روی یک نرم‌افزار با معماری یکپارچه و انبوهی از مشکلات مشغول به کار بودند. بخش‌های مختلف به‌شدت به هم وابستگی داشتند و این وابستگی، توسعه را بسیار پرریسک و سخت کرده بود. برای توسعه یک ویژگی جدید با توجه به نیاز به تست‌های دستی بسیار و وابستگی شدید به حداقل ۴ هفته زمان نیاز بود.

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

در مقطعی از کار، زمانی که تیم مدتی تلاش کرد تا ویژگی جدیدی را به برنامه اضافه کند و هر بار انجام کار ناموفق به پایان رسید، بالاخره تیم مدیریتی تصمیم مهمی گرفت. آن‌ها تصمیم گرفتند مدرن‌سازی را انجام دهند و برای این کار، تصمیم بر این شد که تمامی کارهای جدید متوقف شده و تیم مهندسی تمرکز خود را برروی مدرن سازی معماری قرار دهند. این تصمیم زمانی گرفته شد که یک CTO جدید به سازمان اضافه شده بود و او نیز تیم‌ها و افراد توانمندی را در زمینه‌های DevOps، Continuse Delivery و DDD به تیم اضافه کرد.

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

شاید به نظر برسد توقف همه کارها و تمرکز روی مدرن سازی معماری نرم افزار در کسب و کارها ، مانند کاری که در OpenTable انجام شد، تصمیم درستی باشد؛ اما باید دقت کرد که این تصمیم‌گیری در بسیاری از کسب و کارها سخت و بعضاً غیرممکن است و باید به‌دنبال راهکارهای تدریجی باشیم. چندین عامل کلیدی در به ثمر رسیدنِ این حرکت برای OpenTable نقش داشتند، اگر بخواهیم مهم‌ترین عوامل را نام ببریم، عبارتند از:

• قبل از شروع کار، آن‌ها در به ثمر رساندن یک هدف تجاری ناموفق بودند و این، خود دلیل محکمی بود که مدرن‌سازی برای آن‌ها ارزشمند است.
• افراد جدیدی که به سازمان اضافه شدند، از کیفیت بالایی برخوردار بودند.
• توقف توسعه ویژگی‌های جدید برای هشت ماه بدون عواقب شدید تجاری امکان‌پذیر بود.

 

معماری رشد کسب و کار را خفه می کند

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

چهار استراتژی رشد مهم وجود دارد که باید از آن‌ها آگاه باشید:

• نفوذ در بازار
• توسعه بازار
• توسعه محصول
• تنوع محصول

هر یک از این چهار استراتژی ممکن است در هر مقطع زمانی در کسب و کار شما مطرح باشد. استراتژی‌های رشد و نحوه ارتباط آن‌ها به موارد کسب‌وکاریِ نوسازی، در ادامه جزئیات بیشتر پوشش داده می‌شود.

دنبال کردن استراتژی خروج

هدف استراتژیک کلیدی برای برخی از کسب و کارها، دستیابی به یک استراتژی خروج است. مانند خرید توسط شرکتی دیگر یا عمومی شدن با یک IPO (initial public offering – عرضه عمومی اولیه). به‌عنوان مثال، در اوایل سال ۲۰۲۲، مدیرعامل یکی از کسب و کارهایی که با آن‌ها همکاری داشتم، برایم توضیح داد که هدف او این است که شرکت را برای خریداران، جذاب جلوه داده و ظرف سه سال شرکت را به فروش برساند. به همین دلیل، هنگامی که درباره مدرن‌سازی معماری صحبت می‌کردیم، او فقط به بحث درمورد ابتکاراتی علاقه داشت که در آن بازه زمانی تأثیرگذار باشد. هر پیشنهادی که در بازه زمانی کوتاه یا میان‌مدت قابل دستیابی نبود، اصلاً موردتوجه قرار نمی‌گرفت. رهبران فناوری و مهندسان، هنگامی متوجه این موضوع شدند که برای جدا کردنِ یک پایگاه داده غول‌پیکر، که در بخش‌های مختلفی از کسب و کار نفوذ کرده بود، نیاز به زمان و منابع بیشتری بود اما کسب و کار در این مورد همراهی نمی‌کرد.

به هرحال، مالکان کسب و کار به‌دنبال خروج از این شرکت در عرض سه سال بودند و تصمیم داشتند مدرن‌سازی معماری هم در این بازه زمانی محدود باشد. در ذهن داشته باشید که مدرن سازی معماری نرم افزار در کسب و کارها می‌تواند کمک کند که شرکت جذاب‌تر به نظر رسیده و ساده‌تر به هدف مالکان، که خروج از کسب و کار است، دست پیدا کرد. موقع گفتگو با یکی از معماران او به من گفت:

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

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

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

برای رهبران مدرن سازی معماری نرم افزار در کسب و کارها حیاتی است که شرکت‌ها را با معیارهایی مانند آنچه که در بالا ذکر شد نیز مورد بررسی قرار دهند؛ به‌خصوص زمانی که می‌خواهند موارد کسب و کاری خاص را برای مدرن‌سازی کنار هم قرار دهند. با این کار، نه‌تنها بهتر می‌توانید ابتکارات مدرن‌سازی را اولویت‌بندی کنید، بلکه می‌توانید بهتر به زبان کسب و کار صحبت کرده و اعتبار خود را نیز بهبود ببخشید. برای شروع درک این موارد، کتاب Financial Intelligence گزینه خوبی است.

رشد با خرید و اکتساب سایر کسب و کارها

ادغام و اکتساب (Mergers and acquisitions – M&A) برای برخی از کسب و کارها نقشی کلیدی دارد. استراتژی‌های رشد متفاوتی با ادغام و اکتساب می‌تواند در نظر گرفته شود. مثلاً برای افزایش نفوذ در بازار ممکن است یکی از رقبا را خریداری کنید. یا ممکن است کسب و کاری را در بازار دیگری به‌دست آورده تا بتوانید تنوع بهتری در کسب و کار داشته باشید. برای مثال، Salesforce با قیمت ۲۷ میلیارد دلار Slack را در سال ۲۰۲۱ خریداری کرد. Salesforce بر این عقیده بود که خرید Slack به آن‌ها کمک می‌کند که پیشنهاد‌های بهتری در دوران جدیدی که برای کار کردن به‌صورت ریموت ایجاد شده است را ارائه کنند. مثال دیگری در این حوزه‌ نیز خریده شدن Github توسط مایکروسافت در سال ۲۰۱۸ به قیمت هفت میلیارد دلار است که به آن‌ها امکان توسعه‌های خلاقانه‌ای مثل GitHub Copilot یا توسعه به کمک هوش مصنوعی را داد.

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

در چنین شرایطی، شرکت تلاش می‌کند با خرید راهکارهای بیرونی و ارائه یکپارچه آن‌ها، ابتکاراتی را در حوزه کسب و کار وارد کند و از منظر فناوری اطلاعات نیز برای حمایت از این تصمیمات و پیشبرد اهداف شرکت، راهکارهایی مثل ارائه هویت و واحد و متمرکز وجود دارد اما تعداد زیاد تیم و تکنولوژی‌های متعدد، فرآیند تغییر اولیه را کند می‌کند. چالش دیگری نیز در این شرایط وجود خواهد داشت. برای مثال، ممکن است تیم‌ها جایگاه خود در تصویر بزرگی که ایجاد می‌شود را تشخیص ندهند، در برخی قسمت‌ها، سیلوهایی ایجاد و یا کارهای تکراری و پراکنده در قسمت‌های مختلف انجام شود، بعضاً ممکن است در انتخاب تکنولوژی و ایجاد زیرساخت نیز چالش‌هایی به‌وجود آید. همه شرکت‌هایی که استراتژی M&A را در پیش می‌گیرند، در مقیاس Salesforce فعالیت نمی‌کنند اما برخی یا همه این چالش‌ها، احتمالاً تا حدی برای همه وجود خواهد داشت. در نتیجه، ممکن است برای شناسایی معماری بهینه پس از خرید یک کسب و کار، بازنگری اساسی در محصولات، دامنه‌ها، نرم‌افزارها و تیم‌ها موردنیاز باشد. برای تعمق در این موضوع، سخنرانی Ora Egozi Barzilai از MuCon 2019 را مشاهده کنید. وی تجربیات خود را در رهبریِ چندین تکرار برای مدرن‌سازی معماری در Taboola در سال ۲۰۱۶ پس از یک خرید کلیدی را بازگو می‌کند.

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

تجربه کاربری، (UX) ضیعف، شرکت را عقب نگه می دارد

در بعضی از محصولات، UX می‌تواند موجب موفقیت یا عدم موفقیت کل مدل کسب و کار شود. هنگامی که UX ایراد دارد، صرفاً طراحی مجدد وب‌سایت یا نرم‌افزار ممکن است کافی نباشد. در مواردی که UX چنین تأثیر عمیقی دارد، مدرن سازی معماری نرم افزار در کسب و کارها نیز ممکن است ضروری باشد.

یکی از راه‌هایی که معماری می‌تواند عاملی اساسی در UX ضعیف باشد، غیرقابل اعتماد بودن است. آقای Dan Young تجربه‌ای در این زمینه دارند که در ادامه مطالعه می‌کنیم.

در پاییز سال ۲۰۲۱، او سعی داشت سامانه‌ی اجاره ماشین را در اختیار بگیرد و در نهایت، موفق به در اختیار گرفتن سه گزینه شد. این گزینه‌ها UX ضعیفی داشتند که ناشی از مشکلات معماری بود. روزی از وب‌سایت از او خواستند تا فرآیند پرداخت را یک بار بررسی کند؛ زیرا حتی هنگامی که رزرو خودرو با موفقیت انجام می‌شود، بازهم بک اند خطا بازگشت می‌دهد. شرکت پیشنهاد داد وجه یکی از رزرو‌هایی که خطا در آن موجب استرس زیادی برای دن شده بود را بازگشت دهند که این باعث خدشه‌دار شدن وی شود.

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

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

ابزارها و فرآیندهای داخلی ناکارآمد

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

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

بهبود شرایط استخدام و ماندگاری

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

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

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

ایجاد ارتباط بین استراتژی های رشد و مدرن سازی معماری نرم افزار در کسب و کارها

در این بخش به استراتژی‌های رایج رشد کسب‌وکار و انواع چالش‌های مدرن سازی معماری نرم افزار در کسب و کارها خواهیم پرداخت. این استراتژی‌های رشد T مبتنی‌بر ماتریس آنسوف بوده که در شکل نشان داده شده است. ماتریس آنسوفیک شبکه ۴×۴ است که رشد را براساس محصولات جدید در برابر محصولات موجود و بازارهای جدید در برابر موجود طبقه‌بندی می‌کند. توجه کنید که در یک سازمان، تمام یا بخشی از این استراتژی‌ها ممکن است وجود داشته باشند. همچنین شایان ذکر است که نیاز نیست تلاش کنید همه چیز در یکی از این چهار قسمت قرار بگیرد؛ درعوض، از ماتریس به‌عنوان شروع‌کننده مکالمه استفاده کنید.

استراتژی های رشد: توسعه محصول

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

با این نوع استراتژی رشد در مدرن سازی معماری نرم افزار در کسب و کارها ، شرکت درحال توسعه محصولات جدیدی است که احتمالاً شباهت‌هایی به محصولات موجود دارند؛ زیرا همان افراد را هدف قرار داده است. چند نکته‌ی معماریِ واضح که باید در مورد آن‌ها فکر کرد، عبارتند از:

• قابلیت‌های مشترک
• یکپارچه‌سازی محصول
• ایجاد تعادل بین سرمایه‌گذاری جدید و قدیمی

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

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

هنگامی که مشتریان از محصولات یک شرکت استفاده می‌کنند، معمولاً انتظار دارند هم‌افزایی و یکپارچگی وجود داشته باشد. شرکت Salesforce و محصولاتش را در نظر بگیرید؛ مشتریان آن‌ها از اینکه مجبور بودند چندین نام کاربری و رمز عبور برای محصولات مختلف داشته باشند، بسیار ناراحت و سرخورده بودند. سؤالی که زیاد پرسیده می‌شد، این بود که ما درحال استفاده از محصولات Salesforce هستیم؛ چرا باید برای هر محصول، نام کاربری و کلمه عبور مجزا داشته باشیم؟

همچین ایراداتی باید در سطح معماری رفع و رجوع شود. شرایطی باید ایجاد شود که امکان ادغام ویژگی‌های مشترک وجود داشته باشد و برای این کار، نیاز به صرف هزینه در رابطه با اصلاح و مدرن سازی معماری نرم افزار در کسب و کارها است.

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

• یک مثال واقعی: توسعه محصولات دریایی

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

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

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

استراتژی های رشد: نفوذ در بازار

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

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

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

قبلاً درمورد ارائه‌ی ارزش‌های مدرن سازی صحبت کرده‌ایم و در این قسمت مشاهده می‌کنید که چگونه ممکن است در یک کسب و کار نیاز باشد جهت‌گیری‌های متفاوتی برای مدرن‌سازی براساس بازار موجود یا جدید انجام داد و باید این موارد به‌خوبی انتقال یابد تا تصمیم صحیح گرفته شود.

• یک مثال واقعی: نفوذ در بازار بانک های چلنجر آمریکای لاتین

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

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

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

استراتژی های رشد: توسعه بازار

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

• یک مثال واقعی: توسعه بازار شرکت خدمات مسافرتی در زمان کرونا

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

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

استراتژی های رشد: تنوع بخشی

در مدرن سازی معماری نرم افزار در کسب و کارها استراتژی رشد بر مبنای تنوع، روی راه‌اندازی محصولات یا خدمات جدید در بازار یا بازارهایی که سازمان در حال حاضر آن را هدف قرار نمی‌دهد، متمرکز است. یکی از سازمان‌هایی که به‌طور مداوم از تنوع تهاجمی برای موفقیت فوق‌العاده استفاده می‌کند، آمازون است. آمازون در ابتدا یک کتاب‌فروشی بود که به یک غول خرده‌فروشی تبدیل شد، سپس تجارت ابری AWS خود را تأسیس کرد که به تنهایی بیش از ۶۰ میلیارد دلار در سال ۲۰۲۱ درآمد داشت.

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

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

مضامین مدرن‌سازی معماری که قبلاً ذکر شد، ممکن است در یک استراتژی متنوع‌سازی نیز کاربرد داشته باشند: قابلیت‌های مشترک، یکپارچه‌سازی، ذهنیت‌های متنوع، مدل‌های دامنه عمومی در مقابل بازار خاص و تضادهای اولویت‌بندی سرمایه‌گذاری.

• یک مثال واقعی: تنوع در تجارت الکترونیکی تنظیم شده

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

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

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

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

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

ساختار یک پیشنهاد قانع کننده در مدرن سازی معماری نرم افزار در کسب و کارها

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

نمونه ای از ساختار پروپوزال

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

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

1.  چشم انداز / اهداف / موضوعات تجاری سطح بالا

مثال زیر را در نظر بگیرید:

یک شرکت به‌دنبال دو برابر کردن درآمد در عرض ۵ سال است و هزینه‌های پشتیبانی از مشتری‌ را ۴۰ درصد کاهش دهد.

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

2. سهم دامنه از دیدگاه کسب و کار

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

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

3. اصول فنی و سازمانی

مثال:

ما متعهد به بهبود زمان عرضه به بازار برای محصولات خود هستیم. هدف ما این است که به‌جای نسخه‌گذاری فصلی، روزانه بتوانیم با کیفیت و اعتماد بالا به نسخه‌گذاری بپردازیم.

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

4. مجموعه ای از فرصت ها در دامنه خاص

در این قسمت، لیستی از فعالیت‌هایی که قابلیت سرمایه‌گذاری دارند، همراه با مزایا و معایب هر عضو از لیست، به زبان کسب و کار بیان می‌شود. با این لیست نشان می‌دهید که واقعاً درمورد کل فرآیند و کسب و کار اندیشه کرده‌اید و صرفاً اولین ایده را به‌عنوان بهترین پیشنهاد روی میز قرار نداده‌اید.

5. اقدامات پیشنهادی

در این قسمت، با استدلال‌های کسب و کاری بیان می‌کنید که فارغ از انتخاب‌هایی که در قسمت قبل وجود دارد، اقدام منتخب یا پیشنهادی شما چیست؟

6. تغییرات معماری

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

7. بیان خواسته ها

نیازمندی‌های خود برای به ثمر رساندن کار را در این قسمت بیان می‌کنید. زمان، افراد، پول، محدودیت‌ها و سایر سرمایه‌گذاری‌هایی که برای اجرای موفقیت‌آمیز اقدامات خود نیاز دارید را بیان کنید. مثلاً قید کنید که چه بودجه‌ای برای استخدام یک تیم و تضمینی که آن‌ها ۱۰۰٪ به این کار اختصاص خواهند داد، نیاز دارید.

8. سؤالات برجسته، ناشناخته ها و خطرات

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

9. جدول زمان‌ بندی

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

ارزش، بهتر، زودتر، ایمن تر، شادتر

یکی دیگر از ابزارهای ساده و مؤثر برای ساختن ارائه‌های متقاعد کننده در مدرن سازی معماری نرم افزار در کسب و کارها، استفاده از ارزش بهتر، زودتر ایمن‌تر، شادتر یا (Better Value Sooner Safer Happier – BVSSH) است. نمونه‌ای از این ارائه را در زیر مشاهده می‌کنید:

• بهتر – Better: نشان‌دهنده‌ی بهبود کیفیت و در نتیجه، بهبود کارایی و کاهش زمان صرف شده با حذف دوباره کارها است.
• ارزش – Value: نشان‌دهنده‌ی نتایج کسب و کار، مانند بهبود درآمد یا حفظ مشتری است.
• زودتر – Sooner: نشان‌دهنده‌ی بهبودهای زمان عرضه به بازار مانند توانایی ارائه سریع‌تر ویژگی‌های جدید است.
• امن‌تر – safer: نشان‌دهنده‌ی عواملی مانند حاکمیت، ریسک، انطباق و امنیت است.
• شادتر – Happier: نشان‌دهنده‌ی بهبود زندگی افراد درگیر است. مانند شادتر کردن کارکنان در محل کار به‌دلیل ابزار بهتر.

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

جمع بندی

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