IT-Beratung und Software-Architektur

Software Neuprojekte
IT-Architektur Support
Wem wir helfen?
Beratungstermin vereinbaren
Software Neuprojekte
IT-Architektur Support
Wem wir helfen?
Beratungstermin vereinbaren

IT-Architektur ist Kollaboration

Zuhören, Anforderungen verstehen: die Grundlagen jedes guten Systems

Wenn ich Architektur für Systeme betreue, geht es nicht nur um ein System. Ich muss verstehen, wie ein System für Menschen funktioniert, was die Anforderungen sind und dass die Systeme am Ende morgen noch funktionieren müssen.

IT-Architektur heißt nicht umsonst so. Wenn das Fundament, die Umsetzung nicht sitzt, kann kein Mensch es vernünftig nutzen.
Sebastian Schuenemann
Director IT-Architektur
Jetzt kontaktieren

Sebastian Schuenemann

Director IT-Architektur
Jetzt kontaktieren

Software-Produkte und -Projekte neu aufsetzen

Ausgangssituation: Sie wollen ein Produkt/ein Projekt neu aufsetzen. Ob mit Vorerfahrung oder komplettes Neuland. So oder so ist wichtig: jedes Produkt/Projekt ist ein individuelles Unterfangen mit individuellen Anforderungen, Prozessen, Strategien und Erfolgen.

Learnings können deshalb zwar vielleicht teils aus bestehenden Projekten übernommen werden, jedoch nie zu 100%. Abzuwägen was genutzt werden kann, was geändert werden muss und was komplett from scratch gezogen werden muss um dann darauf aufzubauen – das ist der Start von etwas Großem, und das Rezept zum Erfolg.

Unsere Methodik:

  • Zuhören
  • Bedarf ermitteln
  • Zyklus: am Leben halten und laufend optimieren
Unverbindliches Gespräch vereinbaren
Build Measure Learn Loop

Produktzyklen: um gemeinsam erfolgreich zu sein steht hier eine smarte Bildunterschrift. Das hier ist eine Dummygrafik, wir müssen noch eine entwickeln.

IT-Architektur ist Kollaboration

Zuhören, Anforderungen verstehen: die Grundlagen jedes guten Systems

Wenn ich Architektur für Systeme betreue, geht es nicht nur um ein System. Ich muss verstehen, wie ein System für Menschen funktioniert, was die Anforderungen sind und dass die Systeme am Ende morgen noch funktionieren müssen.

IT-Architektur heißt nicht umsonst so. Wenn das Fundament, die Umsetzung nicht sitzt, kann kein Mensch es vernünftig nutzen.
Sebastian Schuenemann
Director IT-Architektur
Jetzt kontaktieren
IT-Architektur heißt nicht umsonst so. Wenn das Fundament, die Umsetzung nicht sitzt, kann kein Mensch es vernünftig nutzen.

Sebastian Schuenemann

Director IT-Architektur
Jetzt kontaktieren

Software-Produkte und -Projekte neu aufsetzen

Ausgangssituation: Sie wollen ein Produkt/ein Projekt neu aufsetzen. Ob mit Vorerfahrung oder komplettes Neuland. So oder so ist wichtig: jedes Produkt, jedes Projekt ist ein individuelles Unterfangen, mit individuellen Anforderungen, Prozessen, Strategien und Erfolgen. Learnings können deshalb zwar vielleicht teils aus bestehenden Projekten übernommen werden, jedoch nie zu 100%. Abzuwägen, was genutzt werden kann, was geändert werden muss und was komplett from scratch gezogen werden muss, um dann darauf aufzubauen – das ist der Start von etwas Großem, und das Rezept zum Erfolg.

Unsere Methodik:

  • Zuhören
  • Bedarf ermitteln
  • Zyklus: am Leben halten und laufend optimieren
Unverbindliches Gespräch vereinbaren
Build Measure Learn Loop

Produktzyklen: um gemeinsam erfolgreich zu sein, sollte man sich immer wieder neuen – auch unbequemen – Fragen stellen.

Ihr Produkt muss zu Ihrer Organisation passen

Immer wieder kommen wir in die Verlegenheit Projekte aus dem Abgrund zu ziehen. Aber: woran liegt das? Was passiert dort und wie helfen wir?

Architektur ist die Kunst dafür zu sorgen, dass es morgen auch noch funktioniert ohne dem Jetzt dabei im Weg zu stehen.
Felix Eckhardt
IT-Architekt, Trainer, Speaker
Felix_Eckardt
Jetzt kontaktieren
Felix_Eckardt

Felix Eckhardt

IT-Architekt, Trainer, Speaker
Jetzt kontaktieren

Produkte, Projekte, Systeme „retten“

Natürlich gibt es nicht den einen Grund, aus dem Projekte in Schieflage geraten. Aber es gibt einige Punkte, deren Berücksichtigung sich bei der Problemfindung als nützlich erwiesen haben.

  1. Fehlerkultur ist enorm wichtig um zurück auf Erfolgskurs zu kommen, denn Fehler sollten als Chance begriffen werden. Zur Entfaltung des vollen Team-Potenzials gilt es, einen Raum zu bieten, in dem alle offen und ohne Angst über das sprechen können, was falsch läuft und wie es besser laufen könnte.
    So findet man zuerst zu einem besseren Arbeiten, dann zu besseren Prozessen und letztendlich zu einem funktionierenden Projekt oder Produkt.
  2. Zuhören und die richtigen Fragen zu stellen ist ebenfalls essentiell um das Problem möglichst genau beschreiben. Ein Problem, das man bestmöglich versteht, ist eigentlich schon gelöst.

Situationsabhängig können z. B. folgende Maßnahmen zur Anwendung kommen:

  • Fehlerkultur etablieren
  • Retros und Reviews einführen
  • Post Mortem Kultur entwickeln
  • Fingerpointing abschaffen
  • Iteratives Vorgehen einführen
  • In den Product-Cycle kommen
  • Gemeinsame Arbeitsweise analysieren und optimieren
Unverbindliches Gespräch vereinbaren

Wie helfen wir typischer Weise? Was sind unsere Erste-Hilfe-Maßnahmen?

Das eine Erfolgsrezept gibt es nicht, sonst hätten Sie es sicher schon gegoogelt und selbst angewandt. Stattdessen sehen wir projekttypische Bestandteile, Rollen und Konzepte und hinterfragen jeden einzelnen Prozessschritt, bis wir den Fehler gefunden haben.

  • Problem erkennen
  • Erfolgsaussichten/Risiken bewerten (lohnt sich die Fortsetzung finanziell, inhaltlich, langfristig?)
  • Transparenz schaffen, Fehlentwicklung skizzieren (für alle klar verständlich machen: was läuft schief?)
  • Ursachen identifizieren
  • Strategie(n) zur Problemlösung erstellen
  • Kommunikation/Veränderungsmanagement betreiben (um erneuten Downfall zu verhindern)
  • Rettung durchführen, Monitoring etablieren, Projektstrukturen optimieren
  • ggf. Übergabe
Problem erkennen

Ihr Produkt muss zu Ihrer Organisation passen

Immer wieder kommen wir in die Verlegenheit, Projekte aus dem Abgrund zu ziehen. Aber: woran liegt das? Was passiert dort und wie helfen wir?

Architektur ist die Kunst dafür zu sorgen, dass es morgen auch noch funktioniert ohne dem Jetzt dabei im Weg zu stehen.
Felix Eckhardt
IT-Architekt, Trainer, Speaker
Felix_Eckardt
Jetzt kontaktieren
Felix_Eckardt
Architektur ist die Kunst dafür zu sorgen, dass es morgen auch noch funktioniert ohne dem Jetzt dabei im Weg zu stehen.

Felix Eckhardt

IT-Architekt, Trainer, Speaker
Jetzt kontaktieren

Produkte, Projekte, Systeme „retten“

Fehlerkultur ist enorm wichtig für den Erfolg. Schauen wir uns Elon Musk an: seine Raketen starten und explodieren immer wieder. Er selbst sieht dies als Weg zum Erfolg. Sicher ist eine so positive Haltung nicht in jeder Situation zutreffend – eine Testrakete darf ggf. versagen, Ihr Projekt nicht. Wie arbeiten und leben wir damit gemeinsam?

  • Fehlerkultur etablieren (Reviews, Retros, disruptive Weiterentwicklung akzeptieren)
  • Teams nach XY zuordnen und sortieren
  • Ressourcen
  • In den Product-Cycle kommen
  • Gemeinsame Arbeitsweise analysieren und optimieren
Unverbindliches Gespräch vereinbaren

Wie helfen wir typischer Weise? Was sind unsere Erste-Hilfe-Maßnahmen?

Ein Erfolgsrezept kann es nicht geben, sonst hätten Sie es ja sicher schon gegoogelt und selber angewandt. Stattdessen sehen wir typische Bestandteile, Rollen und Konzepte, die wir in den meisten Projekten finden, und hinterfragen jeden einzelnen Prozessschritt, bis wir den Fehler gefunden haben.

  • Problem erkennen
  • Erfolgsaussichten/Risiken bewerten (lohnt sich die Fortsetzung finanziell, inhaltlich und langfristig?)
  • Transparenz schaffen, Fehlentwicklung skizzieren (für alle klar verständlich machen, was schief läuft)
  • Ursachen identifizieren
  • Strategie(n) zur Problemlösung erstellen
  • Kommunikation/ Veränderungsmanagement betreiben (verhindert erneuten Downfall)
  • Rettung durchführen, Monitoring etablieren, Projektstrukturen optimieren
  • ggf. Übergabe
Problem erkennen

Produkte auf die nächste Stufe heben

Ihr Produkt, Ihre Dienstleitung wächst, stößt aber an die natürlichen Grenzen Ihrer Architektur. Das kann die Infrastruktur oder die Codebasis sein. Wie geht es weiter?

Ich finde technische Lösungen für fachliche Anforderungen, die zuverlässig und nachhaltig sind. Immer mit dem Fokus den Kunden und seine Ziele vorran zu bringen.
Sven Allers
Software Engineer
Sven Allers Silpion
Jetzt kontaktieren
Sven Allers Silpion

Sven Allers

Software Engineer
Jetzt kontaktieren

Projekte und Produkte skalieren

Sinnvoll skalieren ist angesagt. Wenn wir mit Kunden – die sich für uns zum Glück oft eher wie Partner anfühlen – zusammenkommen, stehen wir meist vor diesen Themen:

  • Zukunftssicher arbeiten, kein Overengineering
  • Was sind die eigentlichen Ziele? Zahlt unsere gemeinsame Arbeit stringent darauf ein?
  • Bilden wir mit dem System die pragmatische Realität wirklich ab?

Je nachdem welche Struktur oder welcher Bereich innerhalb eines Produkts wachsen soll, müssen wir zusammen unterschiedlich darauf eingehen.

Tech scaling is about finding a balance between over-investing (excess capacity) and under-investing (shortage).

Unverbindliches Gespräch vereinbaren

Hier die typischen Bereiche des Produktwachstums bzw. der Skalierung.

  • Growth-Work:
    die Produktverwendung durch Nutzer, die nominelle Anforderung wächst
  • Feature-Work:
    Funktionserweiterung von bestehenden Produkten für einen höheren Wert für bestehende und neue Märkte
  • Scaling-Work:
    Sicherstellung, dass das Produktteam die Fähigkeit behält, neue Dinge (Funktion, Wachstum, Erweiterungen) zur Anpassung an den sich wandelnden Produktmarkt beibehält

Unterteilung der Skalierung:

  • Technische Skalierung (Infrastrukturarbeiten ..)
  • Prozessskalierung (intern, Organisationsprozesse)
  • Benutzerskalierung (Betrugserkennung, Spam, Filter ..)
Skalierung

Produkte auf die nächste Stufe heben

Ihr Produkt, Ihre Dienstleitung wächst, stößt aber an die natürlichen Grenzen Ihrer Architektur. Das kann die Infrastruktur oder die Codebasis sein. Wie geht es weiter?

Ich finde technische Lösungen für fachliche Anforderungen, die zuverlässig und nachhaltig sind. Immer mit dem Fokus den Kunden und seine Ziele vorran zu bringen.
Sven Allers
Software Engineer
Sven Allers Silpion
Jetzt kontaktieren
Sven Allers Silpion
Ich finde technische Lösungen für fachliche Anforderungen, die zuverlässig und nachhaltig sind. Immer mit dem Fokus den Kunden und seine Ziele vorran zu bringen.

Sven Allers

Software Engineer
Jetzt kontaktieren

Projekte und Produkte skalieren

Sinnvoll skalieren ist angesagt. Wenn wir zusammen mit Kunden – die sich für uns zum Glück oft eher wie Partner anfühlen – zusammenkommen, stehen wir meist vor diesen Themen:

  • Zukunftssicher arbeiten, kein Overengineering
  • Was sind die eigentlichen Ziele? Zahlt unsere gemeinsame Arbeit stringent darauf ein?
  • Bilden wir mit dem System die pragmatische Realität wirklich ab?

Je nach dem, welche Struktur oder welcher Bereich innerhalb eines Produkts wachsen soll, müssen wir zusammen unterschiedlich darauf eingehen.

Tech scaling is about finding a balance between over-investing (excess capacity) and under-investing (shortage).

Unverbindliches Gespräch vereinbaren

Hier die typischen Bereiche des Produktwachstums bzw. der Skalierung.

  • Growth-Work:
    die Produktverwendung durch Nutzer, die nominelle Anforderung wächst
  • Feature-Work:
    Funktionserweiterung von bestehenden Produkten für einen höheren Wert für bestehende und neue Märkte
  • Scaling-Work:
    Sicherstellung, dass das Produktteam die Fähigkeit behält, neue Dinge (Funktion, Wachstum, Erweiterungen) zur Anpassung an den sich wandelnden Produktmarkt beibehält

Unterteilung der Skalierung:

  • Technische Skalierung (Infrastrukturarbeiten ..)
  • Prozessskalierung (intern, Organisationsprozesse)
  • Benutzerskalierung (Betrugserkennung, Spam, Filter ..)

Unser Selbstverständnis

Unser Selbstverständnis

Wem wir helfen können

Alle Branchen, technikübergreifend

Zu viel versprochen? Auf keinen Fall. Die Digitalisierung löst für uns als Entwickler:innen Grenzen auf. Ähnliche Bedürfnisse in völlig unterschiedlichen Branchen führen für uns zu wichtigen Learnings, von denen Sie profitieren.

Mittelstand bis Konzern

Die Denkweisen müssen zusammenpassen. Wir fordern unsere Softwareingenieur:innen stetig, eigenständig zu denken und selbstverantwortlich zu handeln. Hierzu helfen wir dabei, agiles Denken zu erlernen und umzusetzen.

National und international

Neben dem Gründungsstandort Hamburg, sind wir durch Dependancen beispielsweise auch in Berlin und am Bodensee seit langem bundesweit aktiv. Doch auch internationale Zusammenarbeiten gehören zu unserem Daily Business.

…lass mal lieber Tacheles reden!

Wir stolpern immer wieder darüber – Sie doch auch. Die „wichtigen“ Trends, Begriffe, Technologien, die man „kennen muss“. Mit einem kleinen Augenzwinkern widmen wir uns unseren Helden der IT-Buzzwords. Haben Sie einen Vorschlag? Kurze Mail an ed.noiplis@etisbew. oder hier (ein Formular tbd) einreichen.

Der Mythos bei Skalierung ist:

„Immer und überall jeder Zeit per Knopfdruck“, „Unsere Systeme müssen (unendlich) skalieren können“

Wie sieht die Realität aus

Wie sieht die Realität aus

Es gibt viele Arten von skalierbarkeit

  • Horizontal & Vertikal
  • Backpressure (z.B. über asynchrone Kommunikation)
  • Partitionierung

Es muss sich immer die Frage gestellt werden wie skalierbar ein System wirklich sein muss.

  • Gibt es eine synchrone Interaktion mit dem Nutzer?
  • Kann das System auch asynchron funktionieren?
  • Welche zeitlichen Constraints gibt es bis Dinge abgearbeitet werden müssen?
  • Wieviele Nutzer nutzen das System überhaupt und was sind die Prognosen?
  • Wie kritisch ist es wenn das System zeitweise langsam oder nicht verfügbar ist?

Bevor das System unendlich skalierbar ist, sollte der Fokus auf einem erfolgreichem Produkt liegen

  • Skalierungsprobleme sind in der Regel Luxusprobleme, denn sie deuten häufig darauf hin, dass das Produkt erfolgreicher ist als erwartet.

Kundenbewertung

3/5 Sterne
Sven Allers
Experte für Softwarearchitektur
Sven Allers Silpion

Was sagt der Experte

„Techniker setzen gerne einen starken Fokus auf Skalierung ohne das Problem zuvor analysiert zu haben, das gelöst werden soll. Verschiedene Szenarien müssen unterschiedlich stark skalieren und erfordern auch verschiedene Maßnahmen zur skalieren. Das beinhaltet auch das Maß der benötigten Skalierung. Bevor der Fokus zu stark auf ein technisches Problem gelenkt wird das noch gar nicht besteht, sollte zunächst das Produkt selber erfolgreich sein, sonst kann Skalierung auch ein Quell von Overengineering und somit unnötig hoher Entwicklungskosten sowie schwerer Wartbarer Software werden“

Der Mythos bei Blockchain ist:

"Blockchain-Technologie ist ein Klimakiller."

Wie sieht die Realität aus

Wie sieht die Realität aus

  • 76% der Miner verwenden bereits einen Energiemix der erneuerbare Energien beinhaltet (Tendenz steigend)
  • Auf den verwendeten Konsens-Algorithmus kommt es an:
    • Lediglich PoW (proof-of-work) zeichnet sich durch einen hohen Energiebedarf aus (z.B. Bitcoin schätzungsweise 830kWh pro Transaktion)
    • PoS (proof-of-stake) hat einen vergleichsweise sehr geringen Energiebedarf (z.B. Tezos schätzungsweise 30mWh pro Transaktion
    • Blockchain ist eine relativ junge Technologie und neuere, energiesparende Konsens-Algorithmen werden laufend (weiter-)entwickelt (z.B. Chia Proof of Space Time)
    • Zum Vergleich: Eine Google-Suchanfrage hat einen Energiebedarf von schätzungsweise 300mWh

Fun fact:
„The amount of electricity consumed every year by always-on but inactive home devices in the USA alone could … power the Bitcoin network for 1.7 years“

Quelle: Cambridge Centre for Alternative Finance https://cbeci.org/cbeci/comparisons

Kundenbewertung

1/5 Sterne
Maxi Reichel
Experte für IT-Architektur

Was sagt der Experte

„Bitcoin und Blockchain sind nicht synonym. Es kommt auf den verwendeten Konsens-Algorithmus an!“

Der Mythos bei DevOps ist:

DevOps umfasst Ideen, Praktiken, Ansätze (=Kultur) darüber, wie eine Idee von der Entwicklung bis zum Einsatz in der Produktivumgebung beschleunigt bereitgestellt werden kann. Ressourcen werden dafür durch Automatisierung und Self-Service dort zur Verfügung gestellt, wo sie am dringendsten benötigt werden. Insofern ist DevOps keine Rolle, die jemand inne hat, sondern ein Mindset, dass jeder IT-Spezialist tagtäglich ausüben und leben muss, damit die Projekt- und Unternehmensziele flexibel und agil erreicht werden können.

Wie sieht die Realität aus

Wie sieht die Realität aus

Es gibt oft ein Devteam, dass

  • lokal entwickelt
  • Dienste lokal (Web-/App-Server, Datenbank, etc.) betreibt
  • ihr Artefakt irgendwann an Ops übergibt

Außerdem gibt es meistens auch ein Opsteam, dass

  • Dienste (s.o.) bereitstellt und überwacht
  • leider oft ohne diese im Detail zu kennen (Applicationserver werden installiert, aber mit Standardkonfiguration betrieben)
  • Artefakte installiert / deployt

Oft ist aber auch ein DevOps-Engineer vorhanden, der

  • das schon alles macht
  • aber zwischen den Stühlen sitzt von „beiden Seiten“ immer wieder mit den gleichen Tasks eingedeckt wird

Kundenbewertung

4/5 Sterne
Patrick Hackbarth
Experte für Software Engineer

Was sagt der Experte

Gutes DevOps ist da möglich wo das Team (WIR): Probleme offen ansprechen kann selbstkritisch Prozesse und Methoden hinterfragen kann Dinge selbständig ändern oder wenigstens in Gang setzen kann DevOps wird schwierig oder wenig nachhaltig, wenn einer abgestellt wird, jetzt DevOps zu machen (am besten noch ein Externer) träge (oder gar keine) Kommunikation zwischen Anforderung, Entwicklung und Betrieb besteht das „DIE“ dem „WIR“ überwiegt Bürokratie Prozesse lähmt

Der Mythos bei NoOps ist:

"Führe NoOps ein, dann kannst Du das Personal für den Betrieb einsparen. Man lässt die Entwickler den Betrieb verantworten und alles wird gut!"

Wie sieht die Realität aus

Wie sieht die Realität aus

  • Nur weil andere Personen eine Aufgabe übernehmen, verschwindet die Arbeit nicht. Automatisierung muss schließlich auch implementiert werden. Das kostet Zeit und Geld. Die Vorteile der Automatisierung können diesen Aufwand allerdings durchaus rechtfertigen, auch wenn am Ende gar kein Geld eingespart wurde .
  • Es fallen andere Aufgaben an. So fängt der Entwickler auf einmal an, Tests für die Infrastrukturautomatisierung zu schreiben. Das ist super, kostet aber eben auch Geld.
  • Ein Entwickler ist kein erfahrener Operations-Mitarbeiter. Ihm fehlen ggf. Wissen und Erfahrung.
  • Wir drängen Entwickler damit in eine immer generischere Rolle. Sie sollen entwickeln, testen, deployen, betreiben und bestenfalls noch Analytics machen, um Daten für data driven decisions zu liefern. Echte Spezialisten, die man für gute Softwareprodukte braucht, werden dabei seltener.
  • Für manche Dinge (z.B. Security) lohnt es sich, teamübergreifend zu agieren und einheitliche Lösungen voranzutreiben. So entstehen Plattformteams, die oft auch erfahrene Operations Mitarbeiter brauchen – das ist dann ganz sicher nicht mehr NoOps.

Kundenbewertung

2/5 Sterne
Felix Eckhardt
Experte für IT-Architektur

Was sagt der Experte

„NoOps ist ein schickes Werbeversprechen, auf das manche leider tatsächlich hereinfallen. Das Einspar-Argument ist Augenwischerei. Wer glaubt, dass er mit NoOps einfach das Budget für den Betrieb streichen kann, irrt.“

Der Mythos bei AI ist:

"Ist kompliziert, soll die AI machen. Black Box: Alles was wir an Daten irgendwie haben kommt rein - eine super tolle Vorhersage/Auswertung kommt raus!
Wenn AI da ist, muss nix weiter gemacht werden."

Wie sieht die Realität aus

Wie sieht die Realität aus

  • Für AI wird eine solide Datengrundlage benötigt, die meist nicht vorhanden ist. Diese zu schaffen liefert meist schon Mehrwert.
  • Auf den Daten können teilweise deterministische Algorithmen laufen, es ist keine AI nötig um Fragestellung zu lösen.
  • Neu hinzukommende Daten müssen berücksichtigt werden. Nachtrainieren ist nötig!
  • Die Nachvollziehbarkeit (wie das Ergebnis zustande kam) erfordert Extraaufwand.
  • Fragestellung zur Ethik von AI: Bias/Diskriminierung, Stromverbrauch …

Kundenbewertung

3/5 Sterne
Philip Dießner
Experte für IT-Architektur und Data Science

Was sagt der Experte

“ „Wir brauchen AI“ ist heutiger Slang für „wir müssen digitalisieren“. AI ist nur so gut, wie die Datenqualität, auf der sie trainiert wurde. AI ist also nur dann approved, wenn es richtig aufgezogen wurde.“

Der Mythos bei IoT ist:

"IoT ist super, da hängt man ein Gerät einfach ans Netz und schon tut sich eine neue Welt auf. Hip und cool und am besten immer und überall. Am besten macht man dann noch einen eigenen Dienst auf, dann kann man die Daten zweitverwerten!"

Wie sieht die Realität aus

Wie sieht die Realität aus

  • Grundsätzlich haben die meisten IoT Produkte im Consumerbereich vor allem ein Problem: Sicherheitsupdates gibt es nicht oder nur selten. So wird dann schon mal die Webcam im Schlafzimmer von einem Angreifer übernommen.
  • Viele IoT Geräte werden gehackt und als Botnetz für Angriffe missbraucht, ohne dass jemand das mitbekommt oder das Problem behoben wird.
  • Die Cloud die an vielen Geräten hängt klingt oftmals vielversprechend. Allerdings kann die 103te Cloud, in der ein Kunde nun einen Account haben soll, auch abschrecken. Der Mehrwert ist teilweise auch sehr überschaubar. Hätte sich die Spülmaschine nicht über mein Smartphone gemeldet, hätte ich gar nicht mitbekommen, dass sie fertig ist. </ironie>

Kundenbewertung

4/5 Sterne
Felix Eckhardt
Experte für IT-Architektur

Was sagt der Experte

„Natürlich gibt es Geräte, die davon profitieren wenn sie smart werden und über IoT mit einer Cloud kommunizieren. Man sollte sich aber fragen, wie hoch der Mehrwert wirklich ist. Der Betrieb der Cloud ist nicht gerade trivial und wenn das nicht meine Kernkompetenz ist, habe ich mit Pech auch noch eine Ransomware am Hals – meine Kunden sind einmal sauer, weil nix mehr geht (schöne Grüße ans smarte Türschloss) und nochmal, wenn ihre Daten geleaked werden. Dieses Risiko sollte man nur eingehen, wenn man es beherrschen kann und damit einen echten Mehrwert erzeugt.“

Der Mythos bei Cloudless ist:

"Da brauche ich keinen cloud provider und container mehr. Und es kostet mich weniger und bietet weniger Angriffssektoren!"

Wie sieht die Realität aus

Wie sieht die Realität aus

Du brauchst spezielle Hardware von Hewlett Packard „silicon root of trust“ ;). Ein „open and dynamic“™ Ökosystem erwartet dich… ist aber leider noch im Aufbau. Cloudless gibt’s so also noch gar nicht wirklich. Es ist spekulativ, eine rein ökonomisch getriebene Entwicklung. Und durch Vendor Lock-in ist man zusätzlich eingeschränkt.

Kundenbewertung

1/5 Sterne
Daniel Gräber
Experte für IT-Architektur

Was sagt der Experte

„Cloudless in dem Sinne ist einfach noch nicht ausgereift.“

Wie können wir zusammenarbeiten?

Sebastian Schuenemann

Director IT-Architektur

Sebastian Schuenemann

Director IT-Architektur

Schildern Sie uns Ihre Situation

Was haben Sie vor? Was sind mögliche Herausforderungen? Wir hören einfach erstmal nur zu.

Jetzt unverbindliches Gespräch anfragen

Jetzt Kontakt aufnehmen

    An welcher Leistung sind Sie interessiert?*

    Bevorzugter Kontaktkanal*

    Silpion verpflichtet sich, Ihre Privatsphäre zu schützen und zu respektieren. Wir verwenden Ihre persönlichen Daten nur zur Verwaltung Ihres Kontos und zur Bereitstellung der von Ihnen angeforderten Produkte und Dienstleistungen. Von Zeit zu Zeit möchten wir Sie über unsere Produkte und Dienstleistungen sowie andere Inhalte, die für Sie von Interesse sein könnten, informieren. Wenn Sie damit einverstanden sind, dass wir Sie zu diesem Zweck kontaktieren, geben Sie bitte unten an, wie Sie von uns kontaktiert werden möchten:

    Alle zum Thema Datenschutz entnehmen Sie unserer Datenschutzerklärung.

    Indem Sie unten auf „Einsenden“ klicken, stimmen Sie zu, dass Silpion die oben angegebenen persönlichen Daten speichert und verarbeitet, um Ihnen die angeforderten Inhalte bereitzustellen.


    Bitte beweise, dass du kein Spambot bist und wähle das Symbol Auto.