Ri­si­ko IT-Ar­chi­tek­tur

Die Le­ga­cy-Welt schluckt die Bud­gets und be­hin­dert die Mo­der­ni­sie­rung der IT.

Computerwoche - - Vorderseite - Von An­dré Christ, Ge­schäfts­füh­rer und Grün­der von Le­anIX und Ex­per­te auf www.computerwoche.de

Soft­ware wird in Zei­ten der Di­gi­ta­li­sie­rung zu ei­ner Kern­kom­po­nen­te vie­ler Pro­duk­te. Die Ge­schwin­dig­keit, mit der Un­ter­neh­men ih­re Soft­ware­sys­te­me aus­tau­schen, nimmt ste­tig zu. Der Ein­fluss der ITEnt­schei­der und vor al­lem der IT-Ar­chi­tek­tur auf den be­triebs­wirt­schaft­li­chen Er­folg war nie grö­ßer. Be­son­ders deut­lich wird das an der Ent­wick­lung der Ser­vice-ori­en­ted Ar­chi­tec­tu­re – kurz SOA –, aus der die Mi­cro­ser­vices Ar­chi­tec­tu­re (MSA) her­vor­ging.

An­ge­sichts der ho­hen Ge­schwin­dig­keit der Än­de­run­gen ist ei­nes be­son­ders wich­tig: Ru­he und Über­sicht be­wah­ren. Rai­ner Jan­ßen, der ehe­ma­li­ge CIO der Mu­nich RE, hat das vor rund fünf Jah­ren in dem Ar­ti­kel „SOA = Sa­me Old Ar­chi­tec­tu­re“für das CIO-Ma­ga­zin gut be­schrie­ben. Sein Rat: „Re­agie­ren Sie ent­spannt.“Den­noch lohnt es sich, das The­ma Mi­cro­ser­vices ver­sus SOA noch ein­mal ge­nau­er un­ter die Lu­pe zu neh­men, um zu se­hen, was sich in den ver­gan­ge­nen Jah­ren ver­än­dert und wei­ter­ent­wi­ckelt hat. Hoch­di­gi­ta­li­sier­te Un­ter­neh­men wie Ama­zon oder Net­flix be­wei­sen heu­te, dass sie dank Mi­cro­ser­vices ih­re Ge­schäf­te ska­lier­bar und in­no­va­tiv ge­stal­ten konn­ten.

Dras­tisch ver­kürz­te Pro­dukt­ent­wick­lung

Die klei­nen, ge­kap­sel­ten Soft­ware­stü­cke, die von so­ge­nann­ten Two-Piz­za-Teams, be­ste­hend aus sechs bis acht Per­so­nen, ent­wi­ckelt wer­den, er­lau­ben es den Un­ter­neh­men, den Pro­dukt­ent­wick­lungs-Zy­klus deut­lich zu ver­kür­zen und zu ver­bes­sern – nicht zu­letzt, in­dem da­bei stän­dig Feed­back ein­ge­sam­melt wird. Die Fä­hig­keit, neue Pro­dukt­be­stand­tei­le schnell zu lie­fern und ei­ne agi­le Ent­wick­lung vor­zu­neh­men, er­mög­licht die kon­se­quen­te Um­set­zung ad­ap­ti­ver Ge­schäfts­mo­del­le in den zu­neh­mend dy­na­mi­schen Märk­ten. So konn­te aus Ama­zon, dem eins­ti­gen On­line-Buch­la­den, der größ­te IT-Cloud-An­bie­ter der Welt wer­den. Net­flix konn­te sich vom DVD-Ver­leih zu ei­ner TV-Pro­duk­ti­on und ei­nem Strea­m­ing-Un­ter­neh­men ent­wi­ckeln.

Die Theo­rie­schlacht um SOA

Auf den ers­ten Blick schei­nen ei­ne Mi­cro­ser­vices-Ar­chi­tek­tur und ei­ne Ser­vice-ori­en­ted Ar­chi­tec­tu­re sehr ähn­lich, doch im De­tail sind si­gni­fi­kan­te Un­ter­schie­de zu er­ken­nen. Die­se Un­ter­schie­de er­for­dern letzt­end­lich ei­nen

„Wäh­rend ei­ne SOA meist vom CIO ver­ord­net wur­de und so­mit Top-down-Ent­wick­lung zur Fol­ge hat­te, ist es bei Mi­cro­ser­vices ge­nau um­ge­kehrt.“

Wech­sel der Ma­nage­ment-Prin­zi­pi­en. Doch der Rei­he nach: Was macht ei­ne SOA ei­gent­lich aus? Sie struk­tu­riert fach­li­che An­for­de­run­gen in Fä­hig­kei­ten, de­fi­niert Ser­vices ent­lang von fach­li­chen Da­ten­ob­jek­ten und er­mög­licht lo­se Ab­hän­gig­kei­ten. Das ge­schieht in ei­ner mög­lichst fle­xi­blen Kom­bi­na­ti­on mit ei­ner ho­hen Wie­der­ver­wen­dung. „Was hat sich denn an der Struk­tu­rie­rungs­auf­ga­be für fach­li­che An­for­de­run­gen grund­sätz­lich Neu­es er­ge­ben?“, frag­te Rai­ner Jan­ßen in sei­nem Ar­ti­kel. Aus mei­ner Sicht ist es ein kom­plet­ter Wech­sel von ei­nem „Top-down-Theo­rie­mo­dell“zur An­wen­dung von „Bot­tom-up Best Prac­tices“.

Für die Ein­füh­rung ei­ner SOA wur­den nicht sel­ten über vie­le Mo­na­te hin­weg in ei­nem Kraft­akt Do­mä­nen­mo­del­le ent­wi­ckelt. An de­nen wur­de so lan­ge ge­feilt, bis Tau­sen­de Do­mä­nen auf ei­nem hal­ben Dut­zend Ebe­nen be­schrie­ben wer­den konn­ten. Manch ei­ner wird sich noch an die Work­shops und Stee­ring Com­mit­tees er­in­nern, die be­wei­sen soll­ten, dass bei­spiels­wei­se die Do­mä­ne „Abrech­nung“im je­wei­li­gen Un­ter­neh­men nun zur Do­mä­ne „Ver­trieb“ge­hö­re und da­mit ab­ge­trennt sei von der Do­mä­ne „Buch­hal­tung“, die wie­der­um der Do­mä­ne „Fi­nan­zen“zu­zu­ord­nen sei.

Das al­les führ­te zu ei­nem im­men­sen theo­re­ti­schen Kraft­akt mit frag­wür­di­gem Re­turn on In­vest­ment. Das Ziel, sämt­li­che Ap­pli­ka­tio­nen ei­nes Un­ter­neh­mens mit die­sem Mo­dell dar­zu­stel­len und dar­aus den rich­ti­gen Zu­schnitt der Ser­vices ab­zu­lei­ten, kam ei­ner Her­ku­les­auf­ga­be gleich. Bei ei­nem Un­ter­neh­men mit rund 500 ein­ge­setz­ten Ap­pli­ka­tio­nen führ­te die­ser An­satz nicht sel­ten zu ei­ner Ma­trix mit mehr als ei­ner Mil­li­on ma­nu­ell aus­zu­füh­ren­den Da­ten­punk­ten.

Von un­ten nach oben: MSA er­mög­licht in­tui­ti­ve Be­nutz­bar­keit

Wäh­rend ei­ne SOA meist vom CIO ver­ord­net wur­de und so­mit die schon er­wähn­te Top­down-Ent­wick­lung zur Fol­ge hat­te, ist es bei Mi­cro­ser­vices ge­nau um­ge­kehrt. Das liegt vor al­lem an in­no­va­ti­ven Open-Sour­ce-Soft­ware­pro­jek­ten und Platt­for­men, die dank of­fe­ner REST-APIs ein­fa­che We­ge der In­te­gra­ti­on ge­schaf­fen ha­ben. Ei­ne REST-Schnitt­stel­le stellt die in­tui­ti­ve Be­nutz­bar­keit durch ei­nen Ent­wick­ler in den Vor­der­grund, bei­spiels­wei­se durch Cha­rak­te­ris­ti­ken wie „Kon­ven­ti­on vor Kon­fi­gu­ra­ti­on“.

Da REST-APIs eben nicht durch ein kopf­las­ti­ges De­sign am Reiß­brett ent­stan­den sind, sind nicht al­le Baustei­ne zu­ein­an­der kon­sis­tent, da­für sind sie aber auf­grund ih­rer Struk­tur für den ge­üb­ten Pro­gram­mie­rer schnell zu ver­ste­hen. Wäh­rend die in ei­ner SOA üb­li­chen Ser­vice­be­schrei­bun­gen via WSDL und Über­tra­gungs­pro­to­kol­len auf ei­ner XML-Ba­sis auf­grund ih­rer Kom­ple­xi­tät für Ent­wick­ler ab­schre­ckend wa­ren, ha­ben die JSON-ba­sier­ten Spe­zi­fi­ka­tio­nen ge­ra­de auch bei Web-Ent­wick­lern ei­ne deut­lich schnel­le­re Lern­kur­ve er­mög­licht.

Nicht et­wa ein Zu­sam­men­schluss von gro­ßen Kon­zer­nen wie das W3C hat ei­ne Spe­zi­fi­ka­ti­on von REST-APIs vom Him­mel fal­len las­sen; hier­bei han­delt es sich viel mehr um ei­ne er­freu­li­che Bot­tom-up-Ent­wick­lung, wie das Bei­spiel Swag­ger zeigt. Aus ei­nem Hob­by­pro­jekt ei­ner Web-Fir­ma ent­wi­ckelt sich ge­ra­de ein De-fac­to-Stan­dard für die Do­ku­men­ta­ti­on von APIs. Das liegt vor al­lem dar­an, dass ei­ne au­to­ma­ti­sche Ge­ne­rie­rung von Soft­wareDe­ve­lop­ments-Kits (SDKs) ge­nau­so mög­lich ist wie ei­ne au­to­ma­tisch er­zeug­te Do­ku­men­ta­ti­on, die es er­laubt, REST-APIs di­rekt auf­zu­ru­fen.

Na­tür­lich war das zu­vor theo­re­tisch auch schon mit WSDL mög­lich, doch erst jetzt kann es er­folg­reich im­ple­men­tiert wer­den. Denn jetzt steht nicht mehr der Zwang der Stan­dar­di­sie­rung und Har­mo­ni­sie­rung im Vor­der­grund, son­dern ei­ne mög­lichst brei­te Nutz­bar­keit in zahl­rei­chen Pro­gram­mier­spra­chen und Frame­works.

In der SOA-Welt setzt sich der Top-downGe­dan­ke auch in der Idee fort, sämt­li­che Web­ser­vice-In­ter­faces und Pro­gramm­code-Vor­la­gen di­rekt aus den so­ge­nann­ten Fach­klas­sen – ge­mäß dem Mo­del Dri­ven De­sign – zu ge­ne­rie­ren, da­mit mög­lichst al­le In­ter­faces „gleich“sind. Die­ser An­satz führt je­doch in ei­ne Sack­gas­se. In mo­der­nen Un­ter­neh­men lässt sich durch ein Kor­sett und durch Zwang kei­ne In­no­va­ti­on her­vor­brin­gen. Die er­folg­rei­che Um­set­zung ei­ner fle­xi­blen und ro­bus­ten Ar­chi­tek­tur darf nicht von ei­nem mög­lichst ho­hen Stan­dar­di­sie­rungs­grad ab­hän­gen. Un­ter­neh­men blei­ben nur dann für Ta­len­te at­trak­tiv, wenn sich mo­der­ne Pro­gram­mier­spra­chen und Frame­works in be­ste­hen­de Ar­chi­tek­tu­ren in­te­grie­ren las­sen.

Ein wei­te­rer Fak­tor, der den Er­folg von Mi­cro­ser­vices be­güns­tigt, ist die Tat­sa­che, dass heu­te Netz­ver­bin­dun­gen mit ho­hen Band­brei­ten zur Ver­fü­gung ste­hen und die La­tenz­zei­ten ge­sun­ken sind. Das führt erst­mals da­zu, dass auch hoch­per­for­man­te Sys­te­me in ih­re Ein­zel­tei­le zer­legt wer­den, die in ih­rem Ba­ckend, wie bei­spiels­wei­se bei Net­flix, auf Hun­der­te ein­zel­ne Mi­cro­ser­vices zu­grei­fen.

Die IT folgt der Or­ga­ni­sa­ti­on

Aus Sicht des Ma­nage­ments sol­cher Ar­chi­tek­tu­ren gibt es kei­ne Top-down-Re­geln oder Fach­klas­sen, son­dern die Fä­hig­keit ei­nes Un­ter­neh­mens, trotz Viel­falt ei­ne Kon­ver­genz zur Ziel­ar­chi­tek­tur her­zu­stel­len. Ei­ne Ziel­ar­chi­tek­tur wird nicht durch ei­ne Top-down-Ge­ne­rie­rung vor­ge­schrie­ben. Zu Zei­ten von SOA konn­ten sich Un­ter­neh­men noch zahl­rei­che Mit­ar­bei­ter leis­ten, die auf Po­wer­point-Ni­veau Ser­vices ent­wor­fen ha­ben. In der glei­chen Zeit ent­ste­hen heu­te bei Un­ter­neh­men wie Ama­zon oder Za­lan­do gan­ze Mi­cro­ser­vices und APIs, die in der Pro­duk­ti­on ge­nutzt wer­den.

Heu­te sind Mit­ar­bei­ter ge­fragt, die, an­statt sich mit theo­re­ti­schen De­fi­ni­ti­ons­fra­gen zu be­schäf­ti­gen, Lö­sun­gen für die kom­ple­xen Her­aus­for­de­run­gen von ver­teil­ten Sys­te­men über­le­gen. Mit dem Con­ways Law eta­bliert sich ei­ne ganz neue Art, sich zu or­ga­ni­sie­ren. Ein IT-Sys­tem und auch ei­ne IT-Land­schaft fol­gen in der Struk­tur der Or­ga­ni­sa­ti­ons­form. Ei­ne hier­ar­chi­sche Or­ga­ni­sa­ti­ons­struk­tur wird der fö­de­rier­ten Ar­beits­wei­se von agi­len Teams nicht ge­recht.

Hier lohnt sich ein Blick auf das von Za­lan­do ein­ge­führ­te Kon­zept der „Ra­di­cal Agi­li­ty“, das Eck­pfei­ler wie Au­to­no­my so­wie Mas­te­ry & Pur­po­se für die Or­ga­ni­sa­ti­on de­fi­niert. Zu­sätz­lich wer­den Füh­rungs­per­so­nen klar in or­ga­ni­sa­to­ri­sche und in­halt­li­che Füh­rungs­ty­pen ein­ge­teilt. Dies soll ver­mei­den, dass wo­mög­lich die bes­ten Pro­gram­mie­rer zu schlech­ten Füh­rungs­per­sön­lich­kei­ten wer­den.

Ent­wick­lung von Ap­pli­ka­tio­nen: Dank Do­cker ent­ste­hen neue Öko­sys­te­me

Die ei­gent­li­che In­no­va­ti­on – um nicht zu sa­gen der Pa­ra­dig­men­wech­sel –, den Mi­cro­ser­vices ge­gen­über Soft­ware-ori­en­ted Ar­chi­tec­tu­res be-

deu­ten, liegt in der Fä­hig­keit, das Kon­zept in die Pra­xis zu über­füh­ren. Das lässt sich un­ter an­de­rem dar­an er­ken­nen, dass Con­tai­ner-Tech­no­lo­gi­en wie bei­spiels­wei­se Do­cker das The­ma Vir­tua­li­sie­rung auf ei­ne ganz neue Ebe­ne he­ben.

Rai­ner Jan­ßens Fra­ge, ob Vir­tu­al Ser­ver und Vir­tu­al Desk­top nichts an­de­res be­deu­ten als die Rück­kehr zum or­dent­li­chen Main­frame-Be­trieb, ist durch­aus be­rech­tigt und drängt sich ge­ra­de­zu auf. Doch auch hier kommt es dar­auf an, wie man es be­trach­tet. Mit Do­cker ent­steht ein neu­es Öko­sys­tem für die Ent­wick­lung von Ap­pli­ka­tio­nen. Zwar be­ruht dies im Kern auch „nur“auf Vir­tua­li­sie­rung, doch klei­ne, fei­ne Cha­rak­te­ris­ti­ka ma­chen den Un­ter­schied.

Zum ei­nen än­dert sich der Res­sour­cen­ver­brauch. Oh­ne Wei­te­res kann an­statt ei­ner vir­tu­el­len Ma­schi­ne ei­ne Viel­zahl von Do­ckerCon­tai­nern ge­star­tet wer­den, die im Bruch­teil von Se­kun­den ver­füg­bar sind. Und zum an­de­ren gibt es auch für die Vir­tua­li­sie­rung das Kon­zept von vor­kon­fi­gu­rier­ten Images, die dann für die ei­ge­nen Ein­satz­zwe­cke ge­nutzt wer­den kön­nen. Erst durch den fein­gra­nu­la­ren Schnitt so­wie durch Do­cker-Images und ei­ne ein­fach zu nut­zen­de Re­gis­try kön­nen sich Ent­wick­ler in Se­kun­den­bruch­tei­len ih­re In­fra­struk­tur zu­sam­men­stel­len, für die sie frü­her st­un­den­lan­ge Se­tups be­nö­tigt hät­ten.

Mit küh­lem Kopf den Um­bau be­gin­nen

Die Fra­gen, mit de­nen sich das Ma­nage­ment heut­zu­ta­ge kon­fron­tiert sieht, lau­ten et­wa: Wel­chem Image kann ich ver­trau­en? Oder: Wie be­trei­be ich ein ef­fek­ti­ves Mo­ni­to­ring und Feh­ler-Ma­nage­ment in ei­ner hoch­gra­dig dy­na­mi­schen In­fra­struk­tur? Auch hier zeigt sich, dass MSA- und SOA-Kon­zept denk­bar ähn­lich sind, al­ler­dings kleins­te De­tails den Aus­schlag ge­ben und über Er­folg oder Miss­er­folg ent­schei­den kön­nen.

Das Kon­zept von Mi­cro­ser­vices ist mitt­ler­wei­le nicht mehr neu. Um­so er­staun­li­cher ist es, dass vie­le Un­ter­neh­men bis­lang nicht dar­auf um­ge­stie­gen sind. Für Or­ga­ni­sa­tio­nen, die Mi­cro­ser­vices ein­set­zen, ist die­ses Mo­dell in­zwi­schen al­ter­na­tiv­los, weil die Vor­tei­le klar über­wie­gen.

Um­fra­gen zei­gen denn auch, dass be­reits im ers­ten Halb­jahr 2017 deut­lich mehr Un­ter­neh­men den Schritt zu Mi­cro­ser­vices-Ar­chi­tek­tu­ren wa­gen wer­den. Und je mehr Un­ter­neh­men mit und an Mi­cro­ser­vices ar­bei­ten, des­to wahr­schein­li­cher ist es, dass auch neue Mo­del­le ent­wi­ckelt wer­den. Wenn es dann so weit ist, sind IT-Ver­ant­wort­li­che gut be­ra­ten, sich an Rai­ner Jan­ßen zu er­in­nern, der schrieb: „Wenn Ih­nen al­so dem­nächst ein Be­ra­ter er­klärt, dass sich die Pa­ra­dig­men in der IT än­dern, re­agie­ren Sie ent­spannt.“Der Viel­zahl der Ve­rän­de­run­gen mit Hek­tik zu be­geg­nen, wä­re si­cher der fal­sche Schritt. Hin­ge­gen mit küh­lem Kopf und Mut die ei­ge­ne Or­ga­ni­sa­ti­on so auf­zu­stel­len, dass sie das Op­ti­mum aus den neu­en Mög­lich­kei­ten her­aus­ho­len kann, wä­re si­cher ein gu­ter Start.

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.