IT-Beratung und Software-Architektur

IT-Architektur ist Kollaboration

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

Wenn ich Architektur für System betreue, geht es nicht nur um ein System. Ich muss verstehen, wie ein System für Menschen funktioniert, was die Anforderungen sind und 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

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
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 System betreue, geht es nicht nur um ein System. Ich muss verstehen, wie ein System für Menschen funktioniert, was die Anforderungen sind und 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
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
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.

Ihr Produkt muss zu Ihrer Organisation passen

Immer wieder kommen wir in die Verlegenheit, Projekte aus dem sumpf 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 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: Raketen starten immer wieder und explodieren. Er selber sieht dies als Weg zum Erfolg. Sicher ist eine so positive Haltung nicht in jeder Situation zutreffend, eine Rakete darf ggf. versagen, ihr Projekt nicht. Wie arbeiten und leben wir damit gemeinsam?

  • Fehlerkultur etablieren (Reviews, Retro, disruptive Weiterentwicklung akzeptieren)
  • Teams nach XY zuordnen und sortieren
  • Ressourcen
  • In den Product-Cycle kommen
  • Gemeinsame Arbeitsweise analysieren und optimieren

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

Ein Erfolgsrezept kann es nicht geben, dann 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

Ihr Produkt muss zu Ihrer Organisation passen

Immer wieder kommen wir in die Verlegenheit, Projekte aus dem sumpf 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
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: Raketen starten immer wieder und explodieren. Er selber sieht dies als Weg zum Erfolg. Sicher ist eine so positive Haltung nicht in jeder Situation zutreffend, eine Rakete darf ggf. versagen, ihr Projekt nicht. Wie arbeiten und leben wir damit gemeinsam?

  • Fehlerkultur etablieren (Reviews, Retro, disruptive Weiterentwicklung akzeptieren)
  • Teams nach XY zuordnen und sortieren
  • Ressourcen
  • In den Product-Cycle kommen
  • Gemeinsame Arbeitsweise analysieren und optimieren

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

Ein Erfolgsrezept kann es nicht geben, dann 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, 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

Sven Allers

Software Engineer
Jetzt kontaktieren

Projekte und Produkte skalieren

Sinnvoll skalieren ist das Thema. 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, nicht 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, 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).

Hier die typischen Bereiche des Produkt-Wachstums 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, 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
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 das Thema. 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, nicht 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, 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).

Hier die typischen Bereiche des Produkt-Wachstums 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

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.

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.


Menü