wie Recht Sie doch haben! Nach über 20 Jahren eigener Erfahrungen mit Open-Source-Systemen (ich nutze seit vielen Jahren OSS sehr erfolgreich auch im beruflichen Umfeld) beobachte ich noch immer Unternehmen, die Schnittstellen-Spezifikationen nicht offenlegen oder die Entwicklung von Treibern für ihre Geräte eher bremsen als fördern. Noch immer gibt es verschiedenste Content-Anbieter (nicht nur im Internet), die ihre Inhalte so „schützen“, dass sie mit freier Software nicht genutzt werden können, auch wenn sie vollkommen legal erworben wurden. Das ist zum einen für den Nutzer ärgerlich, zum anderen sehr schade, weil Chancen unnötig verschenkt werden. Und welcher technische Schutz hat Finsterlinge je von ihrem Tun abgehalten? Vielleicht würde ein wenig mehr Offenheit und Mut tatsächlich Wunder wirken?
Andererseits beobachte ich Anwenderunternehmen, die „ohne Not“ Entscheidungen zugunsten bestimmter Plattformen treffen, für die es freie Alternativen gibt und so mithelfen, den Trend zu geschlossenen Lösungen oder gar oligoploartigen Strukturen zu festigen. Es müssten also nicht nur die mächtigen Intermediäre mehr Mut zur Offenheit haben, sondern auch die großen Anwender, die durch ihre Marktmacht Entwicklungen beeinflussen können. An einigen Stellen hat das erfreulicherweise schon gut funktioniert. Hoffen wir also im Sinne des Open-Source-Gedankens auf weitere Schritte in die richtige Richtung.

Paradox an der ganzen Sache ist allerdings, dass man als gewinnbringender Arbeitnehmer zwar immer mehr Amüsement geboten bekommt, dass aber in manchen Branchen (siehe IT) die Zahl der Ausgebrannten zunimmt – auch wenn diese anfangs Feuer und Flamme für ein tolles großes Unternehmen waren. Der Druck nimmt zu. Das ist zumindest der Eindruck, den ich aus meinem Bekanntenkreis so mitbekomme.

Die Frage ist, welche Ventile Unternehmen schaffen können. Vielleicht ist bei den Top-Unternehmen bald der Hauspsychologe obligatorisch, der den Arbeitnehmern dann hilft, wenn die Arbeit alleine nicht mehr die Erfüllung ist und der Druck zu arg ist. Autogenes Training, Boxen gegen den Frust usw. Das könnte bald Einzug halten.

Schöner wäre es natürlich, wenn man durch ein tolles Betriebsklima gegen den Druck anarbeiten könnte oder eine Atmosphäre schaffen könnte, in der so mancher Frust kompensiert werden kann. Das ist nicht obligatorisch und im Grunde mehr wert als immer bessere materielle Vergünstigungen zu schaffen. Dann wäre es meiner Meinung nach gar nicht nötig sich zu Tode zu amüsieren.

Das ist nur meine Meinung, andere mögen es anders sehen.

Nimmt man die Bezeichnung “Google Earth”, kann man festhalten, dass das ein gelungener Marketing-Begriff ist, und zwar für die abrufbaren Map Presentating Services, die Google auf der Basis von Satellitenaufnahmen und Kartenprojektionen erbringt. Alle weiteren Interpretationen laufen ins Unergiebige und Leere.

Beim Bild des “Cloud Computing” kann man sich, ganz à la Reinhard Mey, vorstellen, dass der abrufende Service-Konsument über diesen Wolken schwebt – sozuschreiben im 7. Service-Himmel ;-), weil ihm auf seinen expliziten Abruf hin aus diesen Wolken die “cloud”- bzw. ICT-systembasierten Business Support Services (ICTBSS) erbracht werden, die er bei Bedarf abruft. Es handelt es sich also in Wirklichkeit um Service (Contribution) Sourcing.
Hält man sich vor Augen, dass die “Clouds” eine andere Bezeichnung für ein Konglomerat von service-relevanten ICT-Systemen sind, wird sofort klar, dass es sich bei der “Cloud” allenfalls um bodennahen Nebel handeln kann, der von der Klimaanlage des betreffenden Rechen- oder Server-Zentrums verursacht wird.

Ähnlich seltsam verhält es sich mit dem “Application Lifecycle Management”. Da eine Applikation(sinstanz) nur jeweils so lange existiert, wie der zugeörige Software-Code in einem Hauptspeicher resident ist, währt der Application Lifecycle vom Starten der Applikation bis zum Beenden derselben. Sofern man allein mit dem Starten & Stoppen von Applikationen Erfolg und ROI erreichen kann, dürfte das Leben recht einfach sein ;-)

Fazit:
Jeder neu erfundene Begriff, der nicht per se fundiert mit valider Bedeutung und praxisrelevantem Inhalt belegt ist, lässt sich leicht entlarven, so dass der entsprechende Begriffsdampf sich schnell verzieht.

Fazit:
Das Business-IT-Alignment bzw. die direkte Kopplung von Business und IT-Governance greift zu kurz, weil sie ausblendet, dass erst der Mitarbeiter in der Business Unit (= berechtigter Service-Konsument) durch Abruf, Konsumierung & Verwendung eines abgerufenen ICT-systembasierten Business Support Service (ICTBSS) die geschäftliche Wertschöpfung realisiert. Sofern der Service-Konsument als kritischer Erfolgsfaktor & die Abfolge von Service-Abruf, Service-Erbringung & Service-Konsumtion ausgeblendet werden, werden die abgerufenen ICTBSS oft in unzulänglicher Qualität erbracht oder (viel zu) häufig versagt. Des Weiteren sind die effektiven Gestehungskosten pro Service-Erbringungseinheit oft unverhältnismäßig hoch. Erst durch die vermittelnden & verbindenden Aktivitäten der durchgängigen Service-Konzipierung können die service-relevanten ICT-Systeme rationell entworfen & dimensioniert, überwacht & gesteuert werden.

- dem reinen Software-Sachgut, d.h. dem Programm-Code, in den die anforderungsgerechten Funktionen hineinprogrammiert sind; das freigegebene Software-Sachgut wird auf einem adäquaten digitalen Speichermedium abgelegt

- der Applikation, die erst dann gegeben bzw. vorhanden ist, wenn das betreffende Software-Sachgut in einer geeigneten Laufzeitumgebung installiert & konfiguriert, aktiviert & operiert, administriert & gepflegt, gewartet & repariert wird.

Daraus ergeben sich die getrennten und aufeinander bezogenen Aufgabenbereiche:

- Software Lifecycle Management mit
– dem Anforderungsmanagement für ein bestimmtes Software-Sachgut mit Blick auf die geschäftsrelevanten ICT-systembasierten Business Support Services (ICTBSS), die durch den Einsatz des Software-Sachguts erbracht werden müssen
– der gesamten Software-Entwicklung bis zur getesteten & freigegeben Software-Version
– dem Release bzw. Versionsmanagement für das freigegebene Software-Sachgut bis zu seinem Rückzug aus dem Software-Angebot bzw. aus der Servuktionsumgebung
– das Wartungs- & Reparaturmanagement für das freigegebene Software-Sachgut, das mit dem Release bzw. Versionsmanagement abgestimmt wird

- Management der adäquaten Laufzeitumgebung, also das Entwerfen & Dimensionieren, Installlieren & Konfigurieren, Aktivieren & Operieren, Administrieren & Pflegen, Warten & Reparieren der technischen Systemumgebung mit Blick auf den Einsatz des betreffenden Software-Sachguts einer bestimmten Version in dieser Umgebung

- Application Hosting Managememt, d.h. das Installieren & Konfigurieren, Aktivieren & Operieren des betreffenden Software-Sachguts in der vorgesehenen Laufzeitumgebung sowie das Administrieren & Pflegen der dann speicherresidenten Applikation

- Application Maintenance Management, das das Warten & Reparieren der Applikation(sinstanzen) in ihren jeweiligen Laufzeitumgebungen umfasst

Ein Applikationssystem bzw. eine Applikationsinstanz ist in vielen Fällen ein service-relevantes System für die Erbringung von Standard-Service-Beiträgen für ICT-systembasierte Business Support Services (ICTBSS). Das Applikationssystem verfügt dann über bestimmte service-relevante Funktionen, durch deren Ausführung bestimmte Standard-Service-Beiträge für einen abgerufenen ICTBSS zugebracht werden. Insofern ist das Service Delivery Management für die geschäftsrelevanten ICTBSS als Ausgangs- & Bezugsbasis maßgeblich für Design & Sizing, Einsatz & Betrieb, Monitoring & Management der service-relevanten Applikationssysteme mitsamt ihrer erforderlichen Infrastruktursysteme. Aus der Service-Konzipierung für die geschäftsrelevanten ICTBSS ergeben sich wesentliche Anforderungen an die Funktionalität der erforderlichen Software-Sachüter.
Auch wenn die Verzahnung der verschiedenen Aufgabenbereiche in vielen Fällen recht eng sein mag, muss jeder einzelne Aufgabenbereich für sich schlüssig & konsistent, durchgängig & konsequent praktiziert werden, damit der darauf aufbauende Aufgabenbereich adäquat ausgefüllt werden kann.

ihr Interesse freut mich. Unten finden Sie einige Literaturstellen zum Thema.

Mit besten Grüßen
Wolfgang Johannsen

Johannsen, W.: Information Governance. Informatik 2010, 40. Jahrestagung der Gesellschaft für Informatik e.V. (GI), Workshop IT-Governance in verteilten Systemen (GVS 2010), Lecture Notes in Informatics (LNI) September 2010, Leipzig.

IBM: The IBM Data Governance Council Maturity Model: Building a roadmap for effective data governance, (www-935.ibm.com/services/uk), Somers, 2007.

ISACA, IT Governance Institute: COBIT 4.1, Framework, Control Objectives, Management Guidelines, Maturity Models, (www.isaca.org.), Rolling Meadows, USA, 2007.

ISO/IEC, Corporate governance of information technology, International Standard, 2008. Unter: http://www.iso.org.

ISACA: Cloud Computing: Business Benefits with Security, Governance and assurance Perspectives. In: ISACA Emerging technology White Paper, ISACA, (www.isaca.org) Rolling Meadows, USA, 2009.

Kampffmeyer, U: GRC –Governance, Risk Management & Compliance, IBM Whitepaper, 2009.

Logan, D.: What is Information Governance? And Why is it So Hard?. In: blogs.gartner.com, Gartner Group, 2010
[SEI09] CMMI for Services, he Software Engineering Institute, Carnegie Mellon University, 2009

Tuft, B.: Data Governance oder Information Governance?. (www.silicon.de), 2010

zurzeit arbeite ich mich in das Thema Data/Information Governance ein. Dieser Beitrag war mir wirklich eine große Hilfe um das Thema besser zu verstehen.

Können Sie mir gute Literatur zu diesen Thema empfehlen?

Vielleicht kann ich in einigen Monaten mehr in diesen Blog zu dem Thema beitragen.

Viel Grüße,
Weber