Was sagt Ihre Technologie über Ihr Unternehmen aus?
Veröffentlicht: 2021-12-22
Unternehmen streben regelmäßig danach, mit viel mehr Innovation und finanziellem Gewinn besser zu werden. Bei der Identifizierung wahrscheinlicher Unternehmensprobleme zielen Unternehmen normalerweise auf das Gesamtbild ab, wollen das Unternehmen als Ganzes betrachten und langsam nach innen. In der Tat kann der Einstieg in das Unkraut mit den Technologien des Unternehmens ein wesentlich breiteres, umfassenderes und tieferes Verständnis für dieses größere Foto bieten.
Da sich Unternehmen im Zuge der Pandemie schnell weiterentwickeln und elektronische Transformationsaufgaben versuchen, von denen ein erheblicher Teil sie nicht richtig abschließen kann, ist es wichtig, zu wissen, wie die von Ihnen mit Ihrer Technologie erstellten Schlussfolgerungen helfen oder behindern Entwicklung.
Was können wir konkret über ein Unternehmen aus seiner technologischen Innovation erfahren?
Wie Gruppen zusammengestellt werden, interagieren und miteinander auftreten, kann einen tiefgreifenden Einfluss auf den verbleibenden Stil Ihrer Waren haben. Wir bezeichnen dies als Conway's Regulation – die Konstruktion von Software spiegelt unbeabsichtigt das Interaktionsmodell der Mitarbeiter wider, die sie entwickelt haben. Das Geschäft des Unternehmens ist wohl der wichtigste Faktor, der bei der Planung eines Produkts oder einer Dienstleistung berücksichtigt werden muss.
organisatorische Verfahren und Architektur sind untrennbar miteinander verbunden – was darauf hindeutet, dass sie sich gegenseitig beeinflussen und einschränken. Daran sollten wir bei der Diagnose eventuell auftretender Probleme denken und daraus wesentliche Erkenntnisse darüber gewinnen, wie das Unternehmen strukturiert ist, warum es zu Schwierigkeiten kommt und wie wir sie überwinden können. Wenn Ihre Engineering-Mitarbeiter ihre Ziele nicht erreichen, könnte es sich lohnen, zu prüfen, wie die Crew aufgestellt ist und was dies notwendigerweise für das Erreichen der gewünschten Ergebnisse bedeutet.
Monolithische vs. Microservices-Architektur
Es gibt mehrere unterschiedliche Architekturkonstruktionen, die je nach Anordnung der Gruppen generiert werden können. Winzige, verteilte Gruppen generieren mit hoher Wahrscheinlichkeit eine modulare, auf Mikroservices ausgerichtete Architektur. Wenn die Crew größer ist und nicht auf Teile der Objektarchitektur ausgerichtet ist, wird sie wahrscheinlich eine monolithische Architektur erstellen. Monolithische Architektur ist vielen ein Begriff, da gängige IT-Programme oder Unternehmenszwecke in der Regel auf diese Weise erstellt werden. Für gleichermaßen unterschiedliche Architekturen gibt es wichtige Stärken und Nachteile, die berücksichtigt werden müssen.
Für Unternehmen, die sich auf die digitale Transformation spezialisiert haben, besteht ein Teil des Unternehmens möglicherweise darin, veraltete, monolithische Anwendungen zugunsten neuer, moderner Microservices zu trennen. Diese Vielfalt an Layouts hat erhebliche Stärken, da sie eine höhere Gesamtflexibilität zur Implementierung von Anpassungen ohne Unterbrechungen ermöglicht und zu einer viel besseren Skalierbarkeit beitragen kann. Trotzdem ist die monolithische Architektur erheblich weniger kompliziert zu verwenden und bereitzustellen. Dies macht es normalerweise zur größten Präferenz für kleinere, sehr einfache App-Entwicklungen und wird normalerweise in frühen Startphasen entdeckt. Im Gegensatz zu Microservices ist eine monolithische Architektur schwieriger zu skalieren, da die Aufgabenstellung die Ausrichtung auf verschiedene Gruppen mit vielen Zielen erfordert. Eine völlig falsche Personalzusammensetzung kann die Stilmethode verlangsamen und später zu erhöhten Herausforderungen führen.
Der florierende oder erfolglose Einsatz einer Microservices-Architektur in einem Unternehmen verrät viel über die von ihm entworfenen Schlussfolgerungen und ob es tief verwurzelte Probleme mit der Kommunikationsstruktur im Unternehmen gibt. Wenn Sie überlegen, ob Sie einen Monolithen aufteilen und auf eine Microservices-Architektur umsteigen müssen, müssen Sie unbedingt sicherstellen, dass die Anatomie Ihres Unternehmens für die von Ihnen gewählte Architektur hilfreich ist.
Unterstützung aufblähen
Unter bestimmten Umständen kann sich durchaus herausstellen, dass die Anzahl der Microservices größer ist als die Anzahl der Ingenieure. Dies wird als aufgeblähte Unterstützung bezeichnet – was problematisch ist, da es zu einer verringerten Entwicklergeschwindigkeit und -verfügbarkeit führt. Dies ist eine wichtige Erklärung dafür, warum es riskant ist, Microservices ohne eine sehr sorgfältige Struktur zu erstellen, und die Garantie, dass die Teamkonstruktion diesen Ansatz unterstützt.
Aufgeblähte Unterstützung ist ein Zeichen dafür, dass das Team keine durchdachte architektonische Linse angewendet hat – es zeigt, dass es wenig Wissen darüber gibt, wie die einzelnen Dienste voneinander abhängen. Dies führt normalerweise bei Microservices zu Anti-Styles, die die Verfügbarkeit verringern und Verzögerungen bei der Einführung neuer Funktionen auslösen. Am liebsten möchte keine Organisation in diesen Zustand geraten.
Durchführung eines Architekturspaziergangs
Neben der Beachtung der organisatorischen Anatomie und der Auswirkungen, die dies auf die Architektur hat, ist es auch wichtig zu beurteilen, wie alles verdrahtet ist, um die Ursachen möglicher Probleme mit Ihrem Produkt zu erkennen. Führen Sie dazu einen einfachen Architekturspaziergang durch. Um einen Architekturspaziergang durchzuführen, müssen Sie sich ansehen, wie alles vom Gerät oder der Software bis zur Datenebene und wieder mit der Antwort verdrahtet ist. Es gibt ein paar wichtige Dinge, die man bei einem Architekturspaziergang im Hinterkopf behalten sollte:
- Es ist wichtig, nach einsamen Schwachstellen, Anbietern, die zur Betriebszeit voneinander abhängig sind, und Komponenten zu suchen, die sich bei erhöhtem Bedarf nicht skalieren lassen.
- Betrachten Sie Statefulness – dazu gehört die Analyse, wo Fakten von Sitzung zu Sitzung gespeichert werden, an der Personen beteiligt sind, und wie diese Fakten aufbewahrt werden.
- Halten Sie Ausschau nach großen Datenbanken, die nicht fragmentiert sind, und nach Anrufen, die standortübergreifend als Element einer öffentlichen Cloud oder selbst gehosteter Faktenzentren hergestellt werden.
- Erscheinen für die Nutzung von Platform as a Service (PaaS) oder Cloud-Datenbanken als Support (DBaaS) genau dort, wo Public-Cloud-Ausfälle für überregionale Telefonate sorgen.
Alle Faktoren, die darüber hinausgehen, sind nur einige Teile, die für die Behebung möglicher Hindernisse bei Ihren Produkten berücksichtigt werden müssen. Das richtige Timing sollte sowohl die Funktionen als auch die Architekturanforderungen berücksichtigen, um einen idealen machbaren Erfolg zu erzielen.
Was müssen erfahrene Produktingenieure darüber wissen?
Ein Schwerpunkt für leitende Leiter der Produktentwicklung muss darin bestehen, eine gewisse Skalierbarkeit und Verfügbarkeit zu gewährleisten. Die Organisation und komplexe Bestandsaufnahme von Finanzschulden erfolgt auf einer gemeinsamen Grundlage, um potenzielle Probleme zu beheben, bevor sie auftreten. Ein Lösungsarchitekt oder ein kleiner Stab von leitenden Ingenieuren sollte Regeln aufstellen, die Produktteams verwenden können, um das richtige Maß an Skalierung und Hochverfügbarkeit zu gestalten und zu entwerfen.
Instrumente wie CodeScene können verwendet werden, um Abhängigkeiten zwischen Anbietern zu erkennen und Hilfestellung bei der Bestandsaufnahme von Herausforderungen im Verhalten der Codebasis zu geben. Die Vorteile unterstützen die Benachrichtigung über den Rückstand der Umgestaltung erfordert und spezialisierte Kreditkartenschulden.
Angesichts der Anforderungen von Unternehmen, die sich ständig weiterentwickeln, um sich an einen sich schnell entwickelnden Technologiesektor anzupassen, ist es von entscheidender Bedeutung, ein solides Wissen darüber zu haben, was Ihr technologisches Know-how über frühere Entscheidungen preisgibt. Diese Erkenntnisse können dann verwendet werden, um ähnliche Fehler in der Zukunft zu erkennen und zu reduzieren, sowie Ihrem Team zu helfen, zu verstehen, wie ihr Gruppendesign als Werkzeug eingesetzt werden kann, um Ziele zu erreichen und neue Höhen zu erreichen.
Dave Berardi, Ehemann oder Ehefrau, AKF Partners