Über uns

Die Anfänge

Die TeamWiSE GmbH wurde 1991 gegründet mit dem Ziel, maßgeschneiderte Entwicklungswerkzeuge und –methoden für solche Auftraggeber zu entwickeln, die das Potential von „custom-made“ für ihre eigenen Entwicklungsaktivitäten erkennen und erschließen möchten. Der Gründer und heutige Geschäftsführer, Diplom-Informatiker Harry Graave, konnte dazu auf seine langjährige Erfahrung als Entwicklungsleiter eines als Toolhersteller weltweit renommierten Softwarehauses zurückgreifen. Mittlerweile wird die TeamWiSE GmbH von 10 Mitarbeitern an zwei Geschäftstellen getragen.

Der Kern

Von Anfang an lag als Voraussetzung für diese Entwicklungsvorhaben der Fokus sämtlicher Bestrebungen auf der Erarbeitung einer allgemeinen Architektur der mit den Werkzeugen zu entwickelnden Anwendungen, als auch auf der Einbindung eines aktiven Repositories als „Single point of control“. Nach ersten Projekten für Unternehmen aus den Bereichen Energieversorgung, Handel, Tourismus und Gesundheitswesen entwickelte sich bald die Gesamtproblematik eines Versicherungskonzerns zum Schwerpunkt der Aktivitäten.

Die Architektur und ihre Strategie

In engster Zusammenarbeit mit einer Fachhochschule für Informatik (bekannt für ihre Ausrichtung auf systemtechnische Kernkompetenzen) wurden die Grundlagen für eine allgemeine technische Anwendungsarchitektur (TAA) sowie für eine virtuelle Sichtweise auf die zentralen Entwicklungsdaten (DDB) erarbeitet. Diese beiden Kernpunkte zeichneten sich durch ein Höchstmaß an Unabhängigkeit von der systemtechnischen Marktentwicklung aus. So hat sich die Nachhaltigkeit der Architekturkonzepte bis heute durch ihre Aufnahmefähigkeit für sämtliche in dieser Zeit entstandenen Konzepte erwiesen, seien es Client-Server, Objektorientierung, SOA, Webportal, „fat-Client“ oder auch die altbewährten und immer wieder benötigten Mainframekomponenten im Online- und auch Batch-Betrieb. Auch bei der Unterstützung für unterschiedliche Implementierungswege der diversen Anwendungskomponenten erwies sich die Gesamtkonzeption als äußerst integrativ, indem so völlig unterschiedliche Programmiersprachen wie C++, COBOL, C#, Java oder Visual Basic bei einheitlichem Daten- und Kontrollfluss beliebig in einer Anwendung vermischt werden konnten, unterstützt und gesteuert durch TAA-eigene „Broker“. So kann jede Komponente einer Anwendung mit der für sie am besten geeigneten Entwicklungsplattform realisiert werden, wodurch Qualität, Effizienz und Verfügbarkeit optimiert werden können.

Daneben bewährte sich die Architektur bereits mehrmals beim spartenübergreifenden Zusammenspiel von Komponenten, bei der nahtlosen Einbindung von Komponenten Dritter, sowie bei der Zusammenlegung von Anwendungsbereichen aus unterschiedlichen Konzernunternehmen. Die Modularisierung sowie die breite Werkzeugunterstützung ermöglichen der Anwendungsentwicklung außerdem eine hohe Flexibilität und Reaktionsgeschwindigkeit bezogen auf Marktentwicklungen.

Im Grunde genommen verfolgen wir bereits seit 1992 (vier Jahre, bevor der Begriff erstmals geprägt wurde) in unseren Architekturkonzepten die SOA-Prinzipien von heute:

	Komponenten einer Anwendung müssen in sich abgeschlossen und eigenständig nutzbar sein.
	Komponenten müssen im Netzwerk (LAN oder WAN) verfügbar sein.
	Jede Komponente muss eine veröffentlichte Schnittstelle besitzen. Zur Nutzung der Komponente muss die Schnittstellenbeschreibung ausreichen, Details über die Implementierung sind versteckt und brauchen nicht bekannt zu sein.
	Die Funktionalität einer Komponente ist unabhängig von der Plattform. Die Komponente kann auf und von unterschiedlichen Plattformen (Betriebssysteme und Programmiersprachen) benutzt werden.
	Alle Komponenten sind in einem zentralen Verzeichnis bekannt.
	Die Komponenten werden erst zur Laufzeit der Anwendung gesucht und zur Verfügung gestellt. Zur Entwicklungszeit der Anwendung genügt das Vorhandensein der Schnittstellenbeschreibung.

In der obigen Aufstellung kann man für Komponente auch „Service“ lesen: dann passen die Grundlagen unserer TAA zu 100% zu der SOA-Definition. Mit den obigen Prinzipien erreichen wir mit unserer Architektur:

	Eine Austauschbarkeit der Komponenten ohne Einfluss auf die Gesamtanwendung.
	Die Chance, jede Komponente mit der Programmiersprache auf der Plattform zu realisieren, zu der die Funktionalität der Komponente am Besten passt, sowie die Möglichkeit, diese Entscheidung jederzeit revidieren und neue Programmiersprachen und Betriebssysteme im Anwendungssystem integrieren zu können.
	Die Möglichkeit, durch Nutzung der formalen Schnittstellenbeschreibungen in Zusammenhang mit dem unternehmensweiten Datenmodell vorhandene Funktionalitäten leichter auffinden und damit wiederverwenden zu können.
	Evolutionär entwickeln zu können: vereinzelte Komponenten können zunächst nur ein Skelett darstellen, und zu einem späteren Zeitpunkt mit Inhalt gefüllt werden. Damit kann ohne Anpassung der Anwendung diese nach und nach um Funktionalität erweitert werden.

Zur Unterstützung dieser Architektur entwickelten wir im Laufe der Jahre eine umfangreiche Middleware, sowie diverse Modelle und Werkzeuge für die Entwicklungsumgebung. Dadurch, dass die Entwicklungsumgebung auf einem zentralen Repository aufbaut, und die Laufzeitumgebung auf einer zentralen Middleware, entsteht an beiden Seiten ein enormes Potential. Für die Entwicklungsumgebung bedeutet dies unter anderem:

	Ein besseres Zusammenspiel zwischen Fachabteilung und IT durch Überschneidungen in den Modellen auf dem gleichen Repository. Geschäfts- und IT-Ziele sind besser aufeinander abgestimmt.
	Reduzierung der Komplexität, Erhöhung der Flexibilität. Geringere Aufwände für die Erstellung neuer Funktionalitäten. Eine schnellere Reaktion auf geänderte Anforderungen.
	Die spartenübergreifende Nutzung von Entwicklungsdaten.
	Weitreichende Analysemöglichkeiten über die gesamten statischen Definitionen aller Geschäftsprozesse und –daten.
	Ein hochgradig automatisiertes und in allen Entwicklungsprozessen integriertes Konfigurationsmanagement.

Für die Laufzeitumgebung bewirkt das:

	Eine einfache Anpassung an neue Varianten und Versionen der technischen Infrastruktur ohne Eingriff in die Anwendungen. Die Anwendungskomponenten konzentrieren sich ausschließlich auf fachliche Logik, nicht auf die Auseinandersetzung mit den technischen Erfordernissen der jeweiligen Plattform.
	An zentraler Stelle können anwendungsübergreifend ohne Eingriffe in die Anwendungen Erweiterungen vorgenommen werden, um bspw. Prozessdaten zu sammeln und auszuwerten.
	Ebenso können Daten zur Testauswertungen (Regressionstest, Testabdeckungsgrad, Performance) gesammelt und genutzt werden.
	Technische Entscheidungen über die aktuell günstigste Ausführungsvariante können jederzeit neu bewertet und angepasst werden, wiederum ohne irgendwelche Änderungen in der Implementierung der Anwendungskomponenten.

Den maximalen Nutzen erzielt man mit den SOA-Überlegungen mit einem zentralen Repository, einer zentralen Middleware und dazu passenden Servicesystemen, die allesamt eine unternehmensweiten Architektur unterstützen.

Die Projekte und Produkte

Aufgrund der Abkapselung der Entwicklungsaktivitäten von den technischen Randbedingungen konnten Aufgaben in Angriff genommen werden, die nur mit dieser eingebauten Zukunftssicherung zu rechtfertigen waren. Als erster Themenkomplex entstand eine weitgefasste Unterstützung der Geschäftprozess-orientierten Implementierung von Anwendungen durch dedizierte Modelle, Tools, Middleware und sonstige Laufzeitkomponenten. Es folgten nach und nach viele weitere Themen, wie Dokumentenmanagement, Test und Qualitätssicherung, Plausibilitäten, Konfigurationsmanagement und Produktmanagement. Im Laufe der Zeit entstanden für die Entwicklung von TAA- und DDB-nahen Infrastrukturkomponenten auch diverse hausinterne Metatools (wie Compiler, Generatoren, Klassenbibliotheken, Frameworks), mit denen Neu- und Weiterentwicklungen auch über die bestehenden Grundlagen hinaus mit höchster Effizienz möglich sind.