Wie du sicher stellst, dass du von deinem Entwicklungsdienstleister den maximalen Wert für dein Geld bekommst.

Wenn Softwareentwicklung nicht zu deinen Kernkompetenzen gehört, du das Aufbauen eines eigenen Entwicklungsteams als kostspieliges und riskantes Unterfangen einschätzt oder du auf dem Arbeitsmarkt nur mit viel Mühe qualifizierte Softwareingenieure findest, wirst du das Beauftragen eines externen Entwicklungsdienstleister für dein Softwareprojekt in Betracht ziehen. Externe Dienstleister bauen dir neue Softwareapplikationen von Grund auf, helfen dir beim Modernisieren von existierenden Applikationen, erhöhen die Effizienz deiner DevOps Prozesse oder verstärken deine bestehende Entwicklungsorganisation mit zusätzlicher Manpower.

Solltest du dich dazu entscheiden, mit einem externen Dienstleister zusammenzuarbeiten, musst du dich als Auftraggeber mit dem potentiellen Auftragnehmer auf ein Vergütungsmodell einigen. Das Vergütungsmodell und der damit verbundene Vertrag legen fest, was dir der Auftragnehmer zu welchem Preis liefert. Das scheint auf den ersten Blick eine triviale Herausforderung zu sein. Doch wer bereits in IT- oder Entwicklungsprojekte involviert war, weiss das dies keine einfache Problemstellung ist. In der Praxis können die Kosten explodieren oder die Qualität des Ergebnisses lässt zu wünschen übrig. Dies wiederum führt zu Uneinigkeit zwischen Auftraggeber und Auftragnehmer bezüglich der Vergütung der Leistung.

Die Wahl des Vergütungsmodelles und die Konditionen haben einen direkten Einfluss auf die Wirtschaftlichkeit und die Erfolgsaussichten deines Softwareprojektes. Als Auftraggeber möchtest du höchstwahrscheinlich möglichst hohe Qualität zu minimalen Gesamtkosten, also ein möglichst gutes Preis-Leistungs-Verhältnis. Für Entwicklungs- und Ingenieurdienstleistungen heisst das konkret, dass du als Auftraggeber sicherstellen musst, dass der Auftragnehmer die erwarteten Resultate in bestmöglicher Qualität liefern kann und er dir dafür einen möglichst guten und fairen Preis machen kann.

In diesem Artikel vergleichen wir verschiedene Vergütungsmodelle und zeigen auf, welchen Einfluss diese Modelle auf das Preis-Leistungs-Verhältnis und die Gesamtbetriebskosten eines Softwareprojektes haben. Wir vergleichen die beiden etablierten Vergütungsmodelle



* Vergütung zu einem Festpreis mit 
* Vergütung nach Aufwand.

Ausserdem schlagen wir ein drittes Vergütungsmodell vor, welches auf der agilen Softwareentwicklung beruht, die Vorteile der beiden etablierten Vergütungsmodelle vereint und deren Nachteile überwindet:



* Ein Sprint-basiertes Vergütungsmodell

How to make sure you get the maximum value for money from your development service provider.

When software development is not one of your core competencies, when you consider building your own development team to be a costly and risky endeavor, or when you are struggling to find qualified software engineers on the job market, you may consider hiring an external development service provider for your software project. External service providers build new software applications from scratch, help you modernize existing applications, increase the efficiency of your DevOps processes or strengthen your existing development organization with additional manpower.

If you decide to work with an external service provider, you as the customer must agree on a compensation model together with the potential supplier. The compensation model and the corresponding contract define what the supplier will deliver to you and at what price. At first glance, this seems like a trivial challenge. But anyone who has been involved in IT or development projects knows that this is not a simple challenge. In practice, the costs can explode or the quality of the result leaves much to be desired. This in turn leads to disagreement between customer and supplier regarding the compensation for the service.

The choice of the compensation model and its conditions have a direct impact on the profitability and the chances of success of your software project. As a customer, you most likely want the highest possible quality at the lowest possible total cost—i.e. the best possible value for money. For development and engineering services, this means that you, as the customer, must ensure that the supplier can deliver the expected results in the best possible quality and that he can offer you the best and fairest possible price.

In this article, we compare different compensation models and show what impact these models have on the value for money and the total cost of ownership of a software project. We compare the two established compensation models

* compensation at a fixed price with 
* compensation by time and material.

We also propose a third compensation model based on agile software development that combines the advantages of the two established compensation models and overcomes their disadvantages:

* a sprint-based compensation model.

comparison of compensation models for software development

illustration-comparison-compensation-models.png

## Vergütung zu einem Festpreis vermittelt eine trügerische Kostensicherheit

Die Entwicklung einer Softwarelösung zu einem Fixpreis einzukaufen, scheint zwar aus Auftraggebersicht naheliegend, weil man sich eine vermeintliche Kostensicherheit und ein garantiertes Resultat verspricht. In der Praxis ist dies jedoch illusorisch. Die Vergütung zu einem Fixpreis wird nach Schweizer Recht in einem sogenannten Werkvertrag abgebildet (Art. 363 ff. OR). Der Auftraggeber beschreibt detailliert, was vom Auftragnehmer geliefert werden soll (juristisch “das Werk”). Der Auftragnehmer nennt den fixen Preis, zu dem er die Software liefern kann. Die Praxis zeigt, dass es nicht möglich ist, alle Anforderungen an eine Softwarelösung im Voraus genau genug zu spezifizieren. In der Regel werden wichtige Funktionsanforderungen vergessen oder Rahmenbedingungen und Nutzerbedürfnisse ändern sich während des Projektes. Uneinigkeiten über die Kompensation von geänderten oder neuen Anforderungen zwischen Auftraggeber und Auftragnehmer sind also vorprogrammiert.

Mit einem Fixpreis-Kompensationsmodell bezahlt der Auftraggeber tendenziell einen zu hohen Fixpreis und sollte mit zusätzlichen Ausgaben im Projektverlauf rechnen. Weil es für den Auftragnehmer extrem schwierig ist, den Gesamtaufwand eines Entwicklungsprojektes genau abzuschätzen, rechnet der Auftragnehmer eine gewisse Sicherheitsmarge ein. D.h. der Auftraggeber bezahlt nicht nur für die Entwicklungsdienstleistung, sondern noch ein Extra für das Risiko einer falschen Aufwandsschätzung. Zusätzlich bezahlt der Auftraggeber ungeplante Kosten für nicht spezifizierte oder neue Anforderungen, welche im Verlauf des Projektes dazu kommen. In der Regel sind sogenannte “Change Requests” nicht im Fixpreis inkludiert und werden zusätzlich in Rechnung gestellt.


## Vergütung nach Aufwand macht aus einem Entwicklungsprojekt ein Fass ohne Boden 

Kauft der Auftraggeber Softwareentwicklung nach Aufwand ein, hat er zwar maximale Flexibilität bezüglich Entwicklungsumfang, aber kaum Chancen, die Gesamtkosten abzuschätzen. Die Vergütung nach Aufwand wird im Schweizer Recht mit dem Begriff Auftrag definiert (Art. 394 ff. OR) und in Form eines Dienstleistungsvertrag abgebildet. Dabei schuldet der Auftragnehmer dem Auftraggeber lediglich ein Tätigwerden nach anwendbaren Sorgfaltspflichten und bestem Wissen und Gewissen. Der Auftraggeber bezahlt für geleistete Zeit (z.B. Stunden oder Tage) und verbrauchtes Material. Der Auftragnehmer macht in der Regel zwar eine Schätzung, wie viel Zeit er für die Entwicklung einer Softwarelösung benötigt, ist aber nicht verpflichtet, diese Schätzung auch einzuhalten.

Mit einem auf Aufwand basierten Kompensationsmodell bezahlt der Auftraggeber die Ineffizienz der Entwickler und trägt dazu noch das gesamte Erfolgsrisiko. Gerade bei Softwareentwicklern variiert die Produktivität enorm. Eine <a href="https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/" target="_blank" rel="noopener noreferrer nofollow">Vielzahl von Studien</a> seit den 60er Jahren proklamieren den “10x” Faktor in der Produktivität von Programmierern—also einen 10-fachen Unterschied, was ein Entwickler in einer gewissen Zeiteinheit leisten kann. Ob bei einer bezahlten Stunde Arbeit auch effektiv verwertbare Resultate entstehen, ist also nicht garantiert. Ausserdem setzt Vergütung nach Aufwand falsche Anreize für den Auftragnehmer. Wenn er für die Erfüllung einer Aufgabe länger braucht, kann er mehr verrechnen. Im Härtefall kann der Auftragnehmer nach der geleisteten Zeit auf Vergütung bestehen, ohne irgendetwas erreicht zu haben. Der Auftraggeber trägt das Erfolgsrisiko also vollumfänglich.


## Ein Sprint-basiertes Vergütungsmodell reduziert das Projektrisiko und ermöglicht trotzdem Flexibilität

Bei einem Sprint-basierten Vergütungsmodell bezahlt der Auftraggeber einen vor dem Projekt fix definierten Preis pro Sprint. In der agilen Softwareentwicklung ist ein Sprint eine fixe Zeitperiode—von in der Regel zwei Wochen—in welcher bestimmte Arbeitsergebnisse erreicht werden müssen. Auftraggeber und Auftragnehmer definieren die Arbeitsergebnisse und deren Abnahmekriterien gemeinsam vor jedem Sprint. Der Auftragnehmer garantiert die Erfüllung der definierten Ergebnisse pro Sprint. Bei Nicht- oder Teilerfüllung bezahlt der Auftraggeber den Sprint nicht oder nur teilweise. 

Das finanzielle Risiko ist sowohl für den Auftraggeber als auch für den Auftragnehmer überschaubar. Der Auftraggeber hat eine Garantie, dass er für sein Geld mess- und greifbare Resultate bekommt und nicht nur Arbeitsstunden bezahlt, die zu nichts führen. Beide, Auftraggeber und Auftragnehmer können die Arbeitsergebnisse und deren Abnahmekriterien für den Zeithorizont von einem Sprint genügend präzise definieren. Der Auftragnehmer kann zuverlässig abschätzen, welche Resultate er innerhalb der kommenden zwei Wochen realistischerweise erreichen kann und kann diese mit gutem Gewissen und ohne unnötige Sicherheitsmargen versprechen. Für den Auftragnehmer ist das finanzielle Risiko, wenn er sich verschätzt und die versprochenen Arbeitsergebnisse nicht liefern kann, auf den Preis des Sprints begrenzt.

Der Auftraggeber behält beim Sprint-basierten Vergütungsmodell die Flexibilität, den Entwicklungskurs zu korrigieren, sollte sich herausstellen, dass sich die anfänglich definierten Anforderungen geändert haben. Wie auch bei der Vergütung nach Aufwand können die Entwicklungsaktivitäten priorisiert werden, von welchen man sich den höchsten Mehrwert verspricht. Allerdings wird das Preis-Leistungs-Verhältnis deutlich sichtbarer, weil dem fixen Preis pro Sprint greifbare Arbeitsergebnisse gegenübergestellt werden können. Zudem ändert das Mindset des Auftragnehmers von “Stunden leisten” zu “Resultate liefern”.


## Ebenso wichtig wie das Vergütungsmodell ist eine vertrauensvolle Beziehung zwischen Auftraggeber und Auftragnehmer.

Agile Entwicklung und ein Sprint-basiertes Vergütungsmodell helfen, das Risiko in Entwicklungs- und Innovationsprojekten zu reduzieren. Allerdings sind und bleiben Entwicklungs- und Innovationsprojekte von Unsicherheit geprägt. Daran ändert auch ein Sprint-basiertes Vergütungsmodell nichts. Garantien für den Projekterfolg gibt es nicht, auch wenn dies von Managern mit Fragen wie “Wie lange dauert es und was kostet es insgesamt?” oft gewünscht wird. Anstatt langfristige Pläne und Budgets zu erstellen, die dann doch wieder verworfen werden, sollten wir darauf fokussieren, mit einem fixen Budget—dem fixen Preis pro Sprint—jeweils den maximalen Mehrwert zu generieren. Und genau das wird mit einem Sprint-basierten Vergütungsmodell erreicht.

Das richtige Vergütungsmodell und das entsprechende Vertragswerk, welches ein solches abbildet, unterstützen eine funktionierende Zusammenarbeit zwischen Auftraggeber und Auftragnehmer. Ebenso wichtig sind allerdings eine Geschäftsbeziehung, die auf Vertrauen und einer gemeinsamen Vision basiert. Denn das ist es schlussendlich, was alle Beteiligten dazu motiviert, brauchbare, wertsteigernde und von den Nutzern geliebte Softwarelösungen zu entwickeln und zu betreiben.

Bei EMBRIO.tech haben wir das Sprint-basierte Vergütungsmodell in die Praxis umgesetzt und ein darauf zugeschnittenes Vertragswerk geschaffen, das ein maximales Preis-Leistungs-Verhältnis garantieren und Transparenz und Vertrauen fördern soll. Dabei haben wir darauf geachtet, dass das Vertragswerk fair für beide Parteien ist, mit geltendem Schweizer Recht kompatibel ist und den administrativen Aufwand während dem Projekt nicht erhöht, sodass wir uns auf das Wesentliche konzentrieren können—überzeugende Softwarelösungen zu schaffen.

## Compensation at a Fixed Price Conveys a Deceptive Sense of Cost Certainty

Purchasing the development of a software solution at a fixed price may seem obvious from the customer's point of view, because it promises supposed cost security and a guaranteed result. In practice, however, this is illusory. Under Swiss law, compensation at a fixed price is represented in a so-called contract for work and services (Art. 363 ff. OR). The customer describes in detail what is to be delivered by the supplier (legally "the work"). The supplier states the fixed price at which he can deliver the software. In practice, it is not possible to specify all the requirements for a software solution precisely enough in advance. Usually, important requirements are forgotten or circumstances and user needs change during the project. Disagreements about the compensation of changed or new requirements between customer and supplier are therefore inevitable.

With a fixed price compensation model, the customer tends to pay a fixed price that is too high and should expect additional expenses during the course of the project. Because it is difficult for the supplier to accurately estimate the total cost of an entire development project, the supplier includes a certain safety margin. That is, the customer pays not only for the development service, but also an extra for the risk of an incorrect estimation of effort. In addition, the customer pays for unexpected costs for unspecified or new requirements that arise during the course of the project. Generally, so-called "change requests" are not included in the fixed price and are charged additionally.


## Compensation by Time and Material Turns a Development Project into a Bottomless Pit

When the customer purchases software development by time and material, he has maximum flexibility with respect to the scope of development, but hardly any chance of estimating the total costs. In Swiss law, compensation by time and material is defined by the term “agency contract" (Art. 394 et seq. OR). In this case, the supplier only owes the client an activity in accordance with applicable duties of care and to the best of his knowledge and belief. The customer pays for time worked (e.g. hours or days) and material used. The supplier usually makes an estimate of how much time it will take to develop a software solution, but is not obligated to honor that estimate.

With a compensation model based on time and material the customer pays for the inefficiency of developers and in addition bears the entire risk of success. Productivity varies widely, especially among software developers. A <a href="https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/" target="_blank" rel="noopener noreferrer nofollow">number of studies</a> since the 1960s proclaim the "10x" factor in the productivity of programmers—that is, a 10-fold difference in what a developer can accomplish in a certain unit of time. So, whether a paid hour of work produces effectively usable results is therefore not guaranteed. In addition, payment by time and material sets the wrong incentives for the supplier. If it takes him longer to complete a task, he can charge more. In a case of hardship, the supplier can insist on payment after the time worked, without having achieved anything. The customer therefore bears the risk of success in full.


## A Sprint-based Compensation Model Reduces Project Risk while still Allowing Flexibility

With a sprint-based compensation model, the customer pays a fixed price per sprint agreed upon before the project. In agile software development, a sprint is a fixed period of time—usually two weeks—in which certain work results must be delivered. The customer and the supplier jointly define the deliverables and their acceptance criteria before each sprint. The supplier guarantees the fulfillment of the defined deliverables per sprint. In case of non-fulfillment or partial fulfillment, the customer does not pay or only partially pays for the sprint. 

The financial risk is manageable for both the customer and the supplier. The customer has a guarantee that he gets measurable and tangible results for his money and does not just pay for hours worked that lead to nothing. Both the customer and the supplier can define the deliverables and their acceptance criteria with sufficient precision for the time horizon of a sprint. The supplier can reliably estimate which results he can realistically achieve within the upcoming two weeks and can promise them with confidence and without unnecessary safety margins. For the supplier, the financial risk of overestimating and not being able to deliver the results promised is limited to the price of the sprint.

With the sprint-based compensation model, the customer retains the flexibility to adjust the development course if it turns out that the initially defined requirements have changed. As with compensation by time and material, the development activities that are expected to add the most value can be prioritized. However, the value for money becomes much more visible because the fixed price per sprint can be put against tangible work results. In addition, the mindset of the supplier changes from "deliver hours" to "deliver results".


## Equally Important as the Compensation Model is a Trustful Relationship between Customer and Supplier.

Agile development and a sprint-based compensation model help to reduce the risk in development and innovation projects. However, development and innovation projects are and remain characterized by uncertainty. A sprint-based compensation model does nothing to change this. There are no guarantees for project success, even if this is often desired by managers with questions such as "How long will it take and what will it cost overall?" Instead of creating long-term plans and budgets that end up being discarded, we should focus on generating maximum value with a fixed budget—the fixed price per sprint—each time. And that is exactly what is achieved with a sprint-based compensation model.

The right compensation model and the corresponding contract that reflects such a model support a functioning cooperation between customer and supplier. Equally important, however, is a business relationship based on trust and a shared vision. After all, this is what ultimately motivates all parties involved to develop and operate usable and valuable software solutions—solutions that are loved by users.

At EMBRIO.tech, we put the sprint-based compensation model into practice and created a tailored contract framework to ensure maximum value for money and promote transparency and trust. In doing so, we made sure that the contract is fair for both parties, compatible with applicable Swiss law and does not increase the administrative effort during the project, so that we can focus on the essentials—creating compelling software solutions.

large_hustle.jpg

medium_hustle.jpg

small_hustle.jpg

thumbnail_hustle.jpg

hustle.jpg

Gefallen Ihnen unsere Gedanken?

Do you like our ideas?

Wie du den Wert steigern kannst, den du für dein Geld von deinem Entwicklungsdienstleister bekommst. Wir zeigen, welchen Einfluss Kompensationsmodelle auf das Preis-Leistungs-Verhältnis von Softwareprojekten haben.

How to maximize the value for money you get from your development service provider. We show the impact of compensation models on the value for money of software projects.

large_handshake-neon.jpg

medium_handshake-neon.jpg

small_handshake-neon.jpg

thumbnail_handshake-neon.jpg

handshake-neon.jpg

Der Einfluss von Vergütungsmodellen auf das Preis-Leistungs-Verhältnis von Entwicklungsdienstleistungen

The Impact of Compensation Models on Value for Money of Development Services

DevOps_Cycle.png

## Was ist DevOps und warum ist es wichtig?

DevOps entsteht aus der Kombination von Konzepten und Praktiken aus der lean manufacturing, dem agile manifesto und der continuous delivery Bewegung. Es bringt die Entwicklungs- und Betriebsteams unter ein gemeinsames Dach, um die Zusammenarbeit über den gesamten Lebenszyklus von Applikationen zu verstärken. 

DevOps baut auf drei grundlegenden Prinzipien auf:
1. Das Prinzip des Flow - Streben Sie nach einer stabilen, fehlerfreien und ungehinderten Bewegung der Arbeit über die notwendigen Arbeitsschritte hinweg.
2. Das Prinzip der Rückkopplung - nutzen Sie die von nachgelagerten Schritten erfassten Informationen, um Probleme rechtzeitig an ihrem Ursprung zu entschärfen und zu korrigieren.
3. Das Prinzip des kontinuierlichen Lernens - fördern Sie eine Kultur des Experimentierens, der kontrollierten Risikobereitschaft und des Lernens aus Fehlern.

DevOps-Anwender erzielen drei grosse Vorteile:
- Höhere Geschwindigkeit bei der Erstellung und Veröffentlichung von Software
- Verbesserte Stabilität und Zuverlässigkeit der Lösung und des Prozesses
- Höhere Reaktionsfähigkeit auf wechselnde Umgebungsbedingungen

Die Einführung der DevOps-Mentalität kann für Unternehmen ein anspruchsvoller Prozess sein. Obwohl es kein Standardrezept für die DevOps-Umstellung gibt und jedes Unternehmen seinen eigenen besten Ansatz finden muss, zeigt die Erfahrung, dass es einige häufige Fehler und Stolperfallen gibt, die sich leicht vermeiden lassen. Unsere Broschüre fasst unsere Erfahrungen aus mehreren Implementierungsprojekten zusammen und gibt einen Einblick in die unserer Meinung nach häufigsten Fallstricke und Fehler, die es zu vermeiden gilt. Sind Sie neugierig? Unten finden Sie den Download-Link!

<a class="btn btn-primary mt-2 mt-md-4 text-uppercase font-weight-bold font-size-sm hover-lift-light" href="https://docs.google.com/forms/d/e/1FAIpQLSfFIKQH2BmbH4zO1mGi7BDwmp-IVypkoP4Q4mZaggJdwMC9hw/viewform" target="_blank">Get Booklet now!</a>

## What Is DevOps and Why Does it Matter?

DevOps originates from the combination of concepts and practices from: lean manufacturing, the agile manifesto and the continuous delivery movement. It Brings the development and operations teams under the same roof to enforce collaboration across the entire application lifecycle. 

DevOps builds upon three fundamental principles:
1. The principle of flow – strive for a stable, faultless and unconstrained movement of work across the necessary worksteps.
2. The principle of feedback – leverage the information captured from downstream steps to timely mitigate and correct problems at their origin.
3. The principle of ongoing learning – foster a culture of experimentation, controlled risk-taking and learning from failure.

DevOps adopters achieve three major advantages:
- Increased speed in software creation and release
- Improved stability and reliability of the solution and process
- More responsiveness to varying surrounding conditions

Embracing the DevOps mindset can be a challenging process for organizations. Although there is no standard recipe to follow in a DevOps transformation, and each company must come up with its own best approach; experience shows that there are some common mistakes and pitfalls that can be easily avoided. Our booklet summarizes our learning from several implementation projects and provides insights about what in our opinion are the most common pitfalls and mistakes to avoid. Curious? You'll find the download link below!

<a class="btn btn-primary mt-2 mt-md-4 text-uppercase font-weight-bold font-size-sm hover-lift-light" href="https://docs.google.com/forms/d/e/1FAIpQLSfFIKQH2BmbH4zO1mGi7BDwmp-IVypkoP4Q4mZaggJdwMC9hw/viewform" target="_blank">Get Booklet now!</a>

large_ci-cd-infinite-love.jpg

medium_ci-cd-infinite-love.jpg

small_ci-cd-infinite-love.jpg

thumbnail_ci-cd-infinite-love.jpg

ci-cd-infinite-love.jpg

Wollen Sie wissen, wie viel Geld Sie mit einer automatisierten CI/CD-Pipeline in Ihrer Organisation sparen könnten?

Do you want to know how much money you could save with an automated CI/CD pipeline in your organization?

Informieren Sie sich über die Fallstricke, die Ihre DevOps-Transformation bremsen. Erfahren Sie, wie Sie diese erkennen und sofort handeln können.

Learn about the pitfalls slowing down your DevOps transformation. Get useful insights about how to spot them and act immediately to avoid them.

large_Devops_Splash.jpg

medium_Devops_Splash.jpg

small_Devops_Splash.jpg

thumbnail_Devops_Splash.jpg

Devops_Splash.jpg

4 häufige DevOps-Fehler und wie man diese vermeidet - Ein Booklet

4 Common DevOps Mistakes and How To Avoid Them – A Booklet

Unser Standpunkt dazu, wie man exzellente Software—und nicht einfach nur Software—entwickelt und bereitstellt und warum du nach Exzellenz streben solltest.

Software und der Bedarf an ihr ist allgegenwärtig. In der Wirtschaft gibt es für fast jede Herausforderung im Informationsmanagement entweder eine Softwarelösung oder den Bedarf danach. Wenn es für ein bestimmtes Problem keine Softwarelösung gibt, ist es heutzutage dank leistungsfähiger Frameworks, UI-Komponentenbibliotheken und Cloud Computing relativ einfach, eine maßgeschneiderte Software für ein bestimmtes Problem zu entwickeln. Es gibt also viele Möglichkeiten und Alternativen, entweder eine bestehende Softwarelösung oder eine Technologie zu wählen oder eine zu entwerfen und zu entwickeln. Du hast die Qual der Wahl, unabhängig davon, ob du eine bestehende Lösung kaufen willst oder ob du eine Software für deine oder die Herausforderungen eines anderen entwickeln und bereitstellen willst.

Wann immer es Optionen und Alternativen gibt, um ein Problem zu lösen, ist es nur natürlich, dass Menschen den Drang verspüren, die "beste" zu wählen—zum Beispiel die wirtschaftlichste, die leistungsfähigste oder die mit der besten Benutzerfreundlichkeit. Als Softwareentwickler oder -anbieter möchtest du also sicherstellen, dass die Software, die du entwickelst, die "beste" ist—sie sollte exzellent sein. Du beschäftigst dich also wahrscheinlich mit Fragen wie: Wie kannst du deinen Nutzern die "beste" Softwarelösung bieten, die ihren Bedürfnissen und Herausforderungen gerecht wird? Wie kannst du sicherstellen, dass die Nutzer deine Lösung lieben? Und wie kannst du sicherstellen, dass deine Lösung ihren Wettbewerbsvorteil gegenüber den anderen Alternativen aufrechterhält?

Wenn deine Softwarelösung exzellent ist, werden die Leute sie immer wieder benutzen, sie kaufen und sich nicht nach Alternativen umsehen. Ihre Exzellenz garantiert einen Wettbewerbsvorteil. Nur exzellente Software kann auf die kosteneffizienteste Weise bereitgestellt und betrieben werden. Exzellente Software ist der Schlüssel zur Steigerung der betrieblichen Effizienz und damit zu hoher Rentabilität. Und nur exzellente Software kann das Versprechen einlösen, das beste Preis-Leistungs-Verhältnis zu bieten.

In diesem Blogbeitrag stellen wir sechs Grundsätze vor, die es dir ermöglichen, exzellente Software zu entwickeln und anzubieten.



1. Beherrsche die agile Entwicklung.
2. Stelle den Nutzer an die erste Stelle, die Technologie kommt danach.
3. Keep it simple, weniger ist mehr.
4. Wähle die passenden Werkzeuge und Technologien.
5. Handle nach den Prinzipien von DevOps.
6. Halte deine Software wartbar.


## Beherrsche die agile Entwicklung.

Stellen wir das Offensichtliche zuerst fest: Agile Entwicklung ist der Schlüssel zum Erfolg in der Softwareentwicklung. Verschiedene Studien zeigen, dass ein agiler Entwicklungsansatz die Erfolgsquote der Entwicklung erhöht und das Risiko des Scheiterns senkt. Die Standish Group Chaos Studie aus dem Jahr 2020, die auf mehr als 50.000 Projekten basiert, sagt zum Beispiel, dass die Erfolgschancen eines agilen Projekts dreimal höher sind als die eines Wasserfall-Projekts. Die Wahrscheinlichkeit, dass ein Wasserfall-Projekt scheitert, ist im Vergleich zu einem agilen Projekt doppelt so hoch.

Es ist erwähnenswert, dass es beim Beherrschen von agiler Entwicklung nicht nur um die Anwendung von Methoden wie Scrum oder Kanban geht. Wir glauben, dass man zum Meisten von agiler Entwicklung die zugrunde liegenden Prinzipien, Werte und Denkweisen verstehen muss. Dies wird vom Agile Maturity Iceberg von Matías E. Fernández passend illustriert. Teams müssen das "Warum" hinter Agile verstehen und die Werte und Prinzipien vollständig verinnerlichen. Im Wesentlichen ist Agile ein Mindset und Ansatz, um das Risiko in Projekten zu verringern, indem man frühzeitig einen Mehrwert liefert.

Our take on how to develop and deliver excellent software—and not just software—and why you should strive for excellence.

Software and the need for it is omnipresent. In Business, for almost every information management challenge, there is either a software solution or the need for one. If there is no existing software solution for a particular challenge, nowadays it is relatively easy to build custom software targeting a particular challenge—thanks to powerful frameworks, UI component libraries, and cloud computing. Thus, there are many options and alternatives for either choosing an existing software solution or a technology, or for designing and developing one. You are spoiled for choice, independent of whether you want to purchase an existing solution or whether you want to develop and provide for your or somebody else's challenge.

Whenever there are options and alternatives for addressing a challenge, it is only natural that people feel the urge to choose the “best” one—for example the most economic one, the most performant, or the one with the best usability. Thus, as a software developer or provider you want to make sure the software you build is the “best”—it should be excellent. So, you probably care about questions like: How can you provide your users the “best” software solution which addresses their needs and challenges? How can you make sure the users love your solution? And how can you make sure your solution maintains its competitive advantage over the other alternatives out there?

When your software solution is excellent, people will keep using it, keep buying it and do not start to look for alternatives. Its excellence guarantees competitive advantage. Only excellent software can be provided and operated in the most cost efficient way. Excellent software is key for increasing operational efficiency and thus high profitability. And, only excellent software can deliver on the promise of offering the best value for money.

In this blog post we share six guiding principles we believe allow you to develop and provide excellent software.

1. Master agile development
2. Put the user first, technology second
3. Keep it simple, less is more
4. Pick the right tools and technologies
5. Act according to the principles of DevOps
6. Keep your software maintainable


## Master Agile Development

Let’s state the obvious first: Agile development is key for excellence in software engineering. Various studies show that an agile development approach increases the success rate of a development and decreases the risk of failure. For example, the Standish Group Chaos Study from 2020 based on more than 50K project cases claims that the chances of success of an agile project are three times higher than of a waterfall project. And, a waterfall project is two times more likely to fail, compared to an agile project.

Worth mentioning is that mastering Agile is not just about applying methods such as Scrum or Kanban. We believe that mastering Agile means understanding the underlying principles, values and mindsets as nicely illustrated by the Agile Maturity Iceberg by Matías E. Fernández. Teams must understand the “why” behind Agile and fully embody its values and principles. In essence, Agile is a way of reducing the risk in projects by delivering value early.

The Agile Maturity Iceberg by Matías E. Fernández

agile-maturity-iceberg.jpeg

## Stelle den Nutzer an die erste Stelle, die Technologie kommt danach

Nur wenn du die Bedürfnisse deiner Zielnutzer und -nutzerinnen genau kennst, kannst du exzellente und wertschöpfende Software entwickeln. In einem geschäftlichen Umfeld sollte eine Software oder IoT-Anwendung den Nutzer bei der Ausführung seiner Arbeit unterstützen oder besser noch mühsame und sich wiederholende Aufgaben ersetzen, die ohnehin niemand erledigen möchte. Da eine Softwarelösung in der Regel Informationen sammelt, verwaltet und bereitstellt, ist ein guter Ausgangspunkt in der Regel die Frage: Welche Informationen würden einem Nutzer helfen, bessere Entscheidungen zu treffen oder könnten nachfolgende Aktionen auslösen oder ermöglichen? Nachdem du herausgefunden hast, welche Informationen für einen potenziellen Nutzer wertvoll sind, kannst du dir Gedanken über die Umsetzung und die Technologie machen, um diese Informationen auf die am leichtesten zugängliche Weise zur richtigen Zeit und am richtigen Ort bereitzustellen.

Implementiert eine Technologie immer für einen Menschen, niemals nur für ihren Selbstzweck. In der Praxis solltest du deine Anforderungen immer als User- oder Job-Stories formulieren. So kannst du sicherstellen, dass du wirklich verstehst, warum etwas aus der Sicht eines Nutzers umgesetzt werden sollte. Sei dir bewusst, dass ein Nutzer auch der Ingenieur sein kann, der den Code pflegen muss, und nicht immer nur der Endnutzer der Anwendung. Zum Beispiel:

> Als Softwareentwickler möchte ich diesen Code umschreiben, weil ich dadurch weniger Wartungsaufwand habe. 


## Keep it simple, weniger ist mehr

Gute Software ist so wenig Software wie möglich. Das allgemeingültige Designprinzip "Gutes Design ist so wenig Design wie möglich", das der deutsche Designer Dieter Rams in den 1970er Jahren eingeführt hat, lässt sich ohne Weiteres auf die Softwareentwicklung übertragen und hat nach wie vor seine Bedeutung. Indem du dich auf die Funktionen konzentrierst, die wirklich gebraucht werden, kannst du zwei Fliegen mit einer Klappe schlagen. Erstens erhöhst du die Benutzerfreundlichkeit. Eine übersichtliche und einfache Benutzeroberfläche schneidet immer besser ab als eine unübersichtliche mit zu vielen Informationen.  Zweitens hältst du den Wartungsaufwand gering, indem du Code vermeidest, der keinen großen Nutzen bringt. Ganz im Sinne von Rams: Exzellente Software ist rein und einfach!

Um dieses Prinzip in die Praxis umzusetzen, kann die 3-Warum-Regel dabei helfen, unnötige Feature-Anfragen zu erkennen. Immer wenn jemand eine neue Funktion oder eine Änderung anfordert, solltest du oder dein Product Owner (PO) dreimal fragen, warum. Die 3-Warum-Regel hilft dabei, herauszufinden, was gebraucht wird und ob es wirklich notwendig ist. Ein Beispiel:

> **Antragsteller**: Ich hätte gerne ein Eingabefeld für die Hausnummer in einem Adressformular.  
**PO**: Warum?  
**Antragsteller**: Damit der Benutzer seine Hausnummer eingeben kann.  
**PO**: Warum?   
**Antragsteller**: Damit wir die Hausnummer getrennt vom Straßennamen erfassen können.  
**PO**: Warum?  
**Antragsteller**: Damit wir die Bestellungen nach Hausnummern sortieren und die Pakete in der richtigen Reihenfolge ins Lieferfahrzeug laden können.  
**PO**: Ah, ok. Wir brauchen also kein Formularfeld für die Hausnummer, sondern eine Lösung, um die Pakete in der optimalen Reihenfolge in das Fahrzeug zu laden, nicht wahr?  
**Antragsteller**: Ja, genau!


## Wähle die passenden Werkzeuge und Technologien

Eine gute Wahl von Tools und Technologien wirkt sich positiv auf deine operative Exzellenz aus. Die Wahl der Werkzeuge und Technologien hat einen großen Einfluss auf den Aufwand für die Entwicklung, die Wartung und den Betrieb deiner Anwendung. Wenn du dich für neue Tools und Technologien entscheidest, musst du vielleicht etwas Lernaufwand betreiben. Aber das Erlernen von etwas Neuem zahlt sich aus, wenn es deine Effizienz bei der Programmierung, der Wartung und dem Betrieb erhöht.

Achte bei der Auswahl deiner Tools und Technologien darauf, dass sie gerade gut genug für deine Aufgabe sind und vermeide Over-Engineering. Zu viele verschiedene Tools können auch die Komplexität erhöhen und damit die Effizienz verringern. Hinterfrage ausserdem regelmäßig dein aktuelles Technologie-Setup und überdenke deine Entscheidungen, denn vor allem digitale Technologien entwickeln sich schnell weiter. Das bedeutet nicht, dass du auf jeden neuen Technologie-Trend aufspringen musst. Du solltest sorgfältig die Vor- und Nachteile deiner Alternativen abwägen, bevor du dich für einen Wechsel entscheidest. 


## Handle nach den Prinzipien von DevOps

Durch die Einbeziehung der DevOps-Prinzipien stellst du sicher, dass du nicht nur ein exzellentes Softwareprodukt entwickeln kannst, sondern auch während des gesamten Lebenszyklus der Anwendung—Planen, Coden, Kompilieren, Testen, Freigeben, Bereitstellen, Betreiben und Überwachen—hervorragende Ergebnisse erzielst. Das Hauptziel der DevOps-Philosophie ist es, die Geschwindigkeit zu erhöhen, die Stabilität und Zuverlässigkeit zu verbessern und die Reaktionsfähigkeit auf wechselnde Umgebungsbedingungen zu verbessern. Indem du Entwicklung und Betrieb unter einem Dach—im selben Team—vereinst, kannst du einen kontinuierlichen Fluss, direktes Feedback und ständiges Lernen entlang der gesamten Wertschöpfungskette der Bereitstellung einer Softwarelösung ermöglichen.

## Put the User First, Technology Second

Only a deep understanding of your target users’ needs allows you to build excellent software that matters. In a business environment, a software or IoT application should support a user in performing his job or even better replace tedious and repetitive jobs nobody wants to do anyway. As a software solution usually collects, manages and provides information, a good starting point is usually to ask: What information would help a user to make better decisions or could trigger or enable subsequent actions? After identifying the information valuable for a potential user, you can start thinking about the implementation and the technology for providing that information in the most easily accessible way at the right time and place.

Implement technology always for a human being, never just for the sake of it. In practice, you should always formulate your requirements as user or job stories. It helps you to make sure that you really understand why something should be implemented from a user’s perspective. Be aware that a user could also be the engineer who has to maintain the code and not always only the end-user of the application. For example: 

> As a software engineer I want to refactor this code, because it reduces my maintenance effort.

## Keep it simple, less is more

Excellent software is as little software as possible. The general design principle “_good design is as little design as possible_”  introduced by the German designer Dieter Rams in the 1970s can be transferred to software development without further ado and still holds its importance. By focusing on the features that are really needed you can kill two birds with one stone. First, you increase the usability. A clean and simple user interface outperforms a cluttered one with information overload by far. Second, you keep the maintenance efforts low by avoiding code which does not provide much value. In the spirit of Rams: Excellent software is pure and simple!

To put this principle into practice the 3-why rule can help to detect unnecessary feature requests. Whenever someone requests a new feature or a change, you or your product owner (PO) should ask three times why. The 3-why rule helps to find out what is needed and if it is really necessary. For example:

> **Requester**: _I would like to have an input field for the house number in an address form._  
**PO**: _why?_  
**Requester**: _So that the user can enter his house number._  
**PO**: _why?_   
**Requester**: _So that we have the house number separate from the street name._  
**PO**: _why?_  
**Requester**: _So that we can sort orders by house number and pack the parcels in the correct order to the delivery vehicle._  
**PO**: _Ah, ok. So, we don’t need a form field for the house number but a solution to load the parcels in the optimal order to the vehicle, don’t we?_  
**Requester**: _Yes, exactly!_

## Pick the right tools and technologies

A good choice of tools and technologies positively impacts your operational excellence. Your choice of tools and technology has a huge impact on the efforts for developing, maintaining, and operating your application. When you choose new tools and technologies you might need to invest some learning efforts. But learning something new pays off, if it increases your coding, maintenance and operation efficiency down the road.

When selecting your tools and technologies make sure to select the one which is just good enough for the job and avoid over-engineering. Too many different tools can also increase the complexity and therefore decrease the efficiency. Also, regularly question your current setup and reflect on your choices, because especially digital technologies evolve fast. This does not mean that you have to jump on every new technology trend. Carefully weigh the pros and cons of technology alternatives before deciding to switch. 

## Act According to the Principles of DevOps

By incorporating the principles of DevOps you make sure not only to build a great software product but also to achieve excellence over the entire application life cycle—plan, code, build, test, release, deploy, operate, and monitor. The main goal of the DevOps Philosophy ist to increase speed, improve stability and reliability, and responsiveness to varying surrounding conditions. By uniting development and operations under the same roof—in the same team—you enable continuous flow, direct feedback and ongoing learning along the entire value chain of providing a software solution.

Um bei DevOps Exzellenz zu erzielen, musst du deine Wertschöpfungsprozesse kontinuierlich verbessern. Sei dir bewusst, dass DevOps nicht nur aus der Implementierung von CI/CD-Automatisierung und hochskalierbaren Cloud-Deployments besteht. Wenn du deine DevOps-Prozesse verbessern willst, kannst du mit einfachen Dingen wie Anforderungsmanagement oder Release-Planung beginnen.


## Halte deine Software wartbar

Exzellente Software ist keine Konstante. Software muss sich weiterentwickeln und anpassen können. Zum Beispiel muss sie sich an veränderte Nutzerbedürfnisse, an veränderte Technologiestandards oder an eine veränderte Zusammensetzung des Entwicklerteams anpassen. Du musst jederzeit in der Lage sein, mühelos Funktionen hinzuzufügen oder zu entfernen, ohne die Leistung deines Softwareprodukts zu beeinträchtigen. Ein Softwareentwickler, der noch nie an deiner Software gearbeitet hat, sollte trotzdem in der Lage sein, den Code zu verstehen und zu erweitern.

Um Wartungsfreundlichkeit zu erreichen, muss dein Code sauber und gut strukturiert sein. Eine modulare Architektur, die aus Komponenten mit genau definierten und dokumentierten Schnittstellen besteht, ermöglicht die Austauschbarkeit von Komponenten. So können veraltete oder nicht mehr benötigte Komponenten ersetzt oder entfernt werden. Wenn du ein neues Softwareprodukt entwickeln willst, plane und budgetiere nicht nur für die erste Version, sondern überlege auch, wie du das Produkt betreiben, warten und weiterentwickeln willst.


## In Kürze

Die Berücksichtigung unserer sechs Leitprinzipien für die Bereitstellung exzellenter Software ermöglicht es dir, die Qualität deiner Softwarelösung zu erhöhen und die Effizienz und Effektivität bei Entwicklung, Wartung und Betrieb in Richtung Exzellenz zu steigern. Das Streben nach Exzellenz ist wünschenswert, denn es schafft und erhält Wettbewerbsvorteile durch Kostensenkung (operative Exzellenz) und Produktdifferenzierung (Produkt- und Service-Exzellenz). Biete nicht einfach nur eine Softwarelösung an. Biete die Beste ihrer Art an—die, die deine Nutzer und Kunden lieben und auch in Zukunft lieben werden!

To achieve excellence in DevOps you need to continuously improve your value chain processes. Be aware that DevOps is not just the implementation of CI/CD automation and hyperscaling cloud deployments. If you want to improve your DevOps processes you can start with simple things like requirement management or release planning.


## Keep Your Software Maintainable

Excellent software is not a constant. Software must be able to evolve and adapt. For example, it has to adapt to changing user needs, to changing technology standards, or to a changing composition of the engineering team. At all times, you need to be able to effortlessly add or remove functionality without compromising the performance of your software product. A software engineer who has never worked on your software should still be able to understand and extend the code.

Achieving maintainability means keeping your code clean and well structured. A modular architecture made of components with precisely defined and documented interfaces enables interchangeability of components. This allows obsolete or no longer needed components to be replaced or removed. If you want to develop a new software product, plan and budget not only for the initial release, but also consider how you will operate, maintain, and evolve the product.


## In a Nutshell

Incorporating our six guiding principles for providing excellent software allows you to increase the quality of your software solution and to increase the efficiency and effectiveness for development, maintenance and operation towards excellence. Striving for excellence is desirable because it creates and maintains competitive advantage by reducing cost (operational excellence) and product differentiation (product and service excellence). Do not offer just a software solution. Provide the most excellent of its kind—the one your users and clients love and keep loving!

reach the next level of excellence in providing software

large_provide-a-diamond.jpg

medium_provide-a-diamond.jpg

small_provide-a-diamond.jpg

thumbnail_provide-a-diamond.jpg

provide-a-diamond.jpg

Willst du die nächste Stufe der Exzellenz bei der Bereitstellung von Software erreichen?

Do you want to reach the next level of excellence in providing software?

Ein Blogbeitrag darüber, wie man exzellente Software entwickelt und anbietet. Wir erklären, warum wir glauben, dass exzellente Software so wichtig ist. Weiter stellen wir sechs Grundsätze vor, mit denen du unserer Meinung nach exzellente Software entwickeln und anbieten kannst.

A blog post on how to develop and deliver excellent software. We explain why we believe excellent software is so important. Further, we present six principles that we believe you can use to develop and deliver excellent software.

provide excellence in software development

large_provide-excellence-in-software-development.jpg

medium_provide-excellence-in-software-development.jpg

small_provide-excellence-in-software-development.jpg

thumbnail_provide-excellence-in-software-development.jpg

provide-excellence-in-software-development.jpg

Wie man exzellente Software anbietet und warum das so wichtig ist

How to Provide Excellent Software and Why it Matters

Für Investoren und Venture Capitalists (VCs) sind Digital-Tech-Startups sehr attraktiv, weil diese meist eine hohe Skalierbarkeit und damit einen hohen Return on Investment versprechen. Allgemein sind digitale Technologien heutzutage für die meisten Startup-Unternehmen eine zentrale Komponente in ihrem Businessmodell. Um möglichst wettbewerbsfähig zu sein, setzen die technologiegetriebenen Jung­un­ter­neh­men auf Web oder Mobile Apps, Artificial Intelligence (AI) oder Blockchain als Teil ihres Wertversprechens oder entlang ihrer Wertschöpfungskette.

Wer in ein Digital-Tech-Startup—oder auch in ein etabliertes Unternehmen—investiert, sollte genau prüfen, ob die digitale Technologie, welche von einem Unternehmen entwickelt oder eingesetzt wird, mit den Business Ambitionen und den Wachstumsszenarien mithalten kann. Nur weil beispielsweise die Benutzeroberfläche einer App schick und modern ausschaut, heisst das noch lange nicht, dass die zugrundeliegende Technologie richtig gewählt oder eingesetzt wurde. 

Um das Risiko von Fehlinvestitionen zu minimieren, ist die systematische Prüfung der von einem Startup entwickelten oder eingesetzten Technologie vor einer allfälligen Investition unerlässlich. Zu validieren, ob diese hält, was sie verspricht, ist also eine Schlüssel-Herausforderung für Investoren und VCs.

Die Prüfung, Validierung und Bewertung der von einem Unternehmen entwickelten oder eingesetzten Technologie zu Investitionszwecken beschreibt der Begriff Technical Due Diligence (Tech DD) oder auch Software Due Diligence. Der folgende Text erläutert die sechs Kerndimensionen einer Technical Due Diligence Prüfung von Digital-Tech-Startups. Die sechs Dimensionen sind:

1. Qualität
2. Skalierbarkeit
3. Sicherheit
4. Agilität
5. Wartbarkeit
6. Resilienz


Digital tech startups are very attractive to investors and venture capitalists (VCs) because they usually promise high returns on investment due to their high-growth profiles and scalability. In general, digital technologies are a central component in the business model of most startups today. To be as competitive as possible, technology-driven startups rely on web or mobile apps, Artificial Intelligence (AI) or Blockchain as part of their value proposition or along their value chain.

Anyone investing in a digital tech startup—or also in an established company—should carefully examine whether the digital technology being developed or deployed by a startup can keep up with its business ambitions and growth scenarios. For example, just because an app's user interface looks fancy and modern doesn't mean that the underlying technology is fit for purpose or has been properly deployed. 

To minimize the risk of bad investments and the associated losses, systematic evaluation of the technology developed or used by a startup is essential before any investment is made. Validating whether it is capable to deliver on its promises is thus a key challenge for investors and VCs.

The process of reviewing, validating and evaluating the technology developed or deployed by a company for investment purposes is described by the term Technical Due Diligence (Tech DD)—also known as Software Due Diligence. The following text explains the six core dimensions of a comprehensive Technical Due Diligence review for digital tech startups and their developed and deployed technologies. The six dimensions are:

1. Quality
2. Scalability
3. Security
4. Agility
5. Maintainability
6. Resilience


six dimensions of technical due diligence

tech-d-d-spider-chart.png

## Qualität

Die Qualitätsprüfung von einer digitalen Technologie-Anwendung oder einer Softwareapplikation kann in zwei Bereiche unterteilt werden: die **Qualität der Benutzerinterfaces** (UIs) und die **Qualität des Codes**. 

Die **Qualität der UIs** kann bereits ohne vertiefte IT Expertise beurteilt werden. Folgende Fragen helfen bei der Beurteilung des UIs:



* Wie leicht und intuitiv ist die Applikation in der Bedienung?
* Wie einfach ist die Navigation und wie intuitiv sind die Funktionalitäten?
* Wie zeitgemäss und modern ist das UI Design?
* Wie fühlt sich die Bedienung der Applikation an?
* Was passiert, wenn ich die Applikation falsch bediene?

Die Beurteilung der **Code-Qualität** hingegen bedarf tiefgründiger IT Expertise und Erfahrung in Software Engineering. Es sollten Fragen wie die folgenden beantwortet werden.



* Wie effizient sind die Prozesse und Algorithmen? Je effizienter eine Software-Applikation läuft, desto weniger Rechenleistung und Arbeitsspeicher werden benötigt. Was bei Applikationen, welche auf Servern laufen zu tieferen Betriebskosten und bei Desktopanwendungen zu glücklicheren Benutzern führt.
* Wie ist das Errorhandling? Errors und Bugs in der Softwareentwicklung sind so sicher wie das Amen in der Kirche. Fehler können beispielsweise durch falsche Bedienung oder nicht berücksichtigte Sonderfälle verursacht werden. Eine gute Applikation kann damit umgehen, ohne dass es zum Totalausfall kommt. Fehler sollten auch immer aufgezeichnet werden (Error-Log), um deren Ursache zukünftig zu beheben.
* Erfüllt der Code Best Practices und modernste Technologiestandards? Haben die Entwickler die richtige Technologie für ihr Anwendungsproblem gewählt und haben sie diese Technologie richtig angewendet?


## Skalierbarkeit

Die Skalierbarkeit ist gerade für ambitionierte Startups von Bedeutung. Wenn die Nutzerzahlen stark ansteigen, aber die Technologie nicht mit dem Business-Wachstum mithalten kann, führt dies zu existenziellen Problemen: Primär wird das Business-Wachstum verlangsamt. Sekundär sinkt aber meist auch die Zufriedenheit der bestehenden Nutzern, da die App-Performance nachlässt.

Ein Startup muss nicht von Beginn weg eine Software-Applikation bauen, welche für Millionen von Nutzern funktioniert. Viel wichtiger ist eine modulare und skalierbare Architektur, welche mit dem Wachstum der Nutzerzahlen ausgebaut werden kann ohne dass die Applikation nochmal komplett neu gebaut werden muss. Bei Cloud-Applikationen spricht man beispielsweise von horizontaler Skalierbarkeit.

Der Aufwand für Setup und Bereitstellung einer Software-Applikation für einen neuen Kunden ist ein weiterer Punkt, welcher bezüglich Skalierbarkeit beachtet werden sollte. Bedarf die Applikation beispielsweise aufwändiger manueller Installationen und Konfigurationen (z.B. von Servern oder Datenbanken), welche bei wachsender Kundenzahl zum Nadelöhr werden? Was lässt sich möglicherweise automatisieren?


## Sicherheit

Mit dem wachsenden Erfolg eines Unternehmen nimmt auch die Sichtbarkeit und damit die Wahrscheinlichkeit für Hacker-Angriffe zu. Verliert ein Unternehmen das Vertrauen seiner Kunden, weil es nicht in der Lage ist, deren Daten sicher zu verwahren, hat dies einen direkten Einfluss auf den Unternehmenswert. Im schlimmsten Fall kann es zu zusätzlichen finanziellen Schäden kommen, wenn es den Angreifern gelingt, die Funktionsfähigkeit zu sabotieren (z.B. Verschlüsselung der Datenbank durch Ransomware).

Gerade bei Startups, welche möglichst schnell mit ihrem Produkt auf den Markt wollen, werden wichtige Sicherheitsstandards vernachlässigt. Das Thema Sicherheit sollte also spätestens bei der Tech DD ausreichend Beachtung erhalten. Folgende Fragen sollten mindestens geklärt werden:



* Welcher Standard wird für die Authentifizierung eingesetzt und wird dieser Standard richtig angewendet (z.B. OAuth 2.0, OpenID)?
* Werden vertrauliche/sensitive Daten sicher verwahrt (z.B. Datenbank-Passwörter oder API-Keys)?
* Enthält der Source-Code keine schützenswerten Informationen (bei Open Source Projekten) oder wird der Zugriff darauf eingeschränkt?
* Wie anfällig ist die Software-Applikation für Attacken (z.B. Ransomware oder DDoS-Angriffe)?
* Welche Lösungen und Libraries von Dritten werden verwendet und haben diese möglicherweise Sicherheitslücken?


## Agilität

Kundenbedürfnisse können und werden sich ändern. Umstände können und werden sich ändern. Damit ändern sich die Anforderungen an eine Softwarelösung und/oder die digitalen Technologien, welche vom Startup eingesetzt werden. Die Agilität eines Unternehmens hat im Tech DD Kontext zwei Dimensionen: Erstens die **technische Erweiterungsfähigkeit** und zweitens die **organisatorische Flexibilität**.

Um die **technische Erweiterungsfähigkeit** zu gewährleisten, muss die Architektur der Software- und Technologielösung modular sein (siehe auch Wartbarkeit). Im Idealfall können Teile der Software-Applikation ohne Ausfallrisiko jederzeit substituiert oder neue Module mühelos hinzugefügt werden. Wenn kleine Änderungen am Code eine Vielzahl von neuen Bugs und Fehlern verursachen, dann ist die technische Erweiterungsfähigkeit nicht oder nur ungenügend gewährleistet.

Die **organisatorische Flexibilität** bezieht sich vor allem auf die Entwicklungs- und Innovationsprozesse. Ein gutes Mass dafür sind zum Beispiel Release-Zyklen (Häufigkeit mit der neue Funktionalität veröffentlicht wird).  Viele Startups geben an, dass sie nach Lean Startup Ansätzen und mit agilen Methoden wie Scrum oder Kanban arbeiten. Damit sind sie zumindest theoretisch in der Lage, rasch auf Veränderungen zu reagieren. Doch in der Praxis findet man immer wieder auch Startups, welche diesbezüglich eher rigide sind oder die agilen Entwicklungsmethoden nicht effektiv anwenden. Mögliche Fragestellungen sind:



* Wie werden neue Features implementiert?
* Welche Team-Rollen und Verantwortlichkeiten werden gelebt?
* Wie ist Entwicklung und Operations organisiert (DevOps)?


## Wartbarkeit

Ein weiser Entwickler sagte mal “Software ist wie eine Pflanze”. Software wächst und muss gepflegt, respektive gewartet werden, sonst entsteht Wildwuchs und Unkraut. Wie die Software geschrieben, strukturiert und dokumentiert ist, ist massgebend für ihre Wartbarkeit. Eine Dimension von Wartbarkeit ist die technische Erweiterungsfähigkeit (siehe Agilität). Je länger die geplante Verwendungsdauer der Software ist und je weniger Experten für das Themengebiet verfügbar sind, desto wichtiger ist die Wartbarkeit. Folgende Fragen helfen die Wartbarkeit einer Softwarelösung zu beurteilen.



* Wie gut ist die Dokumentation, vor allem von Schnittstellen?
* Entsprechen die Schnittstellen etablierten Standards?
* Sind automatisierte Tests vorhanden (Unit- und Integrationstests)?
* Wurden Design-Prinzipien und etablierte Struktur-Patterns angewendet (z.B. Separation of Concerns)?
* Sind mehrere Entwickler in der Lage die Softwarelösung zu pflegen oder bestehen Abhängigkeiten von einzelnen Knowhow-Trägern?


## Resilienz

Resilienz bezeichnet die Fähigkeit von Softwarelösungen auf Störungen und Probleme, wie Ausfälle einzelner Komponenten, robust zu reagieren und für den Anwender weiterhin oder möglichst schnell wieder ein funktionierendes System zur Verfügung zu stellen. Ein resilientes System erreicht den Zustand des Totalausfalls theoretisch nie. Zu den Eigenschaften eines resilienten Systems zählen hohe Widerstandsfähigkeit, robuste Funktionsweise, schnelle Wiederherstellbarkeit der Datenbasis oder von Teilfunktionen. Beim Beurteilen der Resilienz helfen folgende Fragen:



* Sind Teilkomponenten der Softwarelösung redundant (z.B. mehrere Instanzen/Pods von einzelnen Micro Services)?
* Wird die Verfügbarkeit der Softwarelösung automatisch überwacht (Monitoring) und werden fehlerhafte oder abgestürzte Komponenten automatisch neu gestartet?
* Werden regelmässig und automatisiert Backups der Datenbasis erstellt?
* Können frühere Zustände der Applikation im Störungsfall leicht wieder hergestellt werden (z.B. Rollback-Deployments)?


## Fazit

Die sechs vorgestellten Dimensionen von Technical Due Diligence (Qualität, Skalierbarkeit, Sicherheit, Agilität, Wartbarkeit, Resilienz) erlauben die von einem Digital-Tech-Startup entwickelten oder eingesetzten Technologien zu Investitionszwecken ganzheitlich zu prüfen. Die Fragestellungen, welche für jede Dimension relevant sind, werden skizziert, sind aber nicht vollständig ausgeführt. Sie dienen aber als guter Startpunkt für eine Tech DD. Die sechs Dimensionen können natürlich auch zur Prüfung eines etablierten Unternehmens und dessen digitaler Technologie herangezogen werden, wobei da das Thema Legacy-Applikationen und Modernisierung zusätzlich Beachtung verdient.

## Quality

The quality assessment of a digital technology application or a software application can be divided into two areas: the **quality of the user interfaces** (UIs) and the **quality of the code**. 

The assessment of the **quality of the UIs** is not reliant upon specific software engineering expertise, but can be performed by anyone with an understanding of the customer needs and journey. The following questions help to assess the UI:

* How easy and intuitive is the application to use?
* How simple is the navigation and how intuitive are the functionalities?
* How contemporary and modern is the UI design?
* How does it feel to use the application?
* What happens if I use the application incorrectly?

**Code quality** assessment, on the other hand, requires deep IT expertise and experience in software engineering. Questions like the following should be answered.

* How efficient are the computing processes and algorithms? The more efficiently a computer program runs, the less processing power and memory it requires. Which leads to lower operating costs for servers and/or lower system requirements.
* How is error handling? Errors and bugs occur in software development as sure as day follows night. Errors can be caused, for example, by incorrect operation or edge cases that have not been taken into account. A good application can handle them without total failure. Errors should also always be logged in order to fix their cause in the future.
* Does the code meet best practices and state-of-the-art technology standards? Did the developers choose the right technology for their application problem and did they apply that technology correctly?

## Scalability

A startup does not have to build a software application from scratch that works for millions of users. It is much more important to have a modular and scalable architecture that s as the number of users grows without having to rebuild the application from scratch. In cloud applications, for example, we talk about horizontal scalability.

A startup does not have to build a software application from scratch that works for millions of users. It is much more important to design a modular and scalable architecture that is capable to expand as the number of users grows without having to rebuild the application from scratch. In cloud applications, for example, we talk about horizontal scalability.

The effort required for customer onboarding is another point that should be considered with regard to scalability. For example, does the application require complex manual installations and configurations (e.g., of servers or databases), which become a bottleneck as the number of customers grows? What can possibly be automated?

## Security

In line with a company's success, its visibility and thus the likelihood of hacker attacks increases. If a company loses the trust of its customers because it is unable to keep their data safe, this has a direct and very detrimental impact on the company's value. In the worst case, additional financial damage can occur if attackers succeed in sabotaging the company's ability to continue its operations (e.g., encryption of the database by ransomware).

Important security standards are neglected, especially in the case of startups that want to launch their product on the market as quickly as possible. The topic of security should therefore receive sufficient attention at the latest during the Tech DD. The following questions should at least be clarified:

* Which standard is used for authentication and is this standard applied correctly (e.g. OAuth 2.0, OpenID)?
* Are application secrets kept secure (e.g. database passwords or API keys)?
* Does the source code not contain any information worth protecting (in the case of open source projects) or is access restricted?
* How vulnerable is the software application to attacks (e.g. ransomware or DDoS attacks)?
* What third-party solutions and libraries are used and do they potentially have security vulnerabilities?

## Agility

Customer needs can and will change. Circumstances can and will change. Thus, the requirements for a software solution and/or the digital technologies used by the startup will change. The agility of a company has two dimensions in the Tech DD context: First, **technical extendability** and second, **organizational flexibility**.

To ensure **technical extendability**, the architecture of the software and technology solution must be modular (see also maintainability). Ideally, parts of the software application can be substituted at any time without risk of failure, or new parts can be added effortlessly. If small changes to the code cause a multitude of new bugs and errors, then technical extensibility is not or hardly guaranteed.

**Organizational flexibility** refers primarily to the development and innovation processes. A good measure of this is, for example, release cycles (frequency with which new functionality is released).  Many startups state that they work according to Lean Startup approaches and with agile methods such as Scrum or Kanban. This enables them to react quickly to changes, at least in theory. However, in practice, you can always find startups that are rather rigid in this regard or do not effectively apply the agile development methods. Possible questions are:

* How are new features implemented?
* Which team roles exist and how are responsibilities assigned?
* How is development and operations organized (DevOps)?

## Maintainability

There is this saying "Software is like a plant": Software grows and must be maintained, otherwise it will grow wild and weed. How the software is written, structured and documented is crucial for its maintainability. One dimension of maintainability is technical extensibility (see agility). The longer the planned lifetime of the software and the fewer experts are available for the subject area, the more important maintainability is. The following questions help to assess the maintainability of a software solution.

* How good is the documentation, especially of interfaces?
* Do the interfaces comply with a certain standard?
* Are automated tests available (unit and integration tests)?
* Have design principles and generally established structure patterns been applied (e.g. Separation of Concerns)?
* Are several developers able to maintain the software solution or lies all the know-how with one/few person(s)?

## Resilience

Resilience refers to the ability of software solutions to react robustly to disruptions and problems, such as failures of individual components, and to continue to provide a functioning system for the user or to do so as quickly as possible. A resilient system theoretically never reaches the state of total failure. The characteristics of a resilient system include high resistance, robust functionality, fast recoverability of the database or of partial functions. When assessing resilience, the following questions arise:

* Are subcomponents of the software solution redundant (e.g., multiple instances/pods of individual micro services)?
* Is the availability of the software solution automatically monitored and are faulty or crashed components automatically restarted?
* Is the database backed up regularly and automatically?
* Can previous states of the application be easily restored in the event of a failure (e.g. rollback deployments)?

## Conclusion

The six dimensions of technical due diligence presented (quality, scalability, security, agility, maintainability, resilience) allow the technologies developed or deployed by a digital tech startup to be examined holistically for investment purposes. The questions relevant to each dimension are outlined, but not fully elaborated. However, they serve as a good starting point for a tech DD. The six dimensions can, of course, also be used to examine an established company and its digital technology, whereby the topic of legacy applications and software modernisation deserves additional attention.

large_cta-tech-d-d-3.jpg

medium_cta-tech-d-d-3.jpg

small_cta-tech-d-d-3.jpg

thumbnail_cta-tech-d-d-3.jpg

cta-tech-d-d-3.jpg

Planen Sie in ein Technologieunternehmen zu investieren?

Got plans to invest in a tech company?

Für Investoren und Venture Capitalists (VCs) sind Digital-Tech-Startups sehr attraktiv, weil diese meist eine hohe Skalierbarkeit und damit einen hohen Return on Investment versprechen. Um das Risiko von Fehlinvestitionen zu minimieren, ist die systematische Prüfung der von einem Startup entwickelten oder eingesetzten Technologie vor einer allfälligen Investition unerlässlich. Die Prüfung, Validierung und Bewertung der von einem Unternehmen entwickelten oder eingesetzten Technologie zu Investitionszwecken beschreibt der Begriff Technical Due Diligence (Tech DD).

Digital tech startups are very attractive to investors and venture capitalists (VCs) because they usually promise high scalability and thus a high return on investment. To minimize the risk of bad investments, systematic evaluation of the technology developed or used by a startup is essential before any investment is made. The term Technical Due Diligence (Tech DD) describes the examination, validation and evaluation of the technology developed or used by a company for investment purposes.

large_technical-due-diligence.jpg

medium_technical-due-diligence.jpg

small_technical-due-diligence.jpg

thumbnail_technical-due-diligence.jpg

technical-due-diligence.jpg

Die sechs Kerndimensionen einer umfassenden Technical Due Diligence

The Six Core Dimensions of Comprehensive Technical Due Diligence

Heute bieten viele Softwareanbieter ihre Softwarelösungen entweder als reinen Software-as-a-Service (SaaS) an oder haben zumindest eine SaaS- oder Cloud-Option in ihrem Portfolio. Bei SaaS handelt es sich im Wesentlichen um ein Modell für die Softwarelizenzierung und -bereitstellung, bei dem der Anbieter nicht nur die Software, sondern auch die für den Betrieb notwendigen Rechenressourcen, d.h. den Computer, bereitstellt. Der Kunde kann die Software einfach nutzen und muss sich nicht um die Installation, den Betrieb oder eventuelle Updates kümmern. Zu den bekannten und erfolgreichen SaaS-Anbietern gehören Google, Salesforce, Dropbox, MailChimp, ZenDesk, Slack und Hubspot, die hoch skalierbare, weltweit laufende, cloudbasierte Anwendungen anbieten.


## Es gibt SaaS und es gibt erfolgreiches SaaS. Die Umsetzung macht den Unterschied.

Neben den grossen und bekannten SaaS-Anbietern gibt es eine Vielzahl von Anbietern, die ihre Produkte als SaaS- oder Cloud-Option anbieten, die aber nicht viel mit den cloud-nativen Anwendungen der bekannten SaaS-Anbieter gemein haben. Diese Anbieter bieten eine Softwarelösung an, die ursprünglich für den Betrieb auf einem On-Premises-Server oder auf dem Computer des Nutzers entwickelt wurde. Um sie in ein SaaS-Produkt zu verwandeln, packen die Anbieter ihre Softwarelösung für jeden SaaS-Kunden einfach auf einen Cloud-Server—meist eine virtuelle Maschine (VM)—oder auf einen Remote-Desktop-Rechner und nennen es SaaS.

Die meisten Software-Angebote, die als SaaS bezeichnet werden, erfüllen zwar die Definition von SaaS, nicht aber die Vorteile und das Wertversprechen von SaaS—weder für den Kunden noch für den Anbieter, oder nur in einem sehr begrenzten Umfang. Die Tatsache, dass eine Softwarelösung auf einem Cloud-Server und nicht auf einem On-Premises-Server oder PC läuft, macht eine SaaS-Lösung nicht erfolgreich. 



* Welche Vorteile und Nutzenversprechen kennzeichnen also eine erfolgreiche SaaS-Lösung? 
* Was sind die wichtigsten technischen Merkmale, die die Grundlagen einer erfolgreichen SaaS-Lösung bilden?

Wir haben die Antworten auf diese Fragen in einem Booklet zusammengefasst. Das Booklet erklärt die technischen Merkmale, die eine Softwarelösung haben sollte, um erfolgreiche als SaaS angeboten angeboten werden zu können—mit Vorteilen und Mehrwert für Kunde und Anbieter. Diese Merkmale können als Meilensteine betrachtet werden. Sie unterstützen Softwareanbieter mit Legacy-Software dabei, den Wandel zu einem erfolgreichen SaaS-Angebot gezielt und effektiv zu vollziehen.

<a class="btn btn-primary mt-2 mt-md-4 text-uppercase font-weight-bold font-size-sm hover-lift-light" href="https://forms.gle/4qtPfADeiKxrm2Gy5" target="_blank">Jetzt Booklet erhalten!</a>

Today, many software vendors offer their software solutions either as a pure Software-as-a-Service (SaaS) or at least have a SaaS or cloud option in their portfolio. SaaS is essentially a software licensing and delivery model where the vendor provides not only the software but also the necessary computing resources to run it—i.e. the computer. The customer can simply use the software and does not have to worry about installation, operation or any updates. Well-known, successful SaaS providers include Google, Salesforce, Dropbox, MailChimp, ZenDesk, Slack and Hubspot, which offer highly scalable, globally running, cloud native applications.


## There is SaaS and there is successful SaaS. The implementation makes the difference.

In addition to the large and well-known SaaS vendors, there are a large number of vendors that offer their products as a SaaS or cloud option, but the products do not have much in common with the cloud native applications of the well-known SaaS vendors. These other vendors offer a software solution that was originally designed to run on an on-premises server or on the user’s computer. To turn it into a SaaS product, the vendors simply pack their software solution for each SaaS customer on a cloud server—most often a virtual machine (VM)—or on a remote desktop machine and call it SaaS.

A large number of software offerings labeled as SaaS do not—while still meeting the definition of SaaS—realize the benefits and value proposition of SaaS, neither for the customer or the vendor, or only to a very limited extent. The fact that a software solution runs on a remote rather than an on-premises server or personal computer (PC) does not make a SaaS solution successful. 



* So what benefits and value propositions do characterize a successful SaaS solution? 
* And what are the main technical features that form the basics of a successful SaaS solution?

We wrote a booklet addressing these questions. The booklet explains the technical characteristics that a software solution should have in order to be offered as a successful SaaS solution—with benefits and added value for both customer and provider. These characteristics can be seen as milestones. They support software vendors with legacy software to make the transformation to a successful SaaS offering in a targeted and effective way.

<a class="btn btn-primary mt-2 mt-md-4 text-uppercase font-weight-bold font-size-sm hover-lift-light" href="https://forms.gle/4qtPfADeiKxrm2Gy5" target="_blank">Get Booklet now!</a>

Das Booklet erklärt die technischen Merkmale, die eine Softwarelösung haben sollte, um erfolgreiche als SaaS angeboten angeboten werden zu können—mit Vorteilen und Mehrwert für Kunde und Anbieter. Diese Merkmale können als Meilensteine betrachtet werden. Sie unterstützen Softwareanbieter mit Legacy-Software dabei, den Wandel zu einem erfolgreichen SaaS-Angebot gezielt und effektiv zu vollziehen.

The booklet explains the technical characteristics that a software solution should have in order to be offered as a successful SaaS solution—with benefits and added value for both customer and provider. These characteristics can be seen as milestones. They support software vendors with legacy software to make the transformation to a successful SaaS offering in a targeted and effective way.

large_cloud-saas.jpg

medium_cloud-saas.jpg

small_cloud-saas.jpg

thumbnail_cloud-saas.jpg

cloud-saas.jpg

Technische Meilensteine für eine erfolgreiche SaaS-Transformation – Ein Booklet

Technical Milestones for a Successful SaaS Transfor­mation – A Booklet

Bei komplexen Projekten mit einem hohen Grad an Unsicherheit—wie beispielsweise bei einem Softwareentwicklungsprojekt—helfen agile Ansätze und Methoden, das Risiko von Mehrkosten, Verzögerungen und Misserfolg zu minimieren. Agiles Vorgehen reduziert das Risiko in Projekten nach dem Grundsatz: 

> _“Liefere so früh wie möglich einen Mehrwert”_.

Konkret heisst das, dass alle Projektbeteiligten auf jene Aktivitäten fokussieren sollen, welche mit möglichst wenig Aufwand einen maximalen Mehrwert (Ertrag) bieten. 

Um den Schwerpunkt auf die richtigen Projektaktivitäten zu setzen, muss in einem agilen Projekt der Aufwand und der zu erwartende Mehrwert vor Beginn geschätzt werden. Den Aufwand (aber auch den Mehrwert) eines Projektes oder einer Aktivität zu schätzen, ist eine nicht triviale Aufgabe, erst recht, wenn eine absolute Schätzung (z.B. in Tagen/Stunden/Kosten) gefordert wird. Dies wird unter anderem dadurch veranschaulicht, dass ein Grossteil der Softwareentwicklungsprojekte (60-80%) den geplanten Aufwand oder Fristen überschreiten [2].

Mit einer quantifizierbaren und realistischen Schätzung für Aufwand und Ertrag lässt sich entscheiden, auf welche Projektaktivitäten fokussiert werden soll. Damit kann dem Grundsatz _“Liefere so früh wie möglich einen Mehrwert” _Folge geleistet werden. Aus den beiden Schätzungswerten lässt sich ein Aufwand-Ertrag-Verhältnis berechnen. Die Projektaktivitäten mit dem besten Ertrag-zu-Aufwand Verhältnis können somit priorisiert werden.


## Das Konzept der agilen Schätzung

Agile Estimation ist ein Ansatz, um quantifizierbare und realistische Schätzungen für Aufwand und Ertrag von Projektaktivitäten (z.B. das Entwickeln von einzelnen Produktfeatures einer Softwareapplikation) zu erhalten. Wir tun uns meist schwer damit, Dinge absolut zu schätzen. Das gilt nicht nur für Zeit und Geld, sondern auch für Dinge wie Gewicht oder Distanz. Vergleiche liegen uns hingegen viel mehr: Gegenstand A ist schwerer als Gegenstand B. Tätigkeit X dauert länger als Tätigkeit Y.

Agile Estimation basiert auf der Fähigkeit des Menschen, Dinge relativ—also vergleichend—zu schätzen. Projektaktivitäten werden in Form von User Stories festgehalten, welche die Anforderungen oder Projektziele aus Nutzersicht definieren. Die Nutzerperspektive hilft dabei, den Wert einer User Story für den Adressaten (z.B. einen Kunden oder Softwarenutzer) abzuschätzen. Der Aufwand und der Ertrag einer User Story wird dabei immer im Vergleich zu anderen User Stories geschätzt. 

Um daraus quantifizierbare Schätzungen abzuleiten, werden den geordneten User Stories Punkte zugeordnet: Value Points für den Wert und Story Points für den Ertrag. Die möglichen Punkte sind Zahlen aus der Fibonacci-Folge (1,2,3,5,8,13,...). Die Verwendung von Fibonacci-Zahlen hat sich für die relative Schätzung von User Stories als besonders sinnvoll erwiesen. Die nächsthöhere Fibonacci-Zahl ist jeweils ca. 60% grösser wie die Vorhergehende.

Das folgende Video erklärt im Detail wie Agile Estimation funktioniert.

In complex projects with a high degree of uncertainty—such as in a software development project—agile approaches and methods help to minimize the risk of additional costs, delays and failure. Agile approach reduces the risk in projects according to the principle: 

> _"Deliver value as early as possible"._

In concrete terms, this means that all project participants should focus on the activities that provide maximum added value (return) with the least possible effort. 

In order to focus on the right project activities, the effort and the expected return must be estimated in an agile project. Estimating the effort (but also the return) of a project or activity is a non-trivial task, even more so when an absolute estimate (e.g. in days/hours/costs) is required. This is illustrated by the fact that a large part of software development projects (60-80%) exceed the planned effort or deadlines [2].

With a quantifiable and realistic estimate for effort and return, it is possible to decide on which project activities to focus. Thus, the principle "deliver value as early as possible" can be followed. A return-to-effort ratio can be calculated from the two estimates. The project activities with the best return-to-effort ratio (bang for the buck) can thus be prioritized.


## The concept of agile estimation

Agile Estimation is an approach to obtain quantifiable and realistic estimates for the effort and the return of project activities (e.g., developing individual product features of a software application). As human beings we are not very good at estimating things in absolute terms. This is true not only for time and money but also for things like weight or distance. What we are better at is comparing: Object A is heavier than object B. Activity X takes longer than activity Y.

Agile Estimation is based on the ability of humans to estimate things relatively - i.e. comparatively. Project activities are recorded in the form of user stories. User stories define requirements or project goals from the user's perspective. The user perspective helps to estimate the value of a user story for the addressee (e.g. a customer or software user). The effort and return of a user story is always estimated in comparison to other user stories. 

To make quantifiable estimates out of this, estimation points are assigned to the ordered User Stories: Value Points for the value and Story Points for the effort. The possible points are numbers from the Fibonacci sequence (1,2,3,5,8,13,...). Using Fibonacci numbers has proven to be particularly useful for relative estimation of user stories. The next larger Fibonacci number is about 60% larger than the previous one.

The following video explains in detail how Agile Estimation works.

## Agile Estimation in der Praxis: Estimation Poker

Um die Zuverlässigkeit der Schätzungen in der Praxis zu erhöhen, werden die User Stories in sogenannten Refinement-Meetings geschätzt. Jedes Teammitglied gibt dabei eine unabhängige Schätzung ab. Weichen die Schätzungen voneinander ab, wird solange diskutiert, bis sich das Team einig ist.

Business-Teams schätzen den Wert (Value Points), während die Implementierungs- oder Entwicklerteams den Aufwand schätzen (Story Points). Gemeinsam wird dann das  Ertrag-zu-Aufwand Verhältnis berechnet und über die Priorisierung verhandelt. Manchmal bestimmen auch Randbedingungen über die finale Priorisierung. Bei einem Haus beispielsweise muss zuerst das Fundament gebaut werden, bevor mit dem Mauerwerk begonnen werden kann.

Um die Unabhängigkeit der Schätzungen zu gewährleisten, spielt das Projekt- oder Entwicklungsteam Agile Estimation Poker. Estimation Poker ist eine agile Method, welche auch als "Planning Poker" oder "Scrum Poker" bekannt ist. Jedes Teammitglied erhält ein Spielkarten-Set mit Fibonacci-Zahlen. Auf Kommando zeigen alle Teammitglieder gleichzeitig die jeweilige Karte mit dem geschätzten Wert. Mit diesem Vorgehen bleibt die eigene Meinung unbeeinflusst von den Einschätzungen der Kollegen.

## Agile Estimation in practice: Estimation Poker

To increase the reliability of the estimates in practice, the user stories are estimated in so-called refinement meetings. Each team member provides an independent estimate. If the estimates differ, they are discussed until the team agrees.

Business teams estimate the value (Value Points) while the implementation or development teams estimate the effort (Story Points). Together, the revenue-to-effort ratio is then calculated and prioritization is negotiated. Sometimes, constraints also determine the final prioritization. For a house, for example, the foundation must be built first before the masonry can be started.

To ensure independence of estimates, the project or development team plays Agile Estimation Poker. Estimation Poker is an agile technique, which is also known as "Planning Poker" or "Scrum Poker". Each team member is given a set of playing cards with Fibonacci numbers. On command, all team members simultaneously show the respective card with the estimated value. Thus, the estimates of the colleagues do not influence one’s opinion.

estimation-poker-cards.png

Das Estimation-Poker-Kartenset hat auch zwei Sonderkarten: Split und Unknown. Die Split-Karte signalisiert, dass der Schätzer die User Story als zu gross empfindet und eine Aufteilung in zwei kleinere User Stories empfiehlt. Die Unknown-Karte signalisiert, dass sich ein Teammitglied nicht in der Lage befindet, eine zuverlässige Schätzung abzugeben—z.B. weil die User Story ausserhalb des Kompetenzbereichs liegt.


## Fazit

Agile Estimation mittels Estimation Poker ist ein praxisbewährter Ansatz, um quantifizierbare und realistische Schätzungen für Aufwand und Ertrag von Projektaktivitäten in einem Agile Projekt vorzunehmen. Nur zuverlässige Schätzungen erlauben es, Projektaktivitäten so zu priorisieren, dass dem Grundsatz *“Liefere so früh wie möglich einen Mehrwert”* konsequent gefolgt werden kann. Damit werden die Erfolgsaussichten erhöht und das Projektrisiko minimiert.


#### Quellen und weiterführende Literatur

1. <a target="_blank" href="https://youtu.be/vRne1NiCIHQ">Introduction To Agile</a>
2. <a target="_blank" href="https://ieeexplore.ieee.org/document/1237981">A review of software surveys on software effort estimation</a>

The Estimation Poker deck also has two special cards: Split and Unknown. The Split card signals that the estimator feels the user story is too big and recommends splitting it into two smaller user stories. The Unknown card signals that a team member is not in a position to provide a reliable estimate—e.g. because the user story is outside the area of competence.


## Conclusion

Agile Estimation using Estimation Poker is a proven approach to obtain quantifiable and realistic estimates for effort and output of project activities in an Agile project. Only reliable estimates allow us to prioritize project activities in a way that the principle *"deliver value as early as possible"* can be followed consistently. This increases the chances of success and diminishes the project risk.


#### Sources and further reading

1. <a target="_blank" href="https://youtu.be/vRne1NiCIHQ">Introduction To Agile</a>
2. <a target="_blank" href="https://ieeexplore.ieee.org/document/1237981">A review of software surveys on software effort estimation</a>

Agile Estimation ist ein Ansatz, um quantifizierbare und realistische Schätzungen für den Aufwand und den Ertrag von Projektaktivitäten zu erhalten. Diese Schätzungen zusammen mit dem Grundsatz "so früh wie möglich Mehrwert liefern" ermöglichen es, das Risiko von Misserfolg bei komplexen Projekten mit einem hohen Mass an Unsicherheit zu minimieren.

Agile Estimation is an approach to obtain quantifiable and realistic estimates for the effort and the return of project activities. These estimates together with the principle of "deliver value as early as possible" allow to minimize the risk of failure in complex projects with a high degree of uncertainty.

large_agile-estimation-poker.jpg

medium_agile-estimation-poker.jpg

small_agile-estimation-poker.jpg

thumbnail_agile-estimation-poker.jpg

agile-estimation-poker.jpg

Agile Estimation: Aufwand und Ertrag quantifizierbar und realistisch abschätzen

Agile Estimation: Quantifiable and Realistic Estimates of Effort and Return

Traditionell veröffentlichen softwareentwickelnde Organisationen neue Anwendungsfunktionen in Zyklen. Abhängig von der Anwendung und dem organisatorischen Aufbau dauern solche Release-Zyklen zwischen 2 Wochen und 6 Monaten. Somit wird neue Software zwischen 2 und 26 Mal pro Jahr veröffentlicht. 

In der Theorie sieht ein typischer Software-Releasezyklus wie folgt aus:

1. **Code schreiben** - ein Team von Entwicklern arbeitet an verschiedenen Anwendungsmerkmalen. Sie fügen vorhandenen Code hinzu und ändern ihn.
2. **Code integrieren** - alle Codeänderungen werden in eine bestehende Codebasis integriert.
3. **Stage code** - eine modifizierte Codebasis wird manuell in einer Art Staging-Umgebung bereitgestellt (z.B. in einer virtuellen Maschine über ssh).
4. **Code testen** - ein Qualitätssicherungsteam (QA) testet die neue Version auf Fehler und genehmigt Änderungen.
5. **Code verteilen** - nach Genehmigung durch die QS wird der Code an ein Betriebsteam übergeben und manuell in einer Produktionsumgebung (z.B. auf einer virtuellen Maschine über ssh) verteilt.
6. **Genießen Sie den Code** - die Benutzer können jetzt die neuen Anwendungsfunktionen nutzen, und alle sind zufrieden!

Was ist also das Problem mit dieser Praxis?

## Erwarten Sie das Unerwartete - Fehler verlangsamen den Software-Release-Prozess 

- Die **Code-Änderung** kann **fehlerhaft** sein, ohne dass die Entwickler es merken.
- Die **Integration** von Code-Änderungen **bricht die bestehende Code-Basis**, ohne dass die Entwickler/Integratoren dies merken. 
- Der neue Code ist **nicht richtig** in der Staging-Umgebung installiert oder funktioniert nicht auf die gleiche Weise wie auf dem Rechner des Entwicklers, aber die Person, die die Staging-Umgebung einrichtet, bemerkt es nicht.
- Im Allgemeinen ist das manuelle Einrichten einer produktionsähnlichen Umgebung oder die **Einführung von Code in die Produktion zeitaufwändig**. Daher werden für Entwicklung und Staging oft vereinfachte Umgebungen und Bereitstellungen verwendet. Mit dieser Einschränkung ist eine **vollständige Qualitätsbewertung** der Code-Änderungen unter produktiven Bedingungen **nicht vor dem Release** durchführbar.
- Das QA-Team **findet die Fehler, aber mit einer beträchtlichen Verzögerung** und ohne eine Ahnung, wo die Ursache in den vorherigen Entwicklungsschritten der verschiedenen Entwickler zu suchen ist. Infolgedessen erfordert die Behebung der Fehler ein **unendliches Hin und Her** zwischen QS, Betrieb und Entwicklern.
- Einige der **Fehler rutschen in die Produktion** oder es werden neue Fehler bei der Bereitstellung der Produktionsumgebung oder bei der Installation des neuen Codes gemacht. Dies kann zu Produktionszwischenfällen und **Anwendungsausfallzeiten** führen. Zeitaufwändige, manuelle Rollbacks sind die Folge.

Was also in der Theorie einfach aussieht, ist in der Praxis ein zeitraubender, nicht-linearer Prozess. Benutzer müssen lange auf neue Anwendungsfunktionen warten und können die Anwendung nicht ohne Unterbrechungen genießen. Das Auftreten menschlicher Fehler verlangsamt den Freigabeprozess von Software. Leider sind diese menschlichen Fehler unvermeidlich. Deshalb verbringen Entwickler und Software-Ingenieure nur zwischen 25-35% ihrer Zeit mit dem Schreiben von neuem Code und etwa 50% ihrer Zeit mit der Behebung von Fehlern. 

## Fehlerbehebung - eine Aktivität, die Ressourcen verbraucht, aber keinen Wert produziert

Nach den Konzepten der Lean-Management-Philosophie ist die Behebung von Fehlern (Defekten) eine von sieben Arten von Verschwendung, d.h. Muda - das japanische Wort für jede menschliche Tätigkeit, die Ressourcen verbraucht, aber keinen Wert erzeugt. 50 % der Zeit für die Fehlerbehebung aufzuwenden, bedeutet im Grunde, dass 50 % des Geldes, das Sie für Ihre Entwicklungsressourcen aufwenden, verschwendet werden.

Traditionally, software developing organizations release new application features in cycles. Depending on the application and the organizational setup such release cycles take between 2 weeks and 6 months. Thus, new software is released between 2 and 26 times a year. 

In theory, a typical software release cycle looks like this:

1. **Write code** – a team of developers works on different application features. They add and change existing code.
2. **Integrate code** – all the code changes are integrated into an existing code base.
3. **Stage code** – a modified code base is manually deployed to some sort of staging environment (e.g. to a virtual machine over ssh).
4. **Test code** – a quality assurance (QA) team tests the new release for errors and approves changes.
5. **Deploy code** – after approval by QA, the code is handed over to an operations team and manually deployed to a production environment (e.g. to a virtual machine over ssh).
6. **Enjoy code** – users can now use the new application features and everyone is happy!

So, what is the problem with this practice?

## Expect the Unexpected - Errors Slow Down the Software Release Process 

- The **code** change **can be faulty** without the developers noticing it.
- The **integration** of code changes **breaks the existing code base** without the developers/integrators being aware of this. 
- The new code is **not installed properly** in the staging environment or does not work in the same way as on the developers machine, but the person setting up the staging environment does not notice.
- In general, manually setting up a production-like environment or **deploying code to production is time consuming**. Therefore, simplified environments and deployments are often used for development and staging. With this limitation, a **complete quality assessment** of the code changes under productive conditions **is not feasible before before the release**.
- The QA team **finds the errors but with a considerable delay** and without any idea of where to look for the root cause in the previous development steps of different developers. As a result, fixing the bugs requires **endless back and forth** between QA, operations and developers.
- Some of the **errors slip into production** or new errors are made while provisioning the production environment or installing the new code. This may cause production incidents and **application downtime**. Time-consuming, manual rollbacks ensue.

So, what looks straightforward in theory is a time-consuming, non-linear process in practice. Users have to wait a long time for new application features and can not enjoy the application without interruptions. The occurrence of human errors slows down the release process for software. Unfortunately, these human errors are inevitable. That is why developers and software engineers spend only between 25-35% of their time writing new code and about 50% of their time fixing bugs. 

## Fixing Bugs - An Activity That Consumes Resources But Produces no Value

According to the concepts of the Lean Management philosophy, fixing bugs (defects) is one of seven types of waste, i.e. Muda—the Japanese word for any human activity that consumes resources but produces no value. Spending 50% of the time for bug fixing basically means that 50% of the money you spend for your development resources is wasted.

wasting-money.gif

In der Schweiz kostet ein Vollzeitäquivalent (VZÄ) einer erfahrenen, hoch qualifizierten Entwicklungsressource Ihre Organisation bei einer Berechnung der Gesamtbetriebskosten etwa 240.000 CHF pro Jahr. Die Hälfte davon - 120.000 CHF pro Entwickler, der an Ihren Projekten arbeitet - ist verschwendetes Geld.

Was können Sie also tun, um die Verschwendung dieses Geldes zu stoppen und Ihre Software-Entwicklung effizienter zu gestalten - insbesondere dann, wenn menschliches Versagen ein integraler Bestandteil der Entwicklung und daher unvermeidlich ist?

## CI/CD-Pipelines - Drei Strategien zur Verschwendung von weniger Entwicklungsressourcen

Drei Strategien helfen, menschliche Fehler zu vermeiden und den Zeitaufwand für deren Behebung zu reduzieren.

1. **Automation** - ersetzen repetitive manuelle Aufgaben und integrieren, liefern und verteilen Codeänderungen kontinuierlich und automatisch.
2. **Frühe Fehlererkennung** - Fehler und ihre Grundursachen automatisch und so früh wie möglich in der Wertschöpfungskette der Entwicklung erkennen.
3. **Easy recovery** - ermöglichen ein schnelles Zurücksetzen auf eine stabile Code-Version, falls etwas die produktive Anwendung stört.

Pipelines für automatische, kontinuierliche Integration, kontinuierliche Bereitstellung und kontinuierliches Deployment (CI/CD) ermöglichen die Umsetzung dieser drei Strategien. Sie helfen Ihnen bei der Entwicklung robuster und qualitativ hochwertiger Software-Anwendungen. Sie können wertvolle Zeit und Geld sparen, das Sie für die Codeintegration, -bereitstellung und -verteilung oder für die Fehlerbehebung ausgegeben hätten. Sie können Ihren Benutzern neue Anwendungsfunktionen schnell und effizient zur Verfügung stellen. So können Sie schneller auf sich ändernde Benutzeranforderungen reagieren und die Zeit bis zur Markteinführung Ihrer Anwendung verkürzen. Und für den Fall, dass etwas schief geht, kann ein Rollback zu einer früheren Anwendungsversion mit nur einem Klick durchgeführt werden.

Eine richtig aufgebaute CI/CD-Pipeline reduziert den Muda der Software-Entwicklung. Im Idealfall können Ihre Entwickler bis zu 50% ihrer Zeit freisetzen, und Sie können bis zu CHF 120K pro Entwickler und Jahr sparen. Eine gute CI/CD-Pipeline ermöglicht es Ihnen, robuste Software nicht in Zyklen von 2 Wochen bis 6 Monaten, sondern mehrmals täglich zu veröffentlichen.

Wenn Sie mehr über CI/CD-Pipelines erfahren möchten, zögern Sie nicht, mit uns zu sprechen. Bei EBMRIO.tech unterstützen wir Unternehmen bei der Einrichtung automatisierter CI/CD-Pipelines für schnellere und bessere digitale Innovationen. Profitieren Sie von unseren Kompetenzen im DevOps-Engineering. So können Ihre Software-Tools und -Produkte schnell an sich ändernde Marktbedingungen und sich entwickelnde Benutzerbedürfnisse angepasst werden.

In Switzerland, a full time equivalent (FTE) of an experienced, highly skilled development resource costs your organization roughly CHF 240K a year—using a total cost of ownership calculation. Half of that—CHF 120K per developer working on your projects—is wasted money.

So, what can you do to stop wasting this money and make your software development become more efficient—especially, when human error is an integral part of development and therefore inevitable?

## CI/CD Pipelines - Three Strategies for Wasting Less Development Resources

Three strategies help to avoid human errors and reduce the amount of time spent on fixing them.

1. **Automation** – substitute repetitive manual tasks and integrate, deliver and deploy code changes continuously and automatically.
2. **Early error detection** – detect errors and their root causes automatically and as early as possible in the development value chain.
3. **Easy recovery** – enable a quick reset to a stable code version in case something breaks the productive application.

Automatic, continuous integration, continuous delivery and continuous deployment (CI/CD) pipelines allow you to put these three strategies into action. They help you develop robust and high quality software applications. You can save valuable time and money you would have spent for code integration, delivery and deployment or for bug fixing. You can deliver new application features fast and efficiently to your users. Thus, you can react quicker to changing user needs and reduce the time-to-market for your application. And in case something goes wrong, a rollback to a previous application version can be done with just a click.

A properly set up CI/CD pipeline reduces the Muda of software development. Ideally, your developers can free up 50% of their time and you can save up to CHF 120K per developer and year. A good CI/CD pipeline allows you to release robust software not in cycles, ranging from 2 weeks to 6 months, but multiple times a day.

If you want to learn more about CI/CD pipelines, feel free to talk to us. At EBMRIO.tech we support companies in setting up automated CI/CD pipelines for faster and better digital innovations. Benefit from our competencies in DevOps engineering. So your software tools and products can adapt quickly to changing market conditions and evolving user needs.

In der Software-Entwicklung können Sie mit automatisierten CI/CD-Pipelines bis zu CHF 120K pro Entwickler und Jahr sparen, indem Sie den Zeitaufwand für die Behebung von Fehlern reduzieren.

In software development, automated CI/CD pipelines allow you to save up to CHF 120K per developer and year by reducing the amount of time spent for fixing bugs.

large_ci-cd-infinite.jpg

medium_ci-cd-infinite.jpg

small_ci-cd-infinite.jpg

thumbnail_ci-cd-infinite.jpg

ci-cd-infinite.jpg

Sparen Sie bis zu CHF 120K pro Entwickler und Jahr mit einer CI/CD-Pipeline - ein Business Case

Save up to CHF 120K per Developer and Year With a CI/CD Pipeline – a Business Case

Das Management von Innovationsprojekten ist eine Herausforderung. Sie zeichnen sich meist durch eine unklare Kapitalrendite (ROI) aus, und ihre wichtigsten Entwicklungsanforderungen sind oft ungewiss, vor allem in frühen Phasen. Wenn neue Technologien ins Visier genommen werden, fügen diese dem Projekt eine weitere Ebene der Komplexität hinzu. Wenn es um Entscheidungen über Innovationen geht, sind historische oder vergleichbare ROI-Daten in den meisten Fällen nicht verfügbar; und unter solchen Ungewissheitsbedingungen können Führungskräfte sehr unangenehm werden. Infolgedessen scheinen Zögern und Zweifel gemeinsame Gefühle zu sein, die von den Innovationsgremien geteilt werden; manchmal in dem Maße, dass kritische Entscheidungen ständig zurückgeschoben werden, bis sich das Fenster der Gelegenheit schließlich schließt.

> HÖREN SIE AUF ZU WARTEN, FANGEN SIE AN ZU HANDELN!

Eine führende Methode zur Vermeidung dieser Stasis-Mechanismen findet sich in agilen und iterativen Ansätzen. Durch Agilität werden Lösungskonzepte auf das Wesentliche vereinfacht und inkrementell unter möglichst produktionsnahen Bedingungen getestet. Ein agiler Ansatz reduziert die Vorab-Investitionen und erzielt gleichzeitig wertvolle Einsichten in die technische Machbarkeit und den damit verbundenen Business Case einer innovativen Idee; dadurch wird diese risikofrei. Besondere Aufmerksamkeit ist bei der Planung der ersten Iterationen eines agilen Projekts erforderlich. Drei Fragen sind besonders wichtig und verdienen die Aufmerksamkeit der Manager: 

* Warum machen wir das Projekt?
* Was wird erreicht werden?
* Wie wird das Pilotprojekt durchgeführt?

Die Antworten auf diese Fragen sind in der Anfangsphase eines Innovationsprojekts von entscheidender Bedeutung und sollten in einem lebenden Dokument festgehalten werden. Um dies zu erreichen, haben wir eine spezielle Leinwand für Innovationsprojekte entwickelt.

Innovation projects are challenging to manage. They are mostly characterized by an unclear return on investment (ROI), and their key development requirements are often uncertain, especially at early stages. If new technologies are targeted, these also add a further layer of complexity to the project. When approaching decisions on innovation, historical or comparable ROI data are in most cases not available; and under such uncertainty conditions, executives can become very uncomfortable. As a result, hesitation and doubt seem to be common feelings shared by innovation governance boards; sometimes to the extent that critical decisions are constantly pushed back until the window of opportunity finally closes.

> STOP WAITING, START ACTING!

One leading method to avoid these stasis mechanisms is found in agile and iterative approaches. Through agility, solution concepts are simplified to the essence and incrementally tested under conditions that are as close as possible to production. An agile approach reduces the upfront investment and at the same time achieves valuable insights into the technical feasibility and the related business case of an innovative idea; therefore de-risking it. Special attention is required when planning the first iterations of an agile project. Three questions are particularly important and deserve the attention of managers: 

* Why are we doing the project?
* What will be achieved?
* How is the is the pilot conducted?

The answers to these questions are vital in the initial phase of an innovation project, and should be tracked in a living document. To achieve this we developed a dedicated innovation project canvas.

innovation-project-canvas_v1.0_web.png

<a class='btn btn-primary' style='color: white; text-align: center;' href="/downloads/canvas">CANVAS HERUNTERLADEN</a>

### Wie man die Leinwand des Innovationsprojekts verwendet
Die Leinwand bietet einen vollständigen Überblick über die ersten Schritte eines Innovationsprojekts und dient als Diskussionsgrundlage, indem sie die kritischen Informationen auf einer Seite zusammenfasst. Die Leinwand sollte gefüllt werden, indem jeweils eine Spalte nach der anderen adressiert, also beschrieben wird:

1. Die Projektvision
2. Die Erfolgskriterien für die nächste geplante Iteration
3. Der Projektauftrag

#### Schritt 1: Projektvision
Die Projektvision besteht aus einer Bewertung der aktuellen Situation, der Identifizierung der Zielnutzer für Ihre Innovationsbemühungen und einer genauen Ermittlung ihrer Bedürfnisse. Innovation ist einfacher, wenn sie auf reale Bedürfnisse oder Schmerzpunkte von klar definierten Zielnutzern eingeht. In diesem Schritt geht es darum, die aktuelle Situation zu verstehen und Empathie für die Nutzer als Grundlage für die Entwicklung wünschenswerter Lösungen aufzubauen.

#### Schritt 2: Erfolgskriterien
Der Umfang der Leistungen und Ziele sollte auf das Wesentliche reduziert werden. Die Reduzierung der Komplexität ist von äußerster Wichtigkeit, um das Innovationsprojekt handhabbar zu machen, insbesondere zu Beginn. Ein gutes Gedankenexperiment, um eine solche Vereinfachung zu erreichen, besteht darin, so zu tun, als hätte man eine begrenzte Menge an Ressourcen von 2 Vollzeitmitarbeitern, die 2 Wochen lang an dem Projekt arbeiten, um eine erste Iteration des Produkts abzuschließen. Die Ergebnisse sollten so definiert werden, dass am Ende eines hypothetischen zweiwöchigen Sprints eine ausgearbeitete Arbeitslösung zur Verfügung steht, die mit potenziellen Kunden getestet werden kann. Besonderes Augenmerk muss in dieser Phase auf die Lernziele oder besser auf die Definition der wichtigen Hypothesen gerichtet werden, die bestätigt, getestet oder entmystifiziert werden sollten, um die Durchführbarkeit des zu entwickelnden Systems aus technischer, geschäftlicher und auch Usability-Perspektive zu gewährleisten.

#### Schritt 3: Projektressourcen
Als letzter Schritt ist es nun an der Zeit, dem Projekt ein Team zuzuweisen und die Schlüsselaktivitäten zu definieren, damit die Iteration beginnen kann. In dieser Phase können Sie tatsächlich eine Lückenanalyse zwischen der Projektvision und den Erfolgskriterien durchführen und so die beiden Situationen überbrücken und Ressourcen binden. Die Leinwand verlangt auch, dass Sie eine explizite Entscheidung bezüglich der Projekt-Kompromisse treffen. Insbesondere ist es notwendig, zwei Elemente aus Umfang, Qualität und Zeit als nicht verhandelbar zu wählen und mindestens eines davon offen zu lassen. Diese Wahl ist wichtig, um die Projektprioritäten zu klären und sich daher darauf zu einigen, über welche Elemente im Falle von Druck spekuliert werden soll. 

Als einfaches Hilfsmittel bietet Ihnen die Innovationsprojekt-Leinwand einen Überblick über die wichtigsten Aspekte Ihrer agilen Innovationsprojekte. Bei EMBRIO setzen wir sie erfolgreich zur Planung der meisten unserer Kunden- und internen Aktivitäten ein. Wir hoffen, dass es auch für Sie hilfreich sein kann, um Ihr Streben nach Innovation zu beschleunigen. Zögern Sie nicht, sich mit uns in Verbindung zu setzen, wenn Sie mehr darüber erfahren möchten.

<a class='btn btn-primary' style='color: white; text-align: center;' href="/downloads/canvas">DOWNLOAD THE CANVAS</a>

### How to Use The Innovation Project Canvas
The canvas provides a complete overview on the first steps of an innovation project, and serves as a basis for discussion, summarizing the critical information on one page. The canvas should be filled by addressing one column at a time, therefore describing:

1. The project vision
2. The success criteria for the next planned iteration
3. The project mission

#### Step 1: Project Vision
The project vision is made of an assessment of the current situation, the identification of the target users for your innovation efforts, and a precise identification of their needs. Innovation is easier when it addresses real needs or pain points of clear defined target users. In this step it is all about understanding the current situation and build up empathy for the users as a basis for the development of desirable solutions.

#### Step 2: Success criteria
The scope of deliverables and objectives should be reduced to the essence. Reducing complexity is of uttermost importance to make innovation project manageable, especially at the very beginning. A good thought experiment to achieve such a simplification is to pretend to have a limited amount of resources of 2 full time employees working on the project for 2 weeks to complete a first iteration of the product. The deliverables should be defined so that at the end of a hypothetical 2-weeks sprint, a srtipped-out working solution is available to be tested with potential customers. Particular attention in this phase is must be directed to the learning objectives, or better to the definition of the important hypotheses that should be confirmed, tested, or demystified to ensure the feasibility of the system being developed, from a technical, business and also usability perspective.

#### Step 3: Project Resources
As a last step, it is now time assign a team to the project, and define the key activities so that the iteration can start. At this stage you can actually perform a gap analysis between the project vision and the success criteria, therefore bridging the two situations and committing resources. The canvas also demands you to make an explicit choice regarding the project trade-offs. In particular, it is necessary to choose two elements among scope, quality and time as non negotiable, and leave at least one of them loose. This choice is important to clarify the project priorities and therefore, agree on which elements to speculate in case of pressure. 

As a simple tool, the innovation project canvas provides you an overview on the most important aspects of your agile innovation projects. At EMBRIO we successfully use it to plan most of our customer and internal activities. We hope it can be helpful for you as well to accelerate your quest to innovation. Do not hesitate to get in touch with us if you want to know more about it.

Als einfaches Hilfsmittel ist die Innovationsprojekt Canvas ein lebendes Dokument, das Ihnen einen Überblick über die wichtigsten Aspekte Ihrer agilen Innovationsprojekte bietet.

As a simple tool, the innovation project canvas is a living document providing you an overview on the most important aspects of your agile innovation projects.

large_sparking-idea.jpg

medium_sparking-idea.jpg

small_sparking-idea.jpg

thumbnail_sparking-idea.jpg

sparking-idea.jpg

Wie Sie Ihre nächste Innovations-Iteration auf nur einer Seite planen

How to Plan Your Next Innovation Iteration on Just One Page

Begriffe wie Industrial Internet of Things (IIoT), Digitalisierung, Industrie 4.0, Künstliche Intelligenz und Big Data sind in der Industrie allgegenwärtig und für viele Industrieunternehmen von strategischer Relevanz. Das Themenfeld ist umfangreich und umfasst eine Vielzahl technologischer und wirtschaftlicher Teilthemen. Der Begriff Internet of Things (IoT) zum Beispiel, was verbirgt sich dahinter? Handelt es sich um einen Trend, eine Plattformtechnologie, einen intelligenten und vernetzten Sensor, eine Geschäftsmodellinnovation, ein wissenschaftliches Paradigma oder gar eine industrielle Revolution? Und wie grenzt sich dieser Begriff von anderen Begriffen wie Digitalisierung oder Industrie 4.0 ab bzw. wie verhält er sich zu diesen?

Unabhängig von der Diskussion über die genaue Bedeutung der einzelnen Begriffe erkennen Industrieunternehmen die Wichtigkeit des Themas an und engagieren sich häufig durch die Initiierung und Durchführung von Projekten zur digitalen Transformation. Doch aufgrund der Unschärfe des Themas fällt es vielen Organisationen schwer, konkrete Projekte und Anwendungen zu erfassen und zu definieren, die ihre Produkte, Dienstleistungen oder Prozesse wertschöpfend digitalisieren würden. Projekte werden schnell groß, komplex und voller unbekannter Variablen.

Um Projekte überschaubar zu halten, ist ein gängiger Ansatz in der industriellen Praxis, mit etwas Einfachem und Überschaubarem zu beginnen, wie z.B. der Integration eines zusätzlichen Sensors in ein bestehendes Produkt oder dem Sammeln leicht verfügbarer Daten. Wichtige Überlegungen, wie man auf Sensordaten zugreift oder wie man die Daten auswertet und nutzt, werden typischerweise auf einen späteren, unbestimmten Zeitpunkt verschoben. Dieser Ansatz beschäftigt zwar die Entwickler, führt aber nicht zu einem wertvollen Projektergebnis, weil die Schlüsselelemente einer erfolgreichen und wertschöpfenden IoT-Anwendung fehlen.

### Drei Schlüsselelemente einer erfolgreichen industriellen IoT-Anwendung

Wenn Sie wollen, dass Ihre digitalen Transformationsprojekte greifbare Ergebnisse liefern, müssen Sie sicherstellen, dass Sie alle Schlüsselelemente einer erfolgreichen und wertschöpfenden IIoT-Anwendung von Beginn der Entwicklung an abdecken. Was ist denn nun eine erfolgreiche und wertschöpfende IIoT-Anwendung?

> Eine erfolgreiche und wertschöpfende Industrial-Internet-of-Things-Anwendung löst automatisch Aktionen oder Entscheidungen aus, die auf aussagekräftigen Informationen über physische Objekte und deren Umgebung basieren, die durch Datenerfassungs-, -übertragungs- und -auswertungstechnologie generiert werden.

Basierend auf dieser einfachen Definition kann eine IIoT-Anwendung oder jede IoT-Anwendung im Allgemeinen durch einen Rahmen beschrieben werden, der aus drei Schlüsselelementen besteht:

1. *Ein oder mehrere physische Objekte*
1. *Eine Datenverarbeitungskette*
1. *Ein klarer Mehrwert*

Darüber hinaus kann das zweite Schlüsselelement *Datenverarbeitungskette* in die drei Unterelemente *Datenerfassung*, *Datenübertragung* und *Datenauswertung* unterteilt werden. Dieser konzeptionelle Rahmen ermöglicht die Erfassung und Beschreibung von IoT-Anwendungen und stellt sicher, dass Sie die Entwicklung ganzheitlich angehen.

Terms like the Industrial Internet of Things (IIoT), Digitalization, Industry 4.0, Artificial Intelligence, and Big Data are omnipresent in the industry and of strategic relevance for many industrial organizations. The subject area is extensive and covers a wide range of technological and economical subtopics. The term Internet of Things (IoT) for example, what does it represent? Is it related to a trend, a platform technology, a smart and connected sensor, a business model innovation, a scientific paradigm, or even an industrial revolution? Moreover, how does this term differentiate from or relate to other terms like Digitalization or Industry 4.0?

Regardless of the discussion on the exact meaning of each of the terms industrial organizations acknowledge the importance of the topic and often engage by initializing and conducting digital transformation projects. But because of the fuzziness of the topic, many organizations are having a hard time to capture and define tangible projects and applications which would digitize their products, services or processes in a value-adding manner. Projects quickly become large, complex, and full of unknown variables.

In order to keep projects manageable a common approach in industrial practice is to start with something simple and straightforward like integrating an additional sensors into an existing product or collecting readily available data. Important considerations on how to access sensor data or how to evaluate and use the data are typically postponed to a later, indefinite point in time. Although this approach occupies the developers, it does not lead to a valuable project outcome because the key elements of a successful and value-adding IoT application are missing.

### Three key elements of a successful industrial IoT application

If you want your digital transformation projects to deliver tangible results you have to make sure you cover all key elements of a successful and value-adding IIoT application from the very beginning of development. So, what is a successful and value-adding IIoT application then?

> A successful and value-adding Industrial Internet of Things application automatically triggers actions or decisions based on meaningful information on physical objects and their environment generated by data sensing, transmission and evaluation technology.

Based on this simple definition, an IIoT application or any IoT application in general can be described by a framework consisting of three key elements:

1. *One or a set of physical objects*
1. *A data processing chain*
1. *A clear added value*

Moreover, the second key element *data processing chain* can be divided into the three subelements *data sensing*, *data transmission*, and *data evaluation*. This conceptual framework allows to capture and describe IoT applications and makes sure you address the development holistically.

IoT-framework.png

Lassen Sie uns dieses Framework anhand des einfachen, aber sehr bekannten und weit verbreiteten Beispiels der intelligenten Lagercontainer veranschaulichen. Solche Container gab es wahrscheinlich schon Jahre, bevor alle über IoT und Industrie 4.0 sprachen, aber sie sind eine perfekte Darstellung einer IoT-Anwendung. Smarte Lagerbehälter sind Behälter mit einem integrierten Sensor zur Messung des Füllstandes. Diese Behälter werden zur Lagerung von Produktionsteilen wie z. B. Schrauben verwendet. Immer wenn der Füllstand ein vordefiniertes Minimum erreicht, wird automatisch ein Nachfüllauftrag ausgelöst. Dieses Beispiel kann auf dem Framework abgebildet werden:

<table class="table font-size-sm">
	<thead>
		<tr>
			<th scope="col">Schlüsselelement</th>
			<th scope="col">Beispiel</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>Physisches Objekt</td>
			<td>Produktionsteile (z.B. Schrauben)</td>
		</tr>
		<tr>
			<td>
 Datenverarbeitungskette 
 
			<td>
 intelligente Speicherbehälter 
 
		</tr>
 <tr>
			<td>&emsp; Datenerfassung</td>
			<td>&emsp; Füllstandssensor (z. B. Gewichtssensor)</td>
		</tr>
 <tr>
			<td>&emsp; Datenübertragung </td>
			<td>&emsp; Nachfüllauftrag (z.B. automatische Bestell-E-Mail) </td>
		</tr>
 <tr>
			<td>&emsp; Datenauswertung</td>
			<td>&emsp; Vergleich mit Mindestfüllstand (z.B. <20% Füllstand)</td>
		</tr>
		<tr>
			<td>Mehrwert</td>
			<td>automatische Lagerverwaltung</td>
		</tr>
	</tbody>
</table>

Dieses Framework kann als Werkzeug verwendet werden, um alle Schlüsselelemente einer beliebigen IoT-Anwendung zu definieren, die Sie zu entwickeln beabsichtigen oder bereits entwickeln. Um dies zu erreichen, ist jedoch ein tieferes Verständnis dessen, was jedes Schlüsselelement darstellt, wichtig. Lassen Sie uns also in jedes der Elemente eintauchen.

#### Physische Objekte - Fokus auf arbeitsrelevante Informationen

Das Schöne an IoT-Anwendungen ist, dass aussagekräftige Informationen über die physische Welt und ihre vielen Objekte automatisch generiert werden können, ohne dass ein menschliches Handeln erforderlich ist. Im Gegensatz zu den meisten Informationen, die heute im Internet verfügbar sind und von Menschen manuell erfasst oder eingefügt werden mussten, sind IoT-Anwendungen in der Lage, nahtlos und autonom einzigartige Informationen bereitzustellen.

Mit der Möglichkeit, automatisch Informationen über Objekte und deren Umgebung zu erstellen, können wir anfangen, darüber nachzudenken, welche Objekte für uns von Interesse sind. Im industriellen Kontext bedeutet dies, welche Objekte und welche zugehörigen Informationen sind für mich relevant, während ich meine Arbeit verrichte? Ist es der Stuhl, auf dem ich sitze, die Maschinen oder Werkzeuge in unserer Produktion, die Produkte, die wir herstellen, die Autos, mit denen unsere Vertriebsmitarbeiter unterwegs sind, oder das gesamte Fabrikgebäude? 

Ein Objekt zu identifizieren, das für einen industriellen Anwender von Bedeutung ist, und die Informationen zu definieren, die für die Verrichtung seiner Arbeit relevant sind, ist ein guter Ausgangspunkt für die Entwicklung einer industriellen IoT-Anwendung.

#### Datenverarbeitungskette - Sinnvolle Informationen automatisch generieren

Die Datenverarbeitungskette umfasst alle Informations- und Kommunikationstechnologien (IKT), die notwendig sind, um die aussagekräftigen Informationen über die beteiligten physischen Objekte automatisch zu erzeugen und zu verteilen. Die notwendigen IKT-Technologien bestehen in der Regel aus Software und Hardware-elektronischen Komponenten sowie der Netzwerkinfrastruktur.

##### Data sensing - Finden Sie den einfachsten und wirtschaftlichsten Sensor

Die Möglichkeiten der Datenerfassung sind immens. Von Sensortechnologien zur Objektidentifikation (z. B. QR-Code oder RFID), Objektlokalisierung (z. B. GPS oder Ultrabreitband) bis hin zur Erfassung nahezu beliebiger physikalischer Eigenschaften (z. B. Beschleunigung, Feuchtigkeit, Kraft, Licht, Temperatur usw.) eines physischen Objekts oder seiner Umgebung; die Generierung von Daten ist in der Regel kein Problem. Die Herausforderung besteht darin, den einfachsten und sparsamsten Sensor zu finden, der Daten liefert, die mit den gewünschten Informationen korrelieren und mit der zur Verfügung stehenden Energieversorgung funktioniert. Die Leistungsaufnahme eines bestimmten Sensors ist vor allem bei Low-Power-Anwendungen wichtig.

##### Datenübertragung - Daten überall und jederzeit abrufen

Ähnlich wie bei der Datenerfassung gibt es eine Vielzahl von Datenübertragungstechnologien, aus denen je nach erforderlicher Bandbreite (d. h. Häufigkeit und Menge der zu übertragenden Daten), verfügbarer Stromversorgung und Standort (z. B. Innen- vs. Außenbereich, stationär vs. mobil oder lange vs. kurze Entfernung) gewählt werden kann. Wenn ein Standard-Internetnetzwerk (z. B. LAN, WLAN, LTE) anwendbar ist, sind HTTP- und MQTT-Protokolle beliebte Kommunikationsstandards. Bei entfernten und stromsparenden Anwendungen werden andere Netzwerke mit speziellen Protokollen verwendet (z. B. Sigfox, LoRaWAN, NB-IoT, Bluetooth). Die Datenspeichertechnologie ist ebenfalls Teil der Datenübertragungsarchitektur, um historische Daten bereitzustellen.

##### Datenauswertung - Aus Daten sinnvolle Informationen machen

Das Unterelement *Datenauswertung* ist das wichtigste der Datenverarbeitungskette und verdient besondere Aufmerksamkeit. Die für die Datenauswertung verwendete Technologie verwandelt die Daten in sinnvolle und wertvolle Informationen. Ohne dieses Element sind alle Bemühungen zur Datenerfassung wertlos. Die Datenauswertung kann auf der Geräteebene (d. h. am Rande), zentralisiert (d. h. in der Cloud) oder irgendwo dazwischen (d. h. Fog Computing) erfolgen. Neben der elektronischen Hardware mit Rechenleistung ist die Software von entscheidender Bedeutung.

*Datenauswertung* bedeutet nicht, dass jede IoT-Anwendung mit Algorithmen der künstlichen Intelligenz (KI) und Machine Learning (ML) Cores arbeiten muss. In vielen Fällen reicht eine maßgeschneiderte Benutzeroberfläche, die aus der Ferne die Informationen über ein physisches Objekt anzeigt, die für einen bestimmten Zielbenutzer und seine Aufgabe relevant sind. Man sollte jedoch vermeiden, Informationen anzuzeigen, die für den Benutzer nicht relevant sind. Natürlich ermöglichen automatisierte logische Prozesse und modernste KI-Algorithmen die Generierung von aussagekräftigeren Informationen.

#### Mehrwert - Fokus auf den Anwender und seine Bedürfnisse

Im Gegensatz zu Consumer-IoT-Anwendungen müssen industrielle Anwendungen einen wirtschaftlichen Mehrwert liefern, um erfolgreich zu sein. Aus Sicht eines Industrieunternehmens ist der Mehrwert dann gegeben, wenn durch die Entwicklung einer IoT-Anwendung ein Wettbewerbsvorteil entsteht oder erhalten bleibt. In Anlehnung an Michael E. Porter wird ein Wettbewerbsvorteil dann erreicht, wenn die IoT-Anwendung entweder eine Angebotsdifferenzierung (d.h. neue oder bessere Produkte und Dienstleistungen) oder eine Kostensenkung (d.h. eine erhöhte organisatorische Effizienz) ermöglicht. Die Zielnutzer können also intern (z. B. Mitarbeiter) oder extern (z. B. Kunden) sein.

Unabhängig davon, ob der Zielnutzer intern oder extern ist, muss die IoT-Anwendung mindestens eines seiner Bedürfnisse befriedigen. Da der Hauptnutzen einer IoT-Anwendung in der automatischen Generierung von aussagekräftigen Informationen besteht, sollte sie das Informationsbedürfnis eines Benutzers befriedigen. Informationen sind für einen Benutzer wertvoll, wenn sie ihn befähigen, eine bestimmte Aufgabe besser zu erledigen, indem sie notwendige Aktionen oder richtige Entscheidungen auslösen. Im besten Fall ist die Qualität und Zuverlässigkeit der generierten Informationen so hoch, dass die Arbeit des Anwenders automatisiert werden kann und die frei werdende menschliche Kapazität für etwas Wichtigeres genutzt werden kann.

Let us illustrate this framework based on the simple but well known and widespread example of smart storage containers. Such containers have probably existed years before everyone started to talk about IoT and Industry 4.0 but they are a perfect representation of an IoT application. Smart storage containers are containers with an integrated sensor to measure fill level. These containers are used to store production parts such as screws for example. Whenever the fill level reaches a predefined minimum a refill order is triggered automatically. This example can be mapped on the framework:

<table class="table font-size-sm">
	<thead>
		<tr>
			<th scope="col">Key element</th>
			<th scope="col">Example</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>physical object</td>
			<td>production parts (e.g. screws)</td>
		</tr>
		<tr>
			<td>
 data processing chain 
 
			<td>
 smart storage containers 
 
		</tr>
 <tr>
			<td>&emsp; data sensing</td>
			<td>&emsp; fill level sensor (e.g. weight sensor)</td>
		</tr>
 <tr>
			<td>&emsp; data transmission </td>
			<td>&emsp; refill order (e.g. automatic order email) </td>
		</tr>
 <tr>
			<td>&emsp; data evaluation</td>
			<td>&emsp; comparison to minimum fill level (e.g. <20% fill level)</td>
		</tr>
		<tr>
			<td>added value</td>
			<td>automatic stock management</td>
		</tr>
	</tbody>
</table>

This framework can be used as a tool to define all key elements of any IoT application you intent to develop or you are already developing. However, to achieve this a deeper understanding of what each key element represents is important. So, let us dive into each of the elements.

#### Physical objects – Focus on job-relevant information

The beauty of IoT applications is that meaningful information on the physical world and its many objects can be generated automatically without any human activity required. In contrast to most of the Information available on the Internet today, where humans had to register or include it manually; IoT applications are able to seamlessly and autonomously provide unique information.

With the possibility of automatically creating information on objects and their environment we can start thinking about which objects are of interest to us. In an industrial context this means which objects and which related information are relevant for me while I am doing my job? Is it the chair I am sitting on, the machines or tools in our production, the products we produce, the cars our sales agents use to travel, or the entire factory building? 

Identifying an object which matters to an industrial user and defining the information relevant for doing his job is a good starting point when developing an industrial IoT application.

#### Data processing chain – Generate meaningful information automatically

The data processing chain covers all information and communication technology (ICT) necessary to automatically generate and distribute the meaningful information on the physical objects involved. The necessary ICT technologies usually consist of Software and Hardware—electronic components and network infrastructure.

##### Data sensing – Find the simplest and most economical sensor

Data sensing possibilities are immense. From sensing technology for object identification (i.e. QR code or RFID), object localization (i.e. GPS or Ultra-wideband), up to detection of almost any physical property (e.g. Acceleration, Moisture, Force, Light, Temperature, etc.) of a physical object or its surroundings; generating data is usually not an issue. The challenge is to find the simplest and most economical sensor, which provides data that correlates with the desired information and works with the available power supply. The power consumption of a certain sensor is especially important in low-power applications.

##### Data transmission – Access data everywhere and anytime

Similar to data sensing a variety of data transmission technologies exist which can be chosen from, depending on the required bandwidth (i.e. the frequency and amount of data to be communicated), and available power supply and location (e.g. indoor vs. outdoor, stationary vs. mobile, or long vs. short distance). When a standard internet network (i.e. LAN, WLAN, LTE) is applicable HTTP and MQTT protocols are popular communication standards. In remote and low-power applications other networks with particular protocols are used (i.e. Sigfox, LoRaWAN, NB-IoT, Bluetooth). Data storage technology is also part of the data transmission architecture to provide historical data.

##### Data evaluation – Make meaningful information out of data

The *data evaluation* subelement is the most important one of the data processing chain and deserves special attention. The technology used for data evaluation transforms data into meaningful and valuable information. Without this element, all data collection efforts are worthless. Data evaluation can happen at the device level (i.e. on the edge), centralized (i.e. in the cloud) or anywhere in between (i.e. fog computing). In addition to electronic hardware with computing power, software is of crucial importance.

*Data evaluation* does not mean that every IoT application needs to run artificial intelligence (AI) algorithms and machine learning (ML) cores. In many cases a tailored user interface remotely displaying the information about a physical object relevant for a certain target user and his job is enough. However, one should avoid displaying information which is not relevant to the user. Of course, automated logical processes and state of the art AI algorithms allow the generation of richer meaningful information.

#### Added value – Focus on users and their needs

In contrast to consumer IoT applications, industrial applications must deliver an economic added value in order to be successful. From the perspective of an industrial organization added value is ensured if the development of an IoT application establishes or maintains competitive advantage. With reference to Michael E. Porter, a competitive advantage is achieved when the IoT application either enables an offer differentiation (i.e. new or better products and services) or a cost reduction (i.e. increased organizational efficiency). Therefore, target users could be internal (i.e. employees) or external (i.e. customers).

Regardless of whether the target user is internal or external the IoT application must satisfy at least one of his needs. As the main benefit of an IoT application is the automatic generation of meaningful information it should satisfy a user's need for information. Information is valuable for a user when it empowers him to do a certain job better by triggering necessary actions or correct decisions. At best, the quality and reliability of the information generated is high enough that the user's job can be automated and the released human capacity can be used for something more important.

iot-action-triggering.png

### Fazit - Das Framework unterstützt die Entwicklung einer erfolgreichen und wertschöpfenden IIoT-Anwendung, indem es sicherstellt, dass alle Schlüsselelemente richtig abgedeckt sind.

Eine erfolgreiche und wertschöpfende industrielle IoT-Anwendung besteht aus den drei Schlüsselelementen *physisches Objekt*, *Datenverarbeitungskette* und *Mehrwert*. Die drei Schlüsselelemente als konzeptioneller Rahmen ermöglichen es, jede industrielle IoT-Anwendung zu erfassen und ganzheitlich zu beschreiben. Bei der Entwicklung von IoT-Anwendungen stellt das Framework sicher, dass objektbezogene, IKT-Technologie-bezogene und geschäftsbezogene Aspekte abgedeckt werden.

Tatsächlich kann das vorgestellte Framework nahezu jede wertschöpfende Technologieanwendung abdecken, die im Zusammenhang mit den Begriffen Internet der Dinge, Digitalisierung, Industrie 4.0, Künstliche Intelligenz und Big Data wahrgenommen wird. Es kann Ihnen helfen, zu erkennen, wo der von Ihnen entwickelten Anwendung wichtige Elemente fehlen und Verbesserungspotenzial besteht.

Sie können das Framework gerne selbst ausprobieren, indem Sie eine Ihnen bekannte industrielle IoT-Anwendung mit den in diesem Artikel vorgestellten Schlüsselelementen erfassen. Wir sind gespannt darauf zu erfahren, wie es gelaufen ist und ob das Framework Ihnen geholfen hat, die Entwicklung Ihrer Anwendung zu verbessern.

### Conclusion – The framework supports the development of successful and value-adding IIoT application by ensuring that all key elements are properly covered

A successful and value-adding industrial IoT application consists of the three key elements *physical object*, *data processing chain*, and *added value*. The three key elements as a conceptual framework allow to capture and holistically describe any industrial IoT application. While developing IoT applications, the framework ensures that object related, ICT technology related, and business related aspects are covered.

In fact, the presented framework can cover almost every value-adding technology application which is perceived in connection with the terms Internet of Things, Digitalization, Industry 4.0, Artificial Intelligence, and Big Data. It can help you to identify where the application you are developing lacks important elements and has room for improvement.

Feel free to try the framework yourself by capturing an industrial IoT application you know with the key elements presented in this article. We are eager to know how it went and if the framework helped you to improve the development of your application.

Wenn Sie wollen, dass Ihre digitalen Transformationsprojekte greifbare Ergebnisse liefern, nutzen Sie das Framework und stellen Sie sicher, dass Sie alle Schlüsselelemente einer erfolgreichen und wertschöpfenden IoT- oder IIoT-Anwendung von Beginn der Entwicklung an abdecken.

If you want your digital transformation projects to deliver tangible results use the framework and make sure you cover all key elements of a successful and value-adding IoT or IIoT application from the very beginning of development.

large_iot-framework-cover-image.jpg

medium_iot-framework-cover-image.jpg

small_iot-framework-cover-image.jpg

thumbnail_iot-framework-cover-image.jpg

iot-framework-cover-image.jpg

Die Kernelemente von industriellen IoT-Anwendungen - ein Framework

The Key Elements of Industrial IoT Applications – A Framework

Jüngste Prognosen gehen davon aus, dass bis 2020 20 bis 40 Milliarden vernetzte Geräte eingesetzt werden. Es wird erwartet, dass etwa 40 % dieser neuen Sensoren in einem industriellen Kontext installiert werden. 

Eine oft übersehene Folge dieses Wachstums an vernetzten Geräten ist die Notwendigkeit von 5 Millionen neuen Softwareanwendungen, um die neu gesammelten Daten sinnvoll zu nutzen. Das ist eine Menge an neuer Software und Apps, die benötigt werden und entwickelt werden müssen, um diese Vielzahl an Daten zu verwalten.

Bei der Annäherung an das Industrial Internet of Things (IIoT) ist es ein gängiger Trend, dass Unternehmen ihren Entwicklungsfokus auf Sensoren und Geräte legen, die eigentliche Herausforderung ist jedoch die Erzielung einer nachhaltigen Wertschöpfung auf der Anwendungsebene. Daher erfordert das Erreichen einer erfolgreichen IIoT-Anwendung einen Mentalitätswechsel, der durch einen einfachen zweistufigen Ansatz erreicht werden kann.

#### 1. Beginnen Sie mit echten Herausforderungen und finden Sie den Weg zu den notwendigen Technologien

Sensoren werden immer billiger und lassen sich aus der Designperspektive grundsätzlich leicht in Produkte integrieren. Allerdings machen große Sensorinstallationen, die riesige Datenmengen in die Cloud pumpen, keinen Sinn ohne eine klare zugrunde liegende Anwendung, die in der Lage ist, diese Daten wertschöpfend zu nutzen.

Wertsteigernde IIoT-Anwendungen zeichnen sich durch die Fähigkeit aus, selbstständig Aktionen oder Entscheidungen auszulösen, ohne dass der Benutzer eingreifen muss. Unter vielen Umständen beginnt die Entwicklung von IIoT-Lösungen jedoch mit der Frage "Wo und wie können wir Daten sammeln?" und nicht mit einem eher anwendungszentrierten Ansatz: "Wir haben eine klare geschäftliche Herausforderung, welche Daten sollten wir sammeln, um sie zu lösen?".

Das ist genau die Phase, in der die meisten Unternehmen, die das IIoT einführen, damit kämpfen, seine Vorteile zu artikulieren. Die eigentliche Herausforderung besteht darin, die Anwendungen und echten Geschäftsfälle zu entwickeln, die den Daten tatsächlich einen Sinn geben, und erst in einem zweiten Schritt die Systeme zu entwerfen, die erforderlich sind, um die benötigten wertschöpfenden Informationen zu messen und zu sammeln.

Der richtige Ansatz für IIoT ist, mit einem realen Problem zu beginnen und zu verstehen, welche Daten und Informationen notwendig sind, um es zu lösen. In einer späteren Phase sollte man dann überlegen, welche Sensoren notwendig sind. Durch diesen Ansatz sind IIoT-Lösungen am Ende weniger komplex, überschaubarer und benötigen weniger Sensoren, um die gewünschte Wertschöpfung zu erzielen.

#### 2. Erstellen Sie eine einfache IIoT-Pilotanwendung, um den Business Case zu beweisen, und skalieren Sie sie dann

IIoT-Anwendungen müssen kontextualisiert werden und zu Lösungen für echte Probleme werden. Wenn reale Probleme identifiziert sind, wird es einfacher, die notwendigen Daten zu sammeln und sinnvoll zu nutzen, aber es wird auch möglich, messbare Metriken zu definieren, um den Nutzen abzuschätzen und einen Business Case zu erstellen.

IIoT-Anwendungen sind ein komplexes Gleichgewicht zwischen Technologie, Prozessen und Menschen. Sie unterliegen einem hohen Maß an Unsicherheit und Unvorhersehbarkeit. Daher erfordern sie einen Entwicklungsansatz, der von Agilität geprägt ist.

Wenn ein Zielproblem klar definiert ist, besteht der nächste Schritt darin, ein Pilotprojekt zu erstellen, um den Business Case und den Return-on-Investment (ROI) zu validieren. Im Moment gibt es praktisch keine historischen Daten oder Berechnungsmodelle, um die Kosten a priori abzuschätzen und den finanziellen Nutzen des IIoT genau zu beschreiben. Es gibt einige Beispiele für erfolgreiche Implementierungen, denen es jedoch an öffentlich zugänglichen Finanzberichten und Metriken mangelt. Das bedeutet, dass Sie den Mehrwert Ihrer IIoT-Anwendung nachweisen und die damit verbundenen Kosten annähernd abschätzen müssen, indem Sie ein Pilotprojekt erstellen. Das Hauptziel eines Pilotprojekts ist nicht nur die Reduzierung des Geschäftsrisikos und die Minimierung der Vorabinvestition, sondern auch die Gewinnung von Erkenntnissen über erforderliche Technologien, Partner und Lieferanten, mit denen Ihr Unternehmen zusammenarbeiten muss, um eine erfolgreiche Implementierung zu erreichen. In diesem Zusammenhang stellt ein Pilotprojekt eine tatsächliche Implementierung der Arbeitsanwendung mit realen Kunden dar, wenn auch in einem begrenzten Umfang und einer begrenzten Komplexität, die daher mit einem Aufwand von wenigen Wochen erreicht werden kann.

Zusammenfassend lässt sich sagen, dass die Entwicklung überschaubarer, weniger komplexer und wertschöpfender IIoT-Anwendungen dadurch erreicht wird, dass man sich erstens auf reale geschäftliche Herausforderungen konzentriert und zweitens den zugehörigen Business Case mithilfe eines Pilotprojekts validiert, bei dem die Komplexität auf das absolute Minimum reduziert und das Projekt mit Lead Usern verifiziert wird.

Latest predictions foresee 20 to 40 billion connected devices deployed by 2020. About 40% of these new sensors are expected to be installed in an industrial context. 

A often overlooked consequence of this growth in connected devices is the necessity of 5 million new software applications to make sense of the newly collected data. This is a lot of new software and apps which will be required and need to be developed to manage this multitude of data.

When approaching Industrial Internet of Things (IIoT), it is a common trend for companies to set their development focus on sensors and devices, however the actual challenge is achieving sustainable value adding at the application level. Hence,  achievement of successful IIoT application require a mindset switch that can be achieved through a simple two-stepped approach.

#### 1. Start with real challenges and figure out your way to the necessary technologies

Sensors are becoming cheaper and cheaper, and are basically easy to integrate in products from a design perspective. However, large sensors installed bases that pump huge datasets into the cloud make no sense without a clear underlying application that is able to make value adding sense of this data.

Value adding IIoT applications are uniquely characterized by the ability of autonomously trigger actions or decisions, without the need of user intervention. However, under many circumstances, the development of IIoT solutions start from the question "where and how can we collect data?" rather than a more application centered approach: "we have a clear business challenge, what data should we collect to address it?".

This is exactly the stage at which most of the companies embracing IIoT struggle in articulating its benefits. The real challenge is developing the applications and real business cases which actually make sense of the data, and only in a second step design the systems required to measure and collect the value adding piece of information required.

The correct approach for IIoT is to begin with a real problem, and understand what data and information is necessary to address it. In a later phase, start think about what sensors are necessary. Through this approach, IIoT solutions end up being less complex, more manageable and require less sensors to achieve the desired value adding.

#### 2. Build a simple pilot IIoT application to prove the business case, then scale it up

IIoT applications need to be contextualized and become solutions to real problems. When real problems are identified, it becomes easier to collect and make sense of the necessary data, but it also become possible to define measurable metrics to estimate the benefits and build a business case.

IIoT applications are a complex balance between technology, processes and people. They are subject to a great extent of uncertainty, and unpredictability. Hence, they require a development approach dominated by agility.

When a target problem is clearly defined, the next step is to create a pilot to validate the business case and the Return-on-Investment (ROI). Right now there is practically no historical data or calculation models to estimate a priori the costs and precisely describe the financial benefits of IIoT. There are some examples of successful deployments, which however lack of publicly available financial reports and metrics. This means you will have to prove the added value of your IIoT application and approximate its related costs by creating a pilot project. The main goal of a pilot is not only to reduce business risk and minimize the upfront investment, but also to obtain insights in required technologies, partners and suppliers your organization needs to collaborate with to achieve a successful implementation. In this context, a pilot project represents an actual implementation of the working application with real customers, albeit on a limited scale and complexity, therefore achievable with an effort of few weeks.

To conclude, the development of more manageable, less complex and value adding IIoT applications is obtained by first focusing on real business challenges and second, by validating the related business case by means of a pilot project, where the complexity is reduced to the bare minimum, and the project is verified with lead users.

Organisationen legen den Schwerpunkt von Industrial Internet of Things (IIoT) häufig auf Sensoren und Geräte, die eigentliche Herausforderung besteht jedoch darin, einen Mehrwert auf der Anwendungsebene zu erzielen. Dies kann durch einen zweistufigen Ansatz erreicht werden.

Organizations often to set the focus of Industrial internet of Things (IIoT) on sensors and devices, however the actual challenge is achieving value adding at the application level. This can be achieved through a two-stepped approach.

large_data-tunnel.jpg

medium_data-tunnel.jpg

small_data-tunnel.jpg

thumbnail_data-tunnel.jpg

data-tunnel.jpg

Wie man handliche und wertsteigernde IIoT-Anwendungen schafft.

How to Achieve Manageable and Value Adding IIoT Applications

Stöbern Sie durch unsere Artikel, um neue Anregungen zu erhalten oder mehr darüber zu erfahren, wie wir arbeiten und denken.

Browse through our articles to get fresh inputs or learn more about how we work and think.

Gedanken

Ideas

Gedanken, die uns begeistern und Dinge, die wir lieben.

Things we love and ideas that get us excited.

Interessiert, inspiriert oder einfach gelangweilt?

Interested, inspired or simply bored?

Digitale Lösungsbauer – Wir bieten Fachwissen, qualifizierte Manpower oder Ihre massgeschneiderte End-zu-End-Lösung im Bereich Softwareentwicklung, Cloud Computing, DevOps Engineering, digitale Innovation und Internet of Things.

Digital Solution Builders – We offer expertise, qualified manpower, or your tailored end-to-end solution in the field of software development, cloud computing, DevOps Engineering, digital Innovation, and Internet of Things.

large_digitalBuildersIllustration_Illustration.png

medium_digitalBuildersIllustration_Illustration.png

small_digitalBuildersIllustration_Illustration.png

thumbnail_digitalBuildersIllustration_Illustration.png

digitalBuildersIllustration_Illustration.png

digitalBuildersIllustration_Illustration.svg

EMBRIO.tech

Gefällt Ihnen unser Team?

Do you like our team?

Wir sind die Agentur für digitale Innovation in der Schweiz mit Wurzeln an der ETH Zürich. Unsere Mission ist es, Unternehmen dabei zu unterstützen, schneller und erfolgreicher mit digitalen Technologien zu innovieren. Wir setzen Ihre Ideen rasch in testbare Lösungen um. Gemeinsam schärfen wir Ihre digitale Vision und verwandeln sie in die wertschöpfenden Produkte, Dienstleistungen und Arbeitsabläufe von morgen.

We are the agency for digital innovation based in Switzerland with roots at ETH Zürich. Our mission is to support businesses in innovating faster and successfully with digital technologies. We rapidly transform your ideas into testable solutions. Together we sharpen your digital vision and turn it into the value-adding products, services and workflows of tomorrow.

Über uns

About

Wir lieben das Entwerfen, Bauen und Betreiben von digitalen Lösungen.

We love to design, build and operate digital solutions.

Haben Sie eine digitale Herausforderung, die Sie angehen möchten?

Got a digital challenge you’re looking to tackle?

Stärken Sie Ihren Wettbewerbsfähigkeit mit zukunftsfähiger Software und Technologien. Hier sind digitale Herausforderungen, bei denen wir Ihnen helfen können.

Strengthen your competitive advantage with future-proof software and technology. Here are some digital challenges we can help you with.