Szoftverfrissítési ciklusok rövidülése

Az SQL Server 2000 és 2005 megjelenése között 5 év telt el. Ennyi év kellett ahhoz, hogy a Microsoft új szoftververziót dobjon piacra. Ezt követően még 2005-ben bejelentették, hogy az új stratégiának megfelelően rövidíteni fogják a termékek megjelenése között eltelt időt, és az SQL Serverből 3 évente új verziót fognak piacra dobni. Ma a felhős BI és az önkiszolgáló BI világában már ott tartunk, hogy gyakorlatilag hetente jelennek meg új verziók, kerülnek új funkciók a szoftverekbe.

Jó ez nekünk?

Igen, hiszen minél hamarabb tudunk egy-egy újdonságot a fejlesztés során a hatékonyság növelésére felhasználni, annál gyorsabban fog megtérülni a BI. És ennek örülünk. Ugyanakkor ha az üzemeltetési oldalát nézzük, akkor már nem ilyen örömteli a kép...

Nálad melyik verzió fut?

Az Excel 2010-es Power Pivotnál jött először és a Power Query-ben csúcsosodott ki a következő probléma: Adott egy nagyvállalat, amelyik elkezdi használni (egyelőre nem menedzselten) az önkiszolgáló BI megoldásokat. Először csak egy ember aztán egyre több és több ember kezdi el használni a technológiát. Hetente frissülő termékekről van szó így mindenki a belépéskori legfrissebb verziót kapja, amivel addig nincs is gond, amíg saját maga használja a technológiát. Ám ha meg akarja osztani a BI megoldását mással, akkor előjönnek a verziók különbségéből adódó kompatibilitási problémák...

Kis és közepes vállalatoknál ez még nem okoz nagy problémát, hisz viszonylag kevés ember önkiszolgáló BI megoldását kell felhúzni közös verzióra. Ugyanakkor egy nagy, több országban jelen lévő multinacionális vállalatnál ez már komoly problémát jelenthet: Hogyan tartsuk azonos verzión az önkiszolgáló BI megoldásokat egy olyan világban, ahol hetente jelennek meg új verziók? Folyamatosan léptessünk minden országot az új verzióra? Ragadjunk le egy régi verziónál és használja mindenki azt?

Egyik út sem járható könnyen egy olyan világban ahol hetente jönnek ki új verziók...

Újratervezés...

Hagy meséljek el egy másik példát: Egy hazai nagyvállalatnál néhány hét alatt összerakunk Azure-ban egy Big Data architektúrát, kiteszteljük a tesztkörnyezetben, elkezdjük összekattintgatni a már éles adatokkal operáló tesztkörnyezetet amikor észrevesszük, hogy megjelent az automatikus partícionálás lehetősége. Amikor az architektúrát terveztem még hiányzott ez a funkció, egyedi fejlesztéssel tudtuk csak megoldani a partícionálást. De most már megjelent...

Mit tegyünk? Ujjuk a startpisztoly ravaszán... Elinduljunk a kitesztelt architektúrával vagy szánjunk rá még pár napot és variáljuk át az architektúrát? Szakmai vénám nem engedné parlagon hevertetni az új funkciót, menedzseri vénám ragaszkodni akar az eredeti architektúrához...

Végül rászánunk még pár napot és újratervezzük az architektúra idevonatkozó részét. De mi lesz akkor, ha az adatvalidálásra is megjelenik egy gyári megoldás? Megint újratervezzük az architektúrát?

Itt van példának rögtön egy tegnapi bejelentés: Megjelent a Stream Analyticsben egy apró újdonság, amely valószínűleg alapvetően befolásolja majd a fájlok tárolását a Blog Storage-on. Természetesen megint élesítés előtt... Egy apró újdonság, amire azonban óriási szükség lenne...

Összefoglalva: A szoftverfejlesztési ciklusok felgyorsulásának egyértelmű előnyei mellett megjelentek azok a problémák is, amelyekre meg kell még találni a megoldást. A régi világban tudtunk készülni egy-egy újabb verzió megjelenésére, el tudtuk dönteni már a tervezés során, hogy érdemes-e megvárni a következő verzió újdonságait, vagy elindulhatunk egy korábbi verzióval és egyedi fejlesztéssel. Ma azonban az önkiszolgáló BI és felhős BI technológiáknál nem látjuk élesen a road map-et, nem tudjuk, hogy a következő héten mi fog megjelenni és az mikor lesz élesben is használható.

Örülünk az újdonságok azonnali megjelenésének, de ember legyen a talpán, aki naprakészen lépést tud tartani velük...