Spôsoby zamedzenia vendor-locku

Prisli nam vyjadrenia k nasim pripomienkam k projektu CES.

4.pripomienka: zavedenie CES predstavuje zásadný zásah do hosp. súťaže v danom segmente. Žiadajú preto dostatočné odôvodnenie postupu, identifikáciu a vyhodnotenie alternatív, nakoľko ciele uvedené pre tento projekt je možné dosiahnuť aj inými než len navrhovanými spôsobmi. Vyplýva aj potreba riešiť zamedzenie vzniku vendor lock-in - tento problém požadujú zaradiť do rizík projektu a identifikovať opatrenia, ktorými sa tomu predíde.

Reakcia MF: vybraný postup je v ŠU zdôvodnený dostatočne a jasne, RZ predstavuje rámec reformy. Alternatívy, ktoré boli zvažované, sú vypracované v zmysle platných metodických usmernení. MF kladie v tomto RZ vysoký dôraz na zabezpečenie “change managementu”, aby garantovalo aj uplatnenie zmien v praxi, nie len zrealizovanie dodávky IS, či iných výstupov. Zvolená platforma, ktorá má len na Slovensku desiatky stredných a veľkých implementátorov je dostatočným nástrojom pre mitigáciu vendor lock-in rizika. Týmto, ak o aj ďalším prípadným rizikám je v prílohách ŠU venovaná osobitná pozornosť.

V studii sa slovo “lock” nachadza 6x a z toho iba 2x to je relevantne:

riziko závislosti od vybraného dodávateľa (vendor lock) je možné mitigovať výberom platformy, ktorá ma na trhu prakticky desiatky možných dodávateľov, pričom súčasťou dodávky má byť aj kompletná dokumentácia (užívateľská, vývojárska a pod.), ktorá MF SR v budúcnosti „uvoľní ruky“ pri výmenách jednotlivých dodávateľov.

Riziko vendor-lock-in je možné mitigovať výberom platformy, ktorá ma na trhu prakticky desiatky možných dodávateľov, pričom súčasťou dodávky má byť aj kompletná dokumentácia (užívateľská, vývojárska a pod.)

Je toto dostatocne? Existuje vobec nejaka statistika kedy toto stacilo na prebratie projektu inym dodavatelom?

Co by ste potrebovali, aby ste skocili do projektu velkosti CES (niekolko desiatok milionov eur)?

Z mojho pohladu (ked si odmyslime, ze robit megaprojekty je riziko same o sebe), tak aby som vobec uvazoval o tom, ze preberiem po niekom projekt potrebujem:

  • zaruku, ze tu je dostatok dodavatelov co v tom vie pokracovat (nie nejaky obskurny jazyk, framework alebo konvencie)
  • kvalitnu dokumentaciu (od architektury, popisu modelov az po zdokumentovane - rozumne zdrojaky a popis instalacie)
  • dodrzane coding standards (toto sa da automatizovat)
  • kvalita kodu (toto sa da aspon trochu automatizovat)
  • pokrytie testami (unit, integracne) aspon niekde na urovni 90%
  • volny pristup k zdrojakom - nech si to viem pozriet a zistit ci to je pravda. (opensource - nech vidime co sa za verejne peniaze nakupuje)

Bez tohto by som sa nechytil ani maleho projektu niekoho ineho, lebo by som sa vystavil obrovskemu riziku, ze nebudem vediet nic urobit.

Ak chceme vyuzivat sutaz naplno tak je potrebne dodatocne zmeny vediet nejako efektivne obstaravat. Napriklad mikroobstaravania v US? Bola by toto schodna cesta? Ako to obstarat u nas? @ps-vo ?

Tento problem sa neustale opakuje. Kazdy jeden novy projekt, ktory nahradza stary legacy projekt robi tie iste chyby. Argumentuje sa, ze zmena stareho systemu by bola drahsia ako vytvorenie noveho. Tak sa postavi novy system, ktory je v momente prevzatia zase legacy system s rovnakym problemom. Nekonecny kruh.

Napady co s tym?

1 Like

Osoba, ktorá nájde odpoveď na to, ako efektívne obstarávať IS asi nájde rovno aj zlatý grál… súčasné procesy VO nie sú nastavené tak, že by umožňovali akúkoľvek dodatočnú zmenu resp. dynamiku pri plnení - predmet musí byť opísaný dostatočne jasne, zrejme, zrozumiteľne a akákoľvek dodatočná zmeny počas plnenia by musela byť posudzovaná, či nie je podstatná a či by nemohla viesť k inému úspešnému uchádzačovi už pri výbere.
Toto neriešia ani postupy ako súťažný dialóg alebo súťaž návrhov, lebo aj v týchto sa scope pred podpisom zmluvy “zabetónuje” (aj keď oproti ostatným umožňuje aspoň ako-takú dynamiku pri tvorbe podkladov a definovaní požiadaviek/riešenia).
Bolo by super, ak by boli riešením mikro-obstarávania, ale mám obavy, že ani toto nie je cesta, lebo:

  • akonáhle by sme jedno mikro-obstarávanie ukončili, museli by sme začať s novým (lebo však VO trvá tých 6 - 9 mesiacov) a tým pádom nám uniká dynamika, lebo vznikajú prestoje kvôli VO
  • pri mikro-obstarávania sa vystavujeme riziku posudzovania rozdelenia predmetu zákazky, čo môže byť posudzované ako v rozpore so zákonom alebo by nás to nútilo do vyšších limitov (aby sme sa vyhli podozreniu z umelého rozdelovania predmetu zákazky za účelom vyhnúť sa vyššiemu limitu + postupu), to však vedie k vyššie spomínaným prieťahom :frowning:

Možno by sme mali prestať obstarávať diela a systémy, ale mali by sme obstarávať služby - osobohodiny expertov (analytikov, programátorov, architektov…)… Ak by sa aj “za jazdy” menil samotný scope a prístup k informačnému systému, principiálne to nemení scope poskytovaný týmito expertmi (analytik by naďalej analyzoval, programátor programoval…) - môžem im zadaním meniť zameranie/cieľ, ale ich práca/výkon sa nemení.
Samozrejme by to chcelo dobrú zmluvu, ktorá by vymedzila, kto je za čo zodpovedný (objednávateľ vs. poskytovateľ) a ktorá by ošetrila prípadné trecie plochy… a samozrejme dostatočne podkutého koordinátora na strane objednávateľa…
Pri takomto prístupe si viem teoreticky predstaviť, že by do rozbehnutého vlaku naskočil iný poskytovateľ a pokračoval v poskytovaní expertov a ich služieb. Príp. by sa dalo rozmýšlať aj nad rámcovkou s viacerými uchádzačmi/poskytovateľmi…

Zaujímavé myšlienky by mohli byť zachytené aj napr. tu:
PUBLIC ENTITIES REDUCING LOCK-IN: THE WAY FORWARD.
Sharing procurement practices in joint development of open source software
OPEN ICT STANDARDS FOR PUBLIC PROCUREMENT - FOSTERING INTEROPERABILITY
The EU CATALOGUE OF ICT STANDARDS

2 Likes

Je vendor lock-in skutocny problem? Podla mna je to skor o vybere spravneho partnera. Neviem, ci je rozumne ocakavat, ze na trhu bude 20 dalsich firiem, ktore by danu zakazku vedeli prebrat. To plati mozno u eshopov.

Je open source skutocne riesenie pre stat? Publikovanie kodu ma svoje vlastne rizika (v kazdom kode su chyby a prilisna otvorenost ulahcuje ich zneuzitie) a rovnako aj pouzivanie inych open source komponentov (nekonecna udrzba). Mne pride rozumne zverejnit kod napr. pre SK Digital a dalsich partnerov pre audit, ale neponukat ho otvorene zlym stranam.

Mam svoj vlastny bias - neviem si uz dnes predstavit iny model tvorby softveru ako SaaS. MVP, postupne vylepsovanie, agilny pristup. Lenze SaaS buduje skilled team niekolko rokov a potom ho treba prinajmensom udrziavat, pravdepodobnejsie nadalej zveladovat. Dokazali by statni uradnici manazovat take projekty a najst vhodne modely financovania? Subscription based vs. one-time fees? Dokazali by udrzat motivaciu ludi pracovat pre nich za rozumnu cenu?

Vyberam z FB.

@anton-somora: Von z vendor lock-in je mat kompetnych ludi na strane statu. Nic viac nic menej, pokial si uradnici zvykli, ze vy pani z firiem beriete tazke prachy, tak sa starajte, tak potom to bude tak. A aby som im nekrividil (ludom na strane statu) tiez im dajme 2000-3000 platy ako v komercnej sfere a tiez im dajme tie iste zdroje ako na strane komercnej sfery (nie ze dvaja robia, aj support, aj projekt manazment aj rozvoj, aj callcentrum)

@semancik: Na vendor lock-in je jedine zname ucinne riesenie: zverejnit zdrojaky. Vsetky. Uplne.

@softpae: A problém je medzi stoličkou a klávesnicou, lebo staré úradnícke gardy si našpecifikujú nový systém tak, aby bol ako starý a očakávajú, že bude robiť nejaké samozázraky, lebo je “nový”… Každý implementátor aj developer to zažil. Kým na strane štátu nebudú ľudia, čo sa nebudú báť postaviť za riešenia, ktoré si vyžadujú zmeny v zaužívaných spôsoboch, tak nejakú veľkú zmenu môžeme len ťažko čakať. To je vec, na ktorej by mal robiť Pellegrini.

Inak ubera sa ta debata uplne inak ako som chcel. Otazka znela, co by ste potrebovali, aby ste skocili/prebrali cudzi projekt. Skuste este raz.

Ja sa budem opakovat :slight_smile:

Na to aby som prebral cudzi projekt potrebujem v prvom rade zdrojaky. Ano, dokumentacia by bola fajn. Ale bez nej sa da prezit ak mam zdrojaky (vyskusane na vela open source projektoch). Ano, architektura by bola fajn. Ale vieme aka “architektura” je bezny standard, ako “perfektne” sa architektonicka dokumentacia udrziava ako “striktne” sa architektonicke principy dodrziavaju. Ano, test doc a test suite by bolo fajn. Ale vieme, ze vacsina projektov sa testuje manualne a casto az priamo v produkcii. Ano, mat ludi z povodneho projektu by bolo fajn. Ale priznajme si, ludia z povodneho projektu su casto prave tym problemom pre ktory ma zakaznik potrebu zmenit dodavatela.

Takze vsetko je to nakoniec o zdrojakoch. Na tom vsetko stoji a pada.

3 Likes

Security by obscurity? Ale ved vieme ze toto nefunguje. Ale budeme to skusat znova a znova. Nepoucime sa. K “zlym stranam” sa to dostane tak ci tak. A povedzme si pravdu, v pripade statnych zakazok je dost casto prave ten co to dodava ta “zla strana”.

1 Like

A vendor lock-in naozaj je skutocny problem. A velmi vazny. Vyber “spravneho partnera” to neriesi. Ani v najmensom. Partner je mozno spravny dnes. Ale bude spravny aj o rok? Aj o 5 rokov? Co o 10 rokov? Akvizicie, bankroty a ine obchodne katastrofy su uplne bezne. Firma co dnes funguje dobre nemusi o rok vobec existovat. A spolu s nou pojdu do obchodneho pekla aj data. Ak nahodou tie data nebudu v zlavnenej ponuke v ramci odpredaja zostatkovej hodnoty firmy. V tomto kontexte je SaaS a ine *aaS mozno aj uplne najhorsie mozne riesenie. Hlavne pre stat.

Zdrojaky su must. Ale dalej asi zalezi aky typ projektu. Ja by som statny projekt nebral bez dokumentacie. Iba ak by to bola ciste technicka zalezitost, bez biznis procesov.

Ked tak uvazujem, ak by som mal do toho ist, tak je tam tak vela rizik, ze by som si to zohladnil v odhadoch (rezervy), potom je otazne ci by sa to este zadavatelovi oplatilo.

Preberali sme niekolko velkych webovych projektov, tak napisem co nam pomohlo:

  • zdrojovy kod - vsetok, vratane konfiguracie - ta konfiguracia moze byt pri niektorych systemoch zaklad, na kode sa daju potom zbehnut analyzy kvality kodu
  • dokumentacia - uvodna analyza, technicka dokumentacia build procesu, odovzdavacia dokumentacia - hlavne poziadavky na system, vypichnutie specifik oproti standardu
  • testy - pokial su nejake biznis procesy, tak urcite unit/integracne testy, inac nam stacia behat testy
  • urcite by som dal podmienku, ze nesmu byt poziadavky na server typu 5 rokov stare nepodporovane phpcko, zend guard a podobne zazraky
  • nedaval by som open-source ako podmienku, ale vypublikovanie vsetkeho kodu na verejne dostupny repozitar ano
2 Likes

Tomuto uplne nerozumiem.

1 Like

mal som na mysli pouzitie existujuceho os projektu.

1 Like

Ako tak citam, tak som si uvedomil, ze tu unika jeden dolezity bod. Prebrat cudzi projekt nie je ten prvy krok v tomto procese. Predtym je na to potrebne urobit ponuku. A na to je potrebne situaciu analyzovat. Ked mi niekto da zdrojaky+config+dokumentaciu+testy na stredne velkom projekte tak mi potrva tyzdne az mesiace kym to prejdem a vyplujem odhad. Do tohto tazko niekto pojde kym nema realnu sancu na uspech. A ano, naozaj to zrejme skonci tak, ze tam nahodi strasne rezervy a celkovo to bude drahsie ako ten locknuty dodavatel. A ak ma ten locknuty dodavatel co i len stipku obchodneho zmyslu tak ten projekt presne tak urobi: zdrojaky budu, ale historia nebude; dokumntacia bude, ale dolezite casti tam nebudu; testy budu, ale nie tie dolezite. Toto nie je cesta. Takto som to nemyslel.

Co som myslel je kompletne otvorenie zdrojoveho kodu od dna 0. Aby bolo vidno historiu projektu. A aktivitu na projekte. Aby bolo vidno kolko ludi na tom realne robi. Kolko zmien tam asi je. Aby bolo vidno vyvoj technologii v projekte. Aby bolo vidno ako sa system prisposoboval poziadavkam. Aby bolo vidno, ci su tam velke kusy kodu ktorych sa nikto 5 rokov nechytil. A tak podobne. Cize normalny open source projekt. Potom sa da urobit odhad ovela lahsie - a to aj bez detailnej analyzy vsetkych zdrojakov. Daju sa vyuzit automatizovane nastroje. Riziko znizuje uz samotny fakt ze projekt je verejny. A to nehovorim o tom, ze takyto projekt moze byt pod verejnou kontrolou od zaciatku. A tym sa zabrani tomu aby sa ten projekt vobec zacal mrsit. Skuste niekto odovzdat Potemkinovsky projekt kde su zdrojaky verejne. Taky projekt sa jednoducho neda vycentrovat! :slight_smile:

Samozrejme, ktora komercna firma ma zaujem na tom, aby “jej” projekt mohla lahko prebrat konkurencia? Toto tazko niekto dobrovolne urobi. Toto musi chciet zakaznik.

3 Likes

Asi najlepsia rekacia aku som tu kedy videl…Stare gardy si predstavuju novinky v IT ako “to stare, v novom šate”. Preto mame stale eID, Java eŽaloby, uzkostne trvanie na Windows-locku, absolutna ignoracia mobilnychj platforiem…Pelegrini je z prave z tej skupinky ludi, co nedokazu koncepcne pojat nove idei a pretvorit ich v efektivnejsi system.

Prosim drzme sa temy.

Tak ak by boli veci open source, s historiou a dokumentáciou, atd, tak potom by sa uz vselico dalo vymyslat, napríklad aj mikrozákazky (vsak preco nie, nejaký chýbajúci konektor by za par supov vedel dat hocikto, aj jednoclovekova firma, tlak na kvalitu by bol aj tym, ze open). Len by to chcelo manazment IT produktu na zakanzika (teraz zial nie je, teda mimo par vynimiek).

1 Like

Predpokladam, ze prevziat projekt znamena prevziat:

  1. prevadzku riesenia a/alebo
  2. podporu riesenia (odstranovanie chyb v SW)
  3. dalsi rozvoj riesenia

Kazda z uvedenych sluzieb bude mat odlisne KPI a prevzatie kazdej z nich bude vyzadovat odlisne zdroje, pristup a cas.

  1. Prevadzka - pristupy na prostredie, technicka dokumentacia/deployment diagram (kde je co nainstalovane), prevadzkove manualy, statistiky o vypadkoch a tak podobne. Cas potrebny na prevzatie je najkratsi z troch uvedenych sluzieb. A ludi, ktori maju skusenost s preberanim prevadzky.

  2. Podpora (odstranovanie chyb v SW) - dizajn a technicke specifikacie, repozitar zdrojakov, historia bugov a releasov, cas a partiu developerov so spravnym technologickym know-how a schopnostou vrtat sa v zdrojakoch a metodou pokusov a omylov najst workaround a/alebo riesenie. Cas potrebny na toto tiez nemusi byt nejako dramaticky. Zalezi na tom, ake su komercne podmienky (FTFP alebo T&M) a ocakavane garancie (SLA) zo strany dodavatela.

Body 1 a 2 su klucove pre zachovanie chodu uz existujuceho systemu. Pre zvladnutie rizika, ze nieco, co stalo vela $$$ a uz sa dnes pouziva sa pokazi a zrazu nejaka agenda nepobezi (scenare, ako plnit agendu s havarovanym systemom a ich nacvicenie musia byt sucastou takehoto preberania).

A po istom turbulentnom case a zvladnuti sluzieb 1 a 2, kedy novy dodavatel uz zhruba pozna ako system funguje, kde su jeho slabiny a z coho je postaveny, bude vediet efektivne navrhnut aj sposob, ako ho dalej rozvijat. Ci uz upravami alebo prepracovanim.

Pokial sa niekto bude snazit urobit vsetky 3 sluzby naraz, tak to dopadne, ako popisoval Rado. Cena (pokryvajuca vsetky imaginarne rizika na strane preberajuceho dodavatela) bude obrovska, bude sa musiet roztiahnut v case (teda kontrakt na vela rokov) a teda vlastne sa lock-in len prehodi z jedneho na druheho.

1 Like

Pri statnych IS je najvacsie riziko zmena legislativy. Ta prichadza “bez aviza” a terminmi casto sibenicnymi. Caste su scenare, ked zodpovedna institucia ma prechodne obdobie napr. 2 roky, ale zacne to riesit az posledny pol rok pred vyprsanim prechodneho obdobia. Nehovoriac o tom, ze par zmenenych slov v zakone moze mat dalekosiahly dopad na velky IS.

Nesuhlasim. Zmena legislativy postihuje vsetkych, aj IT systemy v sukromnych spolocnostiach. Rovnako v sibenicnych terminoch. Ak niekto zanedba riadenie takejto zmeny v prechodnom obdobi (ktore mimochodom sukromne spolocnosti nedostavaju) tak je to problem riadenia a nie problem IT systemu.

Netvrdim, ze je to problem systemu. Ale je to komplikacia pri preberani riesenia.

Ale ine som tym chcel povedat. A sice, ze je vyssie riziko, ze pride zmena legislativy pocas preberania, ako ze sa system sam od seba zahadne pokazi tak, ze by nesiel obnovit… (teda ak nebol sabotovany, a bol riadne prevadzkovany…)