ZEIT ZUM MARKT

ZEIT ZUM MARKT

ZEIT ZUM MARKT

[ MVP ]

Erreichen Sie Ihr MinimumViable Product , um Ihr

Konzept zu testen.

ZEIT ZUM MARKT

[ MVP ]

Der Umfang deines MVP mussreduziert sein, während du deinProdukt vermarkten kannst.

Setzen Sie auf Early Adopters underhalten Sie ein Maximum anFeedback.

Ihr MVP ist in Produktionimplementiert und verwendbar.

ZEIT ZUM MARKT

[ FAIL-SCHNELL ]

Fail Fast ist learn schnell.

ZEIT ZUM MARKT

[ FAIL-SCHNELL ]

Erleben Sie schnell die Lösung(ein paar Wochen), sammeln SieFeedback von Ihren Benutzernund lernen Sie aus Ihren Fehlern.

Hab keine Angst, alles zu ändern **.

Vergiss nicht, du wirst scheitern!

ZEIT ZUM MARKT

[ KUSS ]

** Halten Sie es einfachund dumm.

Warum kompliziert,wenn es einfach sein

kann? *

ZEIT ZUM MARKT

[ KUSS ]

Vermeiden Sie zu viel Technik ,wenn ein "Papier" -Modell oder einGoogle-Formular ausreicht, um IhrKonzept zu testen, gehen Sie nichtweiter.

Bleib einfach! Sowohl technisch alsauch funktional.

ZEIT ZUM MARKT

[ PRODUCTIVITY ]

Geben Sie weniger an,erweitern Sie mehr.

ZEIT ZUM MARKT

[ PRODUCTIVITY ]

Begrenzen Sie Ihre Spezifikationenauf das Wesentliche,konzentrieren Sie sich auf das"Was" und nicht auf das "Wie".

Das Produkt muss möglichstselbst-dokumentiert sein.

Die Dokumentation muss genausowie der Code versioniert werden.

ZEIT ZUM MARKT

[ SAAS ]

SystematischeUntersuchung von SaaS -

Lösungen

ZEIT ZUM MARKT

[ SAAS ]

SaaS -Lösungen sind nachhaltigund kosteneffektiv.

In einigen Fällen kann SaaS dieImplementierung von MVP ****beschleunigen.

Denken Sie an die ökonomischeVision in Bezug auf dieAlternativen in Bezug aufGesamtkosten ( TCO : T otal C ostof O ** Wernship ) und nicht nurhinsichtlich der Lizenzkosten.

ZEIT ZUM MARKT

[ Herz des Geschäfts ]

Das Kerngeschäft sollteden Aufbau neuer Diensteund Anwendungen nicht

behindern.

ZEIT ZUM MARKT

[ Herz des Geschäfts ]

Das Tempo der Entwicklung undLieferung des Kerngeschäfts mussmit der Agilität der Dienste, die esverbrauchen, vereinbar sein.

Das Kerngeschäft mussDienstleistungen anbieten.

Das Kerngeschäft muss das Event-Driven -Prinzip übernehmen, esberichtet über Management-Aktionen in Form von Events.

ZEIT ZUM MARKT

[ KONTINUIERLICHEVERWENDUNG ]

Bereitstellung inProduktion ist ein Nicht-

Ereignis.

ZEIT ZUM MARKT

[ KONTINUIERLICHEVERWENDUNG ]

Profitieren Sie von derkontinuierlichen Bereitstellung ,um die **** Produktion *an*geschäftliche ** Anforderungenanzupassen und nicht umgekehrt.

Bereitstellungen in Umgebungen,bis zu Produktion , müssenautomatisiert und häufig sein.

ZEIT ZUM MARKT

[ PERPETUAL BETA ]

Der Perpetual Beta -Ansatz ermöglicht es

Ihnen, Ihre Benutzer in denEntwicklungsprozess

einzubeziehen.

ZEIT ZUM MARKT

[ PERPETUAL BETA ]

Fühlen Sie sich frei, das ewigeBetaprinzip zu verwenden, in demBenutzer an der Entwicklungteilnehmen.

Der Begriff "Perpetual Beta"bezieht sich auf eine Anwendung,die in Just-in-Time entwickeltwurde sich ständigweiterentwickelt und keinunvollständiges Produkt.

BENUTZERERFAHRUNG

BENUTZERERFAHRUNG

BENUTZERERFAHRUNG

[ WAHRNEHMUNG ]

Das vom Benutzerwahrgenommene **

Erlebnis ist grundlegend.

Ergonomie ist nichtverhandelbar.

BENUTZERERFAHRUNG

[ WAHRNEHMUNG ]

Vernachlässige nicht die Arbeit vonUX Designern , es ist grundlegendin der Entwicklung einerAnwendung.

Integrieren Sie das Feedback IhrerBenutzer, dieses ist wichtig.

BENUTZERERFAHRUNG

[ PERFORMANCE ]

Verwenden Sieleistungsfähige

Schnittstellen für interneund externe

Anwendungen.

BENUTZERERFAHRUNG

[ PERFORMANCE ]

Die Schnittstellen sind auf Effizienzausgerichtet.

Die Leistung einer Schnittstellespart Zeit , erhöht dieBenutzerzufriedenheit und spartsomit Frustration.

BENUTZERERFAHRUNG

[ MOBILE ZUERST ]

Verabschiedung einerMobile First Strategie.

BENUTZERERFAHRUNG

[ MOBILE ZUERST ]

Mobile Geräte sind der wichtigsteTeil des Marktes.

Mobile Denken denkt an dasWesentliche.

Responsive Design ist die Norm,es ist eine Quelle derEinsparungen (MVP).

BENUTZERERFAHRUNG

[ OMNI-KANAL ]

Anpassung an Nutzungen,der Omni-Channel ist die

Norm.

BENUTZERERFAHRUNG

[ OMNI-KANAL ]

Der Omni-Channel-Ansatz bietetdem Benutzer eine einheitlicheErfahrung (Beispiel: Netflix).

Die verschiedenen Kanäle sindsynchronisiert und kohärent (imGegensatz zu Batch-Prozessen).

Alle Akteure (Kunden, Berater)greifen auf dieselbenInformationen zu.

BENUTZERERFAHRUNG

[ SELBST-DATEN ]

**** Benutzer *sind* Besitzer** ihrer Daten und ihres

Kurses.

BENUTZERERFAHRUNG

[ SELBST-DATEN ]

Lassen Sie Personen jederzeit ihrepersönlichen Daten **kontrollieren.

Stellen Sie ein Vertrauen her,indem Sie Benutzern dieRückverfolgbarkeit und Kontrollein Echtzeit ermöglichen.

Subsysteme müssen die gleichenAnforderungen erfüllen.

BENUTZERERFAHRUNG

[ CRM / SFA ]

Die Kundenbeziehungmuss mit einem flexiblen,

einheitlichen undereignisgesteuerten CRM/ SFA vereinheitlicht undkontextualisiert werden.

BENUTZERERFAHRUNG

[ CRM / SFA ]

Entscheiden Sie sich für ein CRM ,das sowohl die Kundenbeziehungals auch die Führung desVerkaufspersonals verwaltet (SFA :S ales F orce A utomation) ).

CRM muss offen für neueMöglichkeiten sein.

CRM erzeugt Ereignisse , dieVerwaltungsaktionen entsprechen,die in die ereignisgesteuerteLogik der Plattform passen.

BENUTZERERFAHRUNG

[ GROSSE DATEN ]

Die Big Data-Plattformermöglicht Ihnen die

Zentralisierung und dieVerarbeitung von

Benutzerdaten, um IhreReise ** optimal zu

unterstützen.

BENUTZERERFAHRUNG

[ GROSSE DATEN ]

Zentralisieren Sie die Maif Group -,Partner - und Vendor -Daten ineiner Pathway -Logik.

"Datenvorbereitung" undVerarbeitung können die Daten **konsolidieren.

Big Data-Teams kooperieren mitFeature-Teams, um Daten -Governance sicherzustellen.

BENUTZERERFAHRUNG

[ Arbeitsplatz ]

Die Workstation istangepasst und an

Anwendungen undmoderne Kanäle

anpassbar.

BENUTZERERFAHRUNG

[ Arbeitsplatz ]

Übernehmen Sie den IdentityFederation für eine einheitlicheErfahrung.

Ein Portal ermöglicht eineÜbersicht , es ersetzt keineAnwendungen.

Die Workstation muss mobil ,Mehrkanal und Standard sein, umdas Öffnen innerhalb deserweiterten Unternehmens zuermöglichen.

BENUTZERERFAHRUNG

[ MITWIRKENDEN ]

Vergiss nicht, dass deineMitarbeiter moderne

Anwendungen zu Hause inUX verwenden.

BENUTZERERFAHRUNG

[ MITWIRKENDEN ]

Behandle all deine Nutzer als"Kunden" : Internetnutzer,Manager, Betreiber, Entwickler, etc…

Unterschätzen Sie den UX-Aufwand nicht, den Sie für interneVerwaltungsanwendungenimplementieren müssen.

BENUTZERERFAHRUNG

[ ALLE MESSUNGEN ]

Alles was gemessenwerden kann muss sein.

Ohne Maß, alles ist nurMeinung.

BENUTZERERFAHRUNG

[ ALLE MESSUNGEN ]

Denken Sie an die Metrikenwährend der Entwicklung derAnwendung. Logs müssen sowohleine geschäftliche als auch einetechnische ** Dimensionaufweisen.

Vernachlässige nicht dieLeistungsmetriken , sie sindfundamental.

Das Feature-Team stellt Operationzur Verfügung: Es ist dafürverantwortlich, die Anwendungnutzbar zu machen **.

BENUTZERERFAHRUNG

[ A / B-Prüfung ]

A / B Testing spart IhnenZeit, indem Sie Feedback

entscheiden lassen.

BENUTZERERFAHRUNG

[ A / B-Prüfung ]

Anstatt zwischen zwei Lösungenwillkürlich zu entscheiden, zögernSie nicht, A / B-Tests einzurichten.

Dieses Muster besteht aus derDarstellung von zweiverschiedenen Versionenderselben Anwendung und derAuswahl einer davon basierend aufobjektiven Kennzahlen derBenutzeraktivität.

BENUTZERERFAHRUNG

[ VERSCHLECHTERUNG ]

Berücksichtigen Sie dieVerschlechterung und

nicht dieBetriebsunterbrechung im

Falle eines Fehlers.

BENUTZERERFAHRUNG

[ VERSCHLECHTERUNG ]

Bei Ausfall eines der Subsystememuss eine degradierte Versiondes Services ** in erster Linie alseine Unterbrechung angesehenwerden.

Mit Circuit Breakers , Isolieren Sieeine Aufschlüsselung bisVermeiden Sie ihre Auswirkungund Aufspreizung über dasgesamte System.

HUMAN

HUMAN

HUMAN

[ FEATURE TEAM ]

Das Team ist um einProdukt oder einen

Service herum organisiert.

HUMAN

[ FEATURE TEAM ]

Teams sind Feature Teams, die umeinen zusammenhängendenFunktionssatz herum organisiertsind und aus all den Fertigkeitenbestehen, die für diesen Satznotwendig sind.

Zum Beispiel: Business Expert +Webentwickler + Java Developer +Architect + DBA + Operational.

Die Verantwortung ist kollektiv,das Feature-Team hat die Macht,die für diese Verantwortungnotwendig ist.

HUMAN

[ 2-PIZZA TEAM ]

Begrenzen Sie die Größevon Feature Teams (von 5

bis 12 Personen).

HUMAN

[ 2-PIZZA TEAM ]

Begrenzen Sie die Größe einesFeature-Teams: zwischen 5 und 12Personen.

Unter 5 ist sie zu empfindlich fürexterne Ereignisse und es fehlt ihran Kreativität. Über 12 verliert es anProduktivität.

Der Begriff "2-Pizza-Team" zeigtan, dass die Größe des Feature-Teams die Anzahl der Personen,die mit zwei Pizzen gefüttertwerden können, nichtüberschreiten sollte.

HUMAN

[ Künstliche Software ]

Wetten Sie auf vielseitigeLeute, die wissen und wer

gerne tun.

HUMAN

[ Künstliche Software ]

Am wichtigsten ist die Kultur derEntwicklung, Skalierbarkeit undAnpassungsfähigkeit.

Recruiting Software-Handwerkerund Full-Stack-Entwickler ,bringen sie einen echten Mehrwertdurch ihr Know-how und ihreallgemeine Vision.

Mobile Entwickler sind zumBeispiel in der Regel spezialisierteEntwickler.

HUMAN

[ STELLEN ]

Sei attraktiv um denbesten zu rekrutieren.

HUMAN

[ STELLEN ]

Stellen Sie Arbeitsweisen vor, diean die Mitarbeiter angepasst sind:Mobilität, Heimarbeit, CYOD(Choose Your Own Device.

Lassen Sie Zeit für Experimenteund machen Sie es in derArbeitszeit möglich.

HUMAN

[ EVE ]

Die Organisation muss eineSchlafmaschine sein

Der Tag davor ist Teil desJobs.

HUMAN

[ EVE ]

Die Organisation muss eineTagespflege -Maschine sein,indem sie Systeme wieWeiterbildung oder Business-Universitäten einrichtet.

Fühlen Sie sich frei, sie mit andereninformellen Möglichkeiten zukombinieren, wie: Coding Dojos,Brown Bag Lunchs, externeKonferenzen.

HUMAN

[ CO-KONSTRUKTION ]

Brechen Sie die Barrierenzwischen den Trades,

wetten Sie auf dieKonvergenz -Ziele.

HUMAN

[ CO-KONSTRUKTION ]

Um die Barrieren zwischen denGewerken zu überwinden, reichtes nicht aus, Menschen an einemgemeinsamen Ort um eingemeinsames Produkt herum zugruppieren.

Die Agile Approaches beseitigendiese Hindernisse, um eineKonvergenz der Ziele zugewährleisten **.

Diese Praktiken sind einwesentlicher Bestandteil derSchlüssel zum Erfolg, dieOrganisation ist der Garant.

HUMAN

[ DEVOPS ]

DevOps -Praktikenermöglichen es Wänden,

zwischen Build und Run zufallen.

HUMAN

[ DEVOPS ]

Adoptiere DevOps , um Dev undOps zu einem gemeinsamen Zielzusammenzuführen: Diene derOrganisation.

Die Trades bleiben anders !DevOps bedeutet nicht, dassdieselbe Person die Aufgaben vonDev und Ops ausführt. Entwicklerund Operational müssenzusammenarbeiten , um von ****Skills *profitieren* und Empathie zuverbessern.

HUMAN

[ PAIN ]

Schwierige Aufgabenwerden vom Feature-

Team durchgeführt.

Die Automatisierung folgt.

HUMAN

[ PAIN ]

In einer traditionellen Organisationhängt mangelndes Verständniszwischen Teams normalerweisemit Entfernung und ** mangelnderKommunikation zusammen.

Die Mitglieder eines Feature-Teams sind mitverantwortlich undsolidarisch für alle Aufgaben.

Schmerz ist ein Schlüsselfaktor fürKontinuierliche Verbesserung.

HUMAN

[ CDS ]

Die Servicezentren sindschwer mit der kollektiven

Verpflichtung zuvereinbaren.

HUMAN

[ CDS ]

Feature Teams basieren aufPrinzipien, die stark vonCollaboration und kollektivemEngagement abhängen.

Die Dienstleistungszentren strebeneine Rationalisierung undKonsolidierung der IT durch dieUnternehmen an, was dieserVorstellung von kollektivemEngagement widerspricht.

HUMAN

[ VALIDIERUNG ]

Die Organisation hat dieValidierungsfunktion,

ohne dogmatisch zu sein.

HUMAN

[ VALIDIERUNG ]

Stellen Sie sicher, dass dieOrganisation ihre Validierungsrollefür Tools und Verwendungenbeibehält. Insbesondere zu denWerkzeugen, die das Erbebetreffen (Beispiel: Verwaltungdes Quellcodes).

Bieten Feature-Teams mitbedeutet , ihre Auswahl zuunterstützen.

Sei nicht dogmatisch undversichere dich, dass duExperimente anregen kannst.

HUMAN

[Transversalitätsbedingung]

Von den Feature Teamswird erwartet, dass sie

kommunizieren und ihreErfahrung und

Fähigkeiten teilen.

HUMAN

[Transversalitätsbedingung]

Schaffe keine Barrieren zwischenFeature Teams.

Richten Sie eine Organisation unddie Agilität ein, die für Feature-Teams erforderlich ist, ummiteinander zu kommunizierenund ihre Fähigkeiten undErfahrungen zu teilen.

Die Organisation derTransversalität in Spotify (Stämme,Kapitel und Gilden) ist ein beredtesBeispiel.

INTEROPERABILITÄT

INTEROPERABILITÄT

INTEROPERABILITÄT

[ API für alle ]

APIs für alleAnwendungen : intern,

Kunden und Partner,öffentlich.

INTEROPERABILITÄT

[ API für alle ]

Öffnen Sie Ihre Organisation fürneue Anwendungen und neueKunden mit Public APIs.

In kommerziellen Partnerschaften, Kunden als Provider ** sind APIsdas Standardaustauschformat.

APIs sollen auch für interneVerwendungen der Organisationverwendet werden.

INTEROPERABILITÄT

[ SELBSTBEDIENUNG ]

Verwenden Sie eine APImuss einfach und schnell

sein.

INTEROPERABILITÄT

[ SELBSTBEDIENUNG ]

Die Verwendung von APIs sollte soeinfach wie möglich sein. DenkenSie an die Entwicklererfahrung.

Die beste Lösung, um dieAngemessenheit mit derNotwendigkeit zu überprüfen, ist,die API schnell zu testen : ein paarMinuten müssen genügen!

Die Plattform muss eine grafischeSchnittstelle bieten, um die APIeinfach zu testen.

INTEROPERABILITÄT

[ API-Verwaltung ]

Die Verwendung der APIsmuss kontrolliert undkontrolliert werden.

INTEROPERABILITÄT

[ API-Verwaltung ]

Implementieren Sie eine API-Verwaltungslösung zum Verwaltenvon Kontingenten, Drosselung,Authentifizierung undProtokollierung.

Sammeln Sie Messwerte zurVerwaltung von Überwachung,Filterung und Berichterstellung.

INTEROPERABILITÄT

[ ANFORDERUNGEN ]

Legen Sie Anforderungenfür externe Systeme und

Dienste fest, die in diePlattform integriert sind.

INTEROPERABILITÄT

[ ANFORDERUNGEN ]

Erfordern externe Systemeerfüllen die gleichenAnforderungen wie interneSysteme.

Externe Systeme müssenEreignisse veröffentlichen undtechnische Überwachungzulassen.

Für den Fall, dass die externenSystemdaten integriert werdenmüssen, muss die GesamtSynchronisation möglich sein.

INTEROPERABILITÄT

[ MULTI-MIETER ]

Die Architektur muss alsMulti-Tenant betrachtet

werden.

INTEROPERABILITÄT

[ MULTI-MIETER ]

Auch wenn die weiße Markierungan der Basis nicht berücksichtigtwird, richten Sie eine Multi-Tenant-Architektur ein. Ihre ursprünglicheAnwendung ist die ersteHalterung.

Denken Sie von Anfang an an diemultifunktionale Instanziierungdes Systems.

INTEROPERABILITÄT

[ EINSTELLUNG ]

Die Systeme müssen nativkonfigurierbar sein.

INTEROPERABILITÄT

[ EINSTELLUNG ]

Sprachen, Währungen,Geschäftsregeln,Sicherheitsprofile müssen einfacheinzustellen sein.

Vorsicht vor Hyper-Generizität , esist oft nutzlos und Kostenquelle.

Das Setup muss skalierbar undschnell wie erforderlich sein.

INTEROPERABILITÄT

[ FEATURE FLIPPING ]

Erstellen Sie flexible undgenerische Systeme mit

Feature-Flipping.

INTEROPERABILITÄT

[ FEATURE FLIPPING ]

Feature Flipping bedeutet, eineApp als eine Reihe von Funktionenzu gestalten, die aktiviert oderdeaktiviert heiß, Produktion seinkönnen.

In einer Multi-Tenant -Anwendungermöglicht das Feature-Flipping **das Anpassen von Unterstützern.

Das Feature flip vereinfacht die A/ B-Prüfung.

Spielregeln

Spielregeln

Spielregeln

[ TECHNISCHE WAHLEN ]

Die technischenEntscheidungen werden

vom Feature-Teamgetroffen und **angenommen.

Spielregeln

[ TECHNISCHE WAHLEN ]

Das Feature-Team mussverantwortungsvoll handeln , umdie Auswahlmöglichkeiten zuidentifizieren, die sichausschließlich auf das Feature-Team auswirken, sowie dieAuswahlmöglichkeiten, die sich aufdas Unternehmen auswirken.

Die Optionen , die den Umfangdes Feature-Teams überschreiten(z. B. Lizenz, selteneProgrammiersprache), müssen von

der Organisation oder durch denPeer-Konvergenzprozess validiertwerden .

Spielregeln

[ Guter Gebrauch ]

Das richtige Werkzeug fürgute Nutzung ist eine

Ersparnisquelle.

Spielregeln

[ Guter Gebrauch ]

Ein schlechtes Werkzeug , dasallen auferlegt wird, ist ein Risiko.Der Missbrauch eines guten Toolskann sehr schädliche Folgenhaben **. Zum Beispiel sindschlecht verwendete Agile-Methoden gefährlich.

Werkzeuge müssen befragtwerden.

Excel ist oft eine vernünftige Wahl, aber es ist nicht ein Werkzeug,um alles zu tun ** (CRM, ERP,Datamart, …)

Spielregeln

[ BUILD VS. KAUFEN ]

Privileg Build für dasKerngeschäft.

Betrachten Sie Buy für denRest, von Fall zu Fall.

Spielregeln

[ BUILD VS. KAUFEN ]

Je mehr ein Tool eine Funktion zurDifferenzierung für dieOrganisation aufweist, desto mehrsoll es gebaut werden. DasKerngeschäft muss Spezifitätermöglichen und sich schnell undoft anpassen. EinigeSoftwarepakete werdenmanchmal an diesen Bedarfangepasst.

Für den Rest : SaaS, Open Source,Build oder Owner sind von Fall zuFall zu untersuchen **.

Spielregeln

[ OPEN SOURCE ]

Machen Sie das Beste ausOpen Source.

AlternativeAuswahlmöglichkeiten

müssen unterstütztwerden.

Spielregeln

[ OPEN SOURCE ]

Die proprietären Lösungen sindein Risiko für die Organisation, diein der Lage sein muss, dieWartung bei Bedarf fortzusetzen.

Es gibt wenige proprietäre Tools,die keine Open-Source-Alternativen haben.

Die Organisation profitiert von derOpen Source Community undkann ihre Beiträge zurückzahlen.

Spielregeln

[ MICRO-DIENSTE ]

Develop Stand-alone undschwach gekoppelte

Dienste.

Spielregeln

[ MICRO-DIENSTE ]

schwache Kopplung muss dieNorm sein.

Jeder Micro-Service hat eine klardefinierte Schnittstelle.

Diese Schnittstelle bestimmt denLink zwischen den Micro-Services.

Domain Driven Design erlaubt,insbesondere mit den BoundedContexts , dieses Problemvorherzusehen.

Spielregeln

[ DATA ]

Jeder Dienst hat seineigenes **

Datenspeichersystem.

Spielregeln

[ DATA ]

Ein Data Store soll nur mit einemeinzigen Micro-Service **gekoppelt sein.

Der Zugriff auf Daten von einemMicro-Service zu einem anderenerfolgt ausschließlich über seineSchnittstelle.

Dieses Design bedeutetKonsistenz über die Zeit hinwegauf der gesamten Plattform. Esmuss auf allen Ebeneneinschließlich UX aufgegriffenwerden.

Spielregeln

[ SCOPE ]

Jeder Micro-Service musseinen angemessenen

Funktionsumfang haben,der "in den Kopf passt".

Spielregeln

[ SCOPE ]

Ein Micro-Service bietet eineangemessene Anzahl vonFunktionen.

Zögere nicht, einen Micro-Servicezu schneiden, wenn es anfängt zuwachsen.

Ein Dienst von angemessenerGröße macht es möglich, dasUmschreiben ** gelassen zubetrachten, wenn dieNotwendigkeit besteht.

Spielregeln

[ RESPONSIVE ]

Das Reaktive Manifestöffnet den Weg zurGestaltung reaktiver

Architekturen.

Spielregeln

[ RESPONSIVE ]

Responsive Programmierungkonzentriert sich auf denDatenfluss und die Verbreitungvon Änderungen. Es basiert aufdem Muster " Beobachter " imGegensatz zu dem Ansatz "Iterator ", traditioneller.

Das Reaktive Manifest legt diegrundlegenden Achsen fest:Verfügbarkeit undGeschwindigkeit, Ausfallsicherheitfür Zusammenbrüche, Flexibilität ,Elastizität undNachrichtenorientierung.

Spielregeln

[ ASYNC-ERSTE ]

asynchrone Prozessebevorzugen Entkopplung

und Skalierbarkeitzugunsten Leistung.

Spielregeln

[ ASYNC-ERSTE ]

Der Austausch zwischenAnwendungen muss zuerst **asynchron sein.

Asynchrone Austausche erlauben**** *-* - - - - und **** - *-* - **** - *-* -- - **** **.

synchrone Kommunikation solltenur berücksichtigt werden, wenndie Aktion es erfordert.

Spielregeln

[ EVENTS ]

Das Informationssystemmuss Ereignisse orientiert

sein.

Spielregeln

[ EVENTS ]

Die **** ereignisgesteuerten*funktionalen* Prozesse sindnatürlich **** asynchron **implementiert.

Die Event Orientation ermöglichtdie Implementierung von Ansätzenwie C ommand Q sehr RVerantwortlichkeit S egregation(CQRS) und Event Sourcing.

Spielregeln

[ Nachrichtenbroker ]

Privilegieren Sie eineneinfachen, robusten und

leistungsfähigenMessage-Broker zu einer

"Smart Pipe".

Spielregeln

[ Nachrichtenbroker ]

ESB zeigte Grenzwerte :Skalierbare Wartung ist kritisch ,sowohl von technischer als auchorganisatorischer Sichtweise.

**** Broker *-Nachrichten wie* Kafkabieten eine einfache , dauerhafteund belastbare Lösung.

Intelligente Endpunkte undEinfache Pipes ist eine Architektur,die im Maßstab funktioniert: es istInternet.

Spielregeln

[ STEUER ]

Die vollständigeSynchronisation des

Systems sollteberücksichtigt werden,sobald es entworfen

wurde.

Spielregeln

[ STEUER ]

Wenn die Synchronisationzwischen zwei Systemen durcheinen Ereignisfluss sichergestelltwird, muss dieGesamtsynchronisation dieserSysteme zur Entwurfszeit geplantwerden.

Ein automatisches *****Synchronisations-Audit* (Beispiel:per Stichprobe) erlaubt es,mögliche Synchronisationsfehlerzu messen und zu erkennen.

Spielregeln

[ ZENTRALISIERUNG ]

Die Konfiguration derDienste ist zentralisiert,ihre Entdeckung wirddurch ein Verzeichnis

gewährleistet.

Spielregeln

[ ZENTRALISIERUNG ]

Die Konfiguration der Micro-Services ist zentralisiert für alleUmgebungen.

Ein zentrales Verzeichnisgewährleistet dynamischeErkennung von Micro-Services.

Die **** globale *Skalierbarkeit*hängt von diesem Verzeichnis ab.

Spielregeln

[ SAND-FACH ]

Feature-Teams bieten eineSandbox-Umgebung.

Spielregeln

[ SAND-FACH ]

Feature Teams unterhalten eineSandbox -Umgebung (aktuelleVersion und bevorstehendeVersion), um anderen Teams dasScale-up zu ermöglichen.

In einigen nicht-nominalen Fällenkönnen Funktionen in derEntwicklungsumgebung ****deaktiviert sein.

Spielregeln

[ Design für Fehler ]

Ihr System wirdabstürzen!

Entwerfen Sie es so, dasses tolerant ist.

Spielregeln

[ Design für Fehler ]

Ihr System wird abstürzen, es istunvermeidlich. Es muss dafürausgelegt sein (Design ForFailure).

Predict Redundanz auf allenEbenen: Hardware (Netzwerk,Festplatte, etc.), Anwendungen(mehrere Instanzen vonAnwendungen), geographischeZonen, Anbieter (Beispiel: AWS +OVH)

Spielregeln

[ Werkzeugkits ]

Stellen Sie Toolkits zurVerfügung, stellen Sie

keine strengenFrameworks auf.

Spielregeln

[ Werkzeugkits ]

Achtung auf die technischenKomponenten Häuser und Quer !Sie sind restriktiv, teuer undschwer zu warten.

Beschleuniger , Toolkits ,technische Stacks könnenzusammengefasst , frei Feature-Teams sein, die einendogmatischen Ansatz vermeiden.

Spielregeln

[ WOLKE ]

Öffentlich, privat oderhybrid, die Cloud (IaaS

oder PaaS) ist derStandard für die

Produktion.

Spielregeln

[ WOLKE ]

PaaS -Dienste sind bevorzugt,einfach und skalieren schnell.

IaaS -Dienstleistungenermöglichen es Ihnen, Fälleanzugehen, die eine größereFlexibilität erfordern, aber mehroperative Arbeit erfordern.

Eine Private Cloud ist keineherkömmlicheVirtualisierungsumgebung, sieberuht auf Standardhardware.

Spielregeln

[ INFRASTRUKTUR ]

Feature Teams verwaltendie Infrastruktur nicht, sie

wird von der Organisationbereitgestellt und

verwaltet.

Spielregeln

[ INFRASTRUKTUR ]

Infrastrukturprobleme gehörennicht zu Feature Teams. DieInfrastruktur muss durch einenfunktionsübergreifenden Dienstbereitgestellt und ** gewartetwerden.

Spielregeln

[ CONTAINER ]

Container bieten dieFlexibilität, die für

heterogene Werkzeugebenötigt wird.

Spielregeln

[ CONTAINER ]

Container bieten die Flexibilität ,die Feature Teams benötigen, umheterogene Werkzeuge in einemhomogenen Kontext zu aktivieren.

Spielregeln

[ ENVIRONMENTS ]

Die Verwendung vonContainern ermöglicht es,

die Probleme dertechnischen Umgebung

zu überwinden.

Spielregeln

[ ENVIRONMENTS ]

Die Container (Beispiel: Docker)ermöglichen ** die Befreiung vonden Umgebungsdifferenzen.

Der Bereitstellungsprozess mussfür die Umgebung agnostischsein.

Einige Komponenten wieDatenbanken sollten nicht inContainern bereitgestellt werden.Ihr Einsatz ist noch automatisiert.

Spielregeln

[ METRIC ]

Maßnahmen müssenzentralisiert und für alle

zugänglich sein.

Spielregeln

[ METRIC ]

Die Messwerte sind für alleBenutzer mit unterschiedlichemDetaillierungsgrad zugänglich:Detailansicht für das jeweiligeTeam-Feature, Aggregationen fürandere Mitglieder desUnternehmens.

Der Zugriff auf Metrik bedeutetnicht den Zugriff auf die Datender Einheit , sie muss kontrolliertwerden, um die Vertraulichkeit zuwahren.

Alle Umgebungen sind betroffen.

Spielregeln

[ QUALITÄT ]

Softwarequalität ist einSchlüsselfaktor.

Spielregeln

[ QUALITÄT ]

Code Reviews sind systematisch.Sie werden von Mitgliedern desFeature Teams oder anderenMitgliedern der Organisation imRahmen von ContinuousImprovement durchgeführt.

Das ist nicht auditiert, aber deinCode : "Du bist nicht dein Code!".

Die Qualimetrie kann teilweiseautomatisiert werden, aber nichtsschlägt das neue Auge.

Spielregeln

[ AUTOMATISIERTE TESTS]

automatisiertes Testen isteine nicht verhandelbare

Voraussetzung für diekontinuierlicheBereitstellung.

Spielregeln

[ AUTOMATISIERTE TESTS]

Automatisierte Testsgewährleisten die Qualität desProdukts im Laufe der Zeit.

Es ist eine Voraussetzung für diekontinuierliche Bereitstellung, es**** Änderungen *und* häufigeBereitstellungen ** ermöglicht.

Der Production Rollout wird zueinem anekdotischen Event!

Spielregeln

[ TESTSTUFEN ]

Tests auf allen Ebenen :Einheit, Integration,

Funktionalität,Belastbarkeit, Leistung.

Spielregeln

[ TESTSTUFEN ]

Die Tests Integration undFunktional sind die wichtigsten,sie garantieren den effektivenBetrieb.

Einheit -Tests sind fürEntwicklung geeignet.

Leistung Tests messen dieLeistung im Zeitverlauf.

Resilience -Tests helfen Fehlervorwegzunehmen.

Spielregeln

[ COVER ]

Cover ist der primäreZielindikator für die

Testqualität.

Spielregeln

[ COVER ]

Die Codeabdeckung der Tests isteine gute Metrik der Codequalität.

Dies ist eine notwendigeBedingung, aber nichtausreichend , die Abdeckungeiner schlechten Teststrategiekann hoch sein, ohne die guteQualität des Codes zu garantieren.

Spielregeln

[ SICHERHEIT ]

Sicherheit ist ein Prozess ,sollte nicht als Reaktionauf Probleme behandelt

werden.

Spielregeln

[ SICHERHEIT ]

Sicherheitsexperten können beiBedarf direkt in Feature-Teamsintegriert ** werden.

Sicherheitsexperten sind in derOrganisation für Audit , Awarenessund Forward verfügbar.