Miért nem jó beszállítóra bízni a szoftver megszervezését?

Miért nem jó beszállítóra bízni a szoftver megszervezését?

A 21. századi rohanó világunkban teljesen természetes, hogy az informatikai feladatok jelentős része kiszervezésre kerül. Van, aki csak a kódolást viszi ki, van aki az egész infrastrukturális támogatást, és van aki a komplett alkalmazásfejlesztést.

Ennek nyilván megvan az oka – pénz – de nagyon vigyázzunk, mit szervezünk ki és mit nem. Avagy ne öntsük ki a vízzel a gyereket is.

Az architect egy olyan szerep, amit soha semmilyen körülmények között ne vigyünk kívülre. Architect alatt azt a személyt értem, aki megmondja, az adott üzleti igényeket hogyan lehet műszakilag megvalósítani, ergo ő mondja meg hogyan épül fel a szoftver, és műszaki döntéseket hoz.

A „kívülre” nem csak azt jelenti, hogy az indiai kódvetőket jelenti, hanem azt is, hogy például a KatiPeti Bt-től szoftvert vásárlunk.

Azt gondolom mindenki érti, hogy az indiai kódvetők miért ne játszanak tervezősdit. Nem azért, mert ne értenének a technológiát – értenek és szorgalmasak. Csakhogy nem látják az üzleti igények mögött az összefüggéseket, nem ismerik az üzleti folyamatokat. Mivel ők nagyon-nagyon messziről egy fejlesztőközpontban dolgoznak, a cégünk belső dolgaira nincs rálátásuk és nem is lesz.

Na de mi a baj a KatiBeti Bt-vel? Az érdekei.

Elhiszem, hogy egy kkv-ban dolgozó architekt nagyon magas szintet tud megütni szakmailag, jószándékú és rugalmas. Elhiszem, hogy a saját pályáján megveri a multinál dolgozókat.

Csakhogy a kkv-ben, a cégen kívül dolgozó Architect érdekei mások. Ő mindig bizonyítani akar. Olyan szoftvert akar készíteni, ami minden bajra megoldás. Bármilyen üzleti igény merüljön fel, a tökéletes design lehetővé tegye számára a megoldás szállítását.

Kis kitérő, avagy azok a piszkos anyagiak: Ugyebár a szoftverfejlesztéssel foglalkozó kkv-k megrendelésből, projektekből élnek. Számukra létkérdés, hogy minden igényt ki tudjanak elégíteni, hiszen akkor nem lesz mit a tejbe aprítani. Az Architect anyagilag abban érdekelt, hogy minél több megrendelés legyen, és ezeket minél kevesebb munkával meg lehessen oldani.

A kitérő után vissza a műszaki kérdésekre. Szóval ahhoz, hogy a kkv által fejlesztett szoftver mindenféle bajra gyógyír legyen, a szűk keresztmetszetet az interfészek, adatforrások és a multi belső folyamatai fogják jelenteni. A szűk keresztmetszet sosem a kkv műszaki tudása lesz, vagy a programozói teljesítménye: ha kell hétvégéznek, de a meló kész lesz határidőre.

Ezzel rögtön két súlyos baj van: vakon szaladgálás az ügyfél igényei után, és dzsungelharc a multi többi részével.

Kezdjük a másodikkal. Szóval ahhoz, hogy a fejlesztők bármilyen megoldást előállíthassanak, a kihívás nem a kód lesz – bármit megírnak – hanem az, hogy minden adatokhoz férnek hozzá. Mivel ők a multin kívül vannak (beszállítók), ezért csak korlátozott hozzáférésük van, illetve nagyon nehézkes új adatbázisokhoz hozzáférni.

Tehát a kkv teljesítőképessége azon múlik, milyen adatokhoz sikerült hozzáférni, és milyen rendszerekkel sikerült interfészezni. A meglévő adatokkal bármit tudnak bűvészkedni, de ami nincs, azt nem tudják előállítani – hiszen ez nem áll lehetőségükben.

Vagyis az Architect sikeressége azon múlik, milyen hatékonyan tud adatokat megszerezni. Az alkalmazás funkcióinak száma csak akkor növelhető, ha egyre több adattáblát kezel a rendszer. Normális esetben az adatokat ott kellene kezelni, ahova valók, és a többi rendszerrel interfészelni kell.

Példa: tegyük fel, hogy én vagyok az értékesítési rendszer ura. Az értékesítési rendszerben szükség van ügyfél adatokra. Az ügyfél adatok törzse az ügyfélszolgálati rendszerben van. Na ha külső architect lennék, akkor csinálnék egy sima adatduplikációt, hogy nálam is legyen egy ügyféltörzs – innentől kezdve nálam az adatbázis és bármit meg tudok csinálni.

A helyes megoldás persze az lenne, hogy valamilyen SOA-s környezetben mozogva megpróbálnánk elkerülni az adatduplikációt, és ehelyett integrálnánk a rendszereket.

Miért viselkedik másképp a belső és a külső architect? Mert a belsőt elsősorban a minőség és a fenntarthatóság érdekli, ezért a komplexitás és a felelősség csökkentésére (egyszerűsítés) törekszik. A külső architect ezzel szemben minél több adatra és minél több funkcióra hajt, ami folyamatosan növekvő komplexitást és növekvő felelősséget jelent.

A komplexitás növelése azért is jó (a kkv-nek), mert akkor egyre többet lehet karbantartási feladatokkal foglalkozni, folyamatosan növekszik a fejlesztés költsége, ami egyre növekvő profitot jelent a kkv vezetőjének.

Korábban említettem az ügyfél igényei utáni vakon rohangálást. Lehet, hogy az ügyfélnek mindig igaza van, de nem biztos, hogy amit mond, az úgy jó. Elvégre ő nem informatikus. Lehet, hogy az általa adott határidők és igények irreálisak. Lesznek olyan igények, amiket vissza kell dobni, vagy legalábbis pontosítani, hogy mit hogyan kellene megcsinálni.

A helyes döntéshez – mármint mit hogyan tervezzünk – szükség lenne az átfogó kép ismeretére, tudni azt, hogy 2-3-5 év múlva mit akar az ügyfél. Ezt külsősként nem fogjuk látni, és esélyünk sem lesz jó döntést hozni. Külsősként legfeljebb olyan döntéseket hozhatunk, amik ott és akkor jónak tűnnek… de hogy évek múlva mi lesz, az szerencse kérdése.

A végére még egy ok a belső architect mellett. Mint említettem, a multi belső világa a külső kkv számára átláthatatlan dzsungel. Ha bármilyen kérdésük van, nem tudják hova forduljanak. Ha észreveszik, hogy a multi egyik rendszerében hiba van, akkor nem tudják bevasalni annak kijavítását – helyette a szükség munka sokszorosáért építenek egy megoldást az ő oldalukon. Ami nyilván nem lehet tökéletes, hiszen a hiba nem ott van, de legalább jól el lehet fedni a hibát. Aztán egy idő után az eredeti hiba kijavul, a kkv szoftverében pedig ottmarad egy teljesen felesleges funkció, növelve a komplexitást és átláthatatlanságot. (ha évekkel később bele kell nyúlni abba a kódrészbe, senki sem fogja érteni, mit és miért csinál)

Összességében tehát azt mondom: a cégen kívüli architect nem jó megoldás, mert nem fogja egységes rendszerben látni a vállalat szoftvereit, csak a saját szoftverét látja, és csak azon belül tud bármit is megváltoztatni. Hiányozni fog az átfogó kép és a jövőkép, ami a helyes műszaki döntések meghozatalához szükséges.