Umfangreiche Analysen hinsichtlich der Total Cost of Ownership (TCO) und des Return on Investment (RoI) belegen, dass sich die Einführung einer Inhouse-ASP-Lösung nach 18 bis 30 Monaten bezahlt macht. Im Vergleich zu traditionellen Client-Server-Lösungen fallen die einzelnen Kostenblöcke im Verlauf eines Einführungsprojekts jedoch früher an. So sind beispielsweise die notwendigen Erstinvestments gleich, wenn nicht sogar höher als bei traditionellen Client-Server-Installationen. Die Einsparung der ASP-Variante resultiert letztlich aus den geringeren Betriebskosten des Systems über die gesamte Laufzeit hinweg.

Dennoch kämpft die hauseigene ASP-Alternative mit Akzeptanzproblemen, denn trotz Einsparmöglichkeiten von bis zu 30 Prozent entscheiden sich Unternehmen nicht selten für das langfristig ungünstigere System, weil sie sich von den Erstinvestionen abschrecken lassen. Außerdem resultieren abschlägige Entscheidungen häufig aus der Tatsache, dass für Anschaffung und Betrieb unterschiedliche Kostenstellen zuständig sind.

Unter technischen Gesichtspunkten fügt sich eine Inhouse-ASP-Lösung sehr gut und einfach in die bestehende IT-Infrastruktur eines Unternehmens ein. So ist eine sanfte Migration und Überführung der vorhandenen Client-Server-Strukturen in eine zentralisierte IT-Umgebung mit umfangreichen Backend-Ressourcen und schlanken Frontends machbar. Vorhandene Hard- und Software ist weiterhin nutzbar, so dass die getätigten Investitionen geschützt sind. Dennoch verändern sich einige Funktionsbereiche grundlegend. Eine neu definierte Arbeits- und Vorgehensweise ist unumgänglich.

Im ASP-Modus gliedert sich die IT-Umgebung in vier funktionale Ebenen (siehe Abbildung „Architektur der internen ASP-Lösung“). Der Backend-Bereich umfasst alle zentralen Daten-Server (File, Print, SQL, Backup usw.), und die nativen Anwendungs-Server. Diese Landschaft gilt es im Rahmen eines Inhouse-ASP-Projektes zu konsolidieren. Zudem steigen die Anforderungen an die Funktionalität und Verfügbarkeit, so dass eine Standardisierung und Zentralisierung erfolgen muss.

Im Plattformbereich finden sich die Applikations-Server (Windows Terminal Server in Kombination mit Citrix Metaframe) und die Web-Server wieder. Aufgabe dieses Funktionsblocks ist es, die vom Backend zur Verfügung gestellten Daten und Anwendungen in ein Portal-, also Browser-fähiges Format zu wandeln. In der Praxis hat sich gezeigt, dass der Plattformbereich die meisten Server für den Inhouse-ASP-Betrieb erfordert. Nicht Web-fähige Applikationen lassen sich nämlich nur mit Hilfe des Windows Terminal Servers (WTS) und von Citrix Metaframe im Browser darstellen. In aktuellen Projekten versorgen Server-Farmen mit bis zu 200 WTS-Citrix-Rechnern mehrere tausend Anwender. Hardwareseitig haben sich für diese Aufgaben ein Zoll hohe Slimline-Server sowie die seit kurzem verfügbaren Blade-Server bewährt.