Lade...
 

Innovationsstau

Inhaltsverzeichnis:

 

Im Kreis drehen / Hamsterrad

 

DIe Technik entwickelt sich ständig weiter. Ergeben sich daraus auch Vorteile oder drehen wir nach wie vor im Kreis - nur etwas schneller?

 

Güterabwägung

 

Der Einsatz sogenannter „Standardlösungen“ steht für viele Unternehmensentscheider außer Frage. Dahinter steht die Vorstellung „das Rad nicht immer wieder neu erfinden zu wollen“, sicherlich aber auch die Erfahrung, dass individuelle Software Entwicklungsprozesse nicht immer on time oder on budget fertig gestellt wurden und werden.

Viele dieser Lösungen erfüllen jeweils bestimmte, klar abgegrenzte Aufgaben. Unterscheiden sich die eigenen Anforderungen davon, hat man die Wahl, die Abläufe in seinem Unternehmen nach der Software zu richten oder man versucht am Markt eine besser auf das eigene Unternehmen ausgerichtete Software zu finden.

Findet man die zum eigenen Unternehmen passgenaue Standardlösung, schreibt man mit der Einführung dieser neuen Software das zu diesem Zeitpunkt gültige Abbild des eigenen Unternehmens mehr oder minder fest.

 

Entitätenmodelle

 

Daten in Form von Karteikarten zu halten ist eine Form tief Karteikartendenken

Der bis heute weit verbreitete Einsatz relationaler Datenbanken und die damit verbundene Normalisierung von Daten hat zu Entitätenmodellen geführt,

hat zu einem Verständnis von  Entitäten geführt und ihren Beziehungen geführt. , der geprägt war von der zu lösenden Aufgabe und der Notwendigkeit weitestgehend Redundanz zu vermeiden. 

 

 die von fixen Strukturen geprägt sind. 

 damit verbundene den unumstrittene Umgang mit relationalen Modellen und damit verbunden die normalisierung von Daten (=Eliminierung von Redundanzen) hat zu einem Verständnis von  Entitäten geführt und ihren Beziehungen geführt. , der geprägt war von der zu lösenden Aufgabe und der Notwendigkeit weitestgehend Redundanz zu vermeiden. 

Eine Auseinandersetzung darüber, was eine Entität -  was ein Objekt – genau ausmacht, was es umfänglich definiert, war neu. Bisher gebräuchliche Begriffe wurden nun genauer hinterfragt, ein Prozeß der Abstraktion begann.
Werden relationale Entitäten eher als eine aus Anwendungssicht nützliche Zusammenstellung einzelner Datenfelder angesehen, hinterfragt eine Objekt orientierte Sichtweise zusätzlich die gemeinsamen Eigenschaften der Datenfelder im Ensemble.

Der bis dahin gewohnte Umgang mit relationalen Modellen hatte zu einem Verständnis von  Entitäten geführt, der geprägt war von der zu lösenden Aufgabe und der Notwendigkeit weitestgehend Redundanz zu vermeiden. Eine Auseinandersetzung darüber, was eine Entität -  was ein Objekt – genau ausmacht, was es umfänglich definiert, war neu. Bisher gebräuchliche Begriffe wurden nun genauer hinterfragt, ein Prozeß der Abstraktion begann.
Werden relationale Entitäten eher als eine aus Anwendungssicht nützliche Zusammenstellung einzelner Datenfelder angesehen, hinterfragt eine Objekt orientierte Sichtweise zusätzlich die gemeinsamen Eigenschaften der Datenfelder im Ensemble.

 

Eier legende Wollmilchsau

 

Natürlich ist man seitens der Anbieter bemüht, mittels Parametrierung alle möglichen Vorstellungen der Anwender zu antizipieren. Gehen deren Anforderungen aber darüber hinaus, taucht von seiten der Anbieter meist sehr schnell die Begrifflichkeit "Eier legende  Wollmilchsau" auf. Damit soll den Anwendern klargemacht werden, dass die Anforderungen utopisch sind und definitif nicht erfüllt werden können.

 

Objektorientierte Programmierung

 

Das Aufkommen der Objektorientierung Anfang der 1990er Jahre wurde in der Softwareindustrie als Paradigmenwechsel in den eigenen Entwicklungsprozessen angesehen. Gerade auch im Bereich betriebswirtschaftlicher Software war man überzeugt, durch eine veränderte, objektorientierte Sicht auf die zu modellierenden Abläufe, auf die zu erstellenden Anwendungslösungen, eine modularere, eine einfacher konfigurierbare und damit eine zu den Anforderungen der Anwender passendere Software liefern zu können.

 

IBM San Francisco Project

 

Damit war der Startschuss zur Suche nach den Grundbausteinen für betriebswirtschaftliche Anwendungslösungen gefallen. Prominentes Beispiel hierfür war das von IBM initiierte „San Francisco project“. Im Rahmen dieses Projekts wurden "Geschäftsobjekte“ entwickelt, die frei kombinierbar zu fertigen Anwendungslösungen führen sollten. Nach Fertigstellung von über 7000 unterschiedlichen Klassen mit über 35.000 Methoden wurde das Projekt erfolglos eingestellt. Was war schiefgelaufen? War das bereits das Ende der Suche nach einem Standard für die Entwicklung betriebswirtschaftlicher Lösungen?


 

Business Patterns