API یا تبادل فایل؟ کدام روش برای یکپارچهسازی سامانهها بهتر است؟
APIیا تبادل فایل؟
وقتی صحبت از یکپارچهسازی سامانههای سازمانی و شهری میشود، این سؤال یکی از مهمترین تصمیمهای فنی است. بسیاری از سازمانها تصور میکنند استفاده از API بهصورت مطلق، راهکار مدرنتر و بهتر است؛ در حالی که واقعیت معماری نرمافزار پیچیدهتر از این است.
در یک سازمان مانند شهرداری که سامانههای شهرسازی، درآمد، نوسازی، GIS، مالی، اتوماسیون و سایر زیرسیستمها باید با یکدیگر در ارتباط باشند، همه اطلاعات الزاماً به تبادل لحظهای نیاز ندارند.
گاهی لازم است یک سامانه در همان لحظه اطلاعات یک ملک را از سامانه دیگر دریافت کند؛ اما در شرایطی دیگر، انتقال یک فایل حجیم شامل هزاران رکورد در یک بازه زمانی مشخص، راهکار سادهتر، پایدارتر و منطقیتری است.
بنابراین سؤال درست این نیست که: «API بهتر است یا فایل؟»
بلکه سؤال اصلی این است: «برای هر جریان اطلاعاتی، کدام روش تبادل داده مناسبتر است؟»
در این مقاله بررسی میکنیم API چیست، تبادل فایل چگونه انجام میشود، تفاوت API و File Transfer چیست، هرکدام چه مزایا و محدودیتهایی دارند و در معماری یکپارچهسازی سامانههای شهری چه زمانی باید از API، چه زمانی از تبادل فایل و چه زمانی از ترکیب هر دو استفاده کرد.
API چیست؟
API یا Application Programming Interface مجموعهای از قواعد و رابطهایی است که به نرمافزارها اجازه میدهد بدون نیاز به دخالت مستقیم کاربر، با یکدیگر ارتباط برقرار کنند.
به زبان ساده، API مانند یک واسط بین دو سامانه عمل میکند. فرض کنید در شهرداری، سامانه شهرسازی نیاز دارد اطلاعات یک ملک را از سامانه درآمد دریافت کند. بهجای اینکه کاربر اطلاعات را بهصورت دستی وارد کند، سامانه شهرسازی میتواند یک درخواست به API سامانه درآمد ارسال کند و اطلاعات موردنیاز را دریافت کند.
برای مثال: سامانه شهرسازی → درخواست اطلاعات ملک → API → سامانه درآمد → پاسخ
در بسیاری از APIهای تحت وب، این ارتباط از طریق HTTP/HTTPS و قالبهایی مانند JSON یا XML انجام میشود.
مزیت مهم API چیست؟
مهمترین ویژگی API این است که امکان تبادل داده هدفمند و خودکار را فراهم میکند. برای مثال، اگر یک سامانه فقط به شناسه، وضعیت بدهی و مبلغ بدهی یک مؤدی نیاز داشته باشد، لازم نیست کل اطلاعات پایگاه داده منتقل شود. میتوان فقط همان اطلاعات موردنیاز را از طریق API درخواست کرد. این ویژگی API را برای فرآیندهایی که به اطلاعات بهروز، تعامل مستقیم و پاسخ سریع نیاز دارند، بسیار مناسب میکند. (Anuj Varma)
تبادل فایل چیست؟
در روش File-Based Integration یا تبادل فایل، یک سامانه اطلاعات موردنظر را در قالب یک فایل تولید میکند و سامانه مقصد آن فایل را دریافت و پردازش میکند.
فرمت فایل میتواند بسته به معماری سیستم متفاوت باشد؛ برای مثال:
- CSV
- XML
- JSON
- Excel
- TXT
- فایلهای ساختاریافته اختصاصی
این فایل میتواند به شکل دستی یا کاملاً خودکار منتقل شود.
برای مثال: سامانه مبدأ → تولید فایل اطلاعات → انتقال امن → سامانه مقصد → پردازش فایل
انتقال فایل میتواند از طریق روشهایی مانند SFTP یا سایر زیرساختهای انتقال امن انجام شود. تبادل فایل معمولاً برای انتقال حجم زیادی از داده بهصورت دستهای (Batch) و فرآیندهایی که نیاز به پاسخ لحظهای ندارند، کاربرد دارد. (DCKAP)
تفاوت API و تبادل فایل در یک نگاه
معیار | API | تبادل فایل |
مدل ارتباط | درخواست و پاسخ | ارسال و دریافت فایل |
سرعت دسترسی | معمولاً لحظهای | معمولاً زمانبندیشده |
مناسب برای | دادههای لحظهای و تعاملی | دادههای حجیم و دورهای |
حجم زیاد داده | ممکن است نیازمند طراحی خاص باشد | بسیار مناسب |
دریافت بخشی از اطلاعات | بسیار مناسب | معمولاً محدودتر |
پردازش دستهای | ممکن است پیچیده شود | مناسب |
وابستگی به API سامانه | دارد | ندارد |
امکان اتوماسیون | بسیار بالا | بسیار بالا |
کنترل و مانیتورینگ | نیازمند طراحی مناسب | قابل پیادهسازی با کنترل فایل |
کاربرد در سامانههای قدیمی | وابسته به وجود API | معمولاً سادهتر |
مناسب برای پاسخ لحظهای | بله | خیر |
نکته مهم این است که هیچکدام ذاتاً بهتر از دیگری نیستند؛ انتخاب صحیح به نوع داده، حجم اطلاعات، میزان تازگی موردنیاز و معماری سامانهها بستگی دارد. (Zeabyte)
API بهتر است یا تبادل فایل؟
پاسخ کوتاه: بستگی دارد. اگر سامانهای باید در همان لحظه اطلاعات سامانه دیگر را دریافت کند، API معمولاً انتخاب مناسبتری است.
اما اگر قرار است حجم زیادی از اطلاعات در بازههای مشخص منتقل شود و نیازی به پاسخ لحظهای وجود ندارد، تبادل فایل میتواند گزینه مناسبتری باشد.
بنابراین انتخاب روش تبادل اطلاعات باید بر اساس جریان داده (Data Flow) انجام شود، نه صرفاً بر اساس جدیدتر بودن یک فناوری.
چه زمانی API انتخاب بهتری است؟
۱. زمانی که اطلاعات باید لحظهای باشد
فرض کنید شهروند برای دریافت یک خدمت، درخواست خود را در سامانه ثبت میکند.
سامانه باید در همان لحظه بررسی کند:
- اطلاعات ملک چیست؟
- مالک چه کسی است؟
- آیا ملک بدهی دارد؟
- وضعیت پرونده چیست؟
- آیا محدودیت یا مانعی برای انجام فرآیند وجود دارد؟
در چنین شرایطی، انتقال فایل روزانه یا ساعتی نمیتواند پاسخ مناسبی ارائه کند. در اینجا API میتواند اطلاعات موردنیاز را در زمان درخواست دریافت کند.
۲. زمانی که فقط بخشی از اطلاعات موردنیاز است
فرض کنید یک سامانه برای نمایش وضعیت یک پرونده فقط به این اطلاعات نیاز دارد:
- شماره پرونده
- وضعیت پرونده
- تاریخ آخرین تغییر
- وضعیت پرداخت
انتقال یک فایل بزرگ حاوی هزاران رکورد برای دریافت چهار مقدار، منطقی نیست. API امکان دریافت دقیق اطلاعات موردنیاز را فراهم میکند.
۳. زمانی که فرآیند به تعامل دوطرفه نیاز دارد
در برخی فرآیندها تنها دریافت اطلاعات کافی نیست.
سامانه A باید:
- اطلاعاتی را به سامانه B ارسال کند.
- سامانه B آن را اعتبارسنجی کند.
- عملیات را انجام دهد.
- نتیجه را به سامانه A برگرداند.
این مدل از تعامل، یکی از مهمترین کاربردهای API است.
برای مثال: سامانه شهروندی → ثبت درخواست → API → سامانه شهرداری → بررسی → پاسخ
چه زمانی تبادل فایل انتخاب بهتری است؟
۱. زمانی که حجم اطلاعات زیاد است
فرض کنید شهرداری باید اطلاعات صدها هزار رکورد را بین دو سامانه منتقل کند. اگر این فرآیند با تعداد بسیار زیادی درخواست API انجام شود، طراحی، کنترل خطا، مدیریت Retry و مانیتورینگ میتواند پیچیده شود. در چنین شرایطی ممکن است تولید یک فایل ساختاریافته و انتقال دستهای آن، راهکار مناسبتری باشد.
تبادل فایل برای Batch Processing و انتقال حجم بالای اطلاعات یکی از کاربردهای اصلی این روش است. (Anuj Varma)
۲. زمانی که اطلاعات نیازی به بهروزرسانی لحظهای ندارد
همه دادههای سازمانی بهصورت Real-Time موردنیاز نیستند.
برای مثال:
- گزارشهای روزانه
- اطلاعات آماری
- آرشیو داده
- برخی اطلاعات مالی دورهای
- گزارشهای مدیریتی
- خروجیهای حجیم
- دادههای پشتیبان
ممکن است تنها یک بار در روز یا چند بار در روز بهروزرسانی شوند. در چنین مواردی استفاده از API برای هر رکورد ممکن است پیچیدگی غیرضروری ایجاد کند.
۳. زمانی که سامانه مقصد API مناسبی ندارد
یکی از چالشهای واقعی سازمانها این است که همه نرمافزارهای موجود، API کامل و استاندارد در اختیار ندارند. بهخصوص در سازمانهایی که سالها از سامانههای مختلف استفاده کردهاند، ممکن است بخشی از نرمافزارها قابلیت API داشته باشند و بخشی دیگر بر پایه فایل یا روشهای قدیمیتر تبادل اطلاعات کار کنند.
در چنین شرایطی، اصرار بر API برای تمام ارتباطات ممکن است نهتنها مشکل را حل نکند، بلکه پروژه یکپارچهسازی را پیچیدهتر کند.
یک مثال واقعی از یکپارچهسازی در شهرداری
فرض کنیم یک شهرداری دارای این سامانهها باشد:
- سامانه شهرسازی
- سامانه درآمد
- سامانه نوسازی
- سامانه GIS
- سامانه مالی
- سامانه شهروندی
- اتوماسیون اداری
اکنون تصور کنید همه این سامانهها باید با یکدیگر تبادل اطلاعات داشته باشند.
آیا باید برای تمام ارتباطات از API استفاده کرد؟ لزوماً خیر.
برای مثال: استعلام لحظهای بدهی
سامانه شهروندی → API درآمد
چون شهروند باید نتیجه را همان لحظه مشاهده کند.
دریافت اطلاعات مکانی
سامانه شهرسازی → API GIS
چون اطلاعات مکانی باید در زمان انجام فرآیند قابل دسترسی باشد.
انتقال اطلاعات حجیم آماری
سامانه درآمد → فایل دورهای → سامانه گزارشگیری
چون دادهها ممکن است روزانه یا ساعتی منتقل شوند.
انتقال اطلاعات آرشیوی
سامانه مبدأ → فایل → سامانه آرشیو
چون حجم اطلاعات زیاد است و نیازی به پاسخ لحظهای وجود ندارد.
این مثال نشان میدهد که معماری صحیح الزاماً API-Only یا File-Only نیست.
آیا استفاده از API همیشه بهتر است؟
یکی از اشتباهات رایج در پروژههای یکپارچهسازی این است که تصور کنیم:
API = مدرن
File = قدیمی
این برداشت دقیق نیست.
فایل هنوز یکی از روشهای معتبر انتقال داده در معماریهای سازمانی است و برای انتقالهای دستهای، حجم بالای داده و ارتباط با سیستمهایی که API مناسبی ندارند، میتواند انتخاب مناسبی باشد. منابع فنی جدید نیز بر این نکته تأکید دارند که انتخاب بین API و فایل باید بر اساس نیاز واقعی جریان داده انجام شود، نه صرفاً ترجیح فناوری. (SEEBURGER Blog)
مشکل زمانی ایجاد میشود که یک روش برای همه سناریوها استفاده شود.
مثلاً: استفاده از API برای انتقال میلیونها رکورد، فقط به این دلیل که API فناوری جدیدتری است.
یا برعکس: انتقال فایل برای فرآیندی که نیازمند پاسخ لحظهای است.
هر دو میتوانند نشانه طراحی نامناسب معماری یکپارچهسازی باشند.
چالشهای API چیست؟
API مزایای زیادی دارد، اما استفاده از آن بدون طراحی مناسب میتواند چالشهایی ایجاد کند.
وابستگی به سرویس مبدأ
اگر API سامانه مبدأ در دسترس نباشد، فرآیند وابسته به آن نیز ممکن است دچار اختلال شود.
مدیریت خطا
در ارتباطات API باید خطاهایی مانند:
- Timeout
- عدم دسترسی
- خطای اعتبارسنجی
- محدودیت درخواست
- خطای سرور
بهدرستی مدیریت شوند.
امنیت
API باید از نظر:
- احراز هویت
- مجوز دسترسی
- رمزنگاری
- کنترل درخواستها
- ثبت رخدادها
بهدرستی طراحی شود.
نگهداری
APIها Contract مشخصی دارند و تغییر در ساختار آنها میتواند روی سامانههای مصرفکننده اثر بگذارد. بنابراین API فقط «یک URL برای اتصال دو سامانه» نیست؛ بلکه بخشی از معماری نرمافزار است و باید مدیریت و پایش شود.
چالشهای تبادل فایل چیست؟
تبادل فایل نیز بدون چالش نیست.
تأخیر در بهروزرسانی
اگر فایل هر یک ساعت منتقل شود، اطلاعات ممکن است تا یک ساعت از وضعیت واقعی عقبتر باشد.
خطا در ساختار فایل
تغییر نام ستونها، نوع داده یا ساختار فایل میتواند باعث شکست فرآیند پردازش شود.
کنترل فایلهای تکراری
سامانه مقصد باید بتواند تشخیص دهد که آیا فایل قبلاً پردازش شده است یا خیر.
کنترل خطا
باید مشخص باشد:
- فایل دریافت شده؟
- فایل کامل است؟
- پردازش شده؟
- چند رکورد موفق بوده؟
- چند رکورد خطا داشته؟
- آیا نیاز به پردازش مجدد وجود دارد؟
بنابراین تبادل فایل سادهتر از API به نظر میرسد، اما برای استفاده سازمانی همچنان به طراحی، کنترل و مانیتورینگ مناسب نیاز دارد.
API و تبادل فایل؛ کدامیک امنتر است؟
نمیتوان بهصورت مطلق گفت API یا فایل امنتر است. امنیت به نحوه طراحی و پیادهسازی بستگی دارد.
در API میتوان از روشهایی مانند:
- HTTPS
- API Key
- OAuth
- Token
- کنترل سطح دسترسی
- Rate Limiting
استفاده کرد.
در تبادل فایل نیز میتوان از روشهایی مانند:
- SFTP
- رمزنگاری فایل
- کنترل دسترسی
- احراز هویت
- ثبت لاگ
- کنترل صحت فایل
استفاده کرد.
بنابراین پرسش درست این نیست که: «API امنتر است یا فایل؟»
بلکه باید پرسید: «کدام روش، با چه معماری و چه کنترلهای امنیتی پیادهسازی شده است؟»
ترکیب API و تبادل فایل؛ راهکار مناسب برای بسیاری از سازمانها
در معماریهای پیچیده سازمانی، لازم نیست یک روش را برای تمام جریانهای داده انتخاب کنیم. میتوان از یک Hybrid Integration Architecture استفاده کرد.
یعنی: API برای تعاملات لحظهای و File Transfer برای تبادلهای حجیم و دورهای
برای مثال در یک شهرداری:
جریان اطلاعات | روش پیشنهادی |
استعلام بدهی شهروند | API |
استعلام وضعیت پرونده | API |
دریافت اطلاعات یک ملک | API |
تبادل داده حجیم املاک | فایل |
گزارشهای دورهای | فایل |
انتقال اطلاعات آرشیوی | فایل |
عملیات لحظهای بین سامانهها | API |
انتقال حجم بالای داده در زمان مشخص | فایل |
این مدل میتواند باعث شود هر فناوری دقیقاً در جایی استفاده شود که بیشترین کارایی را دارد.
قبل از انتخاب API یا فایل، این ۶ سؤال را بپرسید
برای انتخاب روش مناسب یکپارچهسازی، ابتدا این سؤالات را بررسی کنید:
۱. اطلاعات چقدر باید بهروز باشد؟
اگر اطلاعات باید همان لحظه دریافت شود، API گزینه جدیتری است.
۲. حجم اطلاعات چقدر است؟
برای حجمهای بسیار بالا، تبادل دستهای فایل میتواند مناسبتر باشد.
۳. آیا فرآیند به پاسخ فوری نیاز دارد؟
اگر پاسخ باید بلافاصله برگردد، API معمولاً انتخاب مناسبتری است.
۴. سامانه مبدأ چه امکاناتی دارد؟
اگر API مناسب وجود ندارد، باید معماری را بر اساس قابلیت واقعی سامانه طراحی کرد.
۵. در صورت شکست ارتباط چه اتفاقی میافتد؟
باید مکانیزم مشخصی برای: Retry → Logging → Monitoring → Recovery وجود داشته باشد.
۶. آیا این معماری در آینده قابل توسعه است؟
یکپارچهسازی نباید فقط مشکل امروز را حل کند. باید مشخص شود اگر تعداد سامانهها، حجم داده و تعداد کاربران افزایش پیدا کرد، معماری همچنان قابل مدیریت خواهد بود یا خیر.
اشتباه رایج: یکپارچهسازی را با «اتصال دو سامانه» اشتباه نگیریم
یکی از مهمترین نکات در پروژههای یکپارچهسازی این است که اتصال فنی دو سامانه، بهتنهایی به معنای یکپارچهسازی واقعی نیست. ممکن است دو نرمافزار بتوانند اطلاعاتی را برای یکدیگر ارسال کنند؛ اما همچنان مشکلات زیر وجود داشته باشد:
- دادههای تکراری
- ناسازگاری کدها
- تعاریف متفاوت از یک مفهوم
- عدم هماهنگی ساختار داده
- نبود مرجع مشخص برای داده
- نبود مانیتورینگ
- نبود مدیریت خطا
- نبود حاکمیت داده
در چنین شرایطی، حتی اگر ارتباط از طریق API انجام شود، سازمان الزاماً به یکپارچگی اطلاعاتی نرسیده است.
یکپارچهسازی موفق باید علاوه بر روش انتقال، به معماری داده، استانداردسازی، امنیت، کنترل دسترسی، مانیتورینگ و فرآیندهای سازمانی نیز توجه کند.
API یا تبادل فایل؟ یک تصمیم معماری، نه یک انتخاب تکنولوژی
در نهایت، انتخاب بین API و تبادل فایل نباید بر اساس این تصور انجام شود که یک فناوری «مدرنتر» و دیگری «قدیمیتر» است. اگر یک فرآیند به پاسخ لحظهای، تعامل مستقیم و دریافت اطلاعات مشخص نیاز دارد، API میتواند انتخاب مناسبی باشد.
اگر فرآیند به انتقال حجم بالای داده، پردازش دستهای یا تبادل دورهای نیاز دارد، فایل میتواند گزینه مناسبی باشد. و اگر سازمان دارای فرآیندهای متنوع است، ترکیب API و تبادل فایل میتواند معماری منطقیتری ایجاد کند.
بنابراین: یکپارچهسازی موفق، انتخاب یک فناوری برای همه ارتباطات نیست؛ انتخاب درستترین روش برای هر جریان اطلاعاتی است.
در شهرداریها، انتخاب روش تبادل اطلاعات چرا اهمیت بیشتری دارد؟
در شهرداریها معمولاً با مجموعهای از سامانههای تخصصی و اطلاعات متنوع مواجه هستیم؛ از اطلاعات شهرسازی و املاک گرفته تا درآمد، نوسازی، GIS، پروندههای شهروندی و اطلاعات مالی.
هرکدام از این دادهها ویژگی متفاوتی دارند. برخی باید لحظهای در دسترس باشند و برخی دیگر میتوانند بهصورت دورهای و دستهای منتقل شوند.
بنابراین طراحی یک معماری یکپارچه برای شهرداری، نیازمند بررسی دقیق جریانهای اطلاعاتی و تعیین روش مناسب برای هر ارتباط است.
این نگاه، یک گام مهم در مسیر تحول دیجیتال مدیریت شهری، شهرداری الکترونیک و حرکت به سمت مدیریت دادهمحور محسوب میشود.
راپکو و نگاه یکپارچه به تبادل اطلاعات شهری
در یک معماری جامع مدیریت شهری، هدف تنها اتصال چند نرمافزار به یکدیگر نیست؛ بلکه باید جریان اطلاعات میان زیرسیستمهای مختلف به شکلی منسجم، قابل کنترل، امن و قابل توسعه طراحی شود.
در چنین معماریای، بسته به نوع فرآیند و نیاز اطلاعاتی، میتوان از روشهای مختلف تبادل داده استفاده کرد و برای هر جریان، مناسبترین راهکار را در نظر گرفت.
این موضوع بهویژه زمانی اهمیت پیدا میکند که شهرداری با مجموعهای از سامانههای مختلف مواجه است و قصد دارد بدون ایجاد اختلال در زیرساخت موجود، مسیر یکپارچهسازی سامانههای شهری را توسعه دهد.
آیا در شهرداری شما سامانههای مختلف بهصورت مستقل فعالیت میکنند؟
اگر سامانههای مختلف شهرداری اطلاعات را بهصورت جداگانه نگهداری میکنند، قبل از انتخاب API یا تبادل فایل، باید جریانهای اطلاعاتی، نیازهای عملیاتی و معماری موجود بررسی شود.
ممکن است برای یک ارتباط API بهترین گزینه باشد و برای ارتباط دیگر، تبادل فایل یا حتی یک معماری ترکیبی راهکار مناسبتری باشد.
راپکو میتواند در بررسی مسیر یکپارچهسازی سامانههای شهری و انتخاب راهکار متناسب با زیرساخت موجود، در کنار شما باشد. برای بررسی راهکار مناسب یکپارچهسازی سامانههای شهری با کارشناسان راپکو مشورت کنید.
سوالات متداول
آیا API بهتر از تبادل فایل است؟
خیر. API و تبادل فایل برای نیازهای متفاوتی طراحی شدهاند. API معمولاً برای ارتباط لحظهای و تعامل مستقیم مناسب است، در حالی که تبادل فایل برای انتقالهای دورهای و حجم بالای اطلاعات میتواند گزینه مناسبی باشد.
آیا میتوان API و تبادل فایل را همزمان استفاده کرد؟
بله. در بسیاری از معماریهای سازمانی، استفاده ترکیبی از API و تبادل فایل منطقیتر است؛ API برای فرآیندهای لحظهای و فایل برای عملیات Batch استفاده میشود. (SEEBURGER Blog)
آیا تبادل فایل یک روش قدیمی و منسوخ است؟
خیر. تبادل فایل همچنان در بسیاری از معماریهای سازمانی برای انتقال حجم بالای داده و فرآیندهای دورهای استفاده میشود. مسئله اصلی، تناسب روش با نیاز کسبوکار است.
آیا API برای انتقال حجم بالای اطلاعات مناسب است؟
API میتواند برای حجم بالا استفاده شود، اما در برخی سناریوهای Batch، استفاده از فایل میتواند طراحی و مدیریت سادهتری داشته باشد. تصمیم نهایی باید بر اساس حجم، محدودیتهای سامانه، زمانبندی و نیازمندیهای فرآیند گرفته شود. (Zeabyte)
آیا API امنیت بیشتری نسبت به فایل دارد؟
هیچکدام ذاتاً امنتر نیستند. امنیت به معماری، احراز هویت، رمزنگاری، کنترل دسترسی، مانیتورینگ و نحوه پیادهسازی بستگی دارد.
برای یکپارچهسازی سامانههای شهرداری کدام روش مناسبتر است؟
پاسخ واحدی وجود ندارد. باید هر جریان اطلاعاتی بهصورت مستقل بررسی شود. در بسیاری از معماریهای شهری، ترکیبی از API، تبادل فایل و یک لایه مدیریت یکپارچهسازی میتواند راهکار مناسبتری باشد.
جمعبندی
API یا تبادل فایل؟
این سؤال در ظاهر یک انتخاب فنی ساده است، اما در واقع بخشی از تصمیمگیری معماری یک سازمان محسوب میشود. API برای ارتباطات لحظهای، درخواستهای هدفمند و فرآیندهای تعاملی بسیار مناسب است.
تبادل فایل برای انتقالهای دورهای، پردازشهای دستهای و حجم بالای داده میتواند انتخاب مناسبی باشد. اما در یک سازمان بزرگ مانند شهرداری، احتمالاً پاسخ نهایی نه «API» است و نه «فایل».
پاسخ میتواند: API + File Transfer + معماری یکپارچهسازی مناسب باشد.
زیرا هدف اصلی، انتخاب فناوری نیست؛ هدف، ایجاد یک جریان اطلاعاتی منسجم، دقیق، امن و قابل توسعه میان سامانههای مختلف است.