Nagy András István Solution Architect szerepkörben dolgozik, szakterülete a Big Data és a Machine Learning, a LifeIntech podcast csatornára készült beszélgetésből kiderül, hogyan alakult a karrierje és milyen feladatai vannak jelenleg és mi az a két szó, amivel az EPAM-ot leginkább jellemezné
Hogyan vezetett az utad az EPAM-ig?
Egy magyar cégnél dolgoztam tíz éven keresztül, előbb Java fejlesztőjeként, majd vezető fejlesztőként, végül Solution Architect szerepkörben, mielőtt az EPAM-hoz jöttem volna, hét évvel ezelőtt. Az utóbbi pár évben főleg Big Data-val és mostanában Machine Learning-el foglalkozom. Ezen a területen nem magukat a Big Data eszközöket fejlesztjük, hanem azokra épülő vállalati data platformokat építünk (tipikusan cloud-ban), és valamilyen üzleti problémát megoldó Big Data alkalmazásokon dolgozunk.
Milyen feladatai vannak egy Solution Architect-nek általánosságban, illetve a te szakterületeden?
Elsődlegesen szoftver megoldások tervezése a feladat, amibe a konkrét tervezési munkán kívül sok minden beletartozik. A technológiák nagyon gyorsan változnak, főleg a Big Data területen, és tudni kell, hogy adott környezetben, egy-egy adott problémára mi lenne a legmegfelelőbb megoldás. Ehhez naprakésznek kell lenni a technológiák és az eszközök tekintetében. A környezet alatt pedig egyrészt értem a megrendelőt, az iparágának, cégének az adottságait, szabályozását, vagy akár a szervezeti felépítését, nyitottságát is az új dolgokra. Másrészt ebbe a környezetbe beletartozik a team is, aki az implementáción dolgozik. Pusztán technológiai szempontok mellett nyilván az is számít, hogy egy csapatnak mivel van tapasztalata, mivel dolgozik hatékonyan.
Solution Architect-ként egyébként a technológia mellett egyre többet dolgozom emberekkel. A szoftverfejlesztés minden lépésénél mindenki folyamatosan tervez és hoz döntéseket. Az Architect feladata az is, hogy világosak legyenek azok az elvek, amik alapján mindenki meg tudja hozni ezeket a döntéseket, vagyis hogy egy adott rendszerben bizonyos problémákat hol és hogyan oldjunk meg, hogy a rendszer egy koherens egész legyen, ami jól megérthető és jól karbantartható.
Ehhez a szerepkörhöz milyen szakmai tapasztalatra, tudásra, készségekre van szükség?
Solution Architect-ként egyrészt arra van szükség, hogy átlásd a rendszer egészét, annak kapcsolódását más rendszerekhez, meglegyen a „big picture”, beleértve azt is, hogy a rendszer hogyan segíti az ügyfél üzleti modelljét. Ugyanakkor fontos az is, hogy szükség esetén le tudj ásni a megvalósításban, képes legyél segíteni egy-egy konkrét alacsony szintű probléma megoldásában. Projektenként, csapatonként is változik, hogy ezek milyen súllyal jönnek elő az SA munkájában. Nagyon fontos még a kommunikáció, az együttműködés készsége vagy éppen a konfrontáció, a konfliktusok vállalása is. Nagyra tartom Gregor Hohpe-ot (akit a legtöbben talán az „Enterprise Integration Patterns” című könyv szerzőjeként ismernek), akivel egy német konferencián találkoztam, ő fogalmazta meg, hogy az Architect alapvetően extrovertált személyiség. Én eredendően kevésbé vagyok extrovertált – bár ez nyilván nem egy lineáris dolog, hanem egy spektrum - de SA-ként ezen túl kell lépni, az SA egy „influencer” kell legyen mind a csapat, mind az ügyfél felé. Ha pedig szakmailag valamivel nem tudok azonosulni, akkor ennek érdekében fel kell vállalnom konfliktusokat, akár az ügyfelekkel is. Az egyébként a tapasztalatom, hogy az ügyfelek ezt értékelni szokták – igazából azért keresnek meg minket, mert a tapasztalatainkra, a szakértelmünkre van szükségük.
Igénybe vettél tréningeket ahhoz, hogy fejlődj ezekben a készségekben?
A Solution Architect community az EPAM-nál folyamatosan szervez képzéseket, tréningjeik jól meghatározott tematikán haladnak végig belsős és külső előadókkal. Ilyen program például az SA School, illetve az erre épülő SA University, melyen én is részt vettem és nagyon hasznosnak tartom. A képzés végén a Sofware Engineering Institute által kiadott certification-t kapnak azok, akik elvégezték azt. Emellett szintén az SA community révén hozzáférésünk van szakirodalomhoz, online tréningekhez is. A projektekről is rendszeresen tartunk belső online session-öket, amikor megnézünk egy-egy konkrét esetet, amin valaki dolgozott és annak a tapasztalatairól beszélünk.
Hol van a belépési pont és mi a csúcs, hova lehet eljutni ezen a területen?
Ez is egy olyan terület, amiben az a jó, hogy mindig lehet fejlődni, szakmai vonalon is. Az EPAM körülbelül úgy különbözteti meg az egyes szinteket, hogy milyen volumenű projektet tud vinni valaki architectként, és ezzel változik az is, hogy mi a szerepe, mire lesz elsődlegesen hatással az ügyféllel való együttműködés során. Egyre többször olyan szerepben dolgozom, ahol inkább csak egy nagyon magas szintű vision van meg az ügyfél részéről, és szokszor már a konkrétan megoldandó probléma meghatározásán is közösen dolgozunk. Egy konkrét esetben, amin nemrég dolgoztam, az ügyfél egyik nagy befektetőjének a képviselőjétől származott ez a high level vision. Az ügyfél itt egy nagy multinacionális pénzügyi szolgáltató volt, a vision pedig körülbelül arról szólt, hogy a jelenlegi erősen manuális folyamataikra, döntéseikre, az egyes alkalmazottak személyes kapcsolataira építő szervezetet hogyan lehetne elindítani egy inkább szoftver-driven, data-driven átalakulás felé. Ehhez terveztünk ott egy data platformot és kerestünk olyan use case-eket amik a szervezet felé jól tudják demonstrálni ennek a megközelítésnek az erejét. Ez például egy olyan feladat, aminek nagy a hatása, impact-je, és ezért különösen érdekes tud lenni.
Hogyan tudnád összegezni az EPAM-os munkádat? Miként fogalmazod meg, ha valakinek, akit nem ismersz, elmondod, hogy itt dolgozol és ezzel foglalkozol?
Talán még ma is az a legnagyobb kihívás, hogy hogyan hozzuk össze a valós üzleti igényt egy szoftverben megvalósított megoldással. Valahol minden lead szerepkör feladata ennek a támogatása. Nyilván ebben másra fókuszál egy Delivery Manager, egy Business Analyst vagy egy Solution Architect, de mindenkinek fontos értenie, hogy mi a valós probléma, amit szoftverrel meg akarunk oldani, és én is ennek egy vetületén dolgozom. A Solution Architect feladata nagyon leegyszerűsítve az, hogy a „miért?” kérdés minél alaposabb megértésével segítsen az ügyfélnek a „hogyan?” és a delivery team-nek a „mit?” kérdést megválaszolni, egy koherens szoftver architektúra tervre lefordítva, hogy végül egy hatékony, jól karbantartható és az ügyfél üzleti célkitűzéseit előmozdító rendszer szülessen a csapat munkája által.
Megszokott kis játék a beszélgetéseink végén: mit jelent számodra pár szóban az EPAM?
Egy közösséget, ahol kapcsolatban vagyok olyan kollégákkal, akik hasonló problémákon, hasonló környezetben dolgoznak. Változatosságot, mert az EPAM egy olyan munkahely, ahol úgy tudok munkát váltani, hogy nem kell munkahelyet váltanom.
