ITÉlet

Mi a gond a jól kinéző, frappáns kliens programokkal?

Mi a gond a jól kinéző, frappáns kliens programokkal?

Amikor az ember multinacionális cégnél van, akkor nem 1-2 rendszerrel dolgozik, hanem sokkal. Amikor az ismerőseim meghallják, hogy autós cégnél dolgozik informatikusként, akkor legyintenek – á, mit csinálhat ott egy informatikus, biztos van 1-2 rendszeretek és annyi. Pedig elég sok van, a nagyobbakból kb 150, az apraját és a titkos szoftvereket nem is számolva.

Az emberek bizonyára azért mondják az 1-2-t, mert amikor bemennek a márkakereskedésbe, akkor az orruk előtt a kereskedő valóban csak 1 vagy 2 rendszeren dolgozik, hogy megkeresse a kért modellt, leadja a rendelést és kinyomtassa a szerződést.

Ezek az emberek bizonyára úgy gondolják, hogy egy fészerben gyártjuk az autót, papíron tervezzük meg őket, kockás füzetben követjük a szállítást, és amikor eladunk egy autót, akkor húzunk egy strigulát a falra.

Miért gondolják mégis azt, hogy egy autógyár csak 1-2 rendszert használ? Mert az ember vizuális típus. Amit lát, az létező, kézzelfogható. Amit nem lát, az vagy létezik vagy nem, de legalábbis vitatható.
A látható dolgokról lehet véleményt mondani, azokkal lehet tervezni, azokról el lehet mondani, hogyan lehet kijavítani. Amit nem látunk, arról nehezen mondanak vélemény. Esetleg csak zavartan bólogatnak, hogy biztos jó lesz úgy ahogy mondtátok, de ha kész akkor mutassátok meg.

A szoftverekkel az a helyzet, hogy nem lehet mindegyiket megmutatni. Vannak nagyon látványos szoftverek – ilyen például egy céges web site az ügyfelek részére – és vannak teljesen láthatatlan szoftverek – ilyen például egy web service vagy egy terhelés elosztó szoftver.

A szoftverek fontossága nem attól függ, hogy mennyire látszanak és mennyire nem. A gyártást vezérlő workflow engine például nagyon fontos, és ha egy ici-picit is leáll, akkor megáll a gyár. A beszerzési rendszer azonban napokig állhat anélkül, hogy nagyobb baj lenne.

Ha már láthatóság és fontosság, akkor felhívnám arra a tényre a figyelmet, hogy az sokkal fontosabb, mi van az adatbázisban, mint az, ami a képernyőn megjelenik. Mindkettő fontos, de előfordulhat, hogy a képernyőn valami jól jelenik meg, miközben az adatbázisban rosszul van.

Mindez ellentmondást jelenthet azzal, hogy az ügyfél, az üzlet érdekei a legfontosabbak. Az ügyfél ugyanis nem az adatbázist látja, hanem a képernyőt, tehát mi lenne fontosabb, ha nem a képernyőkép? Igen ám, de a képernyőkép csak akkor lesz helyes, ha a mögötte lévő rendszerekben minden rendben van. A technológia miatt ok-okozat összefügg van a kettő között. Tehát ha az ügyfélnek, a felhasználóknak jót akarunk, akkor az adatoknak a hátsó részen is jónak kell lenniük.

Az ügyfeleknek jót akarunk, de milyen az ügyfél? Ha szerencsénk van, akkor megértő a nagy összefüggéseket az adatbázisok, szolgáltatások, back-end és front-end között. Ha nem, akkor vizuális típus lesz… és akkor neki csak a front-end lesz fontos. Mert ami látható, ami kézzelfogható azzal lehet tervezni.

Tipikusan a back-end rendszer tárolja az adatokat, ott dőlnek el a dolgok, ott van az üzleti logika. A front-end részen csak megjelenítjük az adatokat és interakcióba kerülünk a felhasználóval. Például van egy logisztikai rendszerünk (ahol adatokat tárolunk, döntéseket hozunk a kiszállítást illetőleg) és van egy rendelési rendszerünk, ami csak összegyűjti a rendeléseket, kipostázza azokat a logisztikai rendszernek, illetve megjeleníti a rendelés státuszát.
Ha n-rétegű alkalmazásunk van, akkor ezt még lehet tovább fokozni.

De a vizuális ügyfél mindent a megjelenítési rétegre akar tenni. Először az üzlet logikát. Aztán kiderül, hogy adatokat is lehet ott tárolni – tehát tároljunk mindent ott. Szép lassan a back-end funkciók átkerülnek a front-end részre.

Vezet-e ez valahová? Csak káoszba. A front-end rendszer sosem lesz teljes egészében átvenni az üzleti logika és adattárolás szerepét, de minden próbálkozással egyre instabilabbá válik a rendszer. Átláthatatlanná válik, mi hol van. Egy idő után senki sem mer hozzányúlni, mert ki tudja milyen bonyodalmakat jelent a változtatás. A költségek növekednek, a stabilitás csökken.

Éppen ezért nem szabad, hogy az IT-hoz nem értő ügyfél architektúrális kérdésekben döntsön. Csak adja le az igényeit, és a szakértő majd megmondja, hogyan kell azt megcsinálni.