BaTz DV-Consulting GmbH: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
|||
| Zeile 40: | Zeile 40: | ||
'''Im Vollausbau zerfällt eine Anwendung im TWIGGI Backend in ihre ''kleinsten Module''; ein Vorgang, analog zur Normalisierung einer relationalen Datenbank. Jedes dieser Module besitzt eine vollkommene Identität und Kommunikationsausstattung und kann auf irgendeinem beliebigen Rechner laufen, sofern dieser Teil des Internet ist.''' | '''Im Vollausbau zerfällt eine Anwendung im TWIGGI Backend in ihre ''kleinsten Module''; ein Vorgang, analog zur Normalisierung einer relationalen Datenbank. Jedes dieser Module besitzt eine vollkommene Identität und Kommunikationsausstattung und kann auf irgendeinem beliebigen Rechner laufen, sofern dieser Teil des Internet ist.''' | ||
Wie ein räuberischer Ameisenschwarm auf Beutezug integrieren sich die zuvor zusammenhangslos existierenden Module mittels Steuerungstokens zu ''einer Anwendung''. Im Moment der Integration werden Nutzdaten, Dokumentenformate, Authetifizierungs- und Steuerungscodes sowie Protokolldaten ausgetauscht. Es entsteht eine temporäre virtuelle Prozesskette, an deren Anfang der Ruf aus dem Frontend, und an deren Ende das erwartete Produkt steht, das seinerseits im Frontend erscheint. | Wie ein räuberischer Ameisenschwarm auf Beutezug integrieren sich die zuvor zusammenhangslos existierenden Module mittels Steuerungstokens temporär zu ''einer Anwendung''. Im Moment der Integration werden Nutzdaten, Dokumentenformate, Authetifizierungs- und Steuerungscodes sowie Protokolldaten ausgetauscht. Es entsteht eine temporäre virtuelle Prozesskette, an deren Anfang der Ruf aus dem Frontend, und an deren Ende das erwartete Produkt steht, das seinerseits im Frontend erscheint. Nach Abschluss des Anwendungsszenarios geben alleine die Protokolldaten Auskunft über die ggfs. abrechenbaren Nutzungseinheiten. | ||
Die konsequente Verkleinerung sowie Verteilung funktionstragender Module in einem ''3rd Generation ASP'' erlaubt ein Höchstmass an Skalierung und damit bestmögliche Performance. Bei ausreichender Bandbreite auf den Kommunikationsstrecken kann die Verarbeitungsdauer | Die konsequente Verkleinerung sowie Verteilung funktionstragender Module in einem ''3rd Generation ASP'' erlaubt ein Höchstmass an Skalierung und damit bestmögliche Performance. Bei ausreichender Bandbreite auf den Kommunikationsstrecken kann die Verarbeitungsdauer unter die menschliche Wahrnehmungsschwelle geschrumpft werden. | ||
Das Internet im Jahr 2013 kennt die temporäre Integration individualisierter Module als '''''Flash-Mob''''', wenngleich dieser Begriff zunächst auf den sozialen Kontext menschlicher Individuen beschränkt ist. Die Generalisierung aus dem Bereich '''''Human-Resources''''' heraus ist lediglich eine Frage der Zeit. | |||
Die konsequente Zerlegung und Verteilung funktionstragender Module im Internet ist in 2013 als '''''Cloud-Computing''''' bekannt und wird von einer Reihe großer Hersteller heftig als Kostensenkungsstrategie beworben. | |||
==== Seemingly Monolithic Desktop Architecture ==== | ==== Seemingly Monolithic Desktop Architecture ==== | ||
Version vom 7. November 2013, 08:55 Uhr
Geschichte
Die Firma baTz DV-Consulting GmbH im badischen Dielheim war eine der frühen Gründungen aus der Gruppe kleiner Ingenieurbüros für SAS-Consulting. Die GmbH stellte ab 2002 den Betrieb als Ingenieurbüro sukzessive ein, da sich das Geschäftsmodell mit systemübergreifenden und von Herstellerpolitik unabhängiger Systementwicklung als nicht mehr umsetzbar erwiesen hatte. Die verbliebenen Assets, Produkte und Rechte wurden an die Firma Phenix-MTK GmbH im hessichen Kelkheim am Taunus verkauft.
Während ihres Bestehens von 1991 - 2002 hat die Batz-DV wertvolle Synergien aus den Bereichen Integrierte Sprach-/Daten-Netze, Softwareentwicklung und Schulung bezogen. Als Folge entstanden eine Reihe zukunftsweisender Softwareprodukte als Umsetzung innovativer IT-Paradigmen die aus vorgenannten Synergien ermöglicht wurden. Zwei davon seien hier exemplarisch beschrieben:
ZAZY
Der lautmalerische Name ZAZY leitet sich ab von der Abkürzung SAS S.E.E. für SAS Software Engineering Environment. Das Produkt ZAZY war aus einer Zusammenarbeit mit der Software-Qualitätssicherung des Frankfurter Konzerns Hoechst AG hervorgegangen und gelangte 1997 als Erstimplementierung schliesslich zur Vorstellung auf der Internationalen SAS Benutzerkonferenz SEUGI in Madrid, Spanien.
Versatile Parser Family
Eines von vier Hauptmodulen war die Versatile Parser Family, kurz VPF, in der leistungsfähige Codeanalysewerkzeuge (Parser) zusammengefasst waren. Damit war ZAZY in der Lage, von Dritten verfassten SAS Code nach einer Reihe von Kriterien zu analysieren und die gefundenen Code-Strukturen zur Überarbeitung bereitzustellen. Aus der überarbeiteten Strukturinformation konnten dann weitere Module neuen Code generieren und beides einem Dokumentations- und Maintenance-Modul übergeben, das jederzeit in der Lage war, eine vollständige und aktuelle Zustandsbeschreibung eines gegebenen Softwaresystems zu liefern.
Damit lieferte ZAZY eine bis dahin nicht gekannte Transparenz im Software Engineering mit SAS.
TWIGGI
Der etwas sperrige Name Thin Windowed Internet Graphics Generator Interface, kurz TWIGGI steht für die enge Symbiose von webbasierter Benutzeroberfläche und Adhoc-Datenaufbereitung mit Business-Intelligence-Methoden. Bereits in der produktiven Erstimplementierung aus dem Jahr 2000, als Multikonzern-Datawarehouse mit Web-Interface der Hannoverschen FZ-Gruppe, hat die Technologie überzeugende Leistungsdaten geliefert:
- 2 Millionen vorgehaltene Datensätze pro Woche
- Historie von 100 Wochenbeständen (2 Jahre)
- Thematische Landkarten mit dynamischer Farbcodierung
- Stufenweise Zoomfunktion in PLZ-Teilung bis fünf Stellen
- 10 Sekunden mittlere Antwortzeit
- 20 Sekunden maximale Antwortzeit
Diese Leistungsdaten sind Ergebnis zweier Konzepte, die, vereinfacht ausgedrückt, das Anwendungs-Backend vollkommen neu strukturiert haben, und dem Anwendungs-Frontend eine ebenfalls vollkommen neue Architektur verliehen haben: 3rd Generation ASP und Seemingly Monolithic Desktop Architecture.
3rd Generation ASP
Mit Application Service Provider, kurz ASP, wurden in der Pionierzeit des World Wide Web die Rechenzentren bezeichnet, deren Server über das Hypertext Transfer Protocol (HTTP) erreichbar waren. Als offenes, herstellerunabhängiges Protokoll war HTTP für jede Hardware, oft sogar gratis, erhältlich. Mit einem ASP konnte also jedermann kommunizieren, der nur irgendeinen Computer irgendeines Herstellers besass und in der Lage war, diesen mit dem Telefonnetz zu verbinden.
In Abkehr von den klassischen Rechenzentren mit ihren proprietären Kommunikationstechnologien (= 1st Gen) und den klassischen ASPs (= 2nd Gen) wurde für TWIGGI eine RZ-Architektur in unlimitierter Netz-Topologie (= 3rd Gen) entworfen. In Erweiterung eines Marketing-Slogans der Hardwarefirma Sun Microsystems, "The network is the computer", galt für TWIGGI's Backend-Architektur: "The internet is the computer".
Im Vollausbau zerfällt eine Anwendung im TWIGGI Backend in ihre kleinsten Module; ein Vorgang, analog zur Normalisierung einer relationalen Datenbank. Jedes dieser Module besitzt eine vollkommene Identität und Kommunikationsausstattung und kann auf irgendeinem beliebigen Rechner laufen, sofern dieser Teil des Internet ist.
Wie ein räuberischer Ameisenschwarm auf Beutezug integrieren sich die zuvor zusammenhangslos existierenden Module mittels Steuerungstokens temporär zu einer Anwendung. Im Moment der Integration werden Nutzdaten, Dokumentenformate, Authetifizierungs- und Steuerungscodes sowie Protokolldaten ausgetauscht. Es entsteht eine temporäre virtuelle Prozesskette, an deren Anfang der Ruf aus dem Frontend, und an deren Ende das erwartete Produkt steht, das seinerseits im Frontend erscheint. Nach Abschluss des Anwendungsszenarios geben alleine die Protokolldaten Auskunft über die ggfs. abrechenbaren Nutzungseinheiten.
Die konsequente Verkleinerung sowie Verteilung funktionstragender Module in einem 3rd Generation ASP erlaubt ein Höchstmass an Skalierung und damit bestmögliche Performance. Bei ausreichender Bandbreite auf den Kommunikationsstrecken kann die Verarbeitungsdauer unter die menschliche Wahrnehmungsschwelle geschrumpft werden.
Das Internet im Jahr 2013 kennt die temporäre Integration individualisierter Module als Flash-Mob, wenngleich dieser Begriff zunächst auf den sozialen Kontext menschlicher Individuen beschränkt ist. Die Generalisierung aus dem Bereich Human-Resources heraus ist lediglich eine Frage der Zeit.
Die konsequente Zerlegung und Verteilung funktionstragender Module im Internet ist in 2013 als Cloud-Computing bekannt und wird von einer Reihe großer Hersteller heftig als Kostensenkungsstrategie beworben.
Seemingly Monolithic Desktop Architecture
Seemingly Monolithic Desktop Architecture, kurz SMDA, bezeichnet eine Implementierungsstrategie der Benutzeroberfläche, die dem Anwender das haptische Erlebnis einer einzigen Software-Entität vermittelt, wie das die APPs heutiger Smartphones tun: Obwohl das Gesamtsystem aus einer Vielzahl aktiver Module besteht, die ihrerseits in teilweise heftigem Datenaustausch über ein weltweites Netzwerk miteinander verbunden sind, erlebt der Nutzer einzig die Interaktion mit seiner Applikation. Das gesamte Backend ist ebensowenig spürbar, wie es ohnehin schon sichtbar war; es scheint überhaupt nicht vorhanden zu sein.
Erst diese perfekte Illusion, dass nämlich alles auf seinem Gerät geschieht, dass mithin also alle Eingaben dort bleiben, erzeugt im Anwender das Vertrauen, das nötig ist, der Anwendung alle geforderten Daten zu übergeben: Persönliches, Privates, Vertrauliches und Intimes.
Die Smartphone-APPs des Jahres 2013 erfüllen die Anforderungen der SMDA nahezu vollständig.