Sie befin­den sich hier:Start­sei­te/Blog/„Share and con­quer!“ – IT-Trends für die „sharing economy“

„Share and conquer!“ – IT-Trends für die „sharing economy“

Lese­zeit: 15 Minu­ten
raumschiff socialshare

„Das Inter­net, unend­li­che Wei­ten. Wir schrei­ben das Jahr 2018. Dies sind die Aben­teu­er des Pro­jekts ‚Lets Share IT‘, das mit sei­ner 400 Mann star­ken Besat­zung 5 Jah­re unter­wegs ist, um frem­de Tech­no­lo­gien zu erfor­schen, neue Märk­te und neue Services…“

Kön­nen Sie sich vor­stel­len, dass eine Digi­ta­li­sie­rungs-Erfolgs­ge­schich­te so beginnt? Ich nicht.

Panta rhei

Wenn Sie das Zitat, das ich in der Ein­lei­tung para­phra­sie­re, sofort erkannt haben, durf­ten Sie viel­leicht wie ich als Kind in den 70ern nach dem sams­täg­li­chen Wan­nen­bad „Raum­schiff Enter­pri­se“ sehen (den jün­ge­ren sei gesagt: damals gab es ja nicht nur kein Net­flix oder You­Tube, son­dern nicht mal Pri­vat­fern­se­hen – um nicht zu sagen: „wir hat­ten ja nichts nach dem Krieg“ ;-) ). In die­sem Fall haben Sie im Lau­fe Ihres Lebens ver­mut­lich nicht nur eini­ge Pro­jek­te erlebt, wie ich sie kari­kier­te, son­dern haben auch im eige­nen All­tag den unge­heu­ren Wan­del der letz­ten 3 Jahr­zehn­te erfah­ren: PC-Revo­lu­ti­on, Inter­net, Mobil­te­le­fo­nie, Smart­pho­nes, zuletzt IoT.

In mei­nem Bei­trag „Auf zu neu­en Ufern“ beschrei­be ich, dass Dis­rup­tio­nen sich oft nicht auf Tech­no­lo­gien beschrän­ken, son­dern Wech­sel­wir­kung mit kul­tu­rel­len Aspek­ten haben. Gesell­schaft­lich und volks­wirt­schaft­lich hat ein mas­si­ves Umden­ken statt­ge­fun­den, das all­ge­mein mit dem Begriff „sharing eco­no­my“ umschrie­ben wird. Beson­ders die jun­ge Genera­ti­on der „digi­tal nati­ves“ ist in eine Welt hin­ein gewach­sen, in der Ver­net­zen und Tei­len für sie nor­mal sind, wäh­rend es für uns Älte­re noch ver­gleichs­wei­se unge­wohn­te, wenn nicht beun­ru­hi­gen­de Kon­zep­te sind.

Die­se Hal­tun­gen und Wer­te haben sich auch mas­siv auf IT-Pro­jek­te aus­ge­wirkt: Im vori­gen Jahr­hun­dert (mein Gott, wie das klingt …) war umfang­rei­che Soft­ware noch ein gro­ßes Inves­ti­ti­ons­vor­ha­ben: Lang­lau­fend, über­or­ga­ni­siert („Was­ser­fall“), teu­er (auch weil Sym­pto­me wie „Hel­den­pro­gram­mie­rer“ nor­mal waren; Leu­te, die sich selbst zu unent­behr­li­chen Kopf­mo­no­po­le mach­ten). Auch ein hoher Grad an Schei­tern von Pro­jek­ten war üblich und qua­si imma­nent akzep­tiert. Es ist ver­ständ­lich, dass vor die­sem Hin­ter­grund nie­mand anzwei­fel­te, dass man für das Nut­zungs­recht an einem so teu­ren Inves­ti­ti­ons­gut wie Soft­ware hor­ren­de Lizen­zen zu zah­len hatte.

Das alles ist schon lan­ge infra­ge zu stel­len. Und jeder, der mit Soft­ware zu tun hat, soll­te das tun.

Urknall des Teilens

Anfang der 1990er erschien das Inter­net. Befeu­ert durch den Wunsch nach aka­de­mi­schem Aus­tausch schuf es schnell welt­wei­te Kom­mu­ni­ka­ti­ons­stan­dards und ver­än­der­te dabei Zusam­men­ar­beit und Wis­sens­aus­tausch stär­ker als jede Kul­tur­tech­nik (inklu­si­ve dem Buch­druck) zuvor. Kon­kre­tes Bei­spiel, das jeder schon erlebt haben dürf­te: Statt bei Pro­ble­men Hand­bü­cher zu durch­wüh­len oder einen zufäl­lig kun­di­gen Kol­le­gen zu suchen, bekommt man heu­te ganz selbst­ver­ständ­lich im Netz Hil­fe – und zwar oft in Minu­ten und in pro­fes­sio­nel­ler Qua­li­tät. Ich habe vor kur­zem den Feder­zug mei­ner Spül­ma­schi­ne repa­riert. Hät­te ich frü­her nicht mal im Traum dran gedacht.

Fol­ge­rich­tig hat sich vor allem jene Pro­fes­si­on die­se Mög­lich­kei­ten zu eigen gemacht und sie aus­ge­baut, die damit ohne­hin eng ver­wach­sen ist: Die Software­entwicklung.

Ermög­licht durch die neu­en tech­ni­schen Mög­lich­kei­ten und in Wech­sel­wir­kung mit ihnen tra­ten zwei Ideen ihren Sie­ges­zug an: die agi­le Software­entwicklung und die Open-Source-Soft­ware-Bewe­gung.

Geteiltes Wissen ist explodierendes Wissen

Von indi­vi­du­el­len Aus­nah­men abge­se­hen gilt: Men­schen kom­mu­ni­zie­ren ger­ne. Sie lie­ben es, Pro­ble­me zu lösen. Und sie genie­ßen die Aner­ken­nung in der Hor­de. Das gilt für Soft­ware­ent­wick­ler im beson­de­ren Maße, die ja nicht von unge­fähr einen Beruf gewählt haben, bei dem man einer Maschi­ne stän­dig Lösun­gen kniff­li­ger Pro­ble­me bei­bringt. Ihr Kön­nen wol­len sie so häu­fig wie mög­lich bewei­sen, am liebs­ten in enger Zusam­men­ar­beit mit Leu­ten, die es schät­zen kön­nen. Und apro­pos Zusam­men­ar­beit: Nicht erst seit der agi­len Ent­wick­lung muss das Kli­schee des licht­scheu­en, sich von Cola und Piz­za ernäh­ren­den Nerds revi­diert wer­den: In kaum einem Beruf wird bei der Arbeit mehr gelacht und lösungs­ori­en­tiert kom­mu­ni­ziert als bei Softwareentwicklern.

Es ist kein Wun­der, dass vie­le pro­fes­sio­nel­le Soft­ware­fir­men die dar­in lie­gen­den Pro­duk­ti­vi­täts­vor­tei­le erkannt haben und ihren Teams ent­spre­chen­de Rah­men­be­din­gun­gen und Frei­hei­ten geben. Das umfasst auch die Akzep­tanz und För­de­rung von Open-Source-Soft­ware. Eini­ge Unter­neh­men stel­len ihre eige­nen Soft­ware­inves­ti­tio­nen als Open-Source zur Ver­fü­gung, vie­le finan­zie­ren Open-Source-Pro­jek­te, in dem sie Mit­ar­bei­ter dafür frei bzw. zur Ver­fü­gung stel­len. Wie ernst es den Unter­neh­men mit die­ser Kul­tur ist, lässt sich an der pro­blem­lo­sen Zusam­men­ar­beit gro­ßer Mit­be­wer­ber erken­nen: Als Goog­le bei der Arbeit am Web­cli­ent-Frame­work Angu­lar eine eige­ne Java­script-Trans­pi­ler­spra­che ent­wi­ckel­te und fest­stell­te, dass Micro­soft mit sei­nem Typescript-Pro­jekt schon wei­ter war, hat man ganz ein­fach die Arbeit der Pro­jek­te kon­so­li­diert. Und das ist nur eins von vie­len Bei­spie­len, dass die Rie­sen der Bran­che vor­le­ben, was sinn­voll ist.

Die gro­ßen und klei­nen Play­er des Inter­net betei­li­gen sich an Open-Source aber nicht (nur), weil sie Altru­is­ten sind, son­dern weil sie wis­sen bzw. erfah­ren, dass trans­pa­ren­te Zusam­men­ar­beit die Bran­che als Gan­zes stark macht und schnel­ler vor­an­bringt. Die­ser Erkennt­nis haben wir einen unge­bremst rie­si­gen Inno­va­ti­ons­schub zu ver­dan­ken, dem ein­zel­ne Fir­men mit abge­schlos­se­ner Pro­dukt­ent­wick­lung nichts ent­ge­gen­zu­set­zen haben.

Hüter des verlorenen Schatzes: Die Enterprise-IT

Die dyna­mi­sche Ent­wick­lungs­welt der gro­ßen und klei­nen Inter­net-Play­er ermög­licht deren geschäft­li­che Agi­li­tät. Die Geschäfts­mo­del­le im Inter­net beru­hen auf dem Erhe­ben von Daten, Ver­dich­ten und Ver­sil­bern von Infor­ma­tio­nen und der Inte­gra­ti­on der gan­zen Welt. Die dar­ge­leg­te Arbeits­wei­se ist für die­se Unter­neh­men die wirt­schaft­lich sinn­volls­te – davon abge­se­hen, dass die meis­ten Inter­net Play­er im Gegen­satz zu Fir­men der Vor-Inter­net-Ära ja nie anders gear­bei­tet haben.

Anders sieht es aus, wenn man in typi­sche IT-Abtei­lun­gen oder Soft­ware­pro­jek­te eta­blier­ter Nicht-Inter­net-Fir­men schaut. Dort fin­det man häu­fig meh­re­re der fol­gen­den Sym­pto­me:

  • Eine über­haupt nicht oder nur bedingt agi­le Arbeits­wei­se (ech­te Agi­li­tät fängt wohl­ge­merkt nicht erst im Ent­wick­lungs­team an)
  • Ein viel zu gerin­ger Auto­ma­ti­sie­rungs­grad in den Prozessen
  • Ver­gleichs­wei­se hohe Auf­wän­de mit Betreu­ung, War­tung und Inte­gra­ti­on der soge­nann­ten Lega­cy bei gleich­zei­ti­gem Unver­mö­gen die­se zügig abzulösen
  • Know-How-Rück­stand von nicht sel­ten 5–15 Jah­ren (bei Ent­schei­dern häu­fig sogar weit dar­über!); das betrifft nicht nur feh­len­de Kennt­nis moder­ner Inte­gra­ti­ons­tech­no­lo­gien, son­dern auch das Aus­las­sen von Produktivitätspotenzialen
  • Rela­tiv hohe Feh­ler­quo­ten bei gleich­zei­tig nicht aus­ge­präg­ter Fehlerkultur
  • Ten­denz (vor allem bei Ent­schei­dern), Open-Source-Soft­ware gering zu schät­zen und „sicher­heits­hal­ber“ auf kom­mer­zi­el­le Pro­duk­te zu setzen
  • … Ihnen fällt sicher auch noch was ein

Die­se Lis­te lie­ße sich belie­big fort­set­zen. Ich den­ke, Sie haben die Ten­denz verstanden.

Von Kun­den höre ich mit­un­ter „Wir sind bis­her ein XYZ (Unter­neh­men der jewei­li­gen Bran­che). Und jetzt müs­sen wir plötz­lich Soft­ware­lö­sun­gen anbie­ten. Davon haben wir kei­ne Ahnung“. Die­ses Pro­blem­be­wusst­sein ist schon mal viel wert. Es ist bei Mit­tel­ständ­lern aus­ge­präg­ter als bei Konzernen…

Sehen wir den Tat­sa­chen ins Auge: Vie­le Unter­neh­men, die mit Pro­duk­ten oder Dienst­leis­tun­gen ihr Geld ver­die­nen, haben IT und Soft­ware vor allem für die Opti­mie­rung der eige­nen Geschäfts­pro­zes­se ver­wen­det, kamen aber schon damit kaum den Anfor­de­run­gen hin­ter­her. Ein klas­si­scher Manage­ment­feh­ler ist auch heu­te noch, IT(-Abteilungen) eher als Kos­ten­fak­tor denn als Chan­ce zu sehen. Oder ken­nen Sie ein Unter­neh­men, in dem die Mit­ar­bei­ter durch die eige­nen IT-Sys­te­me naht­los unter­stützt wer­den und nicht auf sie schimpfen?

„Wenn das sie Lösung ist, will ich mein Problem zurück“

Was ist die Erwar­tung, wenn im Rah­men der Digi­ta­li­sie­rung die­se Unter­neh­men nun plötz­lich Lösun­gen ent­wi­ckeln, bei denen Soft­ware und Inte­gra­ti­on im Mit­tel­punkt steht und den Haupt­teil der Wert­schöf­pung erbrin­gen sol­len? Wenn IT-Abtei­lun­gen, die so auf­ge­stellt sind wie oben beschrie­ben, Digi­ta­li­sie­rungs­pro­jek­te durch­füh­ren sol­len, ist das eigent­lich zum Schei­tern ver­ur­teilt. Das glei­che gilt übri­gens für vie­le Soft­ware­häu­ser, die von Unter­neh­men beauf­tragt werden.

Der Grund ist nicht etwa, dass unbe­gab­te­re Exper­ten am Werk sind, son­dern dass die­se Orga­ni­sa­tio­nen für ganz ande­re Auf­ga­ben spe­zia­li­siert wur­den, näm­lich für Unter­neh­mens­soft­ware. Sie wer­den jede Lösung, die sie ange­hen sol­len, wie eine Enter­pri­se-IT-Lösung den­ken, wodurch sie von Vorn­her­ein nicht wett­be­werbs­fä­hig ist, denn sol­che Lösun­gen wer­den von den Anwen­dern mit denen der Gro­ßen (Goog­le, Ama­zon und Co.) ver­gli­chen und nicht mit den (oft sub­op­ti­ma­len) Anwen­dun­gen, die sie von der eige­nen Arbeit kennen.

Das ist übri­gens ein Pro­blem, das nicht nur IT-Abtei­lun­gen haben. In mei­nem Bei­trag „Cus­to­mer Jour­neys statt Fea­turi­tis“ habe ich am Bei­spiel der Auto­in­dus­trie auf­ge­zeigt, dass eine gewach­se­ne Ent­wick­lungs­or­ga­ni­sa­ti­on nahe­zu dazu ver­dammt ist, immer gleich­ar­ti­ge Lösun­gen zu ent­wi­ckeln. Nur wenn man sich die­ses Pro­blems bewusst ist, kann man eine sinn­vol­le Trans­for­ma­ti­on anstre­ben. Wenn man es igno­riert, ist die Chan­ce hoch, viel Geld, Zeit und Ener­gie zu verschwenden.

If you want to share IT, you’ve got to mean IT

Wie sieht so eine Trans­for­ma­ti­on aus, wenn es um Digi­ta­li­sie­rung für die „sharing eco­no­my“ geht? Zur Erläu­te­rung: Damit mei­ne ich Soft­ware­lö­sun­gen, die nicht nur der inter­nen Pro­zess­op­ti­mie­rung die­nen, son­dern die auf den gän­gi­gen Platt­for­men mas­siv nach außen drän­gen und den Kun­den einen Mehr­wert anbie­ten, sich dabei aber naht­los in sei­ne sons­ti­ge digi­ta­le Land­schaft integrieren.

Da sol­che Lösun­gen rele­vant anders sind als z.B. eine inter­ne ERP-Lösung, muss man anders an sie her­an gehen, wenn man Erfolg haben will:

  1. Ori­en­tie­ren Sie sich an den Rich­ti­gen. Neh­men Sie an, Sie wol­len einen Sport wett­kampf­reif betrei­ben. An wem wür­den Sie sich eher ori­en­tie­ren? An Leis­tungs­sport­lern in der jewei­li­gen Sport­art oder an Sport­ar­ti­kel­her­stel­lern, bei denen Sie hoch­wer­ti­ge Beklei­dung kau­fen kön­nen? Eben­so soll­ten Sie sich bei Digi­ta­li­sie­rung eher dafür inter­es­sie­ren, was bei den gro­ßen und klei­nen Play­ern im Inter­net gut (oder auch schlecht) funk­tio­niert hat, als was Ihnen der Anbie­ter ihres kom­mer­zi­el­len IT-Sys­tems erzählt. Denn letz­te­rer wird sie ten­den­zi­ell eher wei­ter in ein „ven­dor-lock in“ locken wol­len, Ihnen aber sicher kei­ne Din­ge nahe­le­gen, die für sei­ne Pro­duk­te pro­ble­ma­tisch sind, auch wenn sie objek­tiv die bes­te Lösung wären. Bei den ande­ren liegt aber kein kom­mer­zi­el­les Inter­es­se vor (außer dass die Digi­ta­li­sie­rung ins­ge­samt vor­an­geht), und das Inter­net ist eine rie­si­ge Fund­gru­be von Ein­füh­run­gen, suc­cess-sto­ries, aber auch gewo­ge­nen Erfah­rungs­be­rich­ten für ver­schie­de­ne Tech­no­lo­gien – dabei den­ke ich nicht an White­pa­pers oder offi­zi­el­le Pro­dukt­vi­de­os, son­dern an die Unmen­gen an Kon­fe­renz­bei­trä­gen, Blogs u.ä., die zu ver­schie­dens­ten Tech­no­lo­gien frei ver­füg­bar sind.
  2. Erken­nen Sie die wesent­li­chen Trends. Damit mei­ne ich nicht das Mode-Frame­work der Woche, son­dern wirk­li­che lang­fris­ti­ge Trends, die im Sin­ne der tech­no­lo­gi­schen Evo­lu­ti­on schlüs­sig sind und auf abseh­ba­re Zeit kei­ne Sack­gas­se dar­stel­len (ein­fa­ches Bei­spiel: REST über htt­ps mt JSON zeich­ne­te sich schon früh als lang­fris­tig trag­fä­hi­ge Kom­mu­ni­ka­ti­ons­ar­chi­tek­tur ab, wenn man davon abwei­chen­de gar pro­prie­tä­re Mecha­nis­men ein­setzt, soll­te ma extrem gute Grün­de haben). Wei­ter unten habe ich Ihnen eini­ge Trends auf­ge­zählt, die ich für aktu­ell rele­vant hal­te. Wel­che Trends für Sie bzw. Ihre Lösung rele­vant sind, kön­nen Sie nur selbst ent­schei­den. Wich­tig erscheint mir hier eine mit­tel­fris­ti­ge Stra­te­gie für Ihre digi­ta­len Produkte
  3. Pro­bie­ren Sie Tech­no­lo­gien aus bzw. schaf­fen Sie Ihren Mitart­bei­tern dafür Raum und Anreiz. Nur auf der Basis eige­ner Expe­ri­men­te ent­steht das Wis­sen, das als Ent­schei­dungs­grund­la­ge dient. Zeit­man­gel darf dafür kei­ne Aus­re­de sein. Heut­zu­ta­ge lässt sich eine neue Tech­no­lo­gie in weni­gen Stun­den spie­le­risch erkun­den und ggf. in weni­gen Tagen in rich­ti­gen Spikes für das eige­ne Vor­ha­ben auf den Prüf­stand stel­len. Es ist bes­ser, auf die­se Wei­se ver­schie­de­ne Alter­na­ti­ven erpro­ben, als Mona­te lang in eine fal­sche Rich­tung zu ent­wi­ckeln, was lei­der immer noch viel zu vie­le Pro­jek­te machen
  4. Sei­en Sie mutig. Gera­de in einer Zeit stän­di­gen Wan­dels droht „ana­ly­sis para­ly­sis“. Aber irgend­wann muss man anfan­gen. Eines mei­ner eng­li­schen Lieb­lings­at­tri­bu­te ist „opio­nio­na­ted“. Wenn Sie auf­grund der Schrit­te 1–3 zu einem Ansatz gekom­men sind, den Sie begründ­bar für trag­fä­hig hal­ten, kämp­fen Sie für sei­ne Umset­zung, auch wenn man Sie als vor­ein­ge­nom­men oder gar bor­niert hal­ten mag

Wie jeder Ver­än­de­rungs­pro­zess ist das kein Selbst­läu­fer und nicht ver­gnü­gungs­steu­er­pflich­tig, wie ich auch schon am eige­nen Lei­be erfah­ren durf­te. Aber wenn es schon dar­an schei­tert, soll­ten Sie bes­ser kei­ne Digi­ta­li­sie­rungs­lö­sun­gen ent­wi­ckeln und bei Ihrem bis­he­ri­gen Geschäft bleiben.

Trends für Digitalisierungslösungen

Abschlie­ßend möch­te ich Ihnen wie ver­spro­chen eini­ge Trends auf­zäh­len, von denen ich glau­be, dass man sie berück­sich­ti­gen, zumin­dest aber ken­nen soll­te, wenn man mit­tel­fris­tig kon­kur­renz­fä­hi­ge Lösun­gen ent­wi­ckeln möch­te. Für Leser, die sich bereits sehr gut im Umfeld die­ser Tech­no­lo­gien aus­ken­nen, mag die­se Lis­te tri­vi­al, ja wie eine Art Kanon, erschei­nen. Aber ich stel­le bei Ges­pächen mit IT-Exper­ten, die zu lan­ge in abge­schlos­se­nen Kon­tex­ten gear­bei­tet haben, immer wie­der fest, dass sie sehr häu­fig vie­le die­ser Kon­zep­te noch nicht ein­mal nament­lich ken­nen geschwei­ge denn anwen­den könn­ten. Und die­ser Bei­trag dient ja vor allem dazu, sol­che Leser zum Erken­nen und Schlie­ßen die­ser Lücken zu ermu­ti­gen, bevor sie Digi­ta­li­sie­rung mit nicht trag­fä­hi­gen Tech­no­lo­gien beginnen.

Bit­te beach­ten Sie, dass die­se Lis­te weder Anspruch auf Voll­stän­dig­keit noch eine all­ge­mein­gül­ti­ge Prio­ri­sie­rung o.ä. legt:

  • Reak­ti­ve Sys­te­me: Dar­un­ter ver­steht man eine Bün­de­lung bestimm­ter Eigen­schaf­ten, die dem Kun­den auch bei wech­seln­der Last oder tech­ni­schen Pro­ble­men einen gleich­mä­ßig hohen Qua­li­ty of ser­vice bie­ten. Uner­läss­lich für eine gute UX (User Expe­ri­ence). Ver­ges­sen Sie nie, dass Sie von End­kun­den mit Goog­le und Co. ver­gli­chen wer­den (s. hier­zu auch https://www.reactivemanifesto.org/de)
  • Neben­läu­fig­keit: Jedes Sys­tem muss heu­te in der Lage sein, sei­ne Arbeit effi­zi­ent zu par­al­le­li­sie­ren, um die aktu­el­len und kom­men­den Mul­ti-Core-Pro­zes­so­ren opti­mal aus­zu­nut­zen. Unge­eig­net ist pro­gram­mier­tes Mul­ti­threa­ding wäh­rend des hohen Lauf­zeit-Over­heads, der unver­hält­nis­mä­ßi­gen Auf­wän­de, des zu gerin­gen Abs­trak­ti­ons­gra­des und nicht gewähr­leis­ten­der Kor­rekt­heit. Set­zen Sie statt des­sen auf Imple­men­tie­run­gen des Aktor­mo­dells wie Akka oder am bes­ten gleich Erlang/Elixir, die auch wei­te­re Vor­tei­le wie strik­te Iso­la­ti­on bringen
  • Ver­tei­lung: Zur Erhö­hung der Aus­fall­si­cher­heit (Red­un­danz) und Ska­lier­bar­keit ist Ver­tei­lung eines Soft­ware­sys­tems auf meh­re­re Rech­ner­kno­ten schon seit den ers­ten Clus­ter-Lösun­gen eine gän­gi­ge Tak­tik. Durch die Cloud, mobi­le Devices und IoT wird sich die­se Not­wen­dig­keit ver­teil­ter Sys­te­me mas­siv ver­schär­fen. Dabei soll­te man kon­zep­tio­nell grund­sätz­lich zwei Ansät­ze unter­schei­den. Bei einer Ser­vice-Archi­tek­tur han­delt es sich streng genom­men nicht um Ver­tei­lung, son­dern um die Kom­mu­ni­ka­ton zwi­schen kon­zep­tio­nell schon im Ent­wurf getrenn­ten Lauf­zeit­sys­te­men. Bes­ser ist die nati­ve Unter­stüt­zung von Ver­tei­lung eines Gesamt­sys­tems, wie Sie z.B. Aktor­sys­te­me mit dem Fea­ture loca­ti­on trans­pa­ren­cy bie­ten, da das Ver­tei­lung ohne nen­nens­wer­ten Over­head zur Ent­wick­lungs- und Lauf­zeit bietet
  • Asyn­chro­ne / Ereig­nis­ba­sier­te Kom­mu­ni­ka­ti­on: In der ver­teil­ten, neben­läu­fi­gen Welt moder­ner Sys­te­me hat das syn­chro­ne Modell eines linea­ren Kon­troll­flus­ses aus­ge­dient und ist durch asyn­chro­ne Kom­mu­ni­ka­ti­on ersetzt wor­den, in der Pro­zes­se nur über den Ver­sand von Nach­rich­ten oder Ereig­nis­sen mit­ein­an­der kom­mu­ni­zie­ren, nicht mehr über einen Call­stack. Den Ereig­nis­sen kommt dabei im Ent­wurf eine beson­de­re Bedeu­tung für einen fle­xi­blen Ent­wurf zu, weil es der Rea­li­tät näher kommt, dass Sys­te­me (wie bio­lo­gi­sche Orga­nis­men, Maschi­nen oder Orga­ni­sa­ti­ons­ein­hei­ten wie Unter­neh­men, Abtei­lun­gen u.ä.) auf Ereig­nis­se reagie­ren und sel­ber wel­che aus­lö­sen, statt ein­an­der „auf­zu­ru­fen“
  • Ser­ver-Sent Events (SSE): Für vie­le Anwen­dungs­fäl­le ist der klas­si­sche Request-Respon­se-Mecha­nis­mus von http noch aus­rei­chend, zumal er moder­nen Web­Apps für den Benut­zer unbe­merkt und ohne „Sei­te neu laden“ funk­tio­niert. Aber je dyna­mi­scher und ver­netz­ter unse­re Welt und je höher die Kom­mu­ni­ka­ti­ons­dich­te wird, umso mehr wird es sich durch­set­zen, dass Cli­ents sich bei Diens­ten anmel­den und von dort auto­ma­tisch über rele­van­te Events infor­miert wer­den. In Chat­rooms und Online-Spie­len ist das schon lan­ge sta­te-of-the-art. Je nach Anwen­dungs­fall ist hier vor allem auf die Leis­tungs­fä­hig­keit zu ach­ten. Für die Chan­nels des aktu­ell leis­tungs­stärks­ten Web­ser­ver-Frame­works Phoe­nix wur­den schon 2 Mio. akti­ve Sockets auf einem ein­zel­nen Ser­ver erreicht.
  • Funk­tio­na­le Pro­gram­mie­rung: Ein Pro­gram­mier­pa­ra­dig­ma, das den Anfor­de­run­gen unse­rer Zeit gerech­ter wird als die objekt­o­rier­te Pro­gram­mie­rung, da es auf die größ­te Feh­ler­quel­le beim Pro­gram­mie­ren (ver­än­der­li­che Zustän­de) kon­se­quent ver­zich­tet und mit vie­len der Mathe­ma­tik ent­lehn­ten Kon­zep­ten eine sehr hohe Aus­drucks­mäch­ti­ge­keit besitzt. Allein durch die Ein­füh­rung von FP lässt sich die Pro­duk­ti­vi­tät der Software­entwicklung sehr deut­lich und vor allem nach­hal­tig stei­gern. Sie­he hier­zu auch mei­nen Bei­trag „Ein­fach, sicher, pro­duk­tiv: Funk­tio­na­le Pro­gram­mie­rung“.
  • Aktor­sys­te­me: Dar­un­ter ver­steht man Sys­te­me, die zur Lauf­zeit aus sehr vie­len unab­hän­gi­gen und von­ein­an­der kom­plett iso­lier­ten Soft­ware-Agen­ten bestehen, die nur mit­hil­fe von Nach­rich­ten mit­ein­an­der kom­mu­ni­zie­ren kön­nen. Bekannt wur­de die­ses Modell auch durch die „Let it crash!“-Philosophie: Da Feh­ler eh nie voll­stän­dig zu ver­mei­den sind, wer­den die Akto­ren in soge­nann­ten Super­vi­si­on trees hier­ar­chisch über­wacht und bei Abstür­zen ein­fach neu gestar­tet. Aktor­sys­te­me erlau­ben sehr kom­ple­xe, dyna­mi­sche, ver­teil­te Sys­te­me, die dank die­ser Grund­prin­zi­pi­en sehr leicht zu beschrei­ben und extrem sta­bil lau­fen. Eine bekann­te Imple­men­tie­rung ist Akka (für Java und Sca­la). Aber der schlachterprob­te Platz­hirsch ist das aus der Tele­kom­mu­ni­ka­ti­on stam­men­de legen­där leis­tungs­fä­hi­ge und resi­li­en­te Erlang. Die­ses ist beson­ders inter­es­sant gewor­den, seit es mit Eli­xir eine extrem moder­ne Ent­wick­lungs­platt­form erhal­ten hat, s. mei­nen Bei­trag „Eli­xir: Zau­ber­trank für Digi­ta­li­sie­rung?“.
  • Per­sis­ten­te Streams: In einer asyn­chro­nen, ver­teil­ten Sys­tem­welt, in der eine Trans­ak­ti­ons­steue­rung erheb­lich erschwert ist, sind hoch­ska­lier­ba­re, ver­teil­te, per­sis­ten­te Streams wie Apa­che Kaf­ka an die Stel­le zen­tra­ler trans­ak­tio­na­ler Daten­ban­ken getre­ten. Sie haben auch den Vor­teil, dass sie den naht­lo­sen Über­gang zu Real­time Data Ana­ly­tics-Lösun­gen wie Spark erlauben
  • Alter­na­ti­ve Per­sis­tenz­me­cha­nis­men: Aber natür­lich wer­den Daten auch noch inner­halb von Sys­te­men bzw. Ser­vices gehal­ten. Für vie­le Use Cases sind dabei die guten alten rela­tio­na­len Daten­ban­ken immer noch ein pro­ba­tes Mit­tel. Aller­dings soll­ten moder­ne Ent­wick­lungs­teams auch die zahl­rei­chen Alter­na­ti­ven ken­nen, die meis­tens unter dem Begriff NoS­QL (für not only SQL) ste­hen und ganz spe­zi­fi­che Stär­ken für beson­de­re Zwe­cke haben (z.B. Graph­da­ten­ban­ken für das Spei­chern und Durch­su­chen von Netz­wer­ken). Erwäh­nens­wert sind auch die Pat­terns Event Sourcing und CQRS (Com­mand and Que­ry respon­si­bi­li­ty segre­ga­ti­on), die ganz spe­zi­fi­sche Stär­ken wie Wie­der­her­stell­bar­keit belie­bi­ger Zustän­de und inte­grier­tes Audit log bieten
  • Pake­tie­rung und Ver­tei­lung: Manu­el­les Auf­set­zen von Ser­vern und Deploy­en von Sys­te­men erzeug­te frü­her erheb­li­che Auf­wän­de und Inkon­sis­tenz­ri­si­ken. Mit Qua­si­stan­dards wie Docker las­sen sich heu­te Lauf­zeit­sys­te­me dekla­ra­tiv defi­nie­ren (Con­fi­gu­ra­ti­on-as-Code) und effi­zi­ent als Lauf­zeit­con­tai­ner ver­tei­len und starten
  • Auto­ma­ti­sie­rung aller regel­mä­ßig wie­der­hol­ten Vor­gän­ge (Erstel­len, Tes­ten, Aus­lie­fern, Über­wa­chen der Soft­ware), auch bekannt als CI/CD-Pipe­line, ist ein Muss, wenn Sie eine kur­ze Time-to-mar­ket mit Qua­li­tät ver­bin­den wol­len – übri­gens auch schon, damit sie im Fal­le einer feh­ler­haf­ten Aus­lie­fe­rung schnell und sicher eine Kor­rek­tur aus­rol­len kön­nen, ohne im Eifer des Gefechts das Pro­blem zu vergrößern
  • Open Source: Ich habe ein­gangs dar­ge­legt, dass Open Source Soft­ware (OSS) heu­te ein Stan­dard ist, dem sich alle kaum ein nam­haf­ter Play­er ent­zieht. Ich wer­de mir nicht die Mühe machen, die diver­sen Vor­tei­le auf­zu­zäh­len, die soll­te man am bes­ten selbst erle­ben. Die ein­zi­ge Gefahr, die ich bei OSS sehe, ist ggf. auf das fal­sche, sprich ein totes Pferd zu set­zen (das kann einem aber bei COTS, com­mer­cial-of-the-shelf, auch pas­sie­ren). Gera­de bei OSS gilt: Pro­bie­ren Sie viel aus, das geht dank Git­Hub und Co. schnell und kos­tet nichts. Ver­ge­wis­sern Sie sich aber vor einem ernst­haf­ten Ein­satz immer, dass das jewei­li­ge Pro­jekt aktiv ist oder (in Aus­nah­me­fäl­len) dass sie es selbst wei­ter betreu­en könn­ten. Und: wenn Sie selbst ein rele­vant neu­ar­ti­ges Grund­la­gen­pro­blem lösen oder gelöst haben, geben Sie es an die Com­mu­ni­ty zurück, damit ande­re avon pro­fi­tie­ren oder dazu bei­tra­gen können

Auch die­se Lis­te lie­ße sich ver­mut­lich noch fortsetzen.

Zusammenfassung und Empfehlung

Offen­sicht­lich ist das For­mat eines sol­chen Bei­trags selbst dann zu kurz, wenn man die­se kom­ple­xen IT-stra­te­gi­sche Erwä­gun­gen nur anreißt. Wie schon bei mei­nen im Text ver­knüpf­ten ande­ren Bei­trä­gen zu Trans­for­ma­ti­on habe ich ver­sucht deut­lich zu machen, dass Ver­än­de­run­gen statt­ge­fun­den haben, denen man sich stel­len muss.

Um die Jahr­tau­send­wen­de erziel­te in Fol­ge der PC-Revo­lu­ti­on die Enter­pri­se-IT einen Durch­bruch mit App­li­ca­ti­on-Ser­ver-basier­ten Lösun­gen. Die dama­li­gen Trends zur Opti­mie­rung und Fle­xi­bi­li­sie­rung der IT hie­ßen z.B. EAI (Enter­pri­se App­li­ca­ti­on Inte­gra­ti­on) und SOA(Service Ori­en­ted Archi­tec­tu­re). Wer damals nur auf dem Wis­sens­stand der Groß­rech­ner und COBOL-Ära agier­te, war nicht mehr wettbewerbsfähig.

In den letz­ten 20 Jah­ren haben wir einen rie­si­gen Inno­va­ti­ons­schub um hoch­leis­tungs­fä­hi­ge Inter­net­lö­sun­gen und Mobi­le Devices erlebt. Wer in die­sem Markt Fuß fas­sen will, soll­te es wie­der­um nicht (nur) mit dem Know-How von Enter­pri­se-IT machen (dass Sie die­ses Know-How brau­chen, um ggf. Ihre mitt­ler­wei­le zur Lega­cy gewor­de­nen Backend-Pro­zes­se an Ihre Digi­ta­li­sie­rungs­lö­sun­gen anzu­bin­den, steht auf einem ande­ren Blatt; auch damals wer­kel­te hin­ter moder­nen Enter­pri­se Ser­vices oft eine COBOL-Legacy).

Ich habe die Befürch­tung dar­ge­legt, dass Digi­ta­li­sie­rungs­pro­jek­te zum Schei­tern ver­ur­teilt sind, wenn sie auf einem zu gro­ßen Know-How-Rück­stand begon­nen wer­den. Aber natür­lich ist das etwas, was Sie für Ihre kon­kre­te Situa­ti­on beur­tei­len müssen.

Soll­ten Sie bei den meis­ten der dar­ge­stell­ten Trends gedacht haben, „Machen wir schon oder kön­nen wir bei Bedarf schnell inte­grie­ren“, freut es mich für Sie. Mit­un­ter kann man auch auf bereits eta­blier­ten Umge­bun­gen neue Tech­ni­ken und Pro­duk­ti­vi­täts­schü­be inte­grie­ren, indem man z.B. nach und nach funk­tio­na­le Pro­gram­mie­rung ein­führt (auf Java-Sys­te­men eher mit Sca­la als mit Java 8, auf .NET mit F#).

Wenn Sie aber das Gefühl haben, zu weit weg zu sein von die­sen gan­zen The­men, emp­feh­le ich: Ver­su­chen Sie nicht, die Para­dig­men­wech­sel in Ihre Lega­cy-Tech­ni­ken und ‑Teams hin­ein zu quet­schen, son­dern nut­zen Sie die Chan­ce für einen par­al­le­len Neu­an­fang, der dafür umso radi­ka­ler sein kann. Das ist eine rie­si­ge Chan­ce: Wenn man auf die­se Wei­se unbe­las­tet Digi­ta­li­sie­rungs­lös­nun­gen in einer ohne­hin neu­en Umge­bung begin­nen kann, wäre mein Tip (den Sie aber bit­te wie den gesam­ten Bei­trag cum gra­no salis neh­men), auf Eli­xir zu set­zen, das auf dem Rücken von Erlang gera­de zu einem regel­rech­ten Sie­ges­zug ansetzt.

Wir leben in span­nen­den Zei­ten. „Soft­ware is eating the world“, hat Marc And­re­sen fest­ge­stellt. Damit Sie ein gro­ßes Stück vom Kuchen abbe­kom­men, soll­ten Sie die Mög­lich­kei­ten nut­zen, Soft­ware­ent­wick­ler heut­zu­ta­ge um Grö­ßen­ord­nun­gen pro­duk­ti­ver, effi­zi­en­ter, selbst­wirk­sa­mer machen als die Genera­tio­nen Ihrer Vor­gän­ger (und das ist durch­aus rele­vant: wenn ich heu­te mal per­sön­lich ent­wick­le, schät­ze ich mei­ne Pro­duk­ti­vi­tät im Ver­gleich zu mei­nen Anfän­gen in dern 80ern, um bestimmt Fak­tor 20–50 höher; das ist schwer zu schät­zen, weil wir uns sei­ner­zeit nicht ansatz­wei­se an so kom­ple­xe Sys­te­me gewagt hät­ten; ich weiß es gibt da drau­ßen Men­schen, die immer noch so programmieren).

Ich beglei­te Sie ger­ne auf die­sem Wege, wenn Sie Archi­tek­tur­be­ra­tung, Work­shops, Coa­chings, Reviews o.ä. benö­ti­gen. Aber auch über all­ge­mei­nen Erfah­rungs­aus­tausch freue ich mich. Spre­chen Sie mich jeder­zeit an.

Let’s code, have fun and chan­ge the world!

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: