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

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

1. مثال واقعی:

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

نام ICE سرنام International Copyright Enterprise Services است که به عنوان یک ارائه‌دهنده‌ پیشرو در خدمات پردازش حق امتیاز و کپی رایت در صنعت موسیقی فعالیت می‌کند. اما ICE با موانعی در سیستم‌ها و زیرساخت‌های فناوری اطلاعات روبرو بود. در دنیای جدید پخش آنلاین موسیقی و کسب‌وکارهای مربوط به آن به‌طور قابل ملاحظه‌ای زیاد شد و این افزایش حجم داده‌ها موجب کند شدن فرایند پردازش آن‌ها شد. در کنار این افزایش حجم درخواست، کسب‌وکار با مشکل دیگری نیز مواجه بود. در فرایند‌ها و معماری قدیمی بخش زیادی از کار به‌صورت دستی انجام می‌شد، این موضوع موجب افزایش ریسک ایجاد خطا و پیچیدگی بیش از حد در فرایند‌های کاری بود. در چنین شرایطی، هنگامی که ویژگی‌ جدیدی درخواست می‌شد، فرایند کاری در پروژه‌ای مستقل انجام می‌پذیرفت. ادامه این فرایند موجب شد ترویج شیوه‌های مهندسی مدرن و توسعه پایدار دشوار شود. با توجه به این شرایط و اینکه ICE می‌خواست جایگاه خود را در بازار رقابتی حفظ کند، در سال 2020 سفر مدرن‌سازی معماری شروع شد. هدف ICE این بود درحالی‌که به سوی یک رویکردِ محصول‌محور (Product Centric) حرکت می‌کند، سرعت، دقت و مقیاس‌پذیری سیستم‌های فناوری اطلاعات را نیز افزایش دهد.

در ابتدای سفر مدرن‌سازی و برای اصلاح زیرساخت IT پردازش حق امتیاز، از روش های استراتژیک مختلفی استفاده کردیم. از Domain-Driven Design (DDD) و Event Storming به‌عنوان ابزارهایی برای درک دامنه و رفتارهای خاص آن استفاده کردیم. در طول جلسات Big Picture Event Storming، ما روی ثبت روابط و تعاملات بین ذی‌نفعان مختلف، سیستم‌ها و رویدادهایی که در دامنه‌ پردازش حق امتیاز اتفاق می‌افتند، تمرکز کردیم. جلسات شامل مخاطبان وسیعی بود تا از دیدگاه‌ها و دانش‌های مختلف که در این دامنه وجود دارد مطلع شویم، زیرا می‌خواستیم یک دید کلی جامع از حوزه کسب‌وکار به‌دست آوریم.

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

در ادامه فرایند، مهاجرتِ تدریجی را با استفاده از الگوی Strangler برنامه‌ریزی کردیم. ما قابلیت این رویکرد را با نمونه‌سازی (prototyping) در اولین زیر دامنه ثابت کنیم. ما نمونه‌ی اولیه را برای نشان دادن مزایای معماری جدید و جلب رضایت سهامداران مورد استفاده قرار دادیم. در ادامه روی یک طرح تجاری کار کردیم که ارزش‌های مورد علاقه سهامداران را به‌صورتی تدریجی و تکاملی ارائه کردیم. در این روش به‌جای اینکه کسب‌وکار، مدت زیادی منتظر مشاهده‌ خروجی باشد و خروجی، ناگهان و به‌صورت Big Bang ارائه شود، ارزش را به‌صورت تدریجی ارائه کردیم. این روش به ما کمک کرد تا طرحی ایجاد کنیم که ارزش را در بخش‌های کوچک‌تر و مداوم ارائه کنیم و توانستیم از این جریان ارزش، برای توجیه بودجه‌ بیشتر برای مهاجرتِ مداوم استفاده کنیم. ما شروع به تقویت تیم کردیم و طبقه‌بندیِ محصولات را که شامل دامنه‌ها، زیر دامنه‌ها و محصولات و همچنین قابلیت‌های این محصولات و تیم‌های مسئول آن‌ها بود را تعریف کردیم.

ما شروع به پیاده‌سازیِ روش‌های جدید کاری در تیم‌های توسعه کردیم. ما روال‎‌های یکپارچه‌سازی مستمر/استقرار مستمر (CI/CD) و زیرساخت به‌‌عنوان کد (Infrastructure as a code) را مورد استفاده قرار دادیم.با این کار ما توانستیم به‌طور خودکار تغییرات کد را چندین بار در روز Build، تست کنیم و در نهایت به جریان کاری منتقل کنیم. علاوه بر این، ما شروع به استفاده از Pair Programming کردیم که این روش منجر به افزایش اشتراک دانش و همکاری در تیم‌ها شد. همچنین ما مطمئن شدیم که تیم‌های توسعه و کسب‌وکار از نزدیک با هم همکاری می‌کنند و این موضوع موجب افزایش درک همه از محصولات شد و قدرت کسب‌وکاری را ارتقا بخشید. با ادامه کار به این روش، توانایی ما در گسترش تیم بیشتر شد و توانستیم تیم‌های بیشتری تشکیل دهیم و سازمان خود را تبدیل به سازمانی کنیم که با نقشه‌ راه محصول به‌صورت فصلی و سالانه کار می‌کند و ارزش‌هایی را به‌صورت مکرر و با افزایش‌های کوچک ارائه می‌دهد.

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

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

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

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

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

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

2. شناسایی امکان تغییر عمیق:

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

2.1. اجتناب از ساختار و فرایند اشتباه:
در برخی موارد مشاهده می‌شود که دیدگاه‌ها نسبت به سازمان بسیار مکانیکی است. آنها دوست دارند از استعاره‌های کارخانه‌ای استفاده کنند. مشکل از جایی شروع می‌شود که عوامل انسانی نادیده گرفته شده و در نتیجه انتظارات غیرواقعی می‌شود و فرصت‌ها از دست می‌رود. شرکت‌های متعددی بارها از من خواسته‌اند که در قالب یک ورکشاپ به آن‌ها کمک کنم تا ساختار سازمانی بهینه‌ خود را شناسایی کنند و سازماندهی مجددی به کمک این ساختار بهینه انجام دهند تا همه مشکلات آن‌ها حل شود. این یک ضد الگو است که با عنوان ساختار و فرایند اشتباه ( The Structure and Process Fallacy) شناخته می‌شود. تصور اینکه با تغییر در ساختار سازمانی یا اتخاذ یک فرایند جدید مثل فرایند‎های چابک، بدون ایجاد تغییرات عمیق‌تر مثل تغییر در طرز تفکر، عملکرد را تا حد زیادی بهبود می‌یابد، نادرست است. اگر کار برای بهبود عملکرد به همین سادگی بود که سازمان‌های زیادی تاکنون این کار را کرده بودند. برای افزایش واقعیِ سرعتِ توسعه، تغییرات جامعی مثل ترویج‌ِ کار تیمی، محول کردن تصمیماتِ مربوط به محصول به تیم‌ها، از بین بردن موانع کسب‌وکاری و فناوری اطلاعات، تغییر مدل‌های تامین مالی و سرمایه‌گذاری در کیفیت فنی مورد نیاز است. ساختار سازمانی و فرایندهای توسعه بسیار مهم هستند اما اعمال تغییرات در آن‌ها به‌ تنهایی بهبود محدودی را به همراه خواهد داشت. صحبت در مورد این موارد در ابتدای سفر مدرن‌سازی بسیار حیاتی است.

2.2. پذیرش رویکردهای معماری مشترک:

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

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

2.3. دور شدن از ساختارهای سیلویی در سازمان:

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

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

2.4. سرمایه گذاری روی شیوه‌های با کیفیت فنی:

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

من یکی از طرفداران Test Driven Development و pair/mob programming هستم. این تکنیک‌ها، رویِ طراحیِ نرم‌افزارهای با کیفیت و تست شده با استفاده از طراحی‌های دقیق و بازسازی (refactoring) مداوم تمرکز می‌کنند. هنگامی که در جست‌وجوی راه‌حل‌های ساده و قابل نگهداری برای پیاده‌سازی یک عملکرد جدید هستید، این تکنیک‌ها بسیار راهگشا هستند. ممکن است به نظر برسد استفاده از این تکنیک‌ها زمان زیادی می‌برد و موجب افزایش هزینه‌ها می‌شود، اما زمانی که به‌طور موثر از آن‌ها استفاده شود، متوجه می‌شویم که آنها در کوتاه‌مدت، میان‌مدت و به‌ویژه بلندمدت بازدهی عالی خواهند داشت. با این حال، مانند بسیاری از تکنیک‌های دیگر، این تکنیک‌ها نیز می‌توانند بسیار تفرقه‌انگیز باشند. همه‌ی تیم‌های برنامه‌نویسی TDD و pair/mob programming را دوست ندارند، بنابراین مهم است که آنچه را که برای شما مناسب‌تر است پیدا کنید.

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

3. اجتناب از مدرن‌سازی‌های سطحی:

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

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

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

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

4. توسعه‌ رهبران در تمامی سطوح:

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

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

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

بسته به اینکه سازمان شما از کجا شروع می‌کند، احتمالاً از روز اول همه‌ این افراد کاملاً خبره نخواهند بود. این بدان معناست که برای رسیدن به هدف خود، به یک راه‌حل کوتاه‌مدت و یک برنامه بلند‌مدت نیاز دارید. این هدف یک تیم توانمند‌سازِ نوسازی معماری یا Architecture Modernization Enabling Team (AMET)(AMET) است.

تا اینجا توضیح داده شد که چرا به رهبران در تمامی سطوح نیاز داریم، اما رهبران در تمامی سطوح به چه معناست؟ برای درک اینکه رهبری در همه سطوح به چه معناست، بسته به اندازه و نوع سازمان شما، فهرستی از افرادی که ممکن است نیاز به ایفای نقش رهبری در نوسازی معماری داشته باشند در زیر آمده و توجه کنید که این لیست صرفا برای مثال بوده و غیرجامع است:

• مدیر فنی (CTO)
• معمار ارشد نرم‌افزار
• معمار نرم‌افزار
• مدیران ستادی
• معمار سازمانی
• معمار داده
• معاون فنی و مهندسی
• ...

5. جمع‌‌بندی:

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