قسمت اول: مدرن‌سازی معماری نرم‌افزار

1. مقدمه:

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

در سال 2022 یک سیستمِ برنامه‌ریزیِ قدیمی، بحرانی بزرگ ایجاد کرد. در یک هفته، 14500 پرواز لغو شد و برند آن‌ها آسیب‌های غیرقابل جبرانی دید. آن‌ها به دلایلی اشتباه، تیتر یک اخبار بین‌المللی شدند.

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

شاید به نظر برسد با افزایش سن، شرکت‌ها و کسب‌وکارشان از یک استارت‌آپ چابک به شرکتی قدیمی، سنگین و سخت با معماری قدیمی تبدیل می‌شوند و این تغییر شرایط اجتناب‌ناپذیر است. اما Netflix ثابت کرد که تغییر این شرایط امکان‌پذیر است. آن‌ها در سال 2009 تغییرات عمده‌ای در کار خود ایجاد کردند. آن‌ها نرم‌افزار خود را از یک نرم‌افزار با معماری Monolith به چندین نرم افزار با معماری Microservice مهاجرت دادند تا قابلیت‌های رقابتی خود را در بازار Streaming حفظ کنند. آقای Adrian Cockroft که آن زمان به عنوان CTO در شرکت Netflix مشغول به کار بود دلیل خود برای این تغییر را اینگونه بیان کرد:

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

در صورت تمایل می‌توانید به این پادکست گوش کنید.

به عقیده‌ی من، هر رهبری باید دائما از خود سولاتی بپرسد که در آن زمان در Netflix نیز پرسیده شد:

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

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

2. معماری مدرن مبتنی بر جنبه‌های فنی و اجتماعی:

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

شاید مدرن‌سازی Netflix ظاهرا یک تلاش کاملاً فنی به نظر برسد. به هر حال، آن‌ها با شکستن نرم‌افزار خود از یک معماری یکپارچه به تعداد زیادی نرم‌افزار کوچک با معماری میکروسرویس، یک الگوی معماری جدید را به کار بردند. اما اگر به دقت نگاه کنید، درخواهید یافت که میکروسرویس‌ها یک الگوی معماریِ اجتماعی- فنی هستند. مزایای این الگوی معماری به یک اندازه فنی و سازمانی است. Sam Newman، نویسنده‌ی Building Microservices (O’Reilly)، این مورد را به خوبی توضیح می‌دهد.

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

مطلب کاملی در این زمینه منتشر شده که می‌توانید آن را اینجا مطالعه کنید.

میکروسرویس‌ها تنها سبکِ معتبرِ معماری برای ما نیستند. صرف‌نظر از الگوها و فناوری‌هایی که استفاده می‌کنیم، یک رویکرد و معماری اجتماعی- فنی برای دستیابی کامل به پتانسیلِ سرعت رسیدن به بازار (speed-to-market) برای سازمان‌ها ضروری است. همان‌طور که Sam Newman تاکید کرد، تیم‌ها برای تغییر و استقرار کدِ خود، بدون وابستگی و نیاز به هماهنگی با دیگران نیاز به استقلال دارند. این جریان در سال‌های اخیر به‌ویژه با انتشار کتاب (Team Topologies (IT Revolution در سال 2019 بسیار مورد توجه قرار گرفته است و به یکی از مفاهیم داغ برای گفتگو در محافل مختلف بدل شده است و توسط بسیاری از سازمان‌ها از Docker گرفته تا دولت نروژ، پذیرفته شده است.

توپولوژیِ تیم‌ها، ابزاری برای سازمان‌هایی است که قصد دارند تغییرات سریع و مکرر را در برنامه‌های خود ایجاد کرده و جریان سریعی از ارزش‌ها را در کسب و کار خود اعمال کنند. در عمل این جریان سریع اغلب به این معنی است که تیم‌ها کد را به‌صورت روزانه یا چند بار در طول روز در محیط عملیاتی استقرار می‌دهند. توپولوژی‌ تیم‌ها عمدتاً بر جنبه‌های اجتماعیِ معماریِ اجتماعی-فنی تمرکز دارد که از آن به عنوان تفکر اول تیم (Team-First Thinking) و مرزهای اول تیم (Team-First Boundaries) یاد می‌شود. معماری نرم‌افزار نیز باید توسط الزامات سازمانی برای دستیابی به جریان سریع به سمت این دیدگاه هدایت شود.

یکی از مفاهیم اساسیِ معماری در توپولوژی‌های تیمی، جریان ارزش (Value Stream) است. جریانِ ارزش، دنباله‌ای از مراحل است که تیم برای کشف نیازهای برآورده نشده کاربران، طراحی راه‌حل‌ها برای آن نیازها، پیاده‌سازی آن راه حل‌ها در قالب نرم‌افزار و ارائه آن ارزش به مشتریان طی می‌کند. تیمی که مسئول یک جریان ارزش است، تیم همسو با جریان (Stream-aligned Team) نامیده می‌شود. شکل زیر نمای کلی و سطح بالا از یک جریان ارزش را ارائه می‌دهد:

دستیابی به جریانی سریع، نیازمند این است که معماری به گونه‌ای باشد که جریان‌های ارزش از هم مستقل باشند. این بدان معناست که تیم، در تصمیم‌گیری در مورد جریان ارزش خود بیشترین اختیار را دارد. مثلا تیم می‌تواند تصمیم بگیرد چه چیزی بسازد، چگونه آن را ساخته و سپس به کار گیرد. این نکته اشاره به این مسئله دارد که شما آن را می‌سازید و شما آن را اجرا می‌کنید ( You Build It, You Run It). برای اینکه این مدل به درستی کار کند، تیم‌ها باید مالک نرم‌افزار برای جریان ارزش خود باشند. تیم‌ها روی انتشار نرم‌افزار خود نیز باید کنترل داشته باشند و برای این کار به سایرین وابسته نباشند. در این روش به جای اینکه تیم‌ها را با ویژگی‌ها و الزامات مربوط به پیاده‌سازی بسنجیم آن‌ها را بر اساس نتایج تجاری، مانند OKRها سنجش خواهیم کرد. یک ضدالگوی معروف در این کار که بعضا تیم‌ها به سمت آن میل پیدا می‌کنند، Feature Factory است.

حال که دریافتیم باید جریان‌هایی از ارزش‌های‌ مستقل داشته باشیم که مالک آن‌ها، تیم‌های مستقل است، مهم است که بتوانیم این جریان‌های ارزش را شناسایی کنیم. تصویر بعد، نحوه‌ی شناسایی جریان‌های ارزش مستقل را نشان می‌دهد. ابتدا کار خود را با شناسایی زیردامنه‌های تجاری (Business Subdomains، معروف به زیر دامنه‌های کسب‌وکار، مناطقی از کسب‌وکار که به اندازه کافی کوچک هستند تا یک تیم واحد داشته باشد) که قرار است در آن سازمان جریان ارزش ایجاد کند، شروع می‌کنیم. مواردی که شناسایی کردیم را جریان‌های ارزش کاندید (Candidate Value Streams) می‌نامیم. سپس جریان‌های ارزش کاندید از سه دیدگاه مختلف یعنی استراتژیک، سازمانی و فناوری ارزیابی می‌شوند. اگر این دیدگاه‌ها با موفقیت تأیید شوند، جریان ارزش به عنوان یک جریان ارزش هدف در نظر گرفته می‌شود، به این معنی که اطمینان کافی وجود دارد که یک جریان ارزش مستقل خواهد بود و نوسازی آن می‌تواند آغاز شود. در طول این فرایند، احتمالاً اصلاحات زیادی وجود دارد. اغلب، مسائل و مشکلات عمیقی ممکن است ظاهر شوند. مسائلی مانند عدم همسوییِ استراتژیک بین سهامداران یا مسائل و مدل‌های تامین مالی. این مسائل باید قبل از ایجاد تغییرات ساختاری مورد توجه قرار گیرند. این کار یک فرایند یا چک لیست ساده نخواهد بود که خیلی راحت و بدون دردسر از بالا تا پایین تیک بزنیم و به پایان آن برسیم.

3. معماری، همسو با دامنه تجاری:

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

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

یکی از مؤثرترین راه‌ها برای ترسیمِ دامنه‌ی تجاری و شناساییِ زیر دامنه‌های آن، تکنیکی به نام Event Storming است. Event Storming یک تکنیک است که در آن افرادی که درگیر ساختِ یک محصول هستند، از گروه‌های متنوعی مانند مهندسان نرم‌افزار، مدیران محصول، طراحان UX، متخصصان QA، و ... گرد هم می‌آیند و به‌طور گروهی نقشه‌برداریِ بخشی از کسب‌وکار را با استفاده از رویدادهای دامنه (Domain Event) در طول یک بازه زمانی انجام می‌دهند. پس از اینکه گروه بازه زمانی را با رویدادهای دامنه ترسیم کرد، رویدادها را می‌توان به زیر دامنه‌ها تقسیم کرد.

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

4. مدل‌های عملیاتیِ محصول‌محور:

معماری مدرن برای توانمندسازی مدل‌های عملیاتی مدرن ضروری است. در گذشته، نرم‌افزار به‌صورت پروژه‌محور ساخته می‌شد. در آن روش، تیم محدوده‌ای از پیش تعیین‌شده در بازه زمانی معلوم شده از قبل و در چارچوب بودجه محدود ارائه می‌کرد. امروزه، سازمان‌ها به سمت مدل‌های عملیاتی و محصول‌محور حرکت می‌کنند که در آن تیم‌هایِ توانمندِ محصول، حولِ نتایج کسب‌وکار متمرکز می‌شوند، به مشتریان نزدیک‌تر می‌شوند و تصمیمات خود را برای محصول می‌گیرند. کارشناسان مدیریت محصول مانند Teresa Torres، Melissa Perri و Marty Cagan بر این عقدیه هستند که تیم‌ها باید به‌صورت منظم مثلا هر هفته با مشتریان خود صحبت کنند.

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

حرکت به سمت مدل عملیاتیِ محصول‌محور ابتدا با تعریفِ واضح محصولات سازمان آغاز می‌شود و سپس با نحوه‌ی مواجهه با مشتری و تیم‌های داخلی، همراه با نتایجِ کسب‌وکار و مشتری‌ای که هر محصول به آن کمک می‌کند، ادامه می‌یابد. این کار به‌عنوان طبقه‌بندی محصول (Product Taxonomy) شناخته می‌شود و پایه و اساس ساختار سازمانی و معماری نرم‌افزار است. تمام جریان‌های ارزشی که به یک محصول معین کمک می‌کند، با ستاره شمالی (North Star) محصول همسو خواهند شد و همان‌طور که در تصویر زیر نشان داده شده است، به رهبران محصول و فناوری اطلاعاتی ارزشمند می‌دهد.

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

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

5. محدوده‌های معماری:

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

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

هنگام کار در محدوده 2 و بالاتر، به دلیل پیچیدگیِ تیم‌هایِ متعدد، پاسخ به بسیاری از سوالات معماری دشوار است:

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

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

6. پلتفرم‌های توسعه‌دهنده داخلی:

مرزهای دامنه‌ی خوب، وابستگی در تغییر را کاهش می‌دهد و منبع کد جدا شده، تیم‌ها را قادر می‌سازد تا تغییرات کد را بدون وابستگی و اصطکاک انجام دهند. با این حال، یک جنبه‌ی حیاتی دیگر وجود دارد که برای استخراج ارزش از یک معماری مدرن و فعال کردن جریان سریع تغییرات ضروری است: توانایی تیم‌ها برای تغییر آسان و سریع کدشان و استقرار و پشتیبانی از آن در محیط عملیاتی. اینجاست که پلتفرم‌های توسعه‌دهنده داخلی (Internal Developer Platforms یا IDP) وارد فرایند مدرن‌سازی معماری می‌شوند.

در اصطلاحات توپولوژی تیم، هدف یک پلتفرم، کاهش بار شناختی، ظرفیت شناختی جمعی و تیم‌های همسو با جریان است. یک IDP ابزارهایی را در اختیار تیم قرار می‌دهد که تیم‌ها برای ایجاد، توسعه و پشتیبانی از برنامه‌های خود به آن‌ها نیاز دارند. یک IDP خوب این قابلیت‌ها را از طریق یک تجربه توسعه‌دهنده خاص(Developer Experience یا DX) به نمایش می‌گذارد، به این معنی که استفاده از پلتفرم به دلیل مستند بودن و سلف‌سرویس بودن آن، آسان است. وقتی تیم‌ها می‌خواهند برنامه‌های جدید ایجاد کنند یا کدی را مستقر کنند، فرایند باید یکپارچه و ساده باشد و نیازی به برقراری ارتباط با تیم پلتفرم یا هر تیم دیگری وجود نداشته باشد. این فرایند ارائه‌ی قابلیت‌های مورد نیاز تیم‌ها و یک DX خوش‌تعریف و خوب، اغلب به عنوان جاده سنگ‌فرش (Paved Road) یا مسیر طلایی (Golden Path) شناخته می‌شود.

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

7. مدرن‌سازی معماری سفری در یک مسیر است نه مقصد:

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

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

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

یکی از خطرات اصلی در هر سفر مدرنیزه شدن، تمام شدن انگیزه و بازگشت به کارهای معمولی و عادت‌های قدیمی است. برای حفظ شتاب بالا، باید یک تیم توانمندسازیِ مدرنیزاسیونِ معماری ( Architecture Modernization Enabling Team یا AMET) ایجاد شود. این تیم هدفش این است که با همکاری و رهبری اولویت‌های استراتژیک را تعیین کرده و از طرق مختلف از تیم‌ها در این سفر حمایت کنند. مثلا اگر تیمی با Event storming آشنا نیست مدتی به عنوان تسهیل‌گر در کارگاه‌های Event Storming حضور یابند. اگر تیمی مشکلی با تکنولوژی‌ها و معماری‌های مدرن دارد، مدتی به عنوان مربی‌ توسعه نرم‌افزار در این تیم‌ها حضور یابد. در مجموع با حمایت‌های خود شتاب سفر را بالا نگه دارد. AMET همچنین بر ایجاد شیوه‌های معماری پایدار و پرورش تغییرات پایدار متمرکز است که حتی پس از پایان مدرن‌سازی نیز ادامه می‌یابد.

در این نوشته‌ها اصول و تکنیک‌های زیادی برای پیمودن یک سفر مدرن‌سازی ارائه خواهد شد اما یک راهنمای گام به گام یا یک چارچوب سفت و سخت ارائه نخواهیم کرد. شما همیشه باید به انواع سوالات زیر فکر کنید و در نهایت تصمیم نهایی را خودتان بگیرید:

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

مطمئن باشید، تکنیک‌ها و مفاهیم این نوشته مانند Event Storming، Wardley Mapping و Team Topologies امتحان و آزمایش شده است. این تکنیک‌ها شما را در شرایط بسیار خوبی قرار می‌دهند تا به این سوالات پاسخ دهید و در هر مرحله از سفر، تصمیم درستی بگیرید.

8. پی‌نوشت:

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

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