<main role="main">
<article class="page-layout--grid">
<header class="center article-intro">
<h1>Innovation Tokens – Gegen Informatikerromantik und Technologieüberflutung</h1>
<h2>Wie viel Innovation sollen wir zulassen?</h2>
<p class="lead">Zu oft werden in Softwareprojekten zu viele neue Dinge gleichzeitig ausprobiert,
ohne dass der Business Value erkennbar wäre- und vor allem, ohne die Risiken
vorher abzuschätzen. Eine Möglichkeit, die unnötige Technologieüberflutung
zu vermeiden, sind Innovation Tokens. Mit diesen lassen sich Innovationen
in geregeltere Bahnen lenken und bieten eine Grundlage für weniger emotionale
Technologiediskussionen.</p>
<div class="content-separator">
<time class="content-separator__date date" datetime="2017-06-26">26. Juni 2017</time>
<time class="content-separator__duration duration" datetime="P8M">8 Min. Lesedauer</time>
</div>
<ul class="list-unstyled">
<li class="author-bio author-bio--short" itemscope itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--small"><a class="avatar__link" href="#author-bio"><img class="avatar__image" itemprop="photo" src="../../assets/heribert.jpg" alt="Portrait von Heribert Innoq"></a>
</div>
<div>
<div class="author-bio__name" itemprop="name"><a class="author-bio__link" itemprop="url" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle">Senior Consultant</div>
</div>
</li>
<li class="author-bio author-bio--short" itemscope itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--small"><a class="avatar__link" href="#author-bio"><img class="avatar__image" itemprop="photo" src="../../assets/heribert.jpg" alt="Portrait von Heribert Innoq"></a>
</div>
<div>
<div class="author-bio__name" itemprop="name"><a class="author-bio__link" itemprop="url" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle">Principal Consultant</div>
</div>
</li>
</ul>
</header>
<aside class="left toc">
<h3 class="toc__heading">Inhalt</h3>
<ol class="toc__list">
<li><a class="toc__anchor" href="#dilemma">Das Dilemma: Innovation vs. Chaos</a>
</li>
<li><a class="toc__anchor" href="#idee">Die Idee hinter Innovation Tokens</a>
</li>
<li><a class="toc__anchor" href="#unbekannt">An die unbekannten Unbekannten denken und besonders darauf achten</a>
</li>
<li><a class="toc__anchor" href="#ballast">Kognitiven Ballast vermeiden</a>
</li>
<li><a class="toc__anchor" href="#fokus">Fokus auf die Wertschöpfung legen</a>
</li>
<li><a class="toc__anchor" href="#fazit">Fazit</a>
</li>
</ol>
</aside>
<section class="center">
<h3 id="dilemma">Das Dilemma: Innovation vs. Chaos</h3>
<p>Eine neue Technologie ins Unternehmen oder Projekt einzubringen, verursacht
Kosten. Aber sind wir uns wirklich im Klaren darüber, über welche Kosten
wir hier sprechen? Wenn wir ein Team von erfahrenen Java-Entwicklern haben,
wird der Vorschlag, neue Anforderungen an unsere Anwendung mit Python umzusetzen,
vermutlich Stirnrunzeln hervorrufen. Denn uns wird relativ schnell bewusst,
dass die Anwendung dadurch komplexer werden würde. Wir würden uns fragen,
ob das Team dies handhaben kann und ob unser Betrieb dem gewachsen ist.</p>
<p>Lautet der Vorschlag aber beispielsweise, die Daten unserer Anwendung
in verschiedene NoSQL-Datenbanken aufzuteilen, die auf die jeweiligen Datenstrukturen
und ihre Anwendungsfälle optimiert sind, bekommen wir stattdessen oft ganz
andere Aussagen zu hören. Nämlich: Gute Idee, wir nutzen das beste Tool
für den jeweiligen Job. Zu leicht vergessen wir, uns vorab schon die vielleicht
unangenehme Frage zu stellen: Kann mein Team, ja, unsere Organisation,
ein System mit diesen Technologien überhaupt betreiben?</p>
<pre><code>pick(:love) do |something|
n.times do
result = play(something)
result.publish
end
end
</code></pre>
<p>Heutzutage sind Unternehmen ständig gefordert einen Spagat auszubalancieren.
Auf der einen Seite bringt zu viel Innovation in Form von neuen Technologien
und Prozess- oder Organisationsveränderungen Unruhe und Unsicherheit ins
Unternehmen. Auf der anderen Seite müssen Unternehmen innovativ sein, um
am Markt gegen den Mitbewerber zu bestehen und gleichzeitig gute Mitarbeiter
anzulocken. Aber es wäre natürlich auch unvernünftig, Innovation in Form
von neuer Technologie generell auszuschließen. Bei einigen großen oder
mittelständischen Firmen durften wir derartige Bemühungen beobachten, die
teilweise einen großen Anteil daran hatten, dass diese Unternehmen von
ihren Mitbewerbern überholt wurden. Die Frage ist also: Wie viel Innovation
und Neuerungen sollen wir zulassen? Was ist das richtige Maß? Um diese
Frage zu beantworten, soll uns die Idee der Innovation Tokens helfen.</p>
<h3 id="idee">Die Idee hinter Innovation Tokens</h3>
<p>Die Idee von Innovation Tokens besteht darin, dass ein Team für die Umsetzung
einer bestimmten Anforderung nur eine begrenzte Anzahl an Tokens zur Verfügung
hat. Die genaue Anzahl hängt von den Fähigkeiten und der Einsatzbereitschaft
des Teams und der Organisation ab. Die Anzahl der Tokens hängt aber nicht
vom Umfang der Anforderung ab. Wenn die Anforderung groß ist, war es in
unseren Projekten bisher nie effektiv, diese mit noch mehr Technologie
zu erschlagen. Dies führte eher zum gegenteiligen Effekt. Des Weiteren
haben wir auch noch kein Team erlebt, das mehr als fünf Tokens in einer
Phase eingesetzt hat. In der Regel sollten Teams mit drei Innovation Tokens
pro Projekt auskommen.</p>
<blockquote class="pullquote">An dieser Stelle kommt oft die Frage auf: Verspiele ich nicht eine Chance,
wenn ich Innovation so stark begrenze?</blockquote>
<p>Nein, denn wir wollen die Anzahl der gleichzeitig eingeführten Neuerungen
auf diejenigen begrenzen, von denen wir uns den größten Mehrwert für unsere
Produkte oder unseren Business Value-Versprechen. Wir können drei wesentliche
Punkte festhalten, die die Notwendigkeit unterstreichen, die Anzahl gleichzeitig
neu eingeführter Technologien zu begrenzen:</p>
<ul>
<li>Die unbekannten Unbekannten reduzieren</li>
<li>Den kognitiven Ballast reduzieren</li>
<li>Unsere Zeit auf die Wertschöpfung verwenden, anstatt auf „Nebenkriegsschauplätze“</li>
</ul>
<ol>
<li>Welches unserer Probleme wird diese Technologie lösen?</li>
<li>Welche Veränderungen erfordert diese Technologie gegenüber dem Status
quo?</li>
<li>Wie könnten wir diese Probleme lösen, wenn wir die Technologie nicht einsetzen
können?</li>
</ol>
<h3 id="unbekannt">An die unbekannten Unbekannten denken</h3>
<p>Wenn wir neue Software schreiben, gibt es immer Dinge, die wir im Vorfeld
noch nicht wissen. Wir wissen aber, dass wir uns um diese Dinge kümmern
sollten. Wir sollten z. B. wissen, wie sich die Datenbank verhält, wenn
ihre Systemressourcen ausgelastet sind und ob unsere Anwendung in dem Fall
auf bestimmte Fehlerszenarien reagieren können muss. Bei neuen Technologien
gibt es aber leider auch einige Dinge, von denen wir gar nichts wissen.
Da wir nicht wissen, dass diese existieren, wissen wir auch nicht, ob und
wann sie für uns überhaupt relevant werden oder ob wir uns darum kümmern
müssen. Ein Beispiel hierfür wäre, dass in unserem Messaging-System in
bestimmten <a href="https://aphyr.com/posts/315-jepsen-rabbitmq">Situationen Nachrichten verloren gehen</a>.
Die Anzahl dieser unbekannten Unbekannten (Unknown Unknowns) wollen wir
dringend auf ein Minimum reduzieren, denn sie können im schlimmsten Fall
zu Datenverlust, Produktionsausfall oder Scheitern des Projekts führen.</p>
<check-list>
<ul class="checklist">
<li>Die unbekannten Unbekannten reduzieren</li>
<li>Den kognitiven Ballast reduzieren</li>
<li>Unsere Zeit auf die Wertschöpfung verwenden, anstatt auf „Nebenkriegsschauplätze“</li>
</ul>
</check-list>
<h3 id="ballast">Kognitiven Ballast vermeiden</h3>
<p>Auch kognitiven Ballast sollten wir vermeiden. Als kognitiven Ballast
bezeichnen wir Aufgaben, die wir bei der Einführung neuer Technologien
implizit mit aufgebürdet bekommen. Es gibt schon Unit-Tests für die Anwendung,
aber wie schreiben wir Unit-Tests für diese neue Technologie? Wir haben
Monitoring für unser System, aber wie muss es angepasst werden, wenn wir
die neue Technologie einführen? Was muss ein Entwickler wissen, um überhaupt
anfangen zu können die neue Technologie zu nutzen? Wie verändern sich dadurch
die Folgeprozesse?</p>
<figure>
<img class="content__image__big" src="http://via.placeholder.com/675x369" alt="Bild Groß">
<figcaption>All diese Themen sind kognitiver Ballast, der mitgetragen werden muss
und nicht oder nur indirekt zum Erreichen des Ziels beiträgt.</figcaption>
</figure>
<p>All diese Themen sind kognitiver Ballast, der mitgetragen werden muss
und nicht oder nur indirekt zum Erreichen des Ziels beiträgt. Jede Firma,
jedes Team kann nur eine bestimmte Menge kognitiven Ballast tragen, bevor
vielleicht wichtige Punkte runterfallen und vergessen werden. Wie groß
diese Menge in einem Team gerade ist, lässt sich schwer messen. Was aber
klar ist: Dass ein Thema runtergefallen ist, bemerken wir meist erst dadurch,
dass es uns schmerzhaft auf die Füße fällt.</p>
<h3 id="fokus">Fokus auf die Wertschöpfung legen</h3>
<p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature
in unserem Produktionssystem genutzt wird. Dementsprechend sollte es unser
Anliegen sein, die Projektziele an dieser Wertschöpfung und den fachlichen
Zielen zu orientieren, damit das Projektteam diese in technische Detailentscheidungen
immer einbezieht – wie der Einführung neuer Technologien. Wenn bei der
Definition der Projektziele die fachlichen Ziele nicht transparent sind
und nicht klar ist, wie der Mehrwert am Ende gemessen wird, kann dies dazu
führen, dass unbewusst Entscheidungen getroffen werden, die gegen unsere
fachlichen Ziele laufen.</p>
<blockquote class="superquote"><span class="superquote__zigzag"></span>
<p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature
in unserem Produktionssystem genutzt wird.</p>
<div itemscope itemtype="http://schema.org/Person"><cite class="superquote__author" itemprop="name">Heribert Innoq</cite>
<span class="superquote__role" itemprop="jobTitle">Senior Consultant</span>
</div>
</blockquote>
<p>Der Endkunde zahlt nicht mehr Geld für unsere Produkte, nur weil unsere
Protokollevents per TCP in eine zentrale ElasticSearch-Datenbank geschrieben
werden, anstatt in eine Datei auf der Festplatte. Wie hilft das dem Kunden?
Wo trägt diese Änderung zur Wertschöpfung bei? Wird das System dadurch
stabiler? Sinken die Wartungskosten? Können potenzielle Fehlerszenarien
früher entdeckt und behoben werden, bevor der Kunde davon betroffen ist?
Die Aufgabe des Entwicklungsteams ist es, mit ihrer Arbeit zur Wertschöpfung
ihres Unternehmens beizutragen. Und unter <code> puts "Hello World"</code> diesem
Gesichtspunkt sollten wir auch unsere Innovation Tokens einsetzen.</p>
<p>Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren
liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt.
Dort wollen wir die Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>,
in dem für uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund
kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein Altbekanntes
sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen
können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden
Mehrkosten sehr gut abschätzen lassen.</p>
<h3>So werden die Tokens eingesetzt</h3>
<p>Nehmen wir an, wir sind in einem Team mit JavaScript-Entwicklern und sollen
eine neue Webanwendung schreiben. Das Team hat bisher gute Ergebnisse mit
dem JavaScript-Web-Framework Express.js erzielt, das im Node.js-Ökosystem
weit verbreitet ist. Nun möchten die Kollegen aber auf das Framework hapi
wechseln, weil es einige Expertenfeatures mitbringt. Hierfür müsste das
Team ein Innovation Token ausgeben, da es sich um einen invasiven Austausch
handelt, durch den die Vorgehensweise bei der Entwicklung verändert wird
und weite Teile der Anwendung umgebaut werden müssen. In Konzeption, Test
und Betrieb sollten die Veränderungen nicht oder nur marginal zu spüren
sein.</p>
<blockquote class="blockquote">"Wichtig ist hierbei, dass die Einführung dieser neuen Technologie eine
Mehrheitsentscheidung des Teams ist und dass diese Entwurfsentscheidung
sowie die Gründe und Alternativen dieser Entscheidung schriftlich festgehalten
werden(<a href="http://www.arc42.de/template/struktur.html">arc42 Kapitel 9</a> ).
Auf diese Weise ist nicht nur für Außenstehende, beispielsweise andere
Teams oder Auditoren, sondern auch für das Team selbst nach ein paar Monaten
noch klar ersichtlich, warum die Entscheidung so getroffen wurde. So kann
das Team zu einem späteren Zeitpunkt die Kriterien ansehen und gegebenenfalls
feststellen, dass sich die Rahmenbedingungen geändert haben und die Entscheidung
zu Gunsten einer Alternative revidiert werden sollte."</blockquote>
<p>In dem Moment, in dem eine Entwurfsentscheidung über die Teamgrenzen hinaus
geht, also beispielsweise auch Auswirkungen auf den Betrieb der Anwendung
hat, muss das Team hierfür zwei Innovation Tokens ausgeben. Dies wäre bei
der Einführung einer neuen Datenbanktechnologie der Fall, die noch nicht
im Unternehmen vorhanden ist. Der Grund hierfür ist, dass dies nicht nur
Aufwände und Risiken in unserem Team erzeugt, sondern eben auch in mindestens
einem anderen Team. Unser Operationsteam muss sich bei der Einführung beispielsweise
von Cassandra mit Themen wie Clusterbetrieb, Datensicherung und -wiederherstellung,
dem Monitoring und dem Verhalten der Datenbank bei <a href="https://en.m.wikipedia.org/wiki/Network_partition">Network Partitions beschäftigen</a>,
damit das Entwicklungsteam die Datenbank überhaupt benutzen kann.</p>
<info-box>
<div class="infobox__teaser">
<div class="infobox__teaser__left">
<h6 class="infobox__teaser__heading">Weitere Informationen</h6><i class="icon icon-info"></i>
</div>
<div class="infobox__teaser__right"><i class="icon infobox__teaser__chevron"></i>
</div>
</div>
<aside class="infobox__content">
<div class="infobox__content__box">
<p class="infobox__content__text">Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren
liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt.
Dort wollen wir die Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>,
in dem für uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund
kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein Altbekanntes
sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen
können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden
Mehrkosten sehr gut abschätzen lassen.</p>
</div>
</aside>
</info-box>
<h3>Ein konkretes Beispielprojekt</h3>
<p>Letztlich steht und fällt die Idee der Innovation Tokens mit der Akzeptanz
bei den Teammitgliedern. Was, wenn die Teams die Gründe für diese Einschränkung
nicht verstehen? Oder schlimmer noch, sie vermuten als Ursache die vermeintliche
Inkompetenz eines anderen Teams mit den neuen Technologien umzugehen und
beschuldigen das andere Team, sie auszubremsen, anstatt dieses Team bei
der Aufgabe zu unterstützen. Da ich allerdings ein großer Freund von kleinen
Experimenten bin und davon, Dinge auszuprobieren, anstatt sie tot zu diskutieren,
haben wir das Konzept in einem kleinen Projekt angewendet.</p>
<p>Der Auftrag des Projekts war es, eine Webanwendung als Microservice zu
erstellen <a href="#fn:1" id="fnref:1" title="see footnote" class="footnote">[1]</a>.
Im Entwicklungsteam herrschten von Anfang an sehr unterschiedliche Vorstellungen
davon, welche Technologien benötigt würden. Nahezu jedes Teammitglied schlug
andere Technologien vor und die meisten beharrten darauf, dass diese unbedingt
notwendig seien. Wir merkten schnell, dass wir so nicht weiterkamen. Wir
mussten ein gemeinsames Verständnis dafür erarbeiten, welche Technologie
uns an welcher Stelle wie stark helfen konnte, wie viel Aufwand die Einführung
bedeutete und welche Alternativen es gab. Deshalb sollte zunächst jeder
seine eigenen Vorschläge dem Team schriftlich vorstellen und dabei folgende
Fragen beantworten:</p>
<figure>
<table class="table">
<thead>
<tr>
<th>Merkmal</th>
<th>Untermerkmal</th>
<th>Szenario</th>
<th>Priorität</th>
</tr>
</thead>
<tbody>
<tr>
<td>Zuverlässigkeit</td>
<td>Robustheit</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen
Hinweis ohne Absturz.</td>
<td>B</td>
</tr>
<tr>
<td></td>
<td>Robustheit</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen
Hinweis ohne Absturz.</td>
<td>A</td>
</tr>
<tr>
<td>Zuverlässigkeit</td>
<td>Datenintegerität</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen
Hinweis ohne Absturz.</td>
<td>A</td>
</tr>
<tr>
<td>Performance</td>
<td>Benutzeranzahl</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen
Hinweis ohne Absturz.</td>
<td>B</td>
</tr>
</tbody>
</table>
<figcaption>Dies ist eine Tabelle mit wichtigem Inhalt</figcaption>
</figure>
<p>Interessant war insbesondere bei den Antworten zu Frage 1, dass hier Probleme
genannt wurden, die vorher nie diskutiert worden waren. Dies war ein Gewinn
für das Projekt, denn es führte zu Schritt 0: Probleme und Herausforderungen
explizit machen. Dieses Ergebnis half den anderen Teammitgliedern, die
Beweggründe des Vorschlagenden zu verstehen und einschätzen zu können.
Anschließend konnten wir im Team Technologievorschläge zusammenfassen und
über die beste Alternative abstimmen. Allerdings konnten wir die Liste
immer noch nicht auf die gewünschte Anzahl von nur drei Technologien verkürzen.</p>
<p>Um dieses Ziel letztlich doch zu erreichen, schlug unser Projektleiter
eine geheime Abstimmung vor. Jeder von uns wählte die aus seiner Sicht
wichtigsten drei Technologien aus und schickte seine Auswahl an unseren
Projektleiter. Dieser addierte die Stimmen und stellte uns das Ergebnis
in einem Folgetermin vor. So reduzierten wir eine Liste von 28 Technologien
auf sechs, wobei zwei Technologien ganz vorne lagen. Da wir uns hier nicht
auf eine dritte Technologie einigen konnten, beschlossen wir, zunächst
mit den zwei neuen sowie den vorhandenen Technologien zu starten. Die Entscheidung
für die dritte Technologie wollten wir erst später treffen, wenn wir an
einen Punkt kommen sollten, an dem wir unsere Herausforderungen nicht mehr
lösen könnten. Dieser Fall trat in diesem Projekt jedoch nie ein.</p>
<p>Rückblickend können wir sagen, dass wir die Probleme vermutlich auch über
Umwege ganz ohne neue Technologien hätten lösen können. Hier wären dann
aber die nicht zu unterschätzenden Faktoren Motivation, Teamgefühl und
vor allem die Weiterbildung zu kurz gekommen. Dies kann sich unserer Erfahrung
nach mittelfristig negativ auf die Produktivität auswirken, wodurch dann
wirklich Wettbewerbsnachteile entstehen können.</p>
</section>
<section class="center footnote-section">
<div class="footnote-section__headline__container">
<h3 class="footnote-section__headline">Quellenangaben</h3>
</div>
<div class="footnotes">
<ol class="footnotes__list">
<li id="fn:1">
<p>Lorem gibson courier long-chain hydrocarbons realism bomb otaku SIN tiger-team
macroform node dermatrodes tower Chiba City pre-table DIY chrome Mole IX
camera People of Importance. Lorem gibson temperfoam sunglasses assault
systema tower order-flow screen macroform node tanto sprawl icebreaker
drone sentient Mole IX Mycotoxin Dex.<a href="#fnref:1" title="return to article"> ↩</a>
</p>
</li>
<li id="fn:2">
<p>Lorem gibson modem hotdog market corrupted Metro Holografix sprawl EMP.</p>
<p>Lorem gibson Kowloon man House of the Blue Lights Turing Registry wristwatch
geodesic nodality new yen House of the Blue Lights memory refrigerator
advert free-market.<a href="#fnref:2" title="return to article"> ↩</a>
</p>
</li>
<li id="fn:3">
<p>Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen,
dpunkt.verlag, 2015, ISBN 978–3864903137<a href="#fnref:3" title="return to article"> ↩</a>
</p>
</li>
<li id="fn:4">
<p><a href="http://www.vasulka.org/archive/Institutions1/EATnews.pdf">http://www.vasulka.org/archive/Institutions1/EATnews.pdf</a>
<a href="#fnref:1" title="return to body" class="reversefootnote"> ↩</a>
</p>
</li>
</ol>
</div>
</section>
</article>
<section class="breakout conclusion">
<div class="breakout__content">
<h1 class="conclusion-headline">Fazit</h1>
<h3 class="conclusion-subheadline">Kurz auf den Punkt gebracht</h3>
<p class="conclusion-text">Innovation Tokens sind ein einfach verständlicher <a href="https://de.wikipedia.org/wiki/Ansatz">Ansatz</a>,
um das richtige Maß an neuen Technologien in Softwareentwicklungsprojekten
zu finden. Projektverantwortliche und Teams bekommen hierbei ein Hilfsmittel
an die Hand, das eine Selbstkontrolle und Fokussierung auf das Notwendige
ermöglicht, anstatt einem Team überladene Genehmigungsprozesse oder lähmende
Regularien aufzubürden. Kurz: Bei richtiger Anwendung fördern sie den gesunden
Menschenverstand und die Besinnung auf die Wertschöpfungsziele.</p>
<p class="conclusion-text"><strong>Kurz:</strong> Bei richtiger Anwendung fördern sie den gesunden
Menschenverstand und die Besinnung auf die Wertschöpfungsziele.</p>
</div>
</section>
<section class="breakout tag-section">
<h3 class="tag-section__headline">TAGS</h3>
<div class="tag-section__container">
<ul class="tag-list">
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=microservices">Microservices</a>
</li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=business+technology">Business Technology</a>
</li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=architecture">Architecture</a>
</li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=organization">Organization</a>
</li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=innovation">Innovation</a>
</li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=project+management">Project Management</a>
</li>
</ul>
</div>
</section>
<aside class="page-layout--grid">
<section class="center">
<div class="blocks">
<div id="author-bio" class="author-bio author-bio--long" itemscope="" itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--base">
<img itemprop="photo" class="avatar__image" src="../../assets/heribert.jpg" alt="Portrait von Alexander Hesingfeld">
</div>
<div class="author-bio__head">
<div class="author-bio__name" itemprop="name"><a class="author-bio__link" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle">Senior Consultant</div>
<div class="author-bio__social"><i class="icon icon-twitter"></i><a class="author-bio__handle" itemprop="url" title="Twitter" href="http://twitter.com/heribert_innoq">heribert_innoq</a>
</div>
</div>
<div class="author-bio__text">Heribert Innoq ist Senior Consultant bei innoQ. Als Berater, Entwickler
und Architekt unterstützt er Kunden vor allem mit seinen langjährigen Kenntnissen
von Java- und JVM-basierten Systemen. Meist beschäftigt er sich hier mit
dem Design, der Evaluierung und Implementierung von Architekturen für moderne
Webanwendungen und Microservices in Softwaremodernisierungsprojekten. Sein
aktueller Fokus gilt den Themen Team-Organisation und Softwareevolution.</div>
</div>
</div>
</section>
<section class="center share-section">
<h3 class="share-section__heading">Share on</h3>
<ul class="share-section__list">
<li><a class="share-section__link" target="_blank" href="http://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F"><i class="icon icon-facebook"></i></a>
</li>
<li><a class="share-section__link" target="_blank" href="http://twitter.com/share?url=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F&text=Innovation+Tokens+%E2%80%93+Gegen+Informatikerromantik+und+Technologie%C3%BCberflutung+von+%40heribert_innoq&via=innoq"><i class="icon icon-twitter"></i></a>
</li>
<li><a class="share-section__link" href="mailto:?subject=Innovation+Tokens+%E2%80%93+Gegen+Informatikerromantik+und+Technologie%C3%BCberflutung&body=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F"><i class="icon icon-email"></i></a>
</li>
</ul>
</section>
<section class="center reference"><a href="#" class="reference__link"><img class="reference__image" src="../../assets/business_technology.svg" alt="Business technology"></a>
<p class="reference__description">Dieser Artikel ist ursprünglich in Ausgabe 04/2016 der Zeitschrift Business
Technology erschienen. Die Veröffentlichung auf innoq.com erfolgt mit freundlicher
Genehmigung des S&S Media-Verlags.</p>
</section>
</aside>
<section class="page-layout--grid">
<div class="center">
<div id="disqus_thread">DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS
DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS
DISQUS DISQUS DISQUS</div>
</div>
</section>
<div class="dark-background">
<div class="page-layout-xl--default">
<footer class="footer">FOOTER</footer>
</div>
</div>
</main>
import { safe, htmlEncode } from "complate-stream";
<main role="main">
<article class="page-layout--grid">
<header class="center article-intro">
<h1>Innovation Tokens – Gegen Informatiker­romantik und Technologie­überflutung</h1>
<h2>Wie viel Innovation sollen wir zulassen?</h2>
<p class="lead">
Zu oft werden in Softwareprojekten zu viele neue Dinge gleichzeitig
ausprobiert, ohne dass der Business Value erkennbar wäre- und vor allem,
ohne die Risiken vorher abzuschätzen. Eine Möglichkeit, die unnötige
Technologieüberflutung zu vermeiden, sind Innovation Tokens. Mit diesen
lassen sich Innovationen in geregeltere Bahnen lenken und bieten eine
Grundlage für weniger emotionale Technologiediskussionen.
</p>
<div class="content-separator">
<time class="content-separator__date date" datetime="2017-06-26">26. Juni 2017</time>
<time class="content-separator__duration duration" datetime="P8M">8 Min. Lesedauer</time>
</div>
<ul class="list-unstyled">
<li class="author-bio author-bio--short" itemscope itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--small">
<a class="avatar__link" href="#author-bio">
<img class="avatar__image" itemprop="photo" src={context.app.uri("assets/heribert.jpg")} alt="Portrait von Heribert Innoq" />
</a>
</div>
<div>
<div class="author-bio__name" itemprop="name">
<a class="author-bio__link" itemprop="url" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle" >Senior Consultant</div>
</div>
</li>
<li class="author-bio author-bio--short" itemscope itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--small">
<a class="avatar__link" href="#author-bio">
<img class="avatar__image" itemprop="photo" src={context.app.uri("assets/heribert.jpg")} alt="Portrait von Heribert Innoq" />
</a>
</div>
<div>
<div class="author-bio__name" itemprop="name">
<a class="author-bio__link" itemprop="url" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle" >Principal Consultant</div>
</div>
</li>
</ul>
</header>
<aside class="left toc">
<h3 class="toc__heading">Inhalt</h3>
<ol class="toc__list">
<li><a class="toc__anchor" href="#dilemma">Das Dilemma: Innovation vs. Chaos</a></li>
<li><a class="toc__anchor" href="#idee">Die Idee hinter Innovation Tokens</a></li>
<li><a class="toc__anchor" href="#unbekannt">An die unbekannten Unbekannten denken und besonders darauf achten</a></li>
<li><a class="toc__anchor" href="#ballast">Kognitiven Ballast vermeiden</a></li>
<li><a class="toc__anchor" href="#fokus">Fokus auf die Wertschöpfung legen</a></li>
<li><a class="toc__anchor" href="#fazit">Fazit</a></li>
</ol>
</aside>
<section class="center">
<h3 id="dilemma">Das Dilemma: Innovation vs. Chaos</h3>
<p>Eine neue Technologie ins Unternehmen oder Projekt einzubringen, verursacht Kosten. Aber sind wir uns wirklich im Klaren darüber, über welche Kosten wir hier sprechen? Wenn wir ein Team von erfahrenen Java-Entwicklern haben, wird der Vorschlag, neue Anforderungen an unsere Anwendung mit Python umzusetzen, vermutlich Stirnrunzeln hervorrufen. Denn uns wird relativ schnell bewusst, dass die Anwendung dadurch komplexer werden würde. Wir würden uns fragen, ob das Team dies handhaben kann und ob unser Betrieb dem gewachsen ist.</p>
<p>Lautet der Vorschlag aber beispielsweise, die Daten unserer Anwendung in verschiedene NoSQL-Datenbanken aufzuteilen, die auf die jeweiligen Datenstrukturen und ihre Anwendungsfälle optimiert sind, bekommen wir stattdessen oft ganz andere Aussagen zu hören. Nämlich: Gute Idee, wir nutzen das beste Tool für den jeweiligen Job. Zu leicht vergessen wir, uns vorab schon die vielleicht unangenehme Frage zu stellen: Kann mein Team, ja, unsere Organisation, ein System mit diesen Technologien überhaupt betreiben?</p>
<pre><code>{safe(htmlEncode(context.code))}</code></pre>
<p>Heutzutage sind Unternehmen ständig gefordert einen Spagat auszubalancieren. Auf der einen Seite bringt zu viel Innovation in Form von neuen Technologien und Prozess- oder Organisationsveränderungen Unruhe und Unsicherheit ins Unternehmen. Auf der anderen Seite müssen Unternehmen innovativ sein, um am Markt gegen den Mitbewerber zu bestehen und gleichzeitig gute Mitarbeiter anzulocken. Aber es wäre natürlich auch unvernünftig, Innovation in Form von neuer Technologie generell auszuschließen. Bei einigen großen oder mittelständischen Firmen durften wir derartige Bemühungen beobachten, die teilweise einen großen Anteil daran hatten, dass diese Unternehmen von ihren Mitbewerbern überholt wurden. Die Frage ist also: Wie viel Innovation und Neuerungen sollen wir zulassen? Was ist das richtige Maß? Um diese Frage zu beantworten, soll uns die Idee der Innovation Tokens helfen.</p>
<h3 id="idee">Die Idee hinter Innovation Tokens</h3>
<p>Die Idee von Innovation Tokens besteht darin, dass ein Team für die Umsetzung einer bestimmten Anforderung nur eine begrenzte Anzahl an Tokens zur Verfügung hat. Die genaue Anzahl hängt von den Fähigkeiten und der Einsatzbereitschaft des Teams und der Organisation ab. Die Anzahl der Tokens hängt aber nicht vom Umfang der Anforderung ab. Wenn die Anforderung groß ist, war es in unseren Projekten bisher nie effektiv, diese mit noch mehr Technologie zu erschlagen. Dies führte eher zum gegenteiligen Effekt. Des Weiteren haben wir auch noch kein Team erlebt, das mehr als fünf Tokens in einer Phase eingesetzt hat. In der Regel sollten Teams mit drei Innovation Tokens pro Projekt auskommen.</p>
{/* start pull quote component @see atoms/text/block/pull-quote */}
<blockquote class="pullquote">
An dieser Stelle kommt oft die Frage auf: Verspiele ich nicht eine Chance, wenn ich Innovation so stark begrenze?
</blockquote>
{/* end pull quote */}
<p>Nein, denn wir wollen die Anzahl der gleichzeitig eingeführten Neuerungen auf diejenigen begrenzen, von denen wir uns den größten Mehrwert für unsere Produkte oder unseren Business Value-Versprechen. Wir können drei wesentliche Punkte festhalten, die die Notwendigkeit unterstreichen, die Anzahl gleichzeitig neu eingeführter Technologien zu begrenzen:</p>
<ul>
<li>Die unbekannten Unbekannten reduzieren</li>
<li>Den kognitiven Ballast reduzieren</li>
<li>Unsere Zeit auf die Wertschöpfung verwenden, anstatt auf „Nebenkriegsschauplätze“</li>
</ul>
<ol>
<li>Welches unserer Probleme wird diese Technologie lösen?</li>
<li>Welche Veränderungen erfordert diese Technologie gegenüber dem Status quo?</li>
<li>Wie könnten wir diese Probleme lösen, wenn wir die Technologie nicht einsetzen können?</li>
</ol>
<h3 id="unbekannt">An die unbekannten Unbekannten denken</h3>
<p>Wenn wir neue Software schreiben, gibt es immer Dinge, die wir im Vorfeld noch nicht wissen. Wir wissen aber, dass wir uns um diese Dinge kümmern sollten. Wir sollten z. B. wissen, wie sich die Datenbank verhält, wenn ihre Systemressourcen ausgelastet sind und ob unsere Anwendung in dem Fall auf bestimmte Fehlerszenarien reagieren können muss. Bei neuen Technologien gibt es aber leider auch einige Dinge, von denen wir gar nichts wissen. Da wir nicht wissen, dass diese existieren, wissen wir auch nicht, ob und wann sie für uns überhaupt relevant werden oder ob wir uns darum kümmern müssen. Ein Beispiel hierfür wäre, dass in unserem Messaging-System in bestimmten <a href="https://aphyr.com/posts/315-jepsen-rabbitmq">Situationen Nachrichten verloren gehen</a>. Die Anzahl dieser unbekannten Unbekannten (Unknown Unknowns) wollen wir dringend auf ein Minimum reduzieren, denn sie können im schlimmsten Fall zu Datenverlust, Produktionsausfall oder Scheitern des Projekts führen.</p>
<check-list>
<ul class="checklist">
<li>Die unbekannten Unbekannten reduzieren</li>
<li>Den kognitiven Ballast reduzieren</li>
<li>Unsere Zeit auf die Wertschöpfung verwenden, anstatt auf „Nebenkriegsschauplätze“</li>
</ul>
</check-list>
<h3 id="ballast">Kognitiven Ballast vermeiden</h3>
<p>Auch kognitiven Ballast sollten wir vermeiden. Als kognitiven Ballast bezeichnen wir Aufgaben, die wir bei der Einführung neuer Technologien implizit mit aufgebürdet bekommen. Es gibt schon Unit-Tests für die Anwendung, aber wie schreiben wir Unit-Tests für diese neue Technologie? Wir haben Monitoring für unser System, aber wie muss es angepasst werden, wenn wir die neue Technologie einführen? Was muss ein Entwickler wissen, um überhaupt anfangen zu können die neue Technologie zu nutzen? Wie verändern sich dadurch die Folgeprozesse?</p>
<figure>
<img class="content__image__big" src="http://via.placeholder.com/675x369" alt="Bild Groß" />
<figcaption>
All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt zum Erreichen des Ziels beiträgt.
</figcaption>
</figure>
<p>All diese Themen sind kognitiver Ballast, der mitgetragen werden muss und nicht oder nur indirekt zum Erreichen des Ziels beiträgt. Jede Firma, jedes Team kann nur eine bestimmte Menge kognitiven Ballast tragen, bevor vielleicht wichtige Punkte runterfallen und vergessen werden. Wie groß diese Menge in einem Team gerade ist, lässt sich schwer messen. Was aber klar ist: Dass ein Thema runtergefallen ist, bemerken wir meist erst dadurch, dass es uns schmerzhaft auf die Füße fällt.</p>
<h3 id="fokus">Fokus auf die Wertschöpfung legen</h3>
<p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem genutzt wird. Dementsprechend sollte es unser Anliegen sein, die Projektziele an dieser Wertschöpfung und den fachlichen Zielen zu orientieren, damit das Projektteam diese in technische Detailentscheidungen immer einbezieht – wie der Einführung neuer Technologien. Wenn bei der Definition der Projektziele die fachlichen Ziele nicht transparent sind und nicht klar ist, wie der Mehrwert am Ende gemessen wird, kann dies dazu führen, dass unbewusst Entscheidungen getroffen werden, die gegen unsere fachlichen Ziele laufen.</p>
{/* start superquote molecule @see molecules/super-quote */}
<blockquote class="superquote">
<span class="superquote__zigzag"></span>
<p>Wertschöpfung findet statt, wenn unsere Änderung oder das neue Feature in unserem Produktionssystem genutzt wird.</p>
<div itemscope itemtype="http://schema.org/Person">
<cite class="superquote__author" itemprop="name">Heribert Innoq</cite>
<span class="superquote__role" itemprop="jobTitle">Senior Consultant</span>
</div>
</blockquote>
{/* end super-quote component */}
<p>Der Endkunde zahlt nicht mehr Geld für unsere Produkte, nur weil unsere Protokollevents per TCP in eine zentrale ElasticSearch-Datenbank geschrieben werden, anstatt in eine Datei auf der Festplatte. Wie hilft das dem Kunden? Wo trägt diese Änderung zur Wertschöpfung bei? Wird das System dadurch stabiler? Sinken die Wartungskosten? Können potenzielle Fehlerszenarien früher entdeckt und behoben werden, bevor der Kunde davon betroffen ist? Die Aufgabe des Entwicklungsteams ist es, mit ihrer Arbeit zur Wertschöpfung ihres Unternehmens beizutragen. Und unter <code> puts "Hello World"</code> diesem Gesichtspunkt sollten wir auch unsere Innovation Tokens einsetzen.</p>
<p>Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>, in dem für uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten sehr gut abschätzen lassen.</p>
<h3>So werden die Tokens eingesetzt</h3>
<p>Nehmen wir an, wir sind in einem Team mit JavaScript-Entwicklern und sollen eine neue Webanwendung schreiben. Das Team hat bisher gute Ergebnisse mit dem JavaScript-Web-Framework Express.js erzielt, das im Node.js-Ökosystem weit verbreitet ist. Nun möchten die Kollegen aber auf das Framework hapi wechseln, weil es einige Expertenfeatures mitbringt. Hierfür müsste das Team ein Innovation Token ausgeben, da es sich um einen invasiven Austausch handelt, durch den die Vorgehensweise bei der Entwicklung verändert wird und weite Teile der Anwendung umgebaut werden müssen. In Konzeption, Test und Betrieb sollten die Veränderungen nicht oder nur marginal zu spüren sein.</p>
{/* start blockquote atom @see atoms/text/block/block-quote */}
<blockquote class="blockquote">
"Wichtig ist hierbei, dass die Einführung dieser neuen Technologie eine Mehrheitsentscheidung des Teams ist und dass diese Entwurfsentscheidung sowie die Gründe und Alternativen dieser Entscheidung schriftlich festgehalten werden(<a href="http://www.arc42.de/template/struktur.html">arc42 Kapitel 9</a> ). Auf diese Weise ist nicht nur für Außenstehende, beispielsweise andere Teams oder Auditoren, sondern auch für das Team selbst nach ein paar Monaten noch klar ersichtlich, warum die Entscheidung so getroffen wurde. So kann das Team zu einem späteren Zeitpunkt die Kriterien ansehen und gegebenenfalls feststellen, dass sich die Rahmenbedingungen geändert haben und die Entscheidung zu Gunsten einer Alternative revidiert werden sollte."
</blockquote>
{/* end blockquote component */}
<p>In dem Moment, in dem eine Entwurfsentscheidung über die Teamgrenzen hinaus geht, also beispielsweise auch Auswirkungen auf den Betrieb der Anwendung hat, muss das Team hierfür zwei Innovation Tokens ausgeben. Dies wäre bei der Einführung einer neuen Datenbanktechnologie der Fall, die noch nicht im Unternehmen vorhanden ist. Der Grund hierfür ist, dass dies nicht nur Aufwände und Risiken in unserem Team erzeugt, sondern eben auch in mindestens einem anderen Team. Unser Operationsteam muss sich bei der Einführung beispielsweise von Cassandra mit Themen wie Clusterbetrieb, Datensicherung und -wiederherstellung, dem Monitoring und dem Verhalten der Datenbank bei <a href="https://en.m.wikipedia.org/wiki/Network_partition">Network Partitions beschäftigen</a>, damit das Entwicklungsteam die Datenbank überhaupt benutzen kann.</p>
<info-box>
<div class="infobox__teaser">
<div class="infobox__teaser__left">
<h6 class="infobox__teaser__heading">Weitere Informationen</h6>
<i class="icon icon-info"></i>
</div>
<div class="infobox__teaser__right">
<i class="icon infobox__teaser__chevron"></i>
</div>
</div>
<aside class="infobox__content">
<div class="infobox__content__box">
<p class="infobox__content__text">
Bei der Definition der Ziele sollte unser Fokus auf den so genannten Differentiatoren liegen, also das zu verbessern, was uns von unseren Mitbewerbern abhebt. Dort wollen wir die Mehrheit unserer Zeit verbringen, nicht im <a href="https://leanpub.com/37things">so genannten Parity-Sektor</a>, in dem für uns und unsere Mitbewerber Gleichheit besteht. Vor diesem Hintergrund kann beispielsweise das beste Werkzeug für eine Aufgabe auch ein Altbekanntes sein. Dies ist der Fall, wenn wir die Aufgabe damit effektiv erledigen können und das Werkzeug außerdem so gut kennen, dass sich die entstehenden Mehrkosten sehr gut abschätzen lassen.
</p>
</div>
</aside>
</info-box>
<h3>Ein konkretes Beispielprojekt</h3>
<p>Letztlich steht und fällt die Idee der Innovation Tokens mit der Akzeptanz bei den Teammitgliedern. Was, wenn die Teams die Gründe für diese Einschränkung nicht verstehen? Oder schlimmer noch, sie vermuten als Ursache die vermeintliche Inkompetenz eines anderen Teams mit den neuen Technologien umzugehen und beschuldigen das andere Team, sie auszubremsen, anstatt dieses Team bei der Aufgabe zu unterstützen. Da ich allerdings ein großer Freund von kleinen Experimenten bin und davon, Dinge auszuprobieren, anstatt sie tot zu diskutieren, haben wir das Konzept in einem kleinen Projekt angewendet.</p>
<p>Der Auftrag des Projekts war es, eine Webanwendung als Microservice zu erstellen <a href="#fn:1" id="fnref:1" title="see footnote" class="footnote">[1]</a>. Im Entwicklungsteam herrschten von Anfang an sehr unterschiedliche Vorstellungen davon, welche Technologien benötigt würden. Nahezu jedes Teammitglied schlug andere Technologien vor und die meisten beharrten darauf, dass diese unbedingt notwendig seien. Wir merkten schnell, dass wir so nicht weiterkamen. Wir mussten ein gemeinsames Verständnis dafür erarbeiten, welche Technologie uns an welcher Stelle wie stark helfen konnte, wie viel Aufwand die Einführung bedeutete und welche Alternativen es gab. Deshalb sollte zunächst jeder seine eigenen Vorschläge dem Team schriftlich vorstellen und dabei folgende Fragen beantworten:</p>
<figure>
<table class="table">
<thead>
<tr>
<th>Merkmal</th>
<th>Untermerkmal</th>
<th>Szenario</th>
<th>Priorität</th>
</tr>
</thead>
<tbody>
<tr>
<td>Zuverlässigkeit</td>
<td>Robustheit</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis ohne Absturz.</td>
<td>B</td>
</tr>
<tr>
<td></td>
<td>Robustheit</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis ohne Absturz.</td>
<td>A</td>
</tr>
<tr>
<td>Zuverlässigkeit</td>
<td>Datenintegerität</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis ohne Absturz.</td>
<td>A</td>
</tr>
<tr>
<td>Performance</td>
<td>Benutzeranzahl</td>
<td>Beim Upload eines korrumpierten jpg-Fotos gibt das System einen aussagekräftigen Hinweis ohne Absturz.</td>
<td>B</td>
</tr>
</tbody>
</table>
<figcaption>
Dies ist eine Tabelle mit wichtigem Inhalt
</figcaption>
</figure>
<p>Interessant war insbesondere bei den Antworten zu Frage 1, dass hier Probleme genannt wurden, die vorher nie diskutiert worden waren. Dies war ein Gewinn für das Projekt, denn es führte zu Schritt 0: Probleme und Herausforderungen explizit machen. Dieses Ergebnis half den anderen Teammitgliedern, die Beweggründe des Vorschlagenden zu verstehen und einschätzen zu können. Anschließend konnten wir im Team Technologievorschläge zusammenfassen und über die beste Alternative abstimmen. Allerdings konnten wir die Liste immer noch nicht auf die gewünschte Anzahl von nur drei Technologien verkürzen.</p>
<p>Um dieses Ziel letztlich doch zu erreichen, schlug unser Projektleiter eine geheime Abstimmung vor. Jeder von uns wählte die aus seiner Sicht wichtigsten drei Technologien aus und schickte seine Auswahl an unseren Projektleiter. Dieser addierte die Stimmen und stellte uns das Ergebnis in einem Folgetermin vor. So reduzierten wir eine Liste von 28 Technologien auf sechs, wobei zwei Technologien ganz vorne lagen. Da wir uns hier nicht auf eine dritte Technologie einigen konnten, beschlossen wir, zunächst mit den zwei neuen sowie den vorhandenen Technologien zu starten. Die Entscheidung für die dritte Technologie wollten wir erst später treffen, wenn wir an einen Punkt kommen sollten, an dem wir unsere Herausforderungen nicht mehr lösen könnten. Dieser Fall trat in diesem Projekt jedoch nie ein.</p>
<p>Rückblickend können wir sagen, dass wir die Probleme vermutlich auch über Umwege ganz ohne neue Technologien hätten lösen können. Hier wären dann aber die nicht zu unterschätzenden Faktoren Motivation, Teamgefühl und vor allem die Weiterbildung zu kurz gekommen. Dies kann sich unserer Erfahrung nach mittelfristig negativ auf die Produktivität auswirken, wodurch dann wirklich Wettbewerbsnachteile entstehen können.</p>
</section>
<section class="center footnote-section">
<div class="footnote-section__headline__container">
<h3 class="footnote-section__headline">Quellenangaben</h3>
</div>
<div class="footnotes">
<ol class="footnotes__list">
<li id="fn:1">
<p>
Lorem gibson courier long-chain hydrocarbons realism bomb otaku SIN tiger-team macroform node dermatrodes tower Chiba City pre-table DIY chrome Mole IX camera People of Importance.
Lorem gibson temperfoam sunglasses assault systema tower order-flow screen macroform node tanto sprawl icebreaker drone sentient Mole IX Mycotoxin Dex.
<a href="#fnref:1" title="return to article" > ↩</a>
</p>
</li>
<li id="fn:2">
<p>
Lorem gibson modem hotdog market corrupted Metro Holografix sprawl EMP.
</p>
<p>
Lorem gibson Kowloon man House of the Blue Lights Turing Registry wristwatch geodesic nodality new yen House of the Blue Lights memory refrigerator advert free-market.
<a href="#fnref:2" title="return to article" > ↩</a>
</p>
</li>
<li id="fn:3">
<p>
Eberhard Wolff: Microservices: Grundlagen flexibler Softwarearchitekturen, dpunkt.verlag, 2015, ISBN 978–3864903137
<a href="#fnref:3" title="return to article" > ↩</a>
</p>
</li>
<li id="fn:4">
<p><a href="http://www.vasulka.org/archive/Institutions1/EATnews.pdf">http://www.vasulka.org/archive/Institutions1/EATnews.pdf</a> <a href="#fnref:1" title="return to body" class="reversefootnote"> ↩</a></p>
</li>
</ol>
</div>
</section>
</article>
<section class="breakout conclusion">
<div class="breakout__content">
<h1 class="conclusion-headline">Fazit</h1>
<h3 class="conclusion-subheadline">Kurz auf den Punkt gebracht</h3>
<p class="conclusion-text">
Innovation Tokens sind ein einfach verständlicher <a href="https://de.wikipedia.org/wiki/Ansatz">Ansatz</a>, um das richtige Maß an neuen Technologien in Softwareentwicklungsprojekten zu finden. Projektverantwortliche und Teams bekommen hierbei ein Hilfsmittel an die Hand, das eine Selbstkontrolle und Fokussierung auf das Notwendige ermöglicht, anstatt einem Team überladene Genehmigungsprozesse oder lähmende Regularien aufzubürden. Kurz: Bei richtiger Anwendung fördern sie den gesunden Menschenverstand und die Besinnung auf die Wertschöpfungsziele.
</p>
<p class="conclusion-text"><strong>Kurz:</strong> Bei richtiger Anwendung fördern sie den gesunden Menschenverstand und die Besinnung auf die Wertschöpfungsziele.</p>
</div>
</section>
<section class="breakout tag-section">
<h3 class="tag-section__headline">TAGS</h3>
<div class="tag-section__container">
<ul class="tag-list">
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=microservices">Microservices</a></li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=business+technology">Business Technology</a></li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=architecture">Architecture</a></li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=organization">Organization</a></li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=innovation">Innovation</a></li>
<li class="tag-list__item"><a class="tag-list__link" href="/de/timeline/?tag=project+management">Project Management</a></li>
</ul>
</div>
</section>
<aside class="page-layout--grid">
<section class="center">
<div class="blocks">
<div id="author-bio" class="author-bio author-bio--long" itemscope="" itemtype="http://schema.org/Person">
<div class="author-bio__image avatar avatar--base">
<img itemprop="photo" class="avatar__image" src={context.app.uri("assets/heribert.jpg")} alt="Portrait von Alexander Hesingfeld" />
</div>
<div class="author-bio__head">
<div class="author-bio__name" itemprop="name">
<a class="author-bio__link" href="#">Heribert Innoq</a>
</div>
<div class="author-bio__info" itemprop="jobTitle" >Senior Consultant</div>
<div class="author-bio__social">
<i class="icon icon-twitter"></i>
<a class="author-bio__handle" itemprop="url" title="Twitter" href="http://twitter.com/heribert_innoq">
heribert_innoq
</a>
</div>
</div>
<div class="author-bio__text">
Heribert Innoq ist Senior Consultant bei innoQ. Als Berater, Entwickler und Architekt unterstützt er Kunden vor allem mit seinen langjährigen Kenntnissen von Java- und JVM-basierten Systemen. Meist beschäftigt er sich hier mit dem Design, der Evaluierung und Implementierung von Architekturen für moderne Webanwendungen und Microservices in Softwaremodernisierungsprojekten. Sein aktueller Fokus gilt den Themen Team-Organisation und Softwareevolution.
</div>
</div>
</div>
</section>
<section class="center share-section">
<h3 class="share-section__heading">Share on</h3>
<ul class="share-section__list">
<li>
<a class="share-section__link" target="_blank" href="http://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F">
<i class="icon icon-facebook"></i>
</a>
</li>
<li>
<a class="share-section__link" target="_blank" href="http://twitter.com/share?url=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F&text=Innovation+Tokens+%E2%80%93+Gegen+Informatikerromantik+und+Technologie%C3%BCberflutung+von+%40heribert_innoq&via=innoq">
<i class="icon icon-twitter"></i>
</a>
</li>
<li>
<a class="share-section__link" href="mailto:?subject=Innovation+Tokens+%E2%80%93+Gegen+Informatikerromantik+und+Technologie%C3%BCberflutung&body=https%3A%2F%2Fwww.innoq.com%2Fde%2Farticles%2F2017%2F06%2Finnovation-tokens%2F">
<i class="icon icon-email"></i>
</a>
</li>
</ul>
</section>
<section class="center reference">
<a href="#" class="reference__link">
<img class="reference__image" src={context.app.uri("assets/business_technology.svg")} alt="Business technology" />
</a>
<p class="reference__description">
Dieser Artikel ist ursprünglich in Ausgabe 04/2016 der Zeitschrift Business Technology erschienen. Die Veröffentlichung auf innoq.com erfolgt mit freundlicher Genehmigung des S&S Media-Verlags.
</p>
</section>
</aside>
<section class="page-layout--grid">
<div class="center">
<div id="disqus_thread">DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS DISQUS </div>
</div>
</section>
<div class="dark-background">
<div class="page-layout-xl--default">
<footer class="footer">FOOTER</footer>
</div>
</div>
</main>
{
"code": "pick(:love) do |something|\n n.times do\n result = play(something)\n result.publish\n end\nend\n"
}
// sass-lint:disable no-ids
#disqus_thread {
margin-bottom: $spacer-base;
}
@media screen and (min-width: $grid-breakpoint-md) {
#disqus_thread {
margin-bottom: $spacer-xxl;
}
}
There are no notes for this item.