CW: Werden mittelstaendische Unternehmen mit fertiger Standardsoftware arbeiten, oder erleben Individualloesungen eine Renaissance auf hoeherem Niveau?
Heiler: Der Trend geht eindeutig zu Individualloesungen, die nicht mehr vom Entwickler, sondern vom Power-User mit Fachwissen hergestellt werden. Die Entwicklung erfolgt schon bald mit Komponenten, die so individualisierbar und kompatibel sind, dass sich Software praktisch am Fliessband erzeugen laesst.
Natuerlich gibt es Abstufungen zwischen Loesungen, die der Anwender fuer sich selbst baut, und solchen, die fuer Gruppen und Unternehmen gemacht werden oder die verkauft werden sollen. Je groesser die Gruppe der Nutzer ist, desto groesser muss das Know-how bezueglich der Komponenten sein.
CW: Was verstehen Sie unter Komponenten?
Heiler: Komponenten lassen sich zur Zeit nur in Hinblick auf den PC-Markt und die dort vorherrschende Technologie beziehungsweise den De-facto-Standards betrachten. Microsoft gibt dort den Ton an, eines der wesentlichen Merkmale von Windows 95 wird die OLE-2- Logik sein in Verbindung mit den sogenannten OLE Control Extensions (OCX). Dabei handelt es sich um vorgefertigte Funktionspakete fuer 32-Bit-Anwendungen, die sich in OLE-faehige Programme einbinden lassen. Diese technologische Basis bietet ungeahnte Moeglichkeiten.
CW: Welche?
Heiler: Programmierbibliotheken mit typischen Sprachen treten in den Hintergrund, statt dessen gibt es fertige Objekte, die auf einer objektorientierten Ebene zur Verfuegung stehen. Der Anwender legt nur noch Softwareschalter um und aktiviert oder parametrisiert auf diese Weise Objekte innerhalb einer Loesung. Irgendwann wird es dazu kommen, dass er seine Anwendung sogar waehrend der Laufzeit veraendert.
CW: Im Moment werden Entwicklungsumgebungen wie Visual Basic dazu verwendet, nach herkoemmlichem Programmierverfahren Erweiterungen rund um Standardsoftware zu stricken.
Heiler: Richtig. Ich halte jedoch die Strategie von Microsoft, alle Standardprodukte mit einer Visual-Basic-Programmiersprache fuer diesen Zweck auszustatten, fuer falsch. Anwender wollen nicht in die Tiefen eines Sourcecodes hinuntergehen. Sie wollen nicht debuggen und all diese Dinge. Heute schreibt man mit Visual Basic eine Adressverwaltung um Word herum - das ist relativ kompliziert und wird nur von wenigen Leuten beherrscht.
CW: Sie halten diesen Aufwand fuer ueberfluessig?
Heiler: Ja. Standardprogramme wie Winword, Access oder Excel sind eierlegende Wollmilchsaeue - riesige Applikationen, die eigentlich schon alles koennen. Wenn man aber beispielsweise eine unternehmensweite Adressverwaltung realisieren moechte, auf die jeder Zugriff haben soll, kommen diese Anwendungen nicht zum Punkt.
Fuer eine solche Loesung benoetigt man nur einen Bruchteil der Word- Funktionalitaet, ein wenig Tabellendarstellung aus Excel etc. Diese Essentials moechte sich der Anwender aus den Programmen herausholen und zu einem Funktionsblock verschweissen. Er will einerseits die Applikationen vollstaendig nutzen und andererseits Funktionen unter einem neuen Menue zu Unterobjekten zusammenfassen und verdrahten koennen. Die OCX-Technologie wird diese Entwicklung vorantreiben.
CW: Wie muss man sich das Design einer Applikation mit sogenannter Component Ware vorstellen?
Heiler: Sie beginnen, indem Sie beispielsweise Ihr Textverarbeitungsobjekt auf wenige Funktionen herunterkonfigurieren, die Sie fuer eine bestimmte Applikation benoetigen. Das Woerterbuch fliegt raus, der Thesaurus ebenfalls. Sie benoetigen nur noch das Dokument, das Sie mit einem bestimmten Datenobjekt verbinden wollen, indem Sie es ueber ein Menue anhaengen. Dann brauchen Sie noch ein Datenvisualisierungsobjekt, eine Mischung aus Liste und Dokument - das binden Sie ebenfalls an.
Man baut Applikationen, indem man Objekte aus diversen Anwendungen miteinander integriert. Standardprogramme werden nach individuellen Massstaeben so weit fragmentiert, dass der Unterschied zwischen einem Programmierobjekt und einer Applikation nicht mehr erkannt wird.
Und das ist das Revolutionaere an der OLE-2-Thematik: Standardprodukte werden zu Entwicklungskomponenten, die sich selbst integrieren. Diese Methode ist bereits in Windows 95 angelegt. Wenn Sie dieses Verfahren im Geiste noch mit der Remote- Procedure-Call-(RPC-)Technologie koppeln, die Ihnen hilft, auch andere Rechner fuer Rechen- und Integrationsaufgaben einzusetzen, dann wird die Sache hoechst interessant.
CW: Wie werden solche Objekte hergestellt?
Heiler: Auf dem untersten Level als Dynamic Link Libraries (DLLs), ansonsten als Visual Basic Extensions (VBX) oder neuerdings als OCX. Mit dieser Technik betreten wir Neuland. Angefangen haben wir mit LIB-Dateien, die man einfach kompilieren konnte. Mit Windows kamen dann die DLLs auf, aus ihnen wurden Objekte, die schon Properties hatten. Heute gehen wir in den rein objektorientierten Bereich hinein, mit Klassenbaeumen, Methoden und Vererbung.
CW: Welche Funktionen haben Programmiersprachen wie Visual Basic, Delphi, SQL Windows oder Powerbuilder kuenftig in Ihrem Szenario?
Heiler: Eine OCX-faehige Komponente kann ein Entwicklungssystem nicht ersetzen - jedenfalls zur Zeit noch nicht. Sie integriert sich jedoch automatisch in ein Programmiersystem, wenn dieses ueber einen OCX-Container verfuegt (Access, Visual Basic 4.0). Zukuenftig kann man sich vorstellen, dass dieser OCX-Container nicht mehr in Form einer Programmiersprache verfuegbar sein muss, sondern auf Betriebssystem-Ebene und damit im Hintergrund arbeitet. Programmieren bedeutet dann, dass man eine Loesung ueber ein Basis- Applikationsobjekt (OCX-Container) unter Zuhilfenahme der OCX- Komponenten per Drag und Drop und Klick zusammenbaut. Das typische Codieren faellt damit weitgehend weg.
Heute lassen sich OCX-Container und -Komponenten nur auf der Ebene von Visual C++ entwickeln. Visual Basic, SQL Windows, Delphi etc. koennen die Komponenten nur integrieren. Aber auch hier kann in Zukunft mehr erwartet werden. Beim Clipper-Nachfolger CA Visual Object etwa koennen auf einer 4GL-Ebene bereits echte DLLs fuer Windows erzeugt werden. Allerdings ist dieses System aus anderen Gruenden im Moment nicht sehr populaer.
CW: Wie ueberbrueckt man heute die Schnittstelle zwischen Component Builder und Komponenten?
Heiler: Die OCX-Technologie sorgt dafuer, dass zwischen den als Objekt verbundenen Methoden und Klassen und dem Component Builder kein Interface mehr geschrieben werden muss. Hersteller werden ihre Tools als OCX herausbringen. Damit sind sie das Schnittstellen- Problem los, und die Kunden koennen ihre Komponenten in verschiedene Entwicklungssysteme einbinden.
CW: Bedeutet das, dass eine Firma Borland ihre Programmierumgebung Delphi nur dann erfolgreich verkaufen wird, wenn eine OCX- Schnittstelle realisiert ist?
Heiler: Richtig. Borland und andere Hersteller von Entwicklungssystemen muessen entscheiden, ob sie OCX-Kompatibilitaet gewaehrleisten wollen. Wir sind zuversichtlich, dass der Markt in diese Richtung geht. Ein Beispiel: Powerbuilder und Gupta werden unsere programmierbare Textverarbeitung High-Edit in der naechsten Version integriert haben. Unser Anpassungsaufwand ist gleich Null. Der Benutzer kann jetzt beispielsweise eine Datenbankapplikation anfertigen, in der das Dokument direkt in einer Textverarbeitung erscheint und Textfelder unmittelbar mit der Datenquelle verbunden sind.
Hersteller von Entwicklungssystemen wie Powersoft oder Gupta sagen sich heute, je mehr wir an solchen Komponenten mitliefern, desto attraktiver wird unser Entwicklungssystem. Sie spueren, dass Entwicklungsumgebungen austauschbar werden. Visual Basic und Delphi zum Beispiel sind einander optisch sehr aehnlich. Leute, die auf Turbo-Pascal stehen, freuen sich ueber Delphi, denn das ist praktisch ein Visual Basic mit Turbo-Pascal-Dialekt. Der objektorientierte Mechanismus ist nahezu identisch.
CW: Wie unterscheiden sich Component Builder denn dann noch voneinander?
Heiler: Von den Anspruechen der Zielgruppe her. SQL Windows von Gupta beispielsweise ist fuer anspruchsvolle datenbankorientierte Nutzer gedacht. Objekte werden daher hoeher parametrisiert und diffiziler justiert als beispielsweise in Microsoft Access. Je mehr Sie von standardisierten Loesungen abweichen wollen, desto komplexer wird Ihr Component Builder. Spaetestens dann, wenn Sie selbst Komponenten entwickeln moechten, muessen Sie sich mit der Microsoft Foundation Class Library (MFC) oder anderen C++-Klassen befassen.
CW: Wie vollzieht sich bei alledem die Koordination von Workflows?
Heiler: Sie realisieren etwa ein Warenwirtschaftsprogramm aus den drei Objekten Spreadsheet, Textprozessor und Datenbank. Die hoechste Klasse ist beispielsweise das "Buch", es definiert, wie die "Seiten", die einzelnen Editoren, aussehen sollen. Das geht ueber eine Property- und Menuestruktur, die sicher nicht aussieht wie ein Menue von einem normalen Warenwirtschaftsprogramm, sondern wie eine Liste von Schaltern, die ich an- und ausknipse. Mit modernen VBX-Controls bricht man schon heute aus der von Microsoft vorgegeben Logik aus und kommt in sehr individuelle Menues.
Mit Hilfe von Text-Controls sagt man dem System, wann und in welcher Form es einen bestimmten Texteditor aufrufen soll. Ueber den Grafik-Control wird definiert, wann eine Information als Tabelle oder Grafik angezeigt wird. So definiert man einen Baum, in dem man Objekte miteinander verkettet. Im Betriebssystem befinden sich diverse Servicelevels, Verzeichnisstrukturen oder Listen, die diese Objekte verwalten - Verkettungslisten.
Der Mensch denkt in Dokumenten. Die Frage ist letztlich, wie ein Dokument in einem Workflow untergebracht ist - es muss von A nach B gehen, es muss das Programm mit sich fuehren. In Zukunft wird das Dokument die Workflow-Definition bei sich tragen. Dokumente werden mitsamt ihrer Steuerung von Rechner zu Rechner gebracht.
CW: Ist der Ansatz einer tabellengesteuerten Software e la SAP, wo sich ueberfluessige Funktionalitaet durch Parametrisierung ausklammern laesst, nicht mehr aktuell?
Heiler: Bei SAP haben Sie diese reduktive Methode. Das, was die Software kann, macht sie so und nicht anders. Auf bestimmte Workflows kann man kaum Einfluss nehmen. Schwierigkeiten entstehen spaetestens dann, wenn man Add-ons einsetzen will. Das Ganze ist nicht so transparent. Wir glauben, dass dieser Typus von Software in Grossunternehmen noch lange existieren wird, aber von der Architektur her im Prinzip schon der Vergangenheit angehoert.
Wir muessen wegkommen von der schweren SAP-Logik. In der Finanzsoftware Quicken beispielsweise finden Sie sehr leistungsfaehige Objekte. Ein Scheckformular, das man sich gut als eigenes Objekt vorstellen kann. Voellig unabhaengig, in jede Programmierumgebung integrierbar. Man kann Schecks drucken und mailen, Ueberweisungen taetigen, Datex-J anwaehlen, Electronic- Banking... Es kann eine Vielzahl von Eigenschaften haben, die man nur an- und abschaltet.
Ein solches Objekt kann voellig stand-alone als OCX dastehen. Es kann mehrere Ueberweisungstraeger darstellen, und man kann es mit mehreren Ueberweisungstraegern zu einer Liste zusammenstellen. Dazu benoetige ich keine Programmiersprache. Wenn ich 200 Eigenschaften habe, die ich nur bei Bedarf aktivieren muss, und diese sinnvoll kombiniere, habe ich eine Applikation fuer sich. Ich kann sie per Mausklick in Winword oder Wordperfect integrieren.
CW: Haben Sie so etwas schon mal gemacht?
Heiler: Ja. Lassen Sie mich am Beispiel eines Vertriebsinformationssystems, das wir fuer einen Kunden realisiert haben, erklaeren, wie es funktioniert. Die Ausgangslage: Ueberall im Unternehmen sind Adressen, die zunaechst einmal koordiniert werden muessen. Stichwort: unternehmensweites Adress-Management. Dann gibt es Vorgaenge, diverse Akten ueber Kunden - die muessen zusammengefasst werden. Hinzu kommt ein DFUE-Problem, weil der Sales-Mann von unterwegs auf den Host zugreifen muss. Er soll seine eingegangenen Auftraege abliefern und seine Umsatzberichte empfangen. Man hat also ein Kommunikationsproblem und eines, das die Heterogenitaet der Datenstrukturen im Unternehmen betrifft.
Wir haben ein solches System fuer einen Kunden innerhalb von drei Monaten gebaut - der Kunde hatte dafuer ein Jahr eingeplant. Wir haben beispielsweise ein unternehmensweites Adress-Management- System realisiert, indem wir uns eine Programmiersprache genommen haben, die die Microsoft-Standards OCX, VBX, DLL etc. unterstuetzt.
CW: Welche Objekte haben Sie gebraucht?
Heiler: Wir benoetigten ein Adressobjekt, das verschiedene Arten des Data Entrys unterstuetzte, und ein Adress-Label-Objekt, das die Informationen, die in den Datenbankfeldern stehen, zu einer international gueltigen Adresse macht. Dazu kam ein Algorithmus, der die Ansprachen auf typischen Kommunikationsebenen wie Brief, Fax etc. realisiert, ein Doubletten-Check-Algorithmus, damit Adressen nicht doppelt erfasst werden und damit sich doppelte Adressen aufspueren lassen, und ein Replikationsalgorithmus fuer die Verbindung mit anderen Host-Systemen, in dem Fall einer AS/400 und Lotus Notes. Ausserdem war ein Uebergang zu einem Dokumenten- Datenbanksystem gewuenscht, das ebenfalls mit Notes realisiert worden war.
CW: Liessen sich Objekte wiederverwenden?
Heiler: Wir haben aus einem anderen Projekt vier gekapselte Objekte uebernommen - DLLs, wenn Sie so wollen. Es gab jedoch ganz klare Entry- und Exit-Points. Nach einem Monat war der Prototyp einschliesslich dieser Funktionalitaeten bereits fertig. Dann hat unser Kunde den Doublettenalgorithmus moniert, da er nicht seinen Beduerfnissen entsprach. Wir haben ihn herausgenommen und nach dem speziellen Kundenwunsch neu gestaltet. Dabei konnten die anderen Algorithmen so belassen werden, wie sie waren, weil alle Objekte gekapselt waren.