Solution architectek Szombathelyen: Vélemények és kedvező árak

Solution architect Szombathely területén

A Solution architect feladata az, hogy egy összetettebb digitális rendszer műszaki felépítését megtervezze, és az üzleti igényeket megvalósítható műszaki megoldássá alakítsa. Magánmegrendelőként akkor lehet rá szükséged, ha egy egyszerű weboldalnál többet szeretnél. Ilyen lehet egy több rendszerből álló ügyfélfelület, egy összetett foglalási megoldás, egy adatokat több helyről összegyűjtő alkalmazás vagy egy régi rendszer teljes átalakítása. Szombathelyen a személyes egyeztetés megoldható, de a tervezési munka nagy része távolról is végezhető.

A megoldástervező nem feltétlenül maga készít el minden programrészt. A fő feladata az irány meghatározása. Felméri a jelenlegi rendszert, összegyűjti az elvárásokat, azonosítja a műszaki kockázatokat, majd olyan tervet készít, amelyet a fejlesztők és más közreműködők követni tudnak. Sok megrendelő ott hibázik, hogy rögtön fejlesztőt keres egy már eldöntött technikai ötlethez. Pedig előfordulhat, hogy az ötlet drágább, bonyolultabb vagy kevésbé biztonságos a szükségesnél.

Mikor indokolt a megoldásarchitektúra

A megoldásarchitektúra akkor indokolt, amikor több rendszernek, adattípusnak vagy szolgáltatásnak kell együttműködnie. Egy kisebb honlapnál erre általában nincs szükség. De ha a rendszer felhasználókat azonosít, adatokat továbbít más szolgáltatásoknak, fizetést kezel, több adatforrást használ vagy később jelentősen bővülhet, a korai tervezés sok hibát megelőzhet.

Egy gyakori helyzet az, amikor a megrendelő több különálló eszközt használ. Az adatok részben táblázatban, részben egy régi alkalmazásban, részben pedig levelezésben vannak. Ilyenkor nem elég egy új felületet készíteni. Előbb tisztázni kell, hol legyen az elsődleges adatforrás, milyen adat mikor változhat, és melyik rendszer felel az egyes műveletekért.

Volt olyan eset a gyakorlatban, amikor egy ügyfél új ügyfélportált szeretett volna. Elsőre egyszerű feladatnak tűnt. Később kiderült, hogy három külön rendszerben tartották ugyanazokat az ügyféladatokat, eltérő formában. Ha rögtön elkezdődött volna a fejlesztés, a hibák átkerültek volna az új felületre is. Előbb közös adatmodellt kellett kialakítani. Csak utána volt értelme az új rendszer részleteit megtervezni.

A rendszertervezés fő lépései

A munka általában igényfelméréssel kezdődik. A szakember megérti, mit szeretne elérni a megrendelő, kik használják majd a rendszert, milyen adatokat kell kezelni, és milyen meglévő megoldásokhoz kell kapcsolódni. Ezután elkészülhet a logikai rendszerkép. Ez megmutatja a fő részeket és a köztük lévő kapcsolatokat.

A következő lépés a műszaki döntések rögzítése. Ide tartozhat az adatok tárolási módja, a külső rendszerekkel való kapcsolat, a belépés, a jogosultságok, a mentés, a naplózás és a teljesítmény kérdése. Egy jó terv nem attól jó, hogy minél több technológiát használ. Én személy szerint az egyszerűbb megoldást kedvelem, ha ugyanazt a célt kevesebb függőséggel is el lehet érni.

Ezután jön a megvalósítás támogatása. A megoldásarchitekt segíthet a fejlesztőknek értelmezni a tervet, ellenőrizheti a fontosabb döntéseket, és szükség esetén módosíthatja az eredeti elképzelést. A terv nem kőbe vésett dokumentum. Ha a projekt közben új információ jelenik meg, a műszaki irányt is hozzá kell igazítani.

Solution architect árak

A díj attól függ, hogy csak rövid tanácsadásra, teljes rendszertervre vagy több héten át tartó műszaki támogatásra van szükség. Egy egyszerű konzultáció lehet néhány órás munka. Egy összetett rendszer felmérése és dokumentálása már több napot vagy hetet igényelhet. Az alábbi összegek tájékoztató jellegű sávok magánmegrendelésekhez és kisebb projektekhez.

Az árakat mindig a várható eredménnyel együtt érdemes nézni. Egy jó rendszerterv nem közvetlenül látható funkció, mégis csökkentheti a későbbi átépítés és hibajavítás költségét. Tapasztalatom szerint 20.000 Ft alatt ritkán fér bele érdemi felmérés és használható műszaki javaslat. Ennél olcsóbb munka akkor reális, ha valóban egyetlen, jól körülhatárolt kérdésről van szó.

Megfelelő megoldásarchitekt kiválasztása

A megfelelő szakember kiválasztásánál fontosabb a gondolkodásmód, mint a hosszú technológiai felsorolás. Érdemes olyan jelentkezőt keresni, aki először kérdez, és csak utána javasol. A jó megoldásarchitekt rákérdez a jelenlegi folyamatokra, a felhasználók számára, a várható terhelésre, az adatvédelemre és a későbbi bővítési tervekre.

Kérj példát korábbi rendszertervezési feladatra. Nem feltétlenül kell teljes dokumentációt mutatnia, mert az gyakran bizalmas. Elég lehet, ha elmagyarázza, milyen problémát kellett megoldani, milyen lehetőségek közül választott, és miért vetett el bizonyos megoldásokat. Ez sokkal többet mond a tapasztalatról, mint egy általános bemutatkozás.

A Qjob.hu felületén különböző szakemberek ajánlatai összehasonlíthatók. Ezen az oldalon érdemes ugyanazt a rövid projektleírást elküldeni több jelentkezőnek. Így jól látható, ki milyen kérdéseket tesz fel és milyen mélységben érti meg a feladatot. Ne csak a díjat hasonlítsd össze. A dokumentáció, az egyeztetések száma és a megvalósítás alatti támogatás is számít.

Helyi szakember Szombathelyen és környékén

Szombathelyen helyi szakember főleg akkor lehet előnyös, ha a tervezéshez személyesen kell megismerni egy meglévő irodai folyamatot, eszközt vagy helyszíni rendszert. A Belváros, Olad, Kámon, Herény, Joskar-Ola és a Derkovits-lakótelep könnyen elérhető személyes egyeztetéshez. A környékről, például Kőszegről, Vépről, Gencsapátiból vagy Körmendről érkező szakértő is megfelelő lehet.

A legtöbb rendszertervezési feladat távolról is elvégezhető. Dokumentumok, képernyőmegosztás és folyamatábrák segítségével a fontos döntések személyes találkozó nélkül is meghozhatók. A helyi jelenlét tehát nem feltétel. Akkor érdemes előnyként kezelni, ha ténylegesen van helyszíni elem a projektben.

Dokumentáció és későbbi bővíthetőség

A megoldásarchitektúra értéke részben abban van, hogy a döntések később is érthetők maradnak. Nem kell több száz oldalas dokumentáció. De legyen világos, milyen fő rendszerelemek vannak, hogyan kapcsolódnak egymáshoz, hol tárolódnak az adatok, és milyen külső szolgáltatásoktól függ a működés.

Fontos rögzíteni a lényeges döntések okát is. Ha például egy bizonyos adatbázis vagy kapcsolati megoldás mellett születik döntés, jó tudni, miért. Enélkül egy új fejlesztő hónapokkal később könnyen lecserélhet egy részt úgy, hogy nem látja az eredeti korlátokat. Szerintem a rövid, naprakész dokumentáció többet ér, mint egy hosszú leírás, amelyet senki nem frissít.

A bővíthetőség nem azt jelenti, hogy minden lehetséges jövőbeli funkciót előre meg kell tervezni. Ez gyakori hiba. Sok pénzt lehet elkölteni olyan rugalmasságra, amelyre soha nem lesz szükség. Jobb a valószínű változásokra készülni, és egyszerűen hagyni módosítható pontokat a rendszerben. Egy jól megválasztott architektúra nem túlméretezett, hanem arányos a feladattal.

Ha a projekt később új funkciókkal bővül, a korábbi rendszerterv segít gyorsabban felmérni a hatásokat. Így könnyebb megmondani, melyik részhez kell hozzányúlni, milyen adat változik, és hol jelenhet meg új kockázat. Ez különösen hasznos hosszabb életű rendszereknél, ahol több fejlesztő is dolgozhat egymás után.