Home / FAQs / Applet, APP, SaaS und alte Systeme
QUESTION & ANSWER

Sollten Enterprise-Systeme in einer Sekundärphase von Null oder von Open-Source-Systemen entwickelt werden?

Prozesse sind üblich, Open-Source-Produkte sind ausgereift und Lizenzen ermöglichen eine sekundäre Entwicklung. Wenn Geschäftsunterschiede, Einschränkungen der Kernarchitektur oder langfristige Upgrade-Kosten hoch sind, kann es sinnvoller sein, sich von Null zu entwickeln.

Beantworten Sie die Frage.

Geben Sie zuerst Schlussfolgerungen, die für die Entscheidungsfindung verwendet werden können

Entscheidend ist, inwieweit Open-Source-Systeme mit den Kernoperationen übereinstimmen. Sind 80% der Prozesse direkt verfügbar, sind nur Marken, Privilegien, einige wenige Schnittstellen und Schnittstellen erforderlich, und die Sekundärentwicklung ist in der Regel wirtschaftlicher; sind umfangreiche Änderungen erforderlich, um Datenmodelle, Privilegien und Schlüsselprozesse von unten nach oben zu bringen, können kurzfristige, scheinbare Sparer möglicherweise Gabelstapler herstellen, die langfristig schwer zu aktualisieren sind.

DECISION FACTORS

Welche Bedingungen müssen vor der Entscheidungsfindung festgelegt werden?

Die gleiche Frage kann in unterschiedlichen Geschäfts-, Daten- und Projektphasen unterschiedliche Antworten haben, und es wird vorgeschlagen, die folgenden Bedingungen zu überprüfen und die gemeinsamen Ergebnisse im Internet in ihre eigenen Projekte einzuarbeiten.

Ob Lizenzen eine kommerzielle Nutzung, den Vertrieb und die Erweiterung um Closed Source erlaubenGrad der Kompatibilität von Kernprozessen mit bestehenden DatenmodellenNachhaltigkeit von Community-basierten Aktivitäten, Sicherheitsupdates und kritischen AbhängigkeitenWie man Upstream-Upgrade kombiniert und technische Schulden nach der sekundären Entwicklung kontrolliert
ACTION STEPS

Vorgeschlagene Reihenfolge des Vorschusses

01

Zuerst werden wir uns über das Ziel und die Grenze im Klaren sein.

Wählen Sie den komplexesten realen Prozess aus, der im Open-Source-Kandidatensystem validiert werden soll.

02

Validierungsschlüsselabhängigkeit

Überprüfung der Modalitäten für Lizenzierung, Architektur, Zuverlässigkeit, Test, Sicherheit und Bereitstellung.

03

Entwicklung bewertbarer Ergebnisse

Die Kosten für die Aufrüstung, Wartung und den Austausch werden über fünf Jahre geschätzt, anstatt nur zum ersten Mal entwickelt zu werden.

04

Stellen Sie sicher, dass Sie den nächsten Schritt mit den tatsächlichen Ergebnissen entscheiden.

Benutzerdefinierte Layer und Cores werden so weit wie möglich entkoppelt und Upgrade- und Migrationsprogramme werden beibehalten.

PRACTICAL EXAMPLE

Wie verstehen Sie es im eigentlichen Geschäft?

Beispiel zur Erläuterung der Beurteilungsmethode

Das Unternehmen muss ein Arbeitsblattsystem mit Open-Source-Produkten erstellen, die Arbeitsblätter, Rollen und Benachrichtigungen unterstützen, aber das Unternehmen benötigt komplexe Geräteprotokolle und Offline-App. Der Kern der ausgereiften Arbeitsblätter kann beibehalten werden, mit zusätzlichen Geräten und mobilen Modulen, die über den API hinzugefügt werden; nachfolgende Sicherheitsupgrades werden schwierig, wenn der Kern direkt umgeschrieben wird. Grenzen sind in der Regel besser kombiniert als Gesamtänderungen. Beispiele repräsentieren nicht die Leistung eines bestimmten Kunden, und tatsächliche Schlussfolgerungen müssen in Verbindung mit dem eigenen Geschäftsvolumen, Beispiel, System und Verantwortungsgrenzen des Unternehmens überprüft werden.

COMMON RISKS

Die einfachste Grube, auf die man treten kann.

Wir denken nicht, dass es die Software kosten wird, wenn wir den Code herunterladen.

Verwendung von Lizenzen für kommerzielle Lieferungen ohne Überprüfung

Zu viele Änderungen am Kerncode ohne Upstream-Upgrade-Strategie

ACCEPTANCE

Wie sollen wir am Ende empfangen und bestätigen?

Die Auswahl sollte die Abgleichszertifizierung, die Lizenzierungsberatung, den Umfang der Änderungen, die Leistungssicherheitsprüfungen, Bereitstellungsprogramme und die Wartungsschätzungen für drei bis fünf Jahre umfassen.

Bei der Vorbereitung auf die Kommunikation mit Lieferanten oder internen Teams empfiehlt es sich, aktuelle Prozesse, repräsentative Muster, bestehende Systeme, Planungszeit und Budgetniveaus mitzunehmen. Zunächst werden die unbekannten Elemente eindeutig gekennzeichnet und dann wird die Entscheidung für Diagnostik, PoC, Feststreckenprojekte oder laufende Forschung und Entwicklung getroffen, was in der Regel zuverlässiger ist als eine direkte Forderung nach einem Preis und einer Dauer ohne Grenzen.

Unsicherheit, ob man sich von Null entwickeln oder sich an Open-Source-Systeme anpassen soll?

Beschreibung der betrieblichen Unterschiede, der möglichen Systeme und der langfristigen Instandhaltungsanforderungen mit vorheriger Genehmigung, der Höhe der Anpassung, des Upgrade-Risikos und des Gesamtinputs.

Kontakt aufnehmen