Hajlamosak vagyunk egy-egy szoftver újdonságaival csak akkor foglalkozni, amikor megjelenik egy új, nagyobb főverzió. A megjelenést ekkor persze gyakran hangos gyártói csinnadratta kíséri, arról győzködve az ügyfélvállalatok IT és üzleti szakértőit és vezetőit, hogy a boldogulás egyetlen útja a mielőbbi áttérés az új, „vN.0” verzióra, miközben a „v(N-1).0.0”, vagy – ne adj Isten – „v(N-2).0.0” verziót tovább használók elszalasztják életük lehetőségét.
Verzióváltás - Miért nem kedveljük?
A nagyvállalati szoftverek verzióváltása azonban ritkán sétagalopp. Még ha nincs is fundamentális, architektúrális változtatás, az érintett üzleti folyamatok újratesztelése ekkor is hosszadalmas, erőforrásigényes feladat. Különösen igaz ez a middleware rétegre, amely alapműködéséből adódóan rengeteg vállalati rendszerhez kapcsolódik, a rajta áthaladó adatfolyamok számtalan kulcsfontosságú folyamatot érinthetnek. A middleware szoftver a motorháztető alatt van, így az üzleti oldal számára kevéssé látványos, de ha bármi gond adódna vele, akkor a hatása miatt a vezérigazgató is nagyon hamar tudomást szerezne róla. A verzióváltás projektek így a „várható üzleti haszon vs kockázat” szempontból vizsgálva gyakran erős hátránnyal indulnak.
Milyen gyakran jön ki új verzió a middleware szoftvereknél?
Nem csoda, hogy a vezető megoldások főverzióinak megjelenései között tipikusan 2-3 év, vagy akár még több idő is el szokott telni. És a vállalatok még ezeket sem mindig követik le. Gyakori, hogy a „technikai” verzióváltást csak a használatban lévő verzió gyártói támogatásának teljes megszűnése kényszerít ki, a megjelenést követő 5 vagy akár 7 év elteltével. (És ez még a jobbik eset! Hazánkban szép számmal futnak üzletileg kritikus szoftverek lejárt gyártói támogatású alapszoftveren is).
Mindez éles ellentétben áll azzal a szoftver-életciklus gyakorlattal, amit magánszemélyként például a mobil alkalmazásoknál már jó pár éve megszokhattunk: ott akár hetente jönnek ki kisebb-nagyobb új funkcionalitást, továbbfejlesztéseket (és persze az elmaradhatatlan hibajavításokat) tartalmazó frissítések. Ez a szoftver release modell egy az egyben nyilván nehezen értelmezhető egy nagyvállalati middleware környezetben. Pedig alapvetően minden nagyvállalati szoftver ugyanazt a célt kell, hogy szolgálja: a vállalat hosszú távú sikerességét. A siker legfontosabb feltétele pedig – piaci környezetben – az innováció és az adaptáció, azaz a képesség a gyors változásra a változó környezetnek megfelelően. Mindez még az olyan stabil „ház-alap” jellegű rétegekben is, mint a middleware, azt igényli, hogy az új ötletek, új megoldások, új technológiák a korábbiaknál megszokottnál sokkal kisebb késéssel kerülhessenek használatba.
Itt most nem beszélünk arról, hogy a SOA megközelítés, a vállalati szolgáltatásbusz (ESB) megléte eleve, alapjellemzőiből adódóan a vállalati „agilitást”, rugalmasságot növeli, hanem az igényt magára a middleware alapszoftverre értelmezzük. Ezt felismerve a nagyobb gyártók az elmúlt pár évben elkezdtek változtatni middleware szoftver-életciklus gyakorlatukon. Például az IBM az üzenetorientált middleware szoftvere (IBM MQ), az alkalmazáskiszolgálója (WebSphere Application Server) és az integrációs gateway-e (Datapower) esetében is bevezette a „Continuous Delivery” modellt. E szerint a ritkább, nagy főverzió megjelenések helyett a korábbiaknál gyakrabban ad ki olyan alverziót, mely új funkcionalitást is tartalmaz, ugyanakkor nem igényel hosszadalmas verzióváltás projektet. A zászlóshajó ESB terméke, az IBM Integration Bus legfrissebb (v10.0) főverziója 2015. áprilisa óta elérhető, amióta már 11 ún. Fix Pack jelent meg (tipikusan negyedévente). Ezek a csomagok azonban már csak a nevükben fix-ek, a dokumentáció szerint közel 60 újdonságot tartalmaznak. Ez több mint kétszerese az eredeti v10.0.0.0 főverzió bejelentett újdonságainak.
Tehát, a middleware alapszoftverek a látszólagos mozdulatlanság ellenére valójában folyamatosan fejlődnek. Mindeközben persze olyan újabb integrációs trendek, igények is megjelentek, melyek az architektúrát alapvetően érintik, nem kevés kihívást okozva a nagyvállalati architektek, fejlesztők, üzemeltetők és biztonsági szakemberek számára. Elég, ha példaként csak az API management témakörére gondolunk, mely egy külön blog-bejegyzést is megérne…
A nagy gyártókhoz képest szerényebb méretekben, de az Intalion is a folyamatos termékfejlesztés híve: saját middleware keretrendszerünk, az Intalion Middleware Suite (IMS) izgalmas funkciókkal bővült a közelmúltban, és további nagyszabású terveink vannak a közeljövőre is!
