۳٫۵٫۳معماری سخت‌افزار برای پشتیبانی همکاری در مکان‌های مختلف، یکسان/ زمان متفاوت
یکی از شکل‌های محبوب تصمیم‌گیری مشترک در ترتیب مکانی متفاوت، کنفرانس تلفنی است که شرکت‌کنندگان در آن توزیع می‌شوند. مکان‌های مختلف و وسیله ارتباطی است تلویزیونی که شرکت‌کنندگان را از طریق یک مدار بسته یا پیوند ماهواره‌ای به هم متصل می‌کند. شکل دیگر، اگرچه محدود به ارتباطات صوتی است، کنفرانس تلفنی چندجانبه است که در آن، شرکت‌کنندگان به‌طور هم‌زمان در یک کنفرانس تماس می‌گیرند.
این اشکال حمایت از تصمیم‌گیری گروهی برای همکاری در مکان‌های مختلف مناسب است. آن‌ها همچنین در مدیریت داده‌ها و عملکردهای پشتیبانی تحلیلی محدود هستند. به این دلیل، پشتیبانی کامپیوتری به‌عنوان فناوری جدید در حال توسعه است که (با توجه به پهنای باند کافی) می‌تواند قابلیت‌های صوتی و تصویری به همراه مدیریت داده‌ها و پشتیبانی تحلیلی را ارائه دهد؛ در غیر این صورت، در کنفرانس‌های راه دور معمولی در دسترس نیست. اینترنت یک زیرساخت ارتباطی تبلیغ‌شده است که می‌توان روی آن، پشتیبانی رایانه‌ای برای کار مشترکی را توسعه داد. اگرچه در پهنای باند فعلی، زیرساخت اینترنت عمدتاً بلادرنگ قادر به پشتیبانی از ویدیو و صدا نیست، اما قابلیت‌های ارتباطی آن برای پشتیبانی از مدیریت داده و عملکردهای تحلیلی لازم برای فضای تصمیم‌گیری مشترک کافی است.
اگرچه می توان معماری مبتنی بر اینترنت را بدون سرور تصور کرد، اما یک کار عملی راه حل برای اکثر تصمیم های توزیع شده در فضا و زمان سیستم های پشتیبانی شامل معماری سرویس گیرنده-سرور می شوند (شکل ۳٫۱۱).
سرور می‌تواند هر رایانه شخصی پیشرفته یا ایستگاه کاری یونیکس با پشتیبانی سخت‌افزاری داخلی برای اتصال به شبکه باشد. مهم است که سرور از طریق اتصال پرسرعت با سرعت حداقل ۱ مگابیت بر ثانیه به زیرساخت اینترنت متصل شود. مشتریان می‌توانند از طریق خط اختصاصی، اتصال مودم پرسرعت (مانند مودم DSL یا کابلی) یا اتصال بی‌سیم به اینترنت متصل شوند.
۳٫۵٫۴ معماری نرم‌افزار برای پشتیبانی همکاری در مکان‌های مختلف، یکسان/ زمان متفاوت
سه رویکرد وجود دارد که می‌توان هنگام طراحی سیستم پشتیبانی تصمیم فضایی با ابزارهای اینترنتی (وب سرور و مرورگر وب) در نظر گرفت. اول، از دیدگاه نرم‌افزار مشتری (مرورگر وب)، برنامه کاربردی ممکن است به‌عنوان یک اپلت (برنامه کوچک) نوشته‌شده به زبان برنامه‌نویسی جاوا کار کند (جانکوسکی و استاسیک، ۱۹۹۷، استاسیک ،۱۹۹۹). اپلت‌های جاوا از پیش کامپایل شده‌اند، در داخل یک سند وب کار می‌کنند و پیشرفت‌هایی را برای محتوای صفحه وب ثابت ارائه می‌دهند. این رویکرد را می‌توان برای قابلیت‌های پشتیبانی تصمیم‌گیری مبتنی بر اینترنت که به برنامه‌های GIS محدود (در اندازه کوچک) نیاز دارند، در نظر گرفت. با این حال، بسیاری از برنامه‌های GIS بزرگ هستند و بنابراین، دانلود کردن زمان می‌برد. از آنجایی که هر بار که کاربران یک صفحه وب را دوباره بازدید می‌کنند، اپلت‌های جاوا باید دوباره بارگیری شوند، زمان مورد نیاز برای بارگیری اپلت‌ها مشکل‌ساز می‌شود. این محدودیت در حال حاضر، استفاده از اپلت‌های جاوا را به چند توابع تحلیل فضایی ساده که برای تصمیم‌گیری مفید هستند، محدود می‌کند.
شکل ۳٫۱۱ معماری سخت‌افزار برای تصمیم‌گیری مشترک فضا و زمان توزیع‌شده سیستم پشتیبانی
پشتیبانی (به‌عنوان مثال پرس‌وجو مبتنی بر فاصله، جستجوی نقطه در چندضلعی، بافر و پوشش).
یکی از راه‌حل‌های جایگزین برای مشکل فوق، ایجاد نرم‌افزار GIS است که مانند یک جزء مرورگر وب عمل می‌کند. به‌عنوان مثال، می‌توان به افزونه‌های متعدد برای مرورگر وب Netscape Navigator اشاره کرد. پلاگین برنامه مستقلی است که در چارچوب یک مرورگر کار می‌کند و خود را بین مرورگر و داده‌های قابل دسترس قرار می‌دهد. تفاوت اساسی بین افزونه و اپلت جاوا در نحوه دسترسی کاربر به آن‌ها است. پلاگین باید ابتدا از یک سرور روی هارد دیسک ماشین کاربر دانلود شود تا بتوان از هارد دیسک به آن دسترسی پیدا کرد. این یک افزونه را قادر می‌سازد تا به فایل‌های دیگر روی هارد دیسک دسترسی داشته باشد. اپلت جاوا برخلاف افزونه، هربار از یک سرور بارگیری می‌شود و فقط در زمینه صفحه WWW خاص که از آن استفاده می‌کند، وجود دارد. مزیت راه‌حل پلاگین نسبت به اپلت جاوا، این است که کاربر مجبور نیست در مورد نرم‌افزارهای پیچیده مانند GIS، داده‌ها را به صورت دستی به یک برنامه خارجی ارسال کند. مرورگر وب این کار را به صورت خودکار انجام می‌دهد.
با اینکه به نظر می‌رسد طراحی سیستم پشتیبانی تصمیم‌گیری فضایی مشارکتی، مبتنی بر مرورگر وب و معماری پلاگین راه‌حل امیدوارکننده‌ای باشد، اما عاری از محدودیت نیست. شدیدترین آن، وابستگی به نرم‌افزار مرورگر وب است. ممکن است نیاز باشد که یک افزونه به‌طور خاص برای مرورگر وب خاصی پیاده‌سازی شود؛ این بدان معناست که باید یک افزونه جداگانه برای Netscape Navigator و MS Internet Explorer وجود داشته باشد. اگر نسخه جدیدی از نرم‌افزار مرورگر در دسترس قرار گیرد، باید افزونه به‌روز شود. علاوه بر این، ارسال حجم زیادی از داده‌ها از مرورگر وب، محدودیت دیگری ایجاد می‌کند. انتقال داده‌های بزرگ باعث کاهش عملکرد می‌شود و حس تعامل را در یک برنامه کاهش می‌دهد.
رویکرد سوم شامل توسعه مستقل است. نرم‌افزار تخصصی که به مشتری اجازه می‌دهد با استفاده از زیرساخت اینترنت با سرور ارتباط برقرار کند، نمونه‌ای از این‌گونه معماری‌ها می‌باشدـ نمونه اولیه نرم‌افزار برای درک فضایی و سیستم پشتیبانی تصمیم (SUDSS) (جانکوسکی و استاسیک،۱۹۹۷،استاسیک،۱۹۹۹). SUDSS بر اساس معماری مشتری- سرور است (شکل ۳٫۱۲ را ببینید). جزء سرور که تحت سیستم‌عامل MS Windows NT 4.0 کار می‌کند، وظایف مدیریت پایگاه داده را انجام می‌دهد. مؤلفه کلاینت (کاربر) که تحت سیستم‌عامل MS Windows 95 کار می‌کند، یک برنامه کاربردی مستقل است که با پایگاه داده روی سرور ارتباط برقرار می‌کند. تبادل داده بین نرم‌افزار مشتری SUDSS و سرور SUDSS، تنها بر اساس پروتکل TCP/IP است. ارتباطات مبتنی بر TCP/IP با استفاده از انتقال داده با سوئیچ بسته، اتصال مشتری- سرور قابل اعتماد را فراهم می‌کند. یک ضعف بالقوه پروتکل از این واقعیت ناشی می‌شود که ممکن است در بالای پروتکل‌های سطح پایین‌تر و کمتر قابل اعتماد، عمل کند. این ممکن است در صورت انتقال چندرسانه‌ای (به‌خصوص زنده) مشکل ایجاد کند. با این حال،
شکل ۳٫۱۲ معماری نرم‌افزار نمونه اولیه SUDSS
مزیت رویکرد مورد استفاده در نمونه اولیه SUDSS (یک نرم‌افزار مستقل و آگاه به اینترنت)، استقلال آن از مرورگر وب و قابلیت‌های مدیریت داده بهتر است. علاوه بر این، از آنجایی که بسیاری از عملکردهای تحلیلی و مدیریت داده‌ها را می‌توان بر روی کلاینت انجام داد، این امر زمان ارتباط شبکه را کاهش داده و درنتیجه، سرعت عملیات نرم‌افزار را افزایش می‌دهد. نقطه‌ضعف این راه‌حل، هزینه توسعه و اغلب «ظاهر» و «احساس» جدید رابط کاربری است که با آنچه ممکن است بسیاری از کاربران در مرورگرهای وب محبوب به آن عادت داشته باشند، متفاوت است.