سامانههای تخصصی معمولاً با یک مسئله مشخص آغاز میشوند. چند فرایند اصلی شناسایی میشود، نرمافزار برای همان نیازها توسعه پیدا میکند و با گسترش استفاده، قابلیتهای تازه یکییکی به آن اضافه میشوند. این روند در بسیاری از سامانههای تخصصی، بهویژه سامانههای سازمانی و دولتی، اجتنابناپذیر است؛ زیرا نیازهای سازمان در طول زمان ثابت نمیماند.
اما از یک نقطه به بعد، اضافهشدن هر خدمت جدید فقط یک تصمیم درباره «قابلیت بعدی نرمافزار» نیست. این پرسش جدیتر مطرح میشود که کدام خدمات باید در هسته سامانه باقی بمانند، کدام قابلیتها میتوانند استقلال بیشتری داشته باشند و چگونه میتوان این تغییر را بدون از دست رفتن یکپارچگی انجام داد.
اینجاست که یک سوءبرداشت رایج میتواند تصمیمگیری را منحرف کند: یکپارچگی الزاماً به معنای یکتکه بودن نرمافزار نیست.
یکپارچگی واقعی بیشتر از آنکه به تعداد برنامهها، سرویسها یا پایگاههای داده وابسته باشد، به پیوستگی تجربه کاربر، جریان داده، هویت کاربران و فرایندهای سازمانی وابسته است.
وقتی رشد یک سامانه به مسئله معماری تبدیل میشود
در ابتدای عمر یک سامانه، قرار گرفتن بسیاری از قابلیتها در یک محصول واحد مزایای روشنی دارد. توسعه سادهتر است، کاربران با یک محیط سروکار دارند، استقرار سیستم پیچیدگی کمتری دارد و ارتباط بین بخشهای مختلف نیز آسانتر مدیریت میشود.
مسئله زمانی ظاهر میشود که سامانه طی چند سال رشد میکند.
مثلا احتمال دارد یک بخش چند برابر بخشهای دیگر استفاده شود؛ یک قابلیت به منابع پردازشی بیشتری احتیاج داشته باشد؛ بخشی از محصول مرتب تغییر کند، در حالی که بخش دیگری بسیار پایدار باشد؛ بعضی قابلیتها کاملاً تخصصی باشند و بعضی دیگر تقریباً در هر سازمانی کاربرد داشته باشند.
حتی امکان دارد نیاز مشتریان نیز یکسان نباشد. یک سازمان ممکن است تقریباً به تمام قابلیتهای سامانه احتیاج داشته باشد، در حالی که همان سازمان در منطقه و استان دیگر، بعضی از فرایندهای خود را با نرمافزارهای موجود پوشش داده باشد و فقط چند خدمت مشخص را بخواهد.
در چنین شرایطی مسئله دیگر صرفاً توسعه نرمافزار نیست؛ معماری محصول نیز وارد تصمیم میشود.
چهار سؤال که نباید با یکدیگر اشتباه گرفته شوند
یکی از دلایل دشوارشدن این تصمیم آن است که چند موضوع متفاوت معمولاً تحت عنوان کلی «معماری سامانه» مطرح میشوند، در حالی که پاسخ آنها الزاماً یکسان نیست.
وقتی پای «معماری» به میان میآید، احتمال دارد درباره نحوه فروش محصول صحبت کنیم، یا درباره چیزی که کاربر روی صفحه میبیند، یا نحوه تقسیم کد، یا محل نگهداری دادهها و یا نحوه ارتباط اجزای مختلف با یکدیگر.
برای مثال، ممکن است یک مجموعه نرمافزاری برای مشتری بهصورت چند محصول یا چند ماژول قابل انتخاب عرضه شود اما پس از ورود، کاربر با یک حساب کاربری، یک محیط هماهنگ و دادههای متصل روبهرو شود.
حالت معکوس هم امکانپذیر است: تمام قابلیتها داخل یک نرمافزار واحد قرار گرفته باشند، اما داده هر بخش جداگانه تولید شود و ارتباط مؤثری میان آنها وجود نداشته باشد.
بنابراین ظاهر محصول، مدل تجاری، معماری نرمافزار و معماری داده چهار موضوع مرتبط اما مستقلاند.
این تفکیک خصوصاً برای سامانههای دولتی اهمیت دارد. برای مثال Technology Code of Practice دولت بریتانیا بر استفاده مجدد از اجزا، استانداردهای باز، قابلیت انطباق فناوری، API و استفاده بهتر از داده تأکید میکند؛ نه بر این اصل که همه خدمات حتماً باید داخل یک نرمافزار واحد قرار گیرند.
یکپارچگی دقیقاً چیست؟
در معماری دولت دیجیتال، یکپارچگی موضوعی فراتر از اتصال دو نرمافزار به یکدیگر است.
چارچوب اروپایی interoperability، تعاملپذیری خدمات عمومی را در سطوح مختلفی از جمله حقوقی، سازمانی، معنایی و فنی تعریف میکند. به بیان ساده، دو سامانه زمانی واقعاً میتوانند با یکدیگر کار کنند که فقط کابل یا API میان آنها وجود نداشته باشد؛ بلکه درباره مفهوم دادهها، قواعد سازمانی و نحوه استفاده از اطلاعات نیز تفاهم وجود داشته باشد.
در نتیجه یک مجموعه میتواند از نظر فنی از چند جزء تشکیل شده باشد و همچنان بسیار یکپارچه عمل کند.
اگر کاربر یک بار وارد شود، سطح دسترسی او در همه بخشها رعایت شود، اطلاعات مشترک دوباره وارد نشوند، داده یک بخش بتواند در فرایند بخش دیگر استفاده شود و مدیر بتواند تصویر واحدی از سازمان داشته باشد، شکستن برخی مرزهای فنی الزاماً به معنای شکستن یکپارچگی نیست.
اتفاقاً ممکن است معماری نامناسبی وجود داشته باشد که از بیرون «یک سامانه» دیده شود اما در عمل چند جزیره دادهای درون همان نرمافزار ایجاد کرده باشد.
در ایران نیز موضوع تعاملپذیری از سطح توصیه فنی فراتر رفته است. چارچوب تعاملپذیری دولت الکترونیکی ایران (EGIF) با هدف یکپارچگی فنی و اجرایی خدمات و تبادل اطلاعات میان دستگاهها تدوین شده و قانون مدیریت دادهها و اطلاعات ملی مصوب ۱۴۰۱ نیز تبادل داده میان دستگاههای مشمول را به مرکز ملی تبادل اطلاعات، منابع داده پایه و سطوح دسترسی مصوب کارگروه تعاملپذیری پیوند داده است. از این منظر، میتوان گفت یکپارچگی در سیاستگذاری دولت دیجیتال ایران نیز بیش از «قرارگرفتن همه خدمات در یک نرمافزار واحد»، بر تعاملپذیری، تبادل استاندارد و کنترلشده داده و مشخصبودن منابع معتبر اطلاعات استوار است.
چه چیزی واقعاً بخشی از هسته سامانه است؟
اینجا مفهوم دیگری از مهندسی نرمافزار میتواند به تصمیمگیری کمک کند.
در Domain-Driven Design معمولاً میان Core Domain، Supporting Subdomain و Generic Subdomain تفاوت گذاشته میشود. وب سرویس آمازون (AWS) نیز در راهنمای معماری خود همین تقسیمبندی را برای تشخیص مرز بخشهای یک سامانه مطرح میکند:
Coreبخشی است که مستقیماً با مزیت و مأموریت اصلی کسبوکار ارتباط دارد؛ Supporting به هسته کمک میکند و Generic قابلیتی است که لزوماً مختص همان حوزه نیست.
مثلا اگر موضوع یک سامانه تخصصی مدیریت محلی و روستایی مطرح باشد، قابلیتهایی مانند بودجه و مالیه دهیاری، پروژههای عمرانی روستایی، مصوبات، عوارض یا فرایندهای تخصصی دهیاری ارتباط مستقیمی با دامنه اصلی محصول دارند.
در مقابل، قابلیتهایی مانند آموزش کارکنان، پیامرسانی، مدیریت اعلانها، برخی انواع مدیریت اسناد یا خدمات عمومی ارتباطی را میتوان در سازمانهایی کاملاً متفاوت نیز تصور کرد.
این تفاوت لزوماً به معنای جداکردن فوری آنها نیست. ارزش این دستهبندی در جای دیگری است: مشخص میکند اگر روزی قرار باشد استقلال فنی یا تجاری بیشتری ایجاد شود، مرزهای منطقی سیستم کجا قرار دارند.
از Monolith تا Microservices؛ یک طیف، نه دو اردوگاه
بحث معماری گاهی بیش از حد ساده میشود: یا باید یک Monolith داشت یا همهچیز را Microservice کرد.
در عمل گزینهها بسیار بیشترند.
در نگرش Monolith، بخش عمده سامانه بهعنوان یک واحد توسعه و استقرار پیدا میکند. مزیت آن سادگی عملیاتی و ارتباط مستقیم اجزاست؛ اما با بزرگشدن سیستم، وابستگی میان بخشها ممکن است تغییر، آزمون و انتشار نسخههای جدید را دشوارتر کند.
سیستم Modular Monolith تلاش میکند همین سامانه واحد را به ماژولهایی با مرزهای روشن تقسیم کند. محصول ممکن است همچنان یک استقرار اصلی داشته باشد، اما کد و منطق هر حوزه تا حد ممکن از سایر حوزهها جدا نگه داشته میشود. این رویکرد در بسیاری از پروژهها میتواند مرحلهای مهم میان یک نرمافزار کاملاً درهمتنیده و یک معماری توزیعشده باشد.
در معماریهای سرویسگرا یا SOA، قابلیتهای مختلف بهصورت سرویسهایی با رابط مشخص در اختیار سایر بخشها قرار میگیرند. ایده اصلی، کاهش وابستگی و امکان استفاده مجدد و تعامل اجزاست. IBM نیز SOA را مبتنی بر واحدهای عملکردی ماژولار و قابل تعامل توصیف میکند.
روش Microservices این استقلال را یک گام جلوتر میبرد. سرویسها کوچکتر میشوند و میتوانند چرخه توسعه، استقرار و مقیاسدهی مستقلتری داشته باشند.
اما کوچکترشدن سرویسها به معنای سادهترشدن کل سیستم نیست.
Microservices درمان خودکار رشد سامانه نیست
Microservices مزایای مهمی دارد. اگر یک سرویس تحت فشار بیشتری قرار گیرد، میتوان همان بخش را مقیاس داد. تیمها میتوانند روی حوزههای مشخص تمرکز کنند و تغییر در یک قابلیت الزاماً به انتشار کل سامانه منجر نمیشود.
در مقابل، بخشی از پیچیدگی که قبلاً داخل برنامه مدیریت میشد، به شبکه و عملیات منتقل میشود.
حالا باید وضعیت چند سرویس مانیتور شود، شکست ارتباط میان آنها مدیریت شود، نسخه APIها کنترل شود، لاگها و رخدادها در چند محیط مختلف دنبال شوند و برای خطاهای توزیعشده راهکار وجود داشته باشد.
لذا پرسش مفید این نیست که «Microservices معماری مدرنتری است یا Monolith؟»
پرسش بهتر این است که استقلال هر بخش چه ارزشی ایجاد میکند و آیا سازمان توان پرداخت هزینه این استقلال را دارد؟
محصول ماژولار الزاماً محصول تکهتکه نیست
موضوع معماری یک بُعد تجاری مهم هم دارد.
گاهی یک سامانه به مجموعه بزرگی از قابلیتها رسیده است، اما تمام مشتریان به تمام آنها نیاز ندارند. در چنین شرایطی الزام مشتری به خرید یا استقرار همه قابلیتها میتواند انعطاف محصول را کاهش دهد.
یکی از الگوهای شناختهشده در مهندسی نرمافزار Software Product Line است. مؤسسه مهندسی نرمافزار دانشگاه Carnegie Mellon این مفهوم را خانوادهای از محصولات تعریف میکند که مجموعهای مدیریتشده از قابلیتها و داراییهای هستهای مشترک دارند، اما میتوانند برای نیازهای متفاوت ترکیبهای مختلفی ارائه دهند.
این مدل نکته مهمی دارد: Modular Product با Fragmented Product یکسان نیست.
امکان دارد چند قابلیت به شکل مستقل قابل عرضه باشند، اما همچنان از هویت مشترک، مدل داده هماهنگ، APIهای استاندارد، طراحی یکسان و زیرساختهای مشترک استفاده کنند.
از دید کاربر حتی ممکن است هیچ مرز فنی آشکاری وجود نداشته باشد. او وارد یک محیط میشود و فقط قابلیتهایی را میبیند که سازمانش انتخاب کرده یا مجاز به استفاده از آنهاست.
در چنین مدلی ماژولارشدن بیشتر درباره «حق انتخاب» است تا «چندپارهکردن تجربه کاربر».
API؛ جایی که استقلال و یکپارچگی به یکدیگر میرسند
اگر قرار باشد بخشهای یک سامانه استقلال بیشتری پیدا کنند، مهمترین مسئله نحوه ارتباط آنهاست.
APIها یکی از ابزارهای اصلی این ارتباطاند، اما صِرف وجود API کافی نیست. تعریف دادهها، مالکیت آنها، نسخهبندی، امنیت، سطح دسترسی و منبع معتبر هر داده نیز باید روشن باشد.
در استانداردهای فناوری برخی کشورها توصیه میشود داده بهعنوان دارایی مستقل از یک فناوری یا سرویس خاص مدیریت شود و برای تبادل اطلاعات از استانداردها و رابطهای مشخص استفاده شود. همچنین استفاده از RESTful APIها، جلوگیری از تکثیر بیدلیل داده و مشخصبودن منبع تأییدشده اطلاعات را توصیه میشود.
این نگاه یک پیام معماری مهم دارد: در یک اکوسیستم ماژولار، یکپارچگی نباید فقط نتیجه دسترسی چند ماژول به یک پایگاه داده مشترک باشد.
قراردادهای روشن میان اجزا، مدل داده هماهنگ و مشخصبودن مالک هر داده در بلندمدت اهمیت بیشتری پیدا میکند.
یک سامانه چه زمانی آماده تغییر معماری است؟
برای چنین تصمیمی نمیتوان یک فرمول عمومی ارائه کرد. تعداد کاربران بهتنهایی کافی نیست؛ تعداد ماژولها هم معیار مناسبی نیست. حتی بزرگشدن پایگاه داده نیز بهتنهایی اثبات نمیکند که معماری باید تغییر کند.
پیش از تصمیم، چند سؤال مهمتر وجود دارد:
پاسخ این پرسشها میتواند برای هر بخش متفاوت باشد. ممکن است هسته یک محصول سالها بهصورت Modular Monolith باقی بماند، یک سرویس پرترافیک بهصورت مستقل توسعه یابد، چند قابلیت عمومی به سرویس مشترک تبدیل شوند و بعضی محصولات نیز از طریق API به این هسته متصل شوند.
هیچ الزام فنی وجود ندارد که تمام سیستم یکباره به یک الگوی معماری واحد مهاجرت کند.
یکپارچگی باید در سطح مأموریت حفظ شود، نه الزاماً در سطح کد
برای سامانههای تخصصی این شاید مهمترین نتیجه باشد. کاربر دولت دیجیتال معمولاً اهمیتی نمیدهد که پشت صفحهای که میبیند یک برنامه اجرا میشود یا بیست سرویس. برای او چیزهای دیگری اهمیت دارد: دوباره همان اطلاعات را وارد نکند، میان چند حساب کاربری سرگردان نشود، اطلاعات متناقض نبیند و فرایندی که در یک بخش آغاز شده در بخش دیگر گم نشود.
به همین دلیل معماری میتواند در پشت صحنه تغییر کند، در حالی که تجربه کاربر حتی یکپارچهتر شود.
در سامانههای تخصصی مدیریت روستایی نیز همین منطق قابل تصور است. ارزش اصلی یک پلتفرم یکپارچه فقط این نیست که تعداد زیادی قابلیت زیر یک نام جمع شده باشند؛ ارزش مهمتر، ایجاد ارتباط میان دادهها و فرایندهایی است که پیش از آن جدا از یکدیگر مدیریت میشدند.
این ویژگی باید مستقل از انتخاب معماری فنی حفظ شود.
معماری خوب الزاماً معماریای با کمترین یا بیشترین تعداد سرویس نیست؛ معماری خوب باید اجازه دهد بخشهای مختلف متناسب با نیازشان رشد کنند، بدون آنکه داده، فرایند و تجربه کاربر دوباره به جزیرههای جداگانه تبدیل شوند.
معماری نیز بخشی از بلوغ محصول است
معماری اولیه یک سامانه قرار نیست برای تمام عمر آن ثابت بماند.
سیستمی که برای چند فرایند و تعداد محدودی کاربر طراحی شده، ممکن است سالها بعد با حجم بسیار بیشتری از داده، کاربران، سازمانها و خدمات روبهرو شود. تغییر معماری در چنین شرایطی الزاماً نشانه اشتباه بودن طراحی اولیه نیست؛ همانطور که ثابت نگهداشتن معماری نیز الزاماً نشانه پایداری و بلوغ نیست.
مسئله اصلی توانایی تغییر کنترلشده است.
گاهی بهترین تصمیم، حفظ معماری موجود است. گاهی باید ابتدا مرز ماژولها در داخل همان سامانه روشنتر شود. در شرایط دیگری ممکن است جداکردن یک سرویس خاص منطقی باشد و در مرحلهای بالاتر حتی یک قابلیت بتواند به محصول مستقلی تبدیل شود.
اما در تمام این حالتها یک اصل باید ثابت بماند: معماری در خدمت محصول و مأموریت آن است، نه برعکس.
برای نسل بعدی سامانههای دولت دیجیتال، شاید مطلوبترین وضعیت دقیقاً همین باشد؛ سامانهای که از نگاه کاربر یکپارچه است، اما در پشت صحنه آنقدر ماژولار طراحی شده که بتواند بدون بازسازی کل سیستم، با نیازهای تازه رشد کند.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
