MD Consulting war als Aussteller aber auch als Redner auf der Unify Entwicklerkonferenz 2011. Dr. Diestelmann hat unsere Eindrücke in einem Nachlesebericht niedergeschrieben. Lesen Sie selbst:

Die zweite Konferenz, bei der die Themen „Modernisierung“, aber auch Anwendungsentwicklung für die Microsoft .Net Plattform im Vordergrund standen.

Man kann – zusammenfassend – sagen, dass die diesjährige Entwicklerkonferenz der Firma Unify eine „Arbeitskonferenz“ war. Was soll damit gesagt werden? Nun, nachdem die Firma Unify die Team Developer Versionen 5.1, 5.2 und 6.0 auf den Markt gebracht hat und im Laufe der Konferenz die derzeit noch im Beta-Stadium befindliche Version 6.1 demonstrierte, kann festgehalten werden, dass Unify mit seiner Zusage Ernst gemacht hat, die lang aufgestauten Wünsche und Anforderungen seiner Kunden zu erfüllen: spätestens mit der Version 6.1, vielleicht aber schon mit der Version 6.0 sind die wesentlichen Punkte „abgearbeitet“:

   • Aufwärtskompatibilität: Der Source Code, den die Entwickler über Jahre hinweg entwickelt haben, lässt sich nach wie vor mit der jeweils neuesten Version des Entwicklungswerkzeugs lesen, bearbeiten und – gegebenenfalls nach ein paar Anpassungen – wieder kompilieren. Ein Schweizer Kunde schrieb uns dazu: „Das größte Lob müssen wir dem TD-Team dafür aussprechen, dass die Umgebung seit mindestens 17 Jahren (solang kenne ich es) aufwärtskompatibel ist!!!“
   • .Net Plattform: Anwendungsentwickler, die mit SQLWindows arbeiten, sind nicht am Ende des Produktlebenszyklus angekommen. Die „Umsetzung“ einer über Jahre, vielleicht sogar Jahrzehnte entwickelten Geschäftsanwendung auf die Plattform des Microsoft .Net Framework ist (ab der Version 6.0) möglich geworden.
   • Bedienoberflächengestaltung: Die beklagten Defizite bei der Gestaltung von Bedienoberflächen von SQLWindows-Geschäftsanwendungen sind durch Bereitstellung von Technologien wie Theming, weitere und erneuerte Controls, WPF Controls und die XAML-basierte Bedienoberflächengestaltung im .Net Bereich mehr als nur behoben.
   • Offene, marktübliche Standards: die Möglichkeit, Teile eines bestehenden Source Codes als .Net assembly zu kompilieren, um eine derartige Komponente anderen Entwicklungsteams zur Verfügung zu stellen und die Möglichkeit, Geschäftslogik als Web Services bereitzustellen bzw. in die eigene Anwendung zu integrieren, ermöglicht ganz neue Kooperationsmodelle mit Entwicklungsabteilungen, die mit gänzlich anderen Entwicklungswerkzeugen arbeiten.

Tatsächlich lässt sich feststellen, dass eine Vielzahl von Kunden mittlerweile die Einsparpotentiale erkannt haben, die sich durch diese neuen Funktionalitäten für sie ergeben können. Eine über die Jahre entwickelte Anwendung muss eben nicht neu, mit einem anderen Entwicklungswerkzeug geschrieben werden. Der Quellcode der alten Anwendung kann in die neueste Version des Entwicklungswerkzeugs übernommen werden, um die Anwendung dann an die neuen Anforderungen anzupassen, anstatt das Ganze von Grund auf neu aufzubauen.
Gerade um diesen Punkt aber kreisten die meisten Fragen, die auf der Entwicklerkonferenz in den einzelnen Sessions, aber auch in den Pausengesprächen eifrig diskutiert wurden. Festmachen kann ich das an meinem Beitrag, in dem ich unter dem Titel „Best practice” – from source code update to a .NET app“ die Erfahrungen referiert habe, die Mitarbeiter von MD Consulting in den letzten Jahren unter dem Titel „Migrationsberatung“ gemacht haben: der Vortrag war am zweiten Tag sowohl vormittags als auch nachmittags (also kurz vor dem Ende der Entwicklerkonferenz) angesetzt und zu meinem Erstaunen fanden sich in der ersten Session mehr als 50 Teilnehmer ein und sogar der zweite Termin hatte 15 Teilnehmer!
Mein Eindruck ist daher, dass eine Vielzahl von Entwicklungsteams derzeit damit beschäftigt ist, im kleinen – „Migration einer bestehenden Anwendung nach 6.x Win32“ – oder im großen – „Migration einer bestehenden Anwendung nach Microsoft .Net“ – zu planen. Es setzt sich zunehmend die Erkenntnis durch, dass Unify zwar der „große Wurf“ gelungen ist, dass aber im Detail eine Vielzahl von Problemen auftauchen können, mit denen der SQLWindows-Entwickler in der Vergangenheit nicht zu tun hatte:

   • UNICODE: manche Entwicklerteams sind sich unsicher, mit welchem Aufwand ihr eigener Code in UNICODE überführt werden kann. Ihnen ist möglicherweise unklar, dass Unify grundsätzlich alle Aspekte, insbesondere die, die die Weiterarbeit mit ANSI-Komponenten betrifft, berücksichtigt hat, wobei ein Teil automatisch durch Unify, ein anderer Teil durch geringfügigen Anpassungsaufwand seitens des Entwicklerteams vorgenommen werden muss.
   • Allgemeines Aussehen: durch die Überführung eines Quellcodes in die neue Entwicklungsumgebung wird automatisch ein Standard-Theme (aus einer Reihe unterschiedlicher Themes) zugeordnet: die Anwendung hat ein anderes Erscheinungsbild als in der Vergangenheit. Viele Entwickler sehen sich mit der Frage konfrontiert, welches der angebotenen Themes am besten mit den im eigenen Source Code gesetzten Gestaltungsattributen harmoniert und welcher Aufwand damit verbunden ist, hier wieder „Ordnung“ herzustellen.
   • Zurück zum „Gupta-Standard“: Unify berücksichtigt bei seiner Produktstrategie im Kern das Umfeld dessen, was in der Vergangenheit mit „Gupta-Mitteln“ gemacht werden konnte. Das heißt, dass das jeweilige Entwicklerteam ermitteln muss, ob man in der Vergangenheit nicht Gupta-Komponenten, wie mTable!, IntelliSal, usw. – eingesetzt hat. Für das Team stellt sich die Aufgabe, diese nicht Gupta-Komponenten im eigenen Code herauszufinden, einen entsprechenden Ersatz zu finden und den Aufwand für die Anpassung des eigenen Codes an die neuen „Komponenten“ einzuschätzen.
   • Neue Nutzungsszenarien: den Teilnehmern wurde immer mehr deutlich, dass Funktionalitäten wie .Net assemblies und Web Services zum ersten Mal die einfache Möglichkeit zur Zusammenarbeit mit anderen Entwicklerteams auf der Basis von Industrie-Standards bietet. Es dämmerte, dass sich hier erhebliche Rationalisierungspotentiale ergeben können, die sich aber nur dann erschließen lassen, wenn bei beiden Teams – beispielsweise den Visual Studio- und/oder Java-Entwicklern und das SQLWindows-Team – in einem kooperativen Arbeitsstil auf einander zu bewegen. In diesem Fall weisen die angebotenen, technischen Features weit über die reine Entwicklungsmannschaft hinaus: sie betreffen die Diskussionsbereitschaft innerhalb einer bestehenden Unternehmenskultur.

Verschwiegen werden sollte nicht die durchaus geäußerte Skepsis vieler Teilnehmer, die nach wie vor Zweifeln, ob der Weg der „Anwendungserneuerung“ schon mit der aktuellen Version von Team Developer beschritten werden kann. Insofern – und hiermit komme ich auf meine einleitenden Worte zurück – waren alle Teilnehmer begierig an Gesprächen mit den Unify-Experten, aber auch untereinander beschäftigt, Erfahrungen, Meinungen und Gedanken genau zu diesem Thema auszutauschen. Es waren daher nicht die vielen Neuerungen von Team Developer 6.1, die im Fokus standen, sondern die Frage, wann man sich auf den Weg machen kann, die Neuerungen, die die Firma Unify seit der Version 5.x eingeführt hat, für die eigenen Anwendungen nutzbar zu machen.
Die aktuelle Nachfrage nach diesen Dienstleistungen bei MD Consulting ist ein Indikator dafür, dass meine verkürzte Darstellung der diesjährigen Entwicklerkonferenz nicht gänzlich falsch ist.

MD Consulting wird zu diesem Thema in der nächsten Zeit Papiere, White Papers, aber auch Erfahrungsberichte veröffentlichen. Hier schon mal ein Auszug der geplanten Veröffentlichungen:
   1. Weiterentwicklung Ihrer TD-Anwendung
   2. TD und .NET – Kosten, Vorteile
   3. Bedienoberflächen in .Net WPF-Anwendungen
   4. Integration von .Net-Framework-Funktionen in SQLWindows Anwendungen

Die Liste hat nicht den Anspruch auf Vollständigkeit. Schauen Sie regelmäßig auf unsere Homepage unter dem Arbeitstitel „Mit dem TD in die .Net-Welt“ nach News. Interessieren Sie weitere Themen? Oder Sie wollen oder können nicht warten.
Sprechen Sie uns an. Gern steht Ihnen Herr Maik Vogt zu einem persönlichen Gespräch zur Verfügung, Tel: 0361/565930.

PS: Das korrigierte SP4 für den TD6 steht ab sofort wieder zur Verfügung. Hier geht’s zum Download .