Dieses Modell ist klassisch für Open Source. Es kommt aus dem Bereich der Infrastruktur-Software wie Betriebssystemen, Datenbanken usw. Die Idee ist, dass der Hersteller selbst am besten dafür sorgen kann, dass die Software in Produktion auch funktioniert bzw. Nutzer am besten trainieren kann. Das ist mit Sicherheit ein wichtiger Teil des Interface21 Geschäftsmodells.
Mit Spring gibt es aber auch einen anderen Aspekt: Spring ist in erster Linie ein Programmiermodell. Das bedeutet, es definiert, wie man Software schreibt und bietet eine Abstraktion über die Dienste der Infrastruktur (Application Server usw.). Daher beeinflusst es auch die Architektur und überhaupt das Vorgehen im Projekt - die nicht völlig offensichtlichen Auswirkungen im Bereich Testen habe ich zum Beispiel in einem Vortrag auf der JAX dargestellt. Das ist ein wichtiger Unterschied zu Datenbanken, Application Servern oder Betriebssystemen, die das Programmiermodell bei weitem nicht so stark beeinflussen.
Aus genau diesem Grund bieten wir auch Consulting zum Thema Architektur und zu anderen Themen im Enterprise-Umfeld. Dabei kommt uns auch Spring wieder zur Hilfe: Da es Open Source ist, müssen wir kein Vertrieb für Lizenzen machen. Auch nicht, um Spring-bezogenes Consulting zu verkaufen: Wir sind ja gerade mit einem breiteren Leistungsspektrums im Enterprise Bereich aufgestellt und machen nicht nur Spring. Wobei die Qualität von Spring natürlich außer Frage steht und es kann eigentlich jedes Projekt von Spring profitieren: Spring bietet eben für praktische alle typischen Herausforderung im Enterprise-Umfeld eine Lösung z.B. durch die Integration anderer Frameworks.
Wegen des radikal modularisierten Aufbaus von Spring haben wir gleichzeitig die Möglichkeit, genau jene Teile von Spring in einem konkreten Projekt zu verwenden, die dort einen Vorteil erbringen. Die dann anzuwendende Migrationsstrategie ist eine weitere interessante Sache.
So sind wir recht offen und unabhängig. Das liegt mir auch persönlich sehr am Herzen, denn von orthodoxen Ansätzen gerade im Enterprise Java Bereich gibt es genug.
Unsere Unabhängigkeit ist auch recht offensichtlich: So bieten wir auch zu Hibernate Trainings an, obwohl wir dieses Produkt nicht selber entwickeln. Da wir aber zum Beispiel mit der Integration von Hibernate in Spring einen Berührungspunkt mit Hibernate haben und das auch auf einer nicht-trivialen technischen Ebene, arbeitet hier Spring in einer anderen Funktion für uns: Wir können auf Spring als Referenz für unser Know-How verweisen. Dies gilt auch allgemeiner: Wer eine solche umfangreiche und gute Lösung für Enterprise Java Probleme wie Spring entwickelt, kann sicher auch unabhängig vom Spring-Framework Lösungen für typische Probleme bei Enterprise Anwendungen aufzeigen. Und genau das wollen wir tun! ¶ 22:37
