Make-or-Buy, Configuration-or-Customizing

Make-or-Buy ist eine Basisentscheidung die in Einklang mit der Digitalen Souveränität und der Ausrichtung an (Industrie-, Markt-, …) Standards einhergeht.

Digitale Souveränität über Standards!

Die Ausrichtung auf Standards stärkt die Digitale Unabhängigkeit, da ein Wechsel und die Beschaffung von anderen Produkten und auch Entwicklern erleichtert wird. Die Unabhängigkeit von dem jeweiligen einzelnen Entwickler stärkt insoweit auch die interne Souveränität. Standard kann dabei ein spezielles Produkt, eine Schnittstelle oder eine Kompatibilitätszusage und sollte neben dem Organisationsinternen auch den Marktstandard berücksichtigen. Standards sind dabei regelmäßig, ebenso wie die Produktauswahl zu prüfen. Die Nutzung von OpenSource Software kann hier verstärkend wirken bedarf jedoch einer Strategie u.a. zur Zulässigkeit von Lizenzen, Umgang mit Lizenzwechseln und dem Beitragen von Quelltext. Zusätzlich muss immer eine angepasste Dual-Vendor-Strategie definiert werden.

Wichtig ist, dass der reine Einsatz von OpenSource keine digitale Souveränität sicher stellen kann. Hierzu gehören zwingend begleitende Maßnahmen wie Lizenzstrategie, Dual-Vendor-Strategie und Mitarbeits- / Beitragsstrategie zur OSS. Hier helfen Fragen z.B. bzgl. des Impacts, wenn der Maintainer die Lizenz wechselt, aufgekauft wird oder auch das Produkt nicht weiter gepflegt wird ebenso wie die Produktdurchdringung des Marktes ist und ob man mit eigenen Entwicklern die Weiterentwicklung stemmen will oder kann bzw. die Übergangszeit eines Produktwechsels überbrücken kann.

Configuration-or-Customizing, AddIns, PlugIns, KISS!

Configuration eines Produkts bedeutet eine vorgesehene und jedem Produktkunden freistehende Anpassung ohne in den Quelltext einzugreifen. Grds. kann das Produkt den eigenen Anforderungen versionsübergreifend personalisiert werden, ohne Entwicklerressourcen und KnowHow vorhalten zu müssen.

Customizing ist eine Anpassung des Produkts auf die eigenen Spezialanforderungen grds. durch Eingriff in den Quelltext. Dabei sollte man vorsichtshalber immer von einer fehlenden Kompatibilität für die nächste Version ausgehen. Customizing kann durch eigene Entwickler oder Fremdfirmen erfolgen inkl. dem Hersteller des Produktes.  

AddIns und PlugIns nutzen Schnittstellen des Herstellers des Produktes um dieses an spezielle Anforderungen des Kunden anpassbar zu gestalten. Diese Art der Personalisierung kann in eine Make-or-Buy Entscheidung bzgl. der *Ins münden und hat eine bessere Zukunftsausrichtung als Customizing.

Darüber hinaus ist eine Entscheidung zum KISS Prinzip zu treffen, ob ein Produkt benötigt wird, welches alle Anforderungen in sich (evtl. monolithisch) vereint oder mehrere Produkte lose gekoppelt (mit Performance- und Handlingsüberlegungen) den gleichen Mehrwert / ROI erreichen. Die Frage der Standardisierung zumindest der Schnittstellen muss hier beantwortet werden.

Welche Strategien müssen geklärt werden?

☐ Gibt es Strategie zu Make over Buy und Customizing over Configuration⁈

☐ Gibt es eine angepasste OpenSource Strategie⁈

☐ Gibt es eine Dual-Vendor-Strategie⁈

Wie beeinflusst meine Strategie meine Digitale Souveränität?

Grds. Digitale Souveränität schlechter ggü. Fremdfirmen / Herstellern, jedoch besser ggü. internen Ressourcen (Entwickler): 

☐ Buy over Make

☐ Customizing over Configuration

☐ Keine Standardprodukte, keine Produkte mit Standardschnittstellen

☐ Keine OpenSource Strategie

Grds. Digitale Souveränität besser ggü. Fremdfirmen / Herstellern, jedoch schlechter ggü. internen Ressourcen (Entwickler): 

☐ Make over Buy

☐ Configuration over Customizing

☐ (Pseudo-, Industrie-) Standardprodukte, Produkte mit Standardschnittstellen

☐ OpenSource Strategie, inkl. Lizenzstrategie und Strategie zum Beitrag zu OSS

☐ Technische Zielarchitektur definiert, inkl. Rahmenbedingungen wie Programmiersprache