Wie führen wir bei Yalantis einen Architekturbewertungsprozess mit TOGAF durch?

Wenn Sie nach einem zuverlässigen Team suchen, das eine architektonische Bewertung durchführt, sollten Sie sicherstellen, Ihr Ansatz ist genau das Richtige für Sie und deckt Ihre geschäftlichen Anforderungen ab. Es gibt verschiedene Bewertungsverfahren, darunter das The Open Group Architecture Framework (TOGAF) und die Architecture Tradeoff Analysis Method (ATAM), wobei jedes von ihnen eigene Anwendungsfälle und Architektur-Checklisten umfasst.

In diesem Artikel werden wir Ihnen die Architekturbewertungsprozesse bei Yalantis anhand des TOGAF-Ansatzes vorstellen und Ihnen die wichtigsten Aspekte jeder Phase näherbringen.

Aber bevor wir zu einer schrittweisen Bewertung übergehen, lassen Sie uns zunächst prüfen, welche Probleme dazu führen können, dass Sie entscheiden, dass Ihr Unternehmen eine Architekturbewertung benötigt.

Jedes der folgenden Szenarien zeigt, dass in Ihrem Unternehmen aufgrund von Architekturproblemen etwas Wichtiges fehlt. Eine Architekturbewertung kann Ihnen dabei helfen, alle Schwächen Ihres Systems zu erkennen und das Hauptproblem zu identifizieren sowie eine einzigartige Lösung vorzuschlagen, die perfekt zu Ihren Geschäftsprozessen passt. 

1. Sie können Ihr Unternehmen nicht effektiv weiterentwickeln, weil die Integration oder die Architektur nicht optimal sind. Nehmen wir an, Sie können die Bestellmenge nicht skalieren, da aufgrund einiger Integrationen Fehler auftreten und die Qualität der Bestellungen beeinträchtigt wird. Schließlich verlangsamt dies Ihre Geschäftsprozesse, und Sie können Ihr Geschäft nicht weiter ausbauen, da mit zunehmender Bestellmenge auch die Anzahl der Probleme zunimmt. Sie könnten außerdem den Bedarf sehen, eine Strategie für die Planung und Implementierung von Hochkapazitive und fehlerverträgliche Architektur für Ihr Software-Ökosystem.
2. Sie wollen einen Wettbewerbsvorteil erzielen. Sie denken wahrscheinlich darüber nach, in Bezug auf die Vielfalt der Produkte oder Dienstleistungen, die Zahlungsarten, die Geschwindigkeit der Website und die Liefergeschwindigkeit oder -kanäle besser als Ihre Wettbewerber zu sein.
3. Es gibt Performance-Probleme, die seit langem nicht behoben wurden. Sie könnten Probleme mit der Performance Ihrer Website oder Ihrer Anwendungen haben. Wenn eine Webseite fünf bis sechs Sekunden dauern muss, werden Ihre Kunden wahrscheinlich die Seite verlassen. Das bedeutet, dass die Servicequalität in der Folge sinken wird, und damit auch Ihre Einnahmen.
4. Ein erwarteter Verkauf oder eine Investitionsrunde steht bevor. In diesen Fällen führt ein Unternehmen in der Regel eine Architekturbewertung des technologischen Aspekts des Unternehmens durch.
5. Das Ingenieurgesetzteam ist frustriert und die Abgabetrate ist hoch. Dies ist oft das Ergebnis von Problemen in der Architektur der Prozesse. Zum Beispiel können Mitarbeiter aufgrund komplizierter und ineffizienter bürokratischer Prozesse den Job verlassen.
6. Es gibt Probleme in Bezug auf die operative Tätigkeit und das Personal. Viele manuelle Prozesse oder langsame Abläufe bei bestimmten Mitarbeitern können die gesamte Geschäftstätigkeit verlangsamen.
7. Sie müssen die Geschwindigkeit Ihrer Entwicklungsteams erhöhen. Wenn ein Unternehmen ein gewisses Maß an Erfolg erreicht, muss es seine Systeme auf ein höheres Niveau upgraden, um weitere Fortschritte zu erzielen. Um solche Änderungen effektiv durchzuführen, benötigt das Unternehmen ein Team von Ingenieuren, und um solche Änderungen schnell durchzuführen, braucht es eine große Anzahl von Ingenieuren. Data-Engineering-Dienste Dies kann die Integration und Verarbeitung von Daten vereinfachen und Ihrem Team ermöglichen, sich auf die Verbesserung der Kernfunktionen zu konzentrieren. Sie könnten planen, Ihr Team von vier auf 20 Entwickler zu erweitern. In diesem Fall ist es wichtig, eine Architekturbewertung durchzuführen, um festzustellen, wie diese Personen effektiv zusammenarbeiten werden. Wenn Ihr Architekt die Arbeit korrekt in Teams und die Teams in das System aufteilt, können dann viele Menschen effizient zusammenarbeiten. Wenn die Teamaufteilung nicht korrekt erfolgt, entstehen unnötige Abhängigkeiten zwischen Systemen und Teams, was zu einer geringen Geschwindigkeit führt.

Da nun ein Verständnis dafür besteht, wann auf die Anwendungsarchitektur geachtet werden muss, gehen wir nun Schritt für Schritt in die Architekturbewertung ein.

Es gibt keine universelle Softwarearchitektur-Bewertungsvorlage, die für alle Fälle geeignet ist. Das Open Group Architecture Framework (TOGAF) Kann eine gute Wahl sein, wenn Sie eine Bewertung für ein großes Unternehmen durchführen müssen, während Architektur-Tradeoff-Analyseverfahren (ATAM) Es ist besser für kleinere Unternehmen.

Wir möchten den TOGAF genauer betrachten, da wir dieses Architekturbewertungswerkzeug bei Yalantis verwenden. Neben seiner hervorragenden Benutzerfreundlichkeit bietet der TOGAF einen integrierten Ansatz für das Design, die Planung, den Übergang, die Umsetzung und das Management einer Unternehmensinformationstechnologie-Architektur. Folgende Übersicht zeigt das gesamte TOGAF-Zyklus-Modell.

Wenn Yalantis-Experten eine Architekturbewertung für einen Kunden durchführen, übernimmt der Yalantis-Architekt die Schritte A bis D/F. Wenn Yalantis-Experten aber auch die Produktimplementierung durchführen, übernehmen wir auch die übrigen Schritte.

Nach dem TOGAF kann die Softwarearchitektur in drei Hauptschichten dargestellt werden:

• Geschäftsanalyse, das die Unternehmensstrategie, die Führungsstruktur und die wichtigsten Geschäftsprozesse definiert
• Architektur von Informationssystemen (Datenarchitektur und Anwendungsorientierte Architektur), das beschreibt die Geschäftsprozesse und Regeln, die Systemstruktur, den technischen Rahmen und die Produkttechnologien für ein Unternehmens- oder Organisationsinformationssystem 
• Technologielandschaft, das die Struktur und die Logik der für Unternehmensanwendungen erforderlichen Software- und Hardwareumgebungen sowie den Zugriff auf die notwendigen Daten definiert; umfasst alle unterstützende Infrastruktur: Netzwerke, Server, Verarbeitung usw.

Bei Yalantis glauben wir, dass die beste Praxis in diesem Beispiel für die Architekturbewertung, TOGAF, darin besteht, drei Kernstufen gemäß dem Bild oben durchzuführen – die Business-, Anwendung- und Technologieebene. Durch diese Vorgehensweise können wir das Gesamtbild des Architekturbewertungsprozesses erkennen. So können wir während unserer Arbeit die Phasen innerhalb jeder Ebene aktualisieren. Wenn wir die Ebenen nicht parallel durchlaufen, werden einige der wichtigsten Prozesse unsichtbar, was die Ergebnisse Ihres Unternehmens beeinträchtigen könnte.

Lesen Sie Dieser Artikel Wenn Sie Interesse daran haben, mehr über die Kernstufen der App-Entwicklung bei Yalantis zu erfahren, die Best Practices bei der Entwicklung anzuwenden und die Kontinuität und Stabilität der Entwicklung zu gewährleisten. Oder versuchen Sie, mehr über Mikroservices-Architektur im Bankwesen.

Lassen Sie uns die Phasen A bis F von TOGAF betrachten, die Yalantis behandelt.

Die Phase der Architekturvision stellt den Startpunkt des TOGAF-Ansatzes dar. Das Ziel dieser Phase besteht darin, die wichtigsten Anforderungen der Stakeholder zu verstehen und die notwendigen Informationen für Ihre zukünftige Architekturvision zu erhalten. Die wichtigsten Stakeholder sind die Schlüsselakteure, mit denen die Architekturbewertung beginnt und auf die der Prozess immer zurückgreift.

Im Rahmen der Architekturvisionphase müssen Yalantis-Experten von Anfang an die wichtigsten Ziele, die Interessengruppen und die Strategie zur Interaktion mit diesen definieren. Um dies zu erreichen, gehen wir folgendermaßen vor:

Schritt 1. Identifizieren Sie wichtige Akteure, die einflussreich und von Interesse sind

Wichtige Mitarbeiter könnten der CEO, der COO, der Produktverantwortliche, der technische Manager und der CTO sein. Es ist am besten, bereits in den frühen Phasen möglichst viele Stakeholder einzubinden, um herauszufinden, was sie erreichen möchten. Dann verwenden wir Maddelows Matrix. 

Schritt 2. Festlegen einer Strategie zur Steuerung der Stakeholder

Nachdem wir die wichtigsten Akteure identifiziert haben, bestimmen wir, wie wir mit den wichtigsten Stakeholdern in dem Unternehmen des Kunden interagieren. Dazu nutzen wir Ansätze wie Stakeholder-Management und Stakeholder-Engagement. In diesem Schritt prüfen und planen wir, wie Besprechungen oder andere Interaktionen mit den wichtigsten Stakeholdern geplant werden sollen. 

3. Analysieren Sie, wie das Unternehmen funktioniert

Nachdem wir das zentrale Ziel identifiziert haben, sammeln wir zusätzliche Informationen, die Folgendes umfassen können:  

• Wie das Geschäft funktioniert (was man herstellen und verkaufen kann, wo man dieses Produkt oder diese Dienstleistung beziehen kann)
• Wer die Kunden sind (wer die Zielgruppe ist)
• Wie und warum Kunden bedienen (über welche Kanäle, Anwendungen oder persönliche Kontakte)?
• Welche Wettbewerbsvorteile Ihr Unternehmen hat (bessere Website-Benutzfreundlichkeit, bessere Supportleistungen, komfortablere Zahlungsarten, Verfügbarkeit einer teuren Domain usw.)
• Welche Geschäftsprozesse sind (Externe Prozesse Sie hängen von der Art und Weise ab, wie Sie mit Ihren Kunden und Lieferanten interagieren; interne Prozesse sind an die Art und Weise gebunden, wie Sie die Effektivität Ihres Geschäfts bewerten)
• Wo manuelle Vorgänge bestehen
• Welche Softwaresysteme befinden sich in dem Unternehmen (erworben oder selbst entwickelt)?
• Wer das Unternehmen abhängig macht (Auftraggeber)
• Auf welche externen Anbieter kommt eine starke Abhängigkeit zu (Hosting, CRM, Dienstleister usw.)
• Welche rechtlichen Anforderungen müssen in Ihrem Unternehmen eingehalten werden (Finanzbestimmungen, DSGVO, Anforderungen an Benutzerdaten, Regulierung und Zulassung in der Ingenieurwissenschaft, usw.)

Nachdem wir in dieser Phase alle notwendigen Informationen gesammelt haben, können wir mit der nächsten Phase von TOGAF beginnen.

Im zweiten Schritt des TOGAF-Projekts besteht unser Ziel darin, Basisarchitekturen und Zielarchitekturen für das Unternehmen zu entwickeln. 

Die Grundlagenarchitektur (gemeinsam als “as-is”-Architektur bezeichnet) ist eine Reihe von Produkten, die die bestehende Software, die wichtigsten Geschäftsprozesse und Systeme sowie die technische Infrastruktur beschreiben und die miteinander interagieren. 

Die Ziel-Geschäftsanalyse Es entspricht fast der Basisarchitektur; der einzige Unterschied besteht darin, dass die Zielarchitektur die ist, die man in einem oder zwei Jahren erreichen möchte.

Von der Basisarchitektur bis zur Zielarchitektur mit der Domain-Driven-Design-Abbaustruktur (DDD)

Die DDD-Decomposition ist eine Methode zur Bestimmung, welche Einheiten für welche Module in der Architektur verantwortlich sind und wie diese richtig zugeordnet werden können. 

• Ziel der DDD-Decomposition ist es, die Entitäten zwischen verfügbaren Systemen neu zu verteilen sowie die Systemverantwortlichkeiten neu zu verteilen und gegebenenfalls diese neu zu vergeben. 
• Letztendlich sorgt die DDD-Decomposition dafür, dass jede Geschäftsbereichsdomäne einem anderen Teil des Geschäfts entspricht. Beispielweise können wir uns vorstellen, dass wir in unserer Basisarchitektur eine Back-End-Plattform, ein Admin-Panel, eine Website und Marketingseiten haben. Das Ziel des Unternehmens ist es, eine mobile App zu entwickeln und Analysen zu sammeln.

Wenn einige Ihrer Dienste ähnlich einer bestehenden generischen Dienstleistung sind, sollten Sie über die Möglichkeit nachdenken, diese durch eine fertige Software zu ersetzen. Dadurch können Sie die Logikverteilung zwischen Diensten eliminieren und unnötige Abhängigkeiten zwischen Diensten vermeiden (je weniger Abhängigkeiten, desto zuverlässiger funktionieren Ihre Dienste). Dies spart möglicherweise Zeit für die Entwickler und Geld für Ihr Unternehmen.

Zu diesem Zeitpunkt ist es auch wichtig zu bedenken, dass wir architektonische Systeme abbauen, um solche Systeme kaufen zu können, für die ein bestimmtes Unternehmen keine Wettbewerbsvorteile besitzt. 

Schließlich wird das obige Beispiel zu einer Zielarchitektur, in der wir die Haupt-API in drei Teile aufgeteilt haben: eine Back-End-Plattform für die App, eine Back-End-Plattform für die Front-End-Plattform und Hintergrund-Cron-Jobs, die begonnen haben, über den Message-Bus zu kommunizieren. Der Message-Bus ermöglicht außerdem die Verbindung der Datenplattform für die Analyse mit der ML-Lösung für Empfehlungen. Außerdem haben wir für die Landing-Pages von einer benutzerdefinierten Lösung auf eine SaaS-Lösung umgestellt, um Entwicklern Zeit zu sparen. Schließlich haben wir A/B-Tests für die Website und die mobile App eingeführt. 

Unser Beispiel zeigt, welche die grundlegende Architektur ist und wie die fertige Zielarchitektur mit dem DDD-Deparmentierungskonzept aussieht.

Diese Phase umfasst sowohl die Bewertung der Datenarchitektur als auch die Anwendungsorientierte Architektur. Lassen Sie uns diese Konzepte genauer betrachten.

Datenarchitektur

Die Basislinie Datenarchitektur Das ist das, was wir derzeit in der Architektur haben. In dieser Phase der Phase C prüfen wir Folgendes: 

• wie Daten ausgetauscht werden 
• in welchen Systemen Daten gespeichert werden
• wie Daten (d. h. Benutzerdaten) von einem System in ein anderes gelangen
• Wie sicher Daten gespeichert und übertragen werden

Die Zieldatenarchitektur Hilft uns bei Problemen im Zusammenhang mit Sicherheit während des Transports und im Ruhezustand, Datenduplikation und unnötigen Synchronisationsproblemen zu lösen. Die erste und eine der wichtigsten Regeln ist die Minimierung der Datenduplikation, die schließlich zu Dateninkonsequenzen führen kann. 

Eine Analyse der Zieldatenarchitektur wird durchgeführt, um zu ermitteln, wo Daten kopiert werden, um zusätzliche Datenübertragungen zu vermeiden. Übermäßige Datenübertragungen schaffen unnötige Fehlergefahr. Wenn Daten an mehreren Standorten gespeichert werden, besteht die Möglichkeit von potenziellen Dateninkonsequenzen. 

Bei der Arbeit mit Open-Source-Enterprise-Datenmanagement-Systemen ist es üblich, in der Datenarchitektur mehrere Speicher- und Verarbeitungsschichten zu verwenden. Dies bedeutet oft, Daten in mehreren Formaten zu speichern, um den Zugriff zu optimieren. Dies kann sogar zur Datenduplizierung führen, die in der Vergangenheit aufgrund der Kosten und Komplexität als kontraproduktiv angesehen wurde. Mit neueren Systemen und günstigerem Speicher ist dies jedoch viel praktischer geworden.

Was sich nicht ändert, ist die Notwendigkeit, die Integrität der Daten zu gewährleisten, die sich vom Datenquellen zu der endgültigen Speicherung durch das System bewegen. Wenn wir von Datenintegrität sprechen, meinen wir, dass wir sicherstellen müssen, dass die Daten in unseren Datenpipelines stets genau und konsistent sind. Um die Datenintegrität zu gewährleisten, müssen wir die Herkunft aller Daten kennen, die sich durch das System bewegen.

Zu diesem Zeitpunkt beseitigt Ihr Expertenteam auch alle Verzögerungen. Beispiel: Es gibt viele Probleme mit Verzögerungen in der Datenbanken, Insbesondere bei der täglichen Berichterstattung, die für die meisten Unternehmen ein langer Prozess ist. Moderne Protokoll-Streaming-Systeme ermöglichen es, Berichte in Echtzeit, innerhalb weniger Sekunden, zu aktualisieren. Ebenso können Sprachauslösefunktionen wie Integration von Siri in iOS-Apps, Sie können die Benutzerinteraktion verbessern und Prozesse optimieren. 

Sie könnten auch in Erwägung ziehen Die Erkennung von Cloud-Sicherheitsrisiken und stärken Sicherheit in Ihrer Anwendungsentwicklung aufgrund der Voraussichtliche Zahl der Bedrohungen im Jahr 2022. Unsere Experten können Ihnen hierbei mit unserem umfangreichen Wissen behilflich sein. Cybersecurity-Expertise. 

Im nächsten Abschnitt beschreiben wir die Anwendungsarchitektur als Teil der Informationssystemarchitektur und beantworten eine ständige Frage: Kauf oder Bauen?

Anwendungsarchitektur

In der Phase der Architekturbewertung klären wir, aus welchen Systemen unsere App besteht, und versuchen, sie mithilfe des Buy-or-Build-Ansatzes zu optimieren. Nach dieser Methode sollten wir rational prüfen, was für ein Unternehmen sinnvoll ist, eigene Systeme zu entwickeln, und wo es lohnender ist, bestehende Software zu kaufen.

Wann kaufen?

Wie bereits erwähnt, raten wir Ihnen zunächst, alle nicht wettbewerbsfähigen Softwareprodukte zu kaufen. Warum unzählige Stunden damit verbringen, die besten Mitarbeiter dafür zu engagieren, eine bereits existierende Lösung zu entwickeln, die auf dem Markt bewährt ist – oder sogar neue Mitarbeiter einzustellen, um dies zu tun? 

Wenn Sie nach konkreteren Beweisen suchen, warum Sie eine fertige Lösung kaufen sollten, können Sie die anfänglichen internen Entwicklungskosten sowie die laufenden Wartungskosten einschätzen. Die Kosten für Produktentwicklung, Qualitätskontrolle, Wartung, Plattformmigration und Patch-Fixes fallen dem Anbieter der Lösung zu, während die interne Entwicklung möglicherweise jahrelange kontinuierliche Arbeit über den ursprünglichen Projektumfang hinaus erfordert.

Pro-Tipp: Wenn Sie ein System kaufen möchten, können Sie SaaS-Lösungen einfach miteinander vergleichen. G2, der weltweit größte Marktplatz, auf dem Unternehmen Technologien entdecken und bewerten können. Eine weitere Option, die tatsächlich kostenlos ist, besteht darin, eine Open-Source-Lösung zu verwenden. In diesem Fall müssen wir die Lösung lediglich selbst hosten, der Code selbst wird jedoch von der Open-Source-Community verwaltet. 

Wann bauen?

Vor allem bauen wir ein System, wenn es dem Geschäft des Kunden einen Wettbewerbsvorteil verschafft. Außerdem, wenn wir einzigartige Lösungen anwenden Denkmalgeschützte Bauwerke oder die Schaffung wirklich neuartiger Funktionen für Endkunden, Kundenspezifische Entwicklung Das könnte ideal sein. Ein weiteres Mal, wenn Sie sich für die Entwicklung einer eigenen Lösung entscheiden möchten, ist, wenn es keine bestehende Software gibt, die Ihren Anforderungen entspricht.

Ofte wollen technische Spezialisten die gesamte notwendige Software selbst entwickeln. Doch eine solche Absicht sollte ein Alarmsignal sein. In der Regel bedeutet dies, dass die DDD-Decomposition-Phase falsch durchgeführt wurde – nämlich dass die Geschäftsarchitektur falsch in andere Systeme unterteilt wurde. In diesem Fall sollte die Architektur erneut überarbeitet werden.

Wir werden uns ansehen, wie es in der Technologieebene von TOGAF aussieht und wie man effiziente Technologie-Entscheidungen trifft.

Die Technologiearchitektur-Baseline ermöglicht es Ihnen, zu sehen, was wir letztendlich in der Architektur haben. Anschließend können wir anhand der Zielarchitektur entscheiden, ob die bestehenden Technologieoptionen ausreichend sind oder ob wir sie ändern müssen. Nachdem wir in der Phase C eine Entscheidung getroffen haben, ob wir fertige Systeme kaufen oder selbst entwickeln, können wir nun die Technologiearchitektur für die Systeme festlegen, die wir selbst entwickeln wollen. 

Wenn Sie sich entscheiden, Ihr eigenes System zu erstellen, müssen Sie Sprachen auswählen., Datenbanken und Hosting. Natürlich., Ihre Expertenmannschaft Man kann die beste Lösung anhand der eigenen Geschäftsanforderungen und des Arbeitsmarktes finden (z. B., welche Ingenieure leichter zu gewinnen sind). Es ist jedoch auch sinnvoll, bei der Auswahl einer Technologie zusätzliche Ressourcen zu nutzen.

Die ThinkWork-Berater haben einen Blog Um Sie bei der Auswahl technischer Lösungen zu unterstützen, die derzeit auf dem Markt verfügbar sind. Ein- oder zweimal jährlich werden durch Aktualisierungen des Technologie-Radar von Experten entschieden, was sinnvoll ist und was Technologien oder Werkzeuge vernachlässigt werden sollten. 

• Die annehmen Der Kreis umfasst Technologien, die für die Implementierung in allen Organisationen, sowohl großen als auch kleinen, empfohlen werden. 
• Die Testversion circle bietet Technologien, auf die die wichtigsten Geschäftsprozesse nicht angewiesen sein sollten. Technologien, die nur seit einem oder zwei Jahren auf dem Markt sind, sind in der Regel hochriskant und sollten daher für wichtige Geschäftsprozesse wie solche, auf die Ihre Verkaufszahlen angewiesen sind, vermieden werden. 
• Die bewerten Der Kreis bezieht sich auf Technologien, die die Zeit nicht bestanden haben, da sie brandneu sind. Diese sind nicht für etablierte und erfahrene Unternehmen geeignet. 
• Die halten Der Kreis umfasst Technologien, die von keinem Unternehmen für irgendwelche Prozesse eingesetzt werden sollten.

Wir empfehlen außerdem, sich an der Zeit zu orientieren, in der die Technologie bereits auf dem Markt ist. Wenn die Technologie bereits seit mehr als fünf Jahren aktiv auf dem Markt eingesetzt wird, ist sie höchstwahrscheinlich etabliert und dürfte auch in den nächsten fünf Jahren beliebt bleiben, was eine sichere Nutzung ermöglicht. 

Lesen Sie auch: Die Wahl eines Technologie-Stacks für die vollständige Entwicklung von Webanwendungen

In dieser Phase müssen wir den Umfang der Arbeit in mehrere Lösungen aufteilen. Um dies zu erreichen, müssen zunächst die gesamte Arbeitsumgebung verstanden werden. Dafür vergleichen wir die Basisarchitekturen und Zielarchitekturen und identifizieren die Unterschiede zwischen ihnen auf allen Ebenen: Business-, Daten- und Anwendungsebene sowie technologische Ebene. 

Danach müssen wir für jede zuvor identifizierte Differenz eine separate Lösung erstellen. In der Regel besteht die Lösung aus einer User-Story-Map, einem Infrastruktur-Diagramm und Aufgaben für Entwickler.

Nach der Phase E, in der wir all unsere bisherige Arbeit in eine visuelle Darstellung umwandeln, gelangen wir zur letzten Phase des TOGAF-Ansatzes.

Ziel der letzten Phase ist es, einen verständlichen Fahrplan zu erstellen. Dafür müssen wir eine Architektur-Checkliste durchlaufen, um zu verstehen, wer genau die Aufgaben ausführen wird und wie viele Teams benötigt werden. Die in der Phase E entwickelten Lösungen sollten bereits in der Roadmap detailliert beschrieben und in der richtigen Reihenfolge angeordnet sein. Falls zwischen den Lösungen Abhängigkeiten bestehen, sollten diese berücksichtigt und in der Roadmap dargestellt werden.

Die Erstellung eines Roadmaps liegt oft in der Verantwortung der Geschäftsleiter. Falls Yalantis die architektonische Bewertung durchführt, empfehlen wir unsere Version des Roadmaps, damit klar ist, wann alles umgesetzt werden soll. Aber selbst dann liegt die endgültige Entscheidung immer bei den Geschäftsleitern.

Durch den gesamten Entwicklungsprozess unserer Architektur haben wir Folgendes erreicht:

• hat die gesamte architektonische Teil des Projekts abgeschlossen
• Klare Verständnis der Änderungsanforderungen
• Die Architektur wurde analysiert
• Angebotene Lösungen
• Erreichtes Lieferplan

Nach dem Architekturentwicklungsprozess bei Yalantis müssen Sie lediglich sicherstellen, dass Ihre Roadmap umgesetzt wird und dass die von uns angebotenen Lösungen von Ihren Entwicklern implementiert werden (Stufe G gemäß TOGAF). Anschließend können Sie die Ergebnisse der Arbeit (Stufe H) evaluieren und den nächsten Zyklus der Architekturbewertung beginnen. 

In Produktunternehmen wird dieser Bewertungsprozess in der Regel einmal oder zweimal im Jahr durchgeführt. Bei schnell wachsenden Unternehmen ist es erforderlich, die Architekturbewertung vierteljährlich durchzuführen. 

Die Experten von Yalantis bieten IT-Lösungen an Beratung Dienstleistungen im Falle, dass Sie noch Fragen zu TOGAF haben. Aber wir möchten auch erwähnen, worauf Sie bei der Auswahl des Teams achten sollten, das Ihre Architekturbewertung durchführt.

Wenn es darum geht, zu entscheiden, wer die Architekturbewertung Ihres Unternehmens durchführen soll, stehen Ihnen drei Optionen zur Verfügung.

#1 Führen Sie eine Bewertung mit Ihrem internen Team durch

In der Regel können Sie eine solche Bewertung mithilfe Ihres Solution Architects, Ihres CTO oder sogar Ihres Lead-Entwicklers durchführen.

Der Vorteil dieser Herangehensweise besteht darin, dass sie schnell und ohne zusätzliche Kosten durchgeführt werden kann. Der Nachteil ist jedoch, dass sie normalerweise mehr Fähigkeiten erfordert, um die Evaluierung der Lösungsarchitektur durchzuführen, als für die Implementierung. Wenn Sie daran interessiert sind, die Entwicklungskosten zu senken, können Sie einen externen Partner für die Evaluierung suchen und dann ein internes Team mit relativ geringerer Fachkompetenz für die eigentliche Implementierung nutzen.

#2 Arbeiten mit einer Beratungsagentur

Sie können zwischen Beratungsagenturen wie McKinsey, Bain & Company, und PwC. Das Besondere hier ist, dass sie lediglich eine Architekturbewertung durchführen, die Implementierung der Architektur übernehmen jedoch nicht. In diesem Fall müssen Sie entweder Ihr internes Team oder einen anderen Anbieter für die Implementierung nutzen. 

Im Allgemeinen funktioniert dieser Ansatz gut, wenn Sie zunächst Ihre Geschäftsstrategie bewerten und dann die Architektur an die neue Strategie anpassen möchten. Wenn Ihr Ziel es ist, Ihre interne Team und ihre Entscheidungen zu bewerten, ist diese Option ebenfalls perfekt. Der Nachteil ist, dass die Zusammenarbeit mit einer Beratungsagentur kostspieliger ist als andere Ansätze, und sie ist nur sinnvoll für Unternehmen, die dies problemlos finanzieren können.

#3 Zusammenarbeit mit einem Software-Engineering-Unternehmen

Sie können auch Hilfe von einem unabhängigen Software-Engineering-Unternehmen erhalten. Ein Software-Engineering-Unternehmen kann sowohl die Bewertung Ihrer Architektur als auch die Umsetzung des Arbeitsbereichs übernehmen. 

Dies ist der beste Ansatz, wenn Sie schnell Ergebnisse erzielen möchten und externe Entwicklungsressourcen einsetzen möchten. Die Zusammenarbeit mit einem Software-Engineering-Unternehmen ist der schnellste Weg, um Ihre Geschäftsidee auf den Markt zu bringen. Warum? Erstens kann das Unternehmen die Entwicklung sofort nach der Evaluierung beginnen. Zweitens stellt das Unternehmen Ihnen ein Entwicklerteam zur Verfügung, und Sie müssen sich keine Sorgen um Anwerbung und Einarbeitung machen.

Yalantis kann sowohl Ihre Lösungsanalyse anhand des TOGAF- oder ATAM-Ansatzes durchführen als auch Ihre Lösung implementieren. Darüber hinaus bieten wir als Teil unserer Dienstleistungen auch eine Infrastrukturanalyse an. Unsere Dienstleistungen im Bereich der Site-Reliability-Engineering. Wir bieten mehrere Dienstleistungen an, darunter Erweiterung des Entwicklungsteams, Kundenspezifische Softwareentwicklung, und IT-Beratung.