KÉPESSÉG=
Módszer+Technológia+Eszköz

„Hisszük, hogy a mai kor nagyvállalatának alapvető érdeke, hogy képessé váljon alkalmazásai, adatai és forrásai egyszerűen használható API-kon keresztüli megjelenítésére és összekapcsolására.”

Különben az IT-t elborítja a legacy rendszerek, és az új fajta üzleti igények kielégítését célzó innovatív, felhőalapú szolgáltatások kavalkádja, és megroppan az egyre rövidebb TTM-ből származó üzleti nyomás alatt…

Miért van ránk szükséged?

Én, mint informatikai vezető úgy látom, hogy Vállalatunknál az elmúlt években az IT, főleg az integráció területén saját elvei feladására kényszerült, és a környezet diktálta opportunista módon fejlődött. Ezért mára az IT tényleges képességei elmaradnak az általam kívánatosnak tartotthoz képest, mivel:

  • Változatos technológiákkal, gyenge dokumentációval kialakított rendszerek sokasága működik, esetleges integrációs megoldásokkal és magas gyártói kitettségekkel.
  • Átfogó integrációs koncepció hiányában, és az „inside-out” megközelítés miatt csak alig definiált adatátadások, és nem az igényekre reagáló szolgáltatások valósultak meg.
  • Nincs valódi ismeretünk az integrált működés minőségéről, max. következtetni tudunk rá.
  • A SOA, ESB és hasonló „hívószavakat” már unjuk; túl nagy beruházást és elköteleződést kívánnak, plusz távolinak és bizonytalannak látjuk a kimenetét.
  • Nem látjuk tisztán, hogy a konténerizáció, MSA, cloud és egyéb „modern dolgok” hogyan segíthetnének, vagy legalább illeszkedhetnének be a működésünkbe.
  • Nem tudjuk felépíteni, pláne fenntartani azt a tudást, amivel saját erőből megkezdhetnénk az átalakulást, és nagy a belső szakértői blokkolás veszélye is.

Eközben a környezeti nyomás továbbra is nagy, az üzleti területek felől folyamatos az igény új rendszerek integrálására, új üzleti funkciók bevezetésére, és az IT modernizálására, ami megfelelő informatikai képességek hiányában a problémák folyamatos súlyosbodásához vezet.

Az integrációs képességek javítása által megteremthetnénk annak feltételeit, hogy az IT fejlődése újra a szakmailag megalapozott irányba forduljon, és egyidejűleg jobb reagálási képességgel növeljük az üzleti területek elégedettségét.

Mutass többet Mutass kevesebbet

Fejlesztőként én úgy látom, hogy tervezési és fejlesztési metodikáink nem kellően kiforrottak ahhoz, hogy az elvárt minőségben oldhassuk meg az integrációs feladatokat. Azzal, hogy az integráció nem kellően átgondolt irányelvek és módszerek mentén folyik, a szolgáltatási szemléletű munka helyett sokszor szimpla technikai problémává egyszerűsítjük azt, és az integráció kialakítását az érintett rendszerek technikai struktúráinak megszületése utánra halasztjuk. Ez ellentmond a „shift-left” elvnek, amit pedig a hatkonyság növelése érdekében a menedzsment elvárásként támasztana a fejlesztéssel szemben; de nincsenek olyan eszközeink és módszereink, melyekkel változtathatnánk ezen.

  • A túlzottan technikai megközelítés erős csatolásokat eredményez a különböző fejlesztések között; ezekkel nem csak azok autonómiáját veszélyeztetjük, hanem a projekttervezést is nehéz helyzetbe hozzuk, egymásra való várakozásokba, egymásra mutogatásokat, és végső soron permanens csúszásokba visszük bele a projekteket.
  • A késői integrációs tevékenység és a túlzottan technikai megközelítés gyakran eredményezi azt, hogy az integrált működésben nem várt problémák merülnek fel, a késői projektszakaszokban az egyes rendszerek működése között már csak nehezen és drágán megoldható „gap-eket” fedezünk fel – ami egy korai, üzleti megközelítésre épülő tervezéssel elkerülhető lett volna.
  • A kiforratlan, ad-hoc vagy egyedi megoldások gyakran eredményeznek rendszerek közötti technológiai eltéréseket is, ahol mindenkinek igaza van, mindenki a másiktól várja a megoldást, és ami elkerülhető lett volna egy idejekorán kijelölt és kellő pontossággal specifikált eszközrendszer használata esetén.
  • Az üzemeltetés olyan monitoring, naplózási és hasonló elvárásokat támaszt az integrációs megoldással szemben, melyek kialakítása véleményem szerint nem egy rendszerfejlesztési projekt scope-jába tartoznak, de nem látni, hogy ha mi nem végezzük el, akkor ki fogja. Ez az egész tesztelési- és élesítési időszakot megterheli.

A fentiek komoly minőségi problémákhoz vezethetnek, és még az alapműködésekre is visszahatnak, rombolva azokat is. Ahhoz, hogy alapvetően jobb minőséget produkálhassunk, szükségünk lenne egy kiszámítható, követhető és pontos módszertanra, mely minden fél számára egyértelmű, világos és következetes előírásokat tartalmaz, és melyhez megfelelő támogató eszközrendszer és tudás is tartozik.

Mutass többet Mutass kevesebbet

Én, mint üzemeltető úgy látom, hogy vállalatunknál az integráció kialakítása ad-hoc jellegű és átgondolatlan. A fejlesztés során elnagyolják az integrációval kapcsolatos funkciók és eszközök tervezését, hogy aztán az üzemeltetéstől várják majd a csodát.

  • Az integrációs megoldások és eszközrendszer az üzemeltetési oldallal nem kerül előzetesen egyeztetésre. A fejlesztők gyakran alkalmaznak váratlan vagy kipróbálatlan integrációs eszközöket, melyeket kellő mértékben ők sem ismernek, és felépítését, működtetését sokszor úgy tolják ránk, hogy az üzemeltetésen sem áll rendelkezésre a szükséges kompetencia. A telepítéskor a szekrényből kidőlő csontvázak megoldására már rendszerint nincs idő, ilyenkor mindenki azt várja, hogy az üzemeletetés „valahogy oldja meg”; a fejlesztő pedig ilyenkor már rég valami máson dolgozik, vagy akár teljesen elérhetetlen.
  • Az integrációs eszközökért viselt felelősség nincs kellőképpen elhatárolva; a fejlesztés „hátra lép”, és bármilyen biztonsági, stabilitási vagy teljesítményprobléma esetén az üzemeltetésre mutogat, akik viszont gyakran semmilyen szinten nem voltak bevonva a megoldás kialakításába, és a mögöttes ötletet vagy koncepciót sem ismerik.
  • A tesztelés, majd később az éles üzem során felmerülő integrációs- és egyéb problémák kapcsán az üzemeltetéstől várnának olyan, az integrációs környezetből származó „élő” és utólagos információkat, melyek megfigyelésére, kinyerésére nincs eszköz, és a kapcsolódó alkalmazások sincsenek felkészítve. Ezek hiányában gyakorlatilag a transzparencia teljes hiányától szenvedünk, és egy fekete dobozzal „futunk”…

Végső soron az üzemeltetésen csattan az ostor, nekünk kell az éles üzem során kifejlesztenünk a tudást és módszereket arra, hogy stabilizáljuk és fenntarthatóvá tegyük az integrációs működést.

Én egy olyan környezetben szeretnék dolgozni, ahol egy stabil, kipróbált, és transzparens integrációs környezetben előre tervezhető módon, jól felmérhető méretű és bonyolultságú üzemeltetési feladatokat kell elvégezni. Ehhez szükséges, hogy a napi rutin teljesen kialakult és stabil legyen, és megoldó jellegű tevékenység a fejlesztési szakaszban, DevOps jellegű együttműködésben történjen.

Mutass többet Mutass kevesebbet

víziónk

Képzeljük el, hogy van egy vállalati integrációs megoldásunk, mely
  • nem technológiai, hanem módszertani nézőpontú;
  • nem igényel eszközökbe vagy humán tudásba való nagy beruházást;
  • nem szakítja szét a szervezetet haladókra és lemaradókra;
  • alacsony érettségi fokon megindítható, nem igényel túl nagy ugrást.
Ha lenne egy ilyen megoldásunk
  • contract alapú integrációra építve láthatóvá tehetnénk az üzleti folyamataink futását!
  • képesek lennénk a rendszerünk valós állapotát (meg- és) felmérni, és előjelzéseket tenni a jövőre!
  • lazíthatnánk a csatolásokat a domainek között, ezzel megnyitva a modernizáció lehetőségét!
  • szabadabban kezdhetnénk gondolkodni az architektúráról, növelve az IT végrehajtási képességét!

módszer

Mi abban hiszünk, hogy a módszerekben rejlik a siker kulcsa, mert hosszú távú, fenntartható sikerhez kevés az eszköz és a technológia, csak megfelelő módszerekkel érhetjük azt el. Különösen az integrációban, mely eltérő érdekek mentén mozgó szereplők és technológiák között, gyakran bizonytalan környezetben kell, hogy sikerre jusson. 

Hisszük, hogy az Inside-Out (csatornákra és struktúrákra koncentráló) megközelítésű integráció helyére Outside-In (a felhasználói igényekre és az ezeket szolgáló API-kra koncentráló) integráció kell, hogy lépjen.
Hiszünk a használati esetekre épülő API-kban, melyek többek, mint köztes réteg: önálló szoftvertermékek, melyek létrehozásával új értéket teremtünk.

Ezt szolgálja API-first elvű, UML vezérelt tervezési metodológiánk, melyet könnyűsúlyú, „smart endpoints and dumb pipes” elvű integráció tervezésére fejlesztünk. Célunk, hogy az integráció a szoftverfejlesztésben ne alárendelt szerepet töltsön be, hanem a fejlesztés motorjává váljon – hiszen a vállalati folyamatok megvalósulásában végső soron legalább akkora az integráció szerepe, mint az alapműködésé. Módszereink támogatják a korai integrációs tervezést, a szabványokra, best practice-ekre, ismert technológiákra és világos elvekre, egyszerű döntésekre épülő munkát. A technológiák és eszközök használatának sztenderdizálásával előmozdítjuk a stabil, biztonságos és transzparens működést. 

technológia

Hiszünk a bevált technológiákban. Bár a legújabb, feltörő technológiák alkalmazása borzasztó vonzó lehet, azonban fel kell ismerjük, hogy a nagyvállalati igényekre nem feltétlenül ezek adják a jó választ. Arról nem is beszélve, hogy életciklusuk még kiszámíthatatlan, és nagyvállalati körülmények között nagyon nehéz kezelni egy rövid életű, süllyesztőbe került technológia maradványait. A nagyvállalat elvárásaihoz és lehetőségeihez a bevált, már bizonyított technológiák illenek, melyek széleskörűen elterjedtek, azonban még életciklusuk zenitjén járnak, és sok éves időtávon sem várható leáldozásuk vagy hirtelen letűnésük. Ezekre a vállalat komoly kompetenciát és tudást építhet, amit képes lesz fenntartani is, így megalapozva a stabil működést.

Elvünk: „SOA in the large, Microservices in the small”.

Az API-first megközelítés nyomán bestseller API technológiákra (SOAP, RESTful) összpontosítunk, melyek MOM és stateless (http) csatornákon való alkalmazását támogatjuk szolgáltatásorientált (SOA, MSA) elvek mentén. Ezek a technológiai elemek jól tudják támogatni a felhő alapú és microservice (vagy azzal rokon) elvű kialakításokat és azok klasszikusabb architektúrákkal való varratmentes „házasítását” is – pl. az MOM eszközök fejlett QoS képességei nyitnak lehetőségeket e téren. Hasonlóan, lehetőség nyílik számunkra a klasszikus on-premise és a feltörő felhő alapú működtetés, illetve ezek változatai együttes alkalmazására, keverésére, akár igény szerinti váltogatására.

E technológiák alkalmazásával fellazíthatjuk a rendszereink és funkcióink közötti csatolásokat, és előmozdíthatjuk az alkalmazásmodernizációt anélkül, hogy sokkszerűen kellene megújítanunk az architektúránkat, és elkerülhetjük, vagy legalábbis fékezhetjük a modernizálás nem kívánt dominóhatását.

eszköz

Nem hiszünk az eszközök mindenhatóságában. Úgy gondoljuk, hogy nem a gazdag funkcionalitású, mindenre „is” jó eszközökben rejlik a siker. Az összetett működés több hibalehetőséget rejt, a eszközben való túlzott bizalom idővel eszköz- és gyártókitettséghez vezet. Ezek használatát az az ígéret hajtja, hogy a gazdag funkcionalitás által megfelelő módszerek hiányában is magától értetődővé válik a problémák megoldása; csak sajnos ez valójában sosem így alakul. Szerintünk – bármit is mondjanak a „nagy” gyártók – az ESB, az API Gateway és hasonló kifejezések koncepciókat, és nem termékeket takarnak; nem attól lesz tehát ESB-m, hogy megvettem, hanem, hogy megvalósítom a mögöttes koncepciókat.

Ezért mi az egyszerű, bevált, robusztus eszközök megfelelő módszerek mentén történő alkalmazásában hiszünk. Mi abban hiszünk, hogy a módszer az eszköz fölött áll, és ha van megfelelő módszerünk, és uraljuk a kiválasztott technológiákat, akkor tiszta és egyszerű elvárásokat tudunk megfogalmazni az eszközökkel szemben, és így képesek leszünk szinte bármilyen eszközön jó működést megvalósítani – legyen az egy piacvezető „all-in-one” termék, vagy egyedi fejlesztésű komponensek lazán kapcsolódó együttese. Módszertanunk éppen ezért eszközfüggetlen megközelítéssel került kialakításra, azzal a fókusszal, hogy maximális rugalmasságot biztosítson az „alá kerülő” eszközök tekintetében.

Az interfészek tervezéséhez egy UML alapú, modellvezérelt eljárást dolgoztunk ki. A módszertan pontos és egyszerű, a különböző szakértők nézőpontjait figyelembe vevő specifikációs- és modellezési módszert ad az üzleti igények megfogalmazásától az informatikai termékek előállításáig. Alkalmazása csak alapszintű UML modellezési ismereteket kíván meg; betanítható rendszerszervezői munkává egyszerűsítve a tervezés ezen szakaszát. A modellezést végző munkatárs a specifikációk alapján elkészíti az interfész platformfüggetlen megközelítésű UML modelljét (PIM). A „varázslat” ezután a teljesen automatikus modelltranszformációkban történik, mely során a PIM modellből előállnak az adott technológiákra és eszközökre célzott, platformspecifikus modellek. Ezen modellek már technológiai és környezeti részleteket is tartalmaznak, és alkalmasak arra, hogy a DEV és OPS által közvetlenül felhasználható artifaktokat hozzunk belőlük létre.

Mutass többet Mutass kevesebbet

Célunk, hogy az interfészek megvalósítása egy kiszámítható, és transzparens folyamattá váljon. A tervezési eljárás generált eredménytermékei a fejlesztésben közvetlenül felhasználhatók a forráskód előállítására, méghozzá lényegileg függetlenül a fejlesztési platformtól. Szintúgy generált termékekkel támogatjuk az integrációs infrastruktúra felépítését (pl. MOM, sorkezelő konfigok), melyek így mindig tökéletesen konzisztensek lesznek a fejlesztési artifaktokkal. A generált termékek előnyei, hogy ezek egy adott technológiai készletre épülnek, így elég egyszer „megtanulni” a használatukat, és onnantól sztenderdként lehet alkalmazni azokat. A laza csatolást biztosító technológiák, a sztenderdizált interfész kialakítások és az ezekkel mindig illeszkedő infrastruktúra kialakítás valóban megnyitják a kaput az automata tesztelés felé is, így az egyes rendszerek fejlesztései végre szétcsatolhatóak lesznek egymástól – ahogy azt mindig is szerettük volna.

Mutass többet Mutass kevesebbet

Az informatikai rendszereink integrált működését leíró nyilvántartások kialakításának sok döccenője van. Legfőbb akadálya azonban mégis csak az, hogy míg a nyilvántartástól várt haszon távoli, és elég absztrakt, a felépítésükkel járó munka nagyon is konkrét és azonnali. A nyilvántartás pedig abban a pillanatban veszíti értelmét, amikor az első helyen pontatlanná válik – ami, valljuk be, nagyon hamar bekövetkezik. Metodológiánk arra épít, hogy a tervezés és megvalósítás során olyan értéket állítunk elő, mely kézzelfogható, azonnali, és komoly érdekek fűződnek fennmaradásukhoz. Ezáltal a modellvezérelt tervezési eljárás fenntarthatónak bizonyul; a modellt pedig úgy alakítjuk ki, hogy egyben nyilvántartásául is szolgálhasson annak az integrációs környezetnek, melyet létrehozunk általa. Így biztosított, hogy a nyilvántartás mindig teljes és pontos, hiszen maga a nyilvántartás lesz a felépítés alapja, és nem csak „utolérni igyekszik” azt!

Mutass többet Mutass kevesebbet

Nem hiszünk a fejlesztés és üzemeltetés szétválasztásában, a fejlesztés során az üzemeltetési szempontok figyelmen kívül hagyásában.
Hiszünk és támogatjuk a DEVOPS-ot.

Az interfész tervezésekor már az interfészek üzemeltetéséhez szükséges szempontok is figyelembe vételre kerülnek és a modellből már az ügyfél által preferált/használt sorkezelőnek megfelelő konfigurációs állományok is előállnak. Az UAT és az éles működés során a modellben szereplő információkat is felhasználva naplózásra kerül az interfészek működése, amely nagyban segíti a hibák felderítését. A sztenderdek alkalmazása által nem dőlnek ki minden alkalommal új „csontvázak a szekrényből”, stabil tudással és eszközrendszerrel készülhet az üzemeltető az integráció működtetésére.

Célunk, hogy az üzemeltető ne a sor „rossz” végén álljon, hanem teljes jogú együttműködője legyen az integrációs tervezési és kialakítási folyamatnak, és számára pont azt a transzparenciát és kiszámíthatóságot biztosíthassuk, amire a megfelelő minőségű munkavégzéshez szüksége van.

Mutass többet Mutass kevesebbet

Kapcsolat