V tomhle případě je totiž nutné uvažovat technické řešení jak klientské, tak i serverové části. Klientské která budou obchodníkům nabízet a zprovozňovat či uprogadovat různé IT firmy podle jejich zařízení ( řekněme od přenastavení registračních pokladen (s napojení na the Internet), až po slibovaná samostatná řešení na tabletech a smartphonech).
Ale pak tedy serverová část běžících někde na serverech MF-a tady se obávám že už je "půl hodiny po 12té", a ´žádná firma už je nedokáže do konce roku implementovat-když navíc ještě vůbec neexistuje ani základní technická specifikace či funkční požadavky. (O takové hlouposti jako že by mělo proběhnout výběrové řízení, radši ani neuvažuji)
Jenomže, vzhledem k tomu že zde má probíhat online komunikace, je naprosto nezbytné aby firmy dodávající klientské části dokončily implementace svých řešení až potom co tato serverová část poběží -a až při reálné zátěži tu komunikaci odzkoušely a dokončily implementaci.
Jinak proti tomuto projektu budou nedávné průšvihy - ala sociální úřady a registr vozidel, naprostá pohodička. Protože tam za obě části, serverovou i klientskou zodpovídala jedna firma, a ta mohla případné opravy sama a v koordinaci provádět. V případě tohoto megamonstra kdy na jedné straně bude serverová část (dodaná narychlo vybranou firmou a zflikovaná na poslední chvíli)-a na druhé straně klientská řešení řekněme desítek/stovek IT firem nasazená u desítek tisíc uživatelů-naprosto neodladitelná a nopravitelná-a to hlavně z hlediska té online komunikace při vysoké zátěži..
Pro doplneni, registr vozidel pouziva zaroven maximalne 200-250 uzivatelu. To je zhruba pocet uredniku kteri s nim pracuji po cele CR v uredni den. Presto nefunguje radne dodnes (je to neuveritelne pomale, a drobne vypadky jsou stale). Tedy to "funguje" radove hure, nez lecjaky "zadarmo web", ktery bez problemu obslouzi o rad vice uzivatelu.
Registr vozidel pak generuje maximalne nizke desitky tisic req denne. Toto bude generovat miliony req. Dovolim si totiz nastrelit, ze takovy stredni obcan nakupuje obden, a obejde pri tom nakupu tak 3 obchody, tudiz i pokud se budu drzet pri zemi, tak nejakych 7,5M realizovanych nakupu denne + pochopitelne veskere akce ruznych drobnych zivnostniku, coz da dohromady jiste 10M pohybu za den.
Dritiva vetsina tech pohybu (rekneme 70%) se pak uskutecni behem 2-3 hodin. Nedovedu si predstavit v podani nasi statni spravy system, ktery by ustal vice nez 2M req/hod.
Ale ne to přece proběhne obráceně. Samozřejmě že nebude - nikdo nic předem vyvíjet (hovoříme o té serverové části)-napřed musí MF vyhlásit technickou specifikaci s funkčními požadavky-na tu pak vyhlásí výběrové řízení...No řekněme že podle toho ty firmy dokáží odhadnout svoje náklady (jak HW, tak implementace SW), a podat svojí nabídku.
A až ten který to výběrové řízení vyhraje, a až potom co s ním stát sepíše smlouvu, na tom začne dělat.
I když se bojím že tohle je fantasmagorie, výběrové řízení se určitě - díky časové tísni konat nebude. MF to přidělí přímo nějaké spřátelené firmě, a ještě bude poměrně benevolentní na "vícepráce"
Vsak to byl rekneme spodni odhad, realita muze byt klidne na desetinasobku i vice. Ale na tom myslim celkem nesejde.
Navic jsem pominul vsemozne automaty na mince i bankovky, kde denne budou generovany taktez miliony pochybu (a jsem vazne zvedav, jak je budou vsichni vymenovat, aby mohly vydavat uctenky, a kdo pak ty uctenky poletujici vsude kolem bude uklizet)