Ugrás a fő tartalomra

LáthatatLAN épITészet II - Építészet és az IT infrastruktúra szövevényes kapcsolata

Egy korábbi post-omban, már szót emeltem a IT / Network és az építőipar kapcsolatáról. Az akkori projektet sikerrel zártuk, és mai napig hellyel-közzel rendben működnek azok a berendezések, amiket akkor sovány-malac vágtában terveztünk (megvalósítási szempontból) és valósítottunk meg.  Azóta eltelt 5 év kapcsán és az akkori tapasztalatokat felhasználva új jogosultsági babérokra szeretnék törni, így ezzel tapasztalt kihívásokat osztok meg veletek.


 

Jogosultságok

 Az informatika és a telekommunikáció világa igen széles látásmódot igényel, kezdve az infrastrukturális elemektől a szoftvereken át egészen a vezérlő protokollokig.  Az iparági ajánlások legjobb gyakorlatok mellett mára több jogi környezet is szabályozza ezen tevékenységekhez kapcsolódó törvényes kereteket, gondoljunk például az adatkezeléshez kapcsolódó GDPR, vagy a pénzügyi szférát érintő DORA vagy a kritikus tevékenységet végrehajtó cégek NIS2 megfelelésére. Ezek a szabályozások törvények és rendeletek törvényes keretet biztosítanak arra vonatkozóan, hogy mit és hogyan építhetünk be a rendszereinkbe, hogyan integrálhatjuk egymással, hogyan férhetnek hozzá a felhasználók.

Ehhez hasonlóan a magyar törvények,  kormány rendeletek, önkormányzati rendeletek és szabványok (amennyiben törvényi hivatkozás van rájuk) szintén befolyásolják a leendő rendszerek tervezését és kivitelezését az építőipari tevékenységek során is, amelynél törvény még a tervező és kivitelező valamint ellenőrző személyekre és szakértőkre is bizonyos szintű megfelelőségeket ír elő.

Ezen szabályozási környezetért és tevékenységekhez kapcsolódó jogosultságok karbantartásáért a Magyar Mérnöki Kamara felel illetve a vármegyei kamarák (esetemben a Budapest és Pest vármegyei Mérnöki Kamara).

Kamara tagság és jogosultság előfeltétele is iskolai végzettségekhez kötött (BSc vagy MSc).

Szakterületünket érintő jogosultságok közül 3 építőiparban és építészetben használatos jogosultság is érdekes lehet:

- Műszaki Ellenőr (ME)
- Felelős Műszaki Vezető (FMV)
- Felelős Tervező (T)

Az informatikában és telekommunikációban alkalmazott szakmai szintek és dokumentáltsági elvárások nehezen egyeztethetők össze ezekkel a tevékenységekkel, legalábbis 5 évvel ezelőtt, amikor egy projekt kapcsán felmerült részünkről az FMV jogosultság szükségessége, még nem volt annyira explicit, hogy egy gyengeáramú aktív rendszer építése során milyen jogosultságokra is lenne szükség, akkoriban három szakági jogosultság felelhetett meg ennek a kritériumnak:

- Hírközlési építmények építési-szerelési munkáinak felelős műszaki vezetése
- Távközlési építmények villamos-szerelési munkáinak felelős műszaki vezetése
- Épületvillamossági felelős műszaki vezető

Ezek a szakmagyakorláshoz kapcsolódó jogosultságok megszerzéséhez szükséges az érvényben lévő jogszabályok (törvények, kormány rendeletek, önkormányzati rendeletek)és vagy jogszabályi fogalmak ismerete, illetve a szakmához kapcsolódó specifikus tudásanyag feldolgozása.

Nagyjából 5 éve sikeresen teljesítettem az MV-TV és MV-TE jogosultsági vizsgákat, nyilván a szükséges előfeltételekkel már rendelkeztem, és most kezdtem be a tervezői jogosultságok megszerzésébe, amelyek egyfajta frissítésül is szolgálhatnak a meglévő jogosultságaimhoz. 

Akkor ez most olyan mint egy CCIE vagy ilyesmi?

Röviden: Igen is, meg nem is.

Igen, mert vizsgázni kell a tudásanyagból, bár itt a gyakorlatot előre kell igazolni, mielőtt vizsgát tesz valaki és nem , mert alapvetően nem csak specifikus szakmai jellegű kérdések jöhetnek egy írásbeli vagy szóbeli alkalmával, hanem főleg szabályozási környezettel kapcsolatos ismertekre kérdeznek rá.

Sikeresen teljesítettem már az HI-V-hez (vezetékes infokommunikációs rendszerek, hálózatok, helyi és helyközi távközlési infrastruktúrák tervezésére jogosultság) kapcsolódó alap és szakspecifikus vizsgákat, most egy úgynevezett IT tervező jogosultsági vizsgára készülök. Ennek az anyagfeldolgozásába kezdtem bele néhány nappal ezelőtt, és kellemesen "csalódtam",  hiszen a valós munkához kapcsolódó jó általános tudásanyagot tartalmaz a felkészítő anyag amely olyan 300-400 oldal terjedelmű...

Az anyag olvasmányos formában olyan témakört feszeget, hogy mi a tervezőnek feladata, milyen tervezési koncepciókat és mikor kövessen, megemlítve, az agilis, scrum, TOGAF, Zachmann keretrendszereket, amik segítségével egy viszonylag egységes minőségű tervdokumentáció és eredménytermék készíthető, mindig az aktuális projekt vagy ügyfél üzleti igényeihez alkalmazkodóan. A tervezési segédlet és a mellékletei tartalmazzák, azokat a tervezői sablonokat, amik "bármilyen" IT projekt kapcsán jó kiindulási alapot adhatnak arra, hogy miként kell a projektet tervezni és kivitelezni. Persze egy IT architectnek nem feladata minden területen a specifikumok meghatározása és nem is lehetséges, viszont egy jó fejlesztési koncepció megalkotása, amibe minden érintett technológia architect vagy mérnök hozzá tudja tenni a saját megoldását.

A dokumentum aztán sorra is veszi, a különböző architektúrákat, általános elméleti síkon egy-egy gyakorlati betekintéssel.

Nos van olyan 120+ kérdés írás és szóbeli, amelyekre a tananyagban fellelhetők a válaszok, ezek némely ponton túl általánosak, vagy túl mély tudást igényelnek - Egy szakmában dolgozó IT tervező nem minden területen rendelkezik mély szoftverfejlesztési és kódolási ismertekkel - de megugorhatónak érzem, aztán majd meglátjuk mi lesz április 9-én ;-)

Az MMK lehetőséget biztosít online (proctored) és on-site vizsgára is, és számomra meglepő módon a on-line szóbeli is lehet. (Gondolom az írásbeli eredmény %-kos függvényében).

Kíváncsi leszek, mennyire lesz harmóniában a tananyag majd az éles vizsgával, remélem sunyiban nem változott a hivatalos kérdésbank.

Addig is akit érdekel a téma az böngéssze a mmk releváns oldalát, vagy a vármegyei kamara honlapját a jogosultságok feltételeiről.

Addig is Kellemes Húsvéti Ünnepet!

Pá...

 

 

 

Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be...

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )...

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy k...

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs...