Alle Artikel in Allgemein

Rescue the RDBMS -GDPR: Initiative to save outdated technologies

Meanwhile, there are projects at three different customers in which I was massively confronted with the consequences of the GDPR for the development and operation of IT systems.

The positive aspect that the personal data of customers and employees were generally no longer handled so carelessly was quite evident.

The negative aspects were the cementation of existing and obsolete structures and the obstruction of new technologies. For example, the data storage in a lambda architecture was cleaned of all personal data, which significantly reduced the value of the system.

The organization did so despite of the fact that one could assume that the processing of the data would have been in the interest of the customers whose data were stored there.
As a further consequence, the outdated GDPR system was not replaced, but continued to operate alongside the „castrated“ new system. At the cost of significantly higher operating costs.

Elsewhere, with reference to the GDPR, the testing of a system with real data was prohibited. Even after reference to the subsequent deletion of the data after the tests carried out under supervision did not lead to a rethinking of the compliance officers.

The tests were therefore carried out with artificially generated test data. This ultimately led to incorrect processing of the data in the production system and corresponding losses.

It looks as if the GDPR is a programme to protect European companies from too much progress and digitalization.

Rettet die RDBMS, oder DSGVO: Initiative zur Rettung veralteter Technologien

Mittlerweile sind es Projekte bei drei verschiedenen Kunden, in denen ich massiv mit den Folgen der DSGVO für Entwicklung und Betrieb von IT-Systemen konfrontiert wurde.

Der positive Aspekt, dass generell nicht mehr so sorglos mit den persönlichen Daten von Kunden und Mitarbeitern umgegangen wurde, war durchaus sichtbar.

Die negativen Aspekte waren eine Zementierung der vorhandenen und veralteten Strukturen und die Behinderung neuer Technologien. So wurde z.B. die Datenhaltung in einer Lambda-Architektur von sämtlichen personenbezogenen Daten bereinigt, was den Wert des Systems deutlich verringerte. Dabei hätte man annehmen können, dass die Verarbeitung der Daten im Interesse der Kunden gewesen wäre, deren Daten dort gespeichert wurden.

Als eine weitere Konsequenz wurde das veraltete RDBMS-System nicht abgelöst, sondern neben dem “kastrierten” Neusystem weiterbetrieben. Zum Preis deutlich erhöhter Betriebskosten

An anderer Stelle wurde mit Verweis auf die DSGVO das Testen eines Systems mit Echtdaten verboten – selbst nach Hinweis auf das nachträgliche Löschen der Daten nach den unter Aufsicht durchgeführten Tests führten nicht zu einem Umdenken der Compliance-Verantwortlichen. Die Tests wurden also mit künstlich generierten Testdaten durchgeführt. Dies führte am Ende zur fehlerhaften Verarbeitung der Daten im Produktivsystem und entsprechenden Verlusten kam.

E sieht also so aus. als würde es sich bei der DSGVO um ein Programm zum Schutz europäischer Unternehmen vor zu viel Fortschritt und Digitalisierung handeln.

MeToo: ITIL® wird agil – ein wenig – vielleicht

Quo Vadis ITIL®?

Anfang des Jahres erhielt ich eine Email von Axelos, dem Rechtewerwerter von ITIL®.

(Axelos Limeted wurde von der englischen Krone mit der Vermarktung, dem Training und der Zertifizierung der in ITIL® beschriebenen Best-Practice-Methoden beauftragt.
(ITIL® ist ein eingetragenes Warenzeichen der AXELOS Limited.))

In der Email enthalten war die Einladung zur Teilnahme an der Diskussion und am Wissensaustauschinnerhalb der Axelos-Community für ein noch für 2018(!) vorgesehenes ITIL®-Update (ITIL®-2018).

Weiterhin wurde noch drei „existentielle“ Fragen gestellt – zur Beantwortung per Video-Clip (ca. 1 min)

Diese Fragen lauteten ungefähr so: (siehe auch ITIL Video Competition):

  • Finden nach Deiner Einschätzung im Service Managementausschließlich ITIL® Best Practices Verwendung?
  • In welcher Weise hat die Einführung von ITIL® Best Practices in Deinem Unternehmen einen Unterschied zur Situation vorher gemacht?
  • Inwiefern ist ITIL® heute noch relevant im ITSM und wie ergänzt ITIL® andere Frameworks?

Weiterhin erwähnt Axelos auf seiner Webseite, dass man sich bereits bisher mit Praktikern und „Vordenkern“ aus der ganzen Welt zusammengetan hätte, um „Einblicke in aktuelle Trends und Herausforderungen zu gewinnen“  – so der Originalton.

Hierzu muss man wissen, dass Axelos gar keine andere Wahl hat, als sich externer Unterstützung  zu bedienen. Axelos ist, wie bereits oben erwähnt, eine „ITIL®-Vermarktungs-und-Zertifizierungs-Agentur“. So beauftragt Axelos z.B. externe Experten mit dem Review von ITIL®-Literatur, wenn diese von den Herausgebern bei ITIL® eingereicht wird. Mir ist nicht bekannt, ob bzw. wieviel zertifizierte ITIL® Trainer Axelos intern beschäftigt.

Die „richtigen“ Vordenker

Somit kann man nur hoffen, dass Axelos für das 2018-Update auch die „richtigen“ Vordenker und Praktiker als Input-Geber konsultiert – und nicht nur im eigenen Saft schmort. Hoffnung  macht ein Statement auf der Axelos-Web-Site (ITIL® 2018 Update) zum Update 2018. Dort findet sich der Hinweis, dass das Update praktische Anleitungen zur Einführung von ITIL® in Verbindung mit Praktiken wie DevOps, Agile und Lean enthalten soll.

Es bleibt zu hoffen, dass Axelos auch den Input verschiedener Experten mit widersprüchlichen Meinungen eingeholt hat – zudem sollten es Meinungen mit übergreifendem Know-How aus ITSM und den genannten Bereichen DevOps, Agile und Lean sein.

Und nicht zuletzt bleibt zu hoffen, dass Axelos die Kompetenz aufbringt, diese Meinungen aus ITSM, DevOps, Agile etc. zusammenzuführen –  und die ITSM/ITIL®-Komfortzone zu verlassen.

Der aktuelle Stand in der Industrie

Aus meiner Erfahrung kann ich sagen, dass einige Organisationen, in denen ITSM auf agile Methoden trifft, bei diesem Thema schon sehr weit vorangeschritten sind:

  • Es wurden z.B. agile Strukturen etabliert, ähnlich oder stark angelehnt an SAFe oder Less, um diese dann soweit wie möglich an die ITIL® LifeCycle Phasen Service Transition (siehe DevOps) und Service Operation anzupassen bzw. auszudehnen.
  • Andere Organisationen setzen größtenteils auf Cloud-basierte IT und treiben NoOps-Ansätze voran. Diese beeinflussen dann auf jeden Fall große Teile der ITIL® LifeCycle Phasen Service Transition und Service Operation.

Zugegebenermaßen stellen diese Beispiel nur wenige Fälle dar, soweit ich das sagen  kann.

Axelos könnte die Erfahrungen und Ansätze derartiger Unternehmen einsammeln und diese als Best Practices in ITIL® aufnehmen. Dabei sollte man sich der starken Erwartungshaltung in der Industrie bewusst sein. Viele Firmen erleben große interne Widerstände, wenn es darum geht, die Effizienz von ITSM-Prozessen unter Zuhilfenahme agiler Methoden und DevOps-Praktiken umzusetzen. Dies führt zu tiefgreifenden Änderungen in den Strukturen der Organisation. Somit erhoffen sich diese Unternehmen überzeugende und einleuchtende Argumente und nachvollziehbare Vorgaben für die Einführung agiler und Lean-Praktiken.

Was man vom ITIL® -Update 2018 erwarten kann …

Allerdings glaube ich, dass Axelos‘ Ziele in Bezug auf das ITIKL 2018 Update gar nicht so hoch gesteckt sind. Denn auf seiner Web-Site versichert Axelos, dass Die Kernelemente von ITIL® bestehen bleiben sollen. Dies soll auch für bestehende Zertifizierungen von Personen gelten, die gültig bleiben sollen – es werden keine vorzeitigen Rezertifizierungskosten fällig.
Neben der Tatsache, dass es sich hierbei um einen gewissen Investituionsschutz handelt sollte auch klar sein, das der  besagte Personenkreis sich anderen Frameworks zuwenden oder ganz auf eine Zertifizierung ganz verzichten könnte.

Zur Alternative stünden agile Konzepten oder Frameworks (SAFe, Less) zuwendet, die dann nur noch durch ITIL® Best Practices ergänzt werden könnten.

Anmerkung des Verfassers:
Eine ähnliche Situation gab es bei „Prince2 Agile“. Dort hatte man es, wie ich meine, prinzipiell leichter, agile Vorgehensweisen in eine Projektorganisation und damit in temporäre Projektstrukturen zu integrieren. Allerdings sind die Meinungen  bzgl. „PRINCE2 Agile“ geteilt. Die einen freuen sich, dass sie sich nach der PRINCE2-Zertifizierung „agil“ nennen dürfen – die anderen halten die agile Erweiterung für PRINCE2 aufgesetzt und beliebig. 

Und zufällig scheint genau dies die dritte Frage (s.o.) nahe zu legen. Vielleicht ist es gar kein Zufall, dass die Frage drei so lautet, dass ITIL® andere Frameworks ergänzt. Dann hätte Axelos die  abnehmende Bedeutung von ITIL® akzeptiert – oder die zunehmende Bedeutung agiler Vorgehensweisen im ITSM-Bereich.

Auf der anderen Seite, soll das 2018er Update konkrete Anleitungen enthalten, wie man ITIL® in Verbindung in Verbindung mit den Buzzwords Agile, DevOps und Lean einsetzt.

… und was nicht

Aufgrund meiner Erfahrungen vertrete ich den Standpunkt, dass es auf lange Sicht nicht erfolgversprechend ist, agile Strukturen und DevOps-Konzepte over-the-Top einzuführen, ohne die gesamte Organisationsstruktur anzupassen. Dies wird einem spätestens klar, wenn man sich mit agilen Frameworks wie SAFe oder LESS näher beschäftigt. Der Einsatz dieser Frameworks erfordert bei konventionell aufgestellten Organisationen mit Matrix-Struktur  tiefgreifende  Umstrukturierungen, wenn z.B. , wie in SAFe beschrieben, Value Streams und Development Streams eingeführt werden sollen.

Auch wenn derartige Framewoks die Software-Entwicklung im Fokus haben, können Organisationen diese auch auf ITSM-Prozesse ausweiten bzw. ihre ITSM-Prozesse anpassen.

Man darf gespannt sein, wie Axelos es zu schaffen gedenkt, Agile Konzepte einzuführen und dabei gleichzeitig die Kirche im Dorf sowie die ITIL®-Batch-Träger in ihrer Komfortzone zu belassen.

TL;DR

Man sollte sich als ITSM-Verantwortlicher nicht zurücklehnen und auf ein leicht umzusetzendes 2018-Update von ITIL® warten, das klar vorgibt, wie denn nun „agile ITSM mit agiler Software-Entwicklung“ vereinbart werden kann.

Unbestritten besteht das Heil nicht immer in der Einführung agiler Vorgehensweisen. Es sollten sich aber in Zeiten von DevOps, Cloud-Computing und NoOps alle IT-Verantwortlichen fragen, inwieweit sie auf in der Vergangenheit bewährte und von dritter Seite weiterentwickelter ITSM-Best Practices (und entsprechende Zertifizierungen) setzen.

Da es bei der agilen Transformation um eine Frage der internationalen Konkurenzfähigkeit geht, bestünde eine Alternative darin, die agile Transformation in der eigenen Organisation selbst voranzutreiben und entsprechende Kompetenzen aufzubauen.

DevOps: Surviving between ITIL® & Agility

(ITIL® is a registered trademark of AXELOS Limited)

Are DevOps and ITIL® incompatible?

According to some people, DevOps and ITIL® are incompatible.

First of all: It is definitely not a „Free Lunch“ to establish DevOps in an ITIL®-orientated IT service organization – possibly still in combination with agile procedures – conversely, as shown in my book „DevOps Strategies„, it can be advantageous for traditional IT service organizations to be open to DevOps-driven changes and thus long overdue.

What is incompatibility?

You should ask yourself what exactly this incompatibility may be before embarking on the mission of introducing DevOps in an organization structured according to best practices described in ITIL®.

One could argue that DevOps addresses the same area as the ITIL® Service Lifecycle Stage „Service Transition“. While ITIL® describes the processes, functions, roles and KPIs, DevOps & Continuous Delivery deal with the soft factors (CALMS) and the automated integration and delivery of software. However, DevOps does not treat software development as a black box, but considers software already at the source code stage, which is at the beginning of every continuous delivery.
For ITIL®, software exists – roughly speaking – only as a deployable and hopefully well-documented software package that needs to be installed and operated, including periodic maintenance releases.

From the sole viewpoint of (especially agile) software development, change management processes can and will be much simpler than described in ITIL®. Or, to put it another way: The process steps and functions described in ITIL® can be streamlined and cleared out in terms of software development to such an extent that they also meet agile software development processes.
Under no circumstances an incorrectly understood „ITIL® compatibility“ should led to the reproduction of every singleprocess step and every operational function mentioned in ITIL® – It is like a disease for the author if organizations are desperate to implement the processes, functions and roles described in i ITIL® 1:1.

These points alone seem to argue for compatibility, but at least for a possible coexistence of ITIL® and DevOps. This would be the mentioned transition lifecycle phase.

But there is another aspect:

DevOps originates from the agile software developer scene, while ITIL® focus only on IT operations.

Although ITIL® recognizes the problem of silo structures, it still assumes that there are functionally separate teams – cross-functional teams, as propagated in the agile world, are foreign to ITIL®.
However, the best practices described in ITIL® are just these – best practices that have no claim to adaptation and change.

Antipattern for the introduction of DevOps in conventional companies.

The fact that functionally separate teams and structures have been established to ensure proper IT operations does not necessarily mean that this must always remain so. This separation sometimes goes far beyond the ITIL® Best Practices, e. g. when DNS entries and IP addresses are assigned and managed in different departments. Such structures have nothing to do with efficient organization, but are not as rare as the author knows from his own experience.

They do not only stand in the way of agile procedures, but also of the efficiency of conventional organizational structures and procedures. Several IT service organizations are also known, in which the defined workflows only function if the representatives of the departments/teams involved meet unofficially for short meetings in which:

  • The status of the respective task is recorded
  • All the involved departments/teams renew their commitments
  • And the various impediments are identified and tackled.

If, in spite of defined processes and workflows, it only degenerates into a „hidden process“ on the basis of unofficial communication, the organization can introduce SCRUM into Service Management anyway – exaggeratedly said ….. Let’s give it a try… The organization could now focus on the areas of greatest suffering caused by excessive functional separation.

DevOps antipattern 1: retention or re-introduction of functionally separate teams

But even without the introduction of agile procedures in parts or in the entire „ITIL® organization“, there will be the creation of (new) teams of software developers, DevOps engineers and operators in the life cycle stage Service Transition.
I. e. some teams must give up or lose persons, especially if the functional separation between teams is to be abolished. In order to limit this „loss“ and to continue to provide long-standing employees with management positions, new silo structures are regularly set up. e. g. in the form of DevOps teams – a contradiction by itself.

Stopping such „crazy“ management actions is difficult, because it is about influence, money and face preservation.

Unfortunately, higher salary classes are automatically accompanied by personnel management tasks. However, it often seems to be irrelevant how bad personnel management is. Outstanding professional or technical performance does not earn as much money as bad leadership. Such companies have significant problems attracting motivated specialists for DevOps and agile development, while the management adheres to inefficient structures and team leaders.

Societies with less rigid, highly hierarchical structures should have it easier to implement such changes than societies of emerging countries with an even stronger hierarchical character. However, I see this competitive advantage waning.

DevOps Antipattern 2: Missing sourcing strategy

Another antipattern in the DevOps introduction is to assign the title of the DevOps Engineer or „DevOps“ to existing persons, without or before they have acquired the necessary qualifications – instead of giving these employees the necessary training measures.
I. e.: When introducing DevOps, additional personnel must always be built up, at least temporarily as external employees:

  • Either these are already qualified DevOps employees.
  • Or conventional skilled workers, so that existing employees have the time for further training.

Software developers and software architects who are interested in business processes often already have the majority of the necessary prerequisites for a DevOps Engineer, while „old“ service management specialists and administrators have to master a much steeper learning curve when it comes to acquiring knowledge in software development. I would ask for the reader’s indulgence if this statement sounds very generalizing – but in many cases it points into the right direction.

Employees with potential must be encouraged and challenged in a targeted manner, regardless of existing team sizes and areas of responsibility.

TL;DR

  1. The introduction of DevOps has far-reaching consequences, is not for free and leads to changes to personnel structures. Affected members of the team and department head level often reluctantly accept these changes as they are associated with disadvantages for the respective persons.
  2. The integration of DevOps into conventional IT service structures often fails due to a lack of willingness to purify processes structured according to ITIL® and to eliminate unnecessary functional separations.
  3. Another impediment in the DevOps rollout is a failed or half-hearted sourcing strategy – as well as for existing and new staff.

If an organization can overcome these and other obstacles to DevOps deployment, it is not impossible to successfully establish DevOps in ITIL®-influenced IT service organizations.