<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.