No mozno by som navrhol další approach. Tak ako sa daju flagovat vyvíjané, alebo zamýšľané projekty, tak sa dá flagovať aj prevádzka (alebo pred realizáciou, zamýšľaný spôsob prevádzky). To znamená, kde to bude nainštalované, ako je to tam so stavom administrátorov a prevádzkových manažérov, ako tam majú riešenú bezpečnosť všeobecne a ako do toho zasiahne nový zamýšľaný projekt. Ako vyzerajú postupy v danom datacentre. Čo sa deje pri malom výpadku, čo sa deje pri kritikom výpadku, vedia vôbec ľudia ohodnotiť dopady výpadkov ? Aká je fyzická možnosť dodávateľov rýchlo niečo diagnostikovať, majú tam vôbec prístup (fyzický / vzdialený) ? Ak mú v kritickej infrastruktúre zapojené jedinečné HW zariadenia, je zabezpečený ich support (výmena) v prípade výpadku ?.. a podobne. A myslím, že to je (aspoň sčasti) to čo @IvanK myslel svojim príspevkom.
Pretože ako baba Vanga hovorí napríklad celý eHealth padne najskor práve na toto …
(bezp. projekt nadefinoval učitý počet rolí, ktoré sa nesmú prekrývať jedným človekom … a ak chcem zabezpečiť 24x7x365, tak tam musíš mať 3 smennú prevádzku s premysleným zastupovaním. Na nielktoré tie role ani tolko certifikovaných ludí čo by ten eHealth potrebival nenájdeš… A reálny stav je pár ľudí v jednosmennej prevádzke, v režime permanentnej nespokojnosti … Takže čo sa celé tie roky robilo ?)
PS: je mi jasné že dostať sa k týmto informáciám nie je jednoduché, lebo prevádzka datacentier môže a možno by aj mala byť v sprísnenom až utajovanom režime. Ale možno sa podarí také niečo vnúknuť do hlavy Pellému a on už veci zariadí z pozície sily . Vo vlastnom záujme.
Ano v tomto mas absolutnu pravdu. Tak to je az na svetle vynimky vsade v statnom sektore. a vidim uz aj priklon k SLA … aj k specializovanym security. Ale stale iba viacmenej o prevadzke bezpecnosti (udrzanie pri zivote, updaty, aby vsetko prispievalo do SIEM, pripadne nejaky rychly check manazmentov/SIEM raz za tyzden/dva). Bezpecnostna SLA v zmysle kontinualneho monitoringu, analytiky, incident response a pod je zatial iba vo hviezdach.
Edit: mozno by stalo za myslienku nieco ako jednotne SOC pre stat, aspon pre male projekty, ktore nemaju vlastne kapacity na udrziavanie bezpecnosti. Ale to je zatial asi iba moja fantazia …
Edit2: btw prave (aj) taketo situacie by mala rizikovka pokryvat a malo by z nej byt jasne, ake su rizika, ako sa daju pokryt a co sa stane ak nebudu pokryte. To je prvy krok. Druhy je navhnutie procesov/technologii/postupov a pod na ich pokrytie. A treti krok je realna realizacia navrhov, teda aj zvysenie personalneho stavu ak to projekt vyzaduje…
Prevadzka sa da flagovat iba do urovne, ktora je spomenuta v projekte. A casto tam o tom nic podstatne nieje. Stav adminov moze dopadnut tak, ze v ramci projektu sa rata s navysenim poctu adminov kvoli jeho prevadzke a nakoniec niekto prepusti aj polovicu aktualnych adminov, lebo setrenie. IR sa tam pokial mi pamat siaha nikde nespomina, pokial to nepotlaci poctivy dodavatel. Ostatne detaily casto niesu zname ani zadavatelom a dlho ani dodavatelovi.
Taketo hodnotenie ako hovoris by mala riesit v ramci statu niektora z organizacii (ja som bol vzdy za nieco ako ministerstvo informatizacie alebo nejaky prierezovy utvar s velkou vahou … a aj politickym pokrytim, aby mohol aj na ministra) interne, pre kazde ministerstvo, organizaciu, a projekt. Akesi ich interne redflags. Aby sa zamedzili duplicity (obrovske), zabezpecila koordinacia jednotlivych projektov, ich integracia medzi rezortmi a podobne. Proste aby to malo pana. Samotne ministerstva na to nemaju personalne ani odborne.
Co sa tyka eHealth, tak tam sa napr. robila rizikovka a security je tam ponata dost komplexne. POcet roli vypadol prave z toho. Je to dost dolezity projekt, aby sa koli nemu viedla aj 3smenna prevadzka a prijalo sa par adminov. A nemusia sediet prave v BA, kde je vysoka fluktuacia a ludia sa tam tocia ako kolotoc. A ked sa pytas, co sa za tie roky robilo? Ubudalo adminov Aktualne su tam na sec infra dvaja.
Rozumiem. Poriadne riešenie bezpečnosti je samozrejme dôležité. Aj si viem zhruba predstaviť čo by sa dalo v časti “produkt” takéhoto projektu vyžadovať/kontrolovať. Akurát že tieto veci nikdy nebudú pre nás (verejne) dostupné. Čo s tým?
Mam jeden napad na zlepsenie Red Flags. Ide aspon o zakladnu (architektonicku) kontrolu kvality navrhu sluzieb. Aby ich nebolo vela, aby zoznamy boli konzistetne a aby davali zmysel. Pricom podla metodiky plati, ze koncove sluzby su pre ludi a aplikacne su pre stroje (inak povedane API v mojom ponimani).
Z podhladu Red Flags dobre hodnoteny ORSR je v tomto prikladom, kde je mozne navrhnute sluzby vylepsit. Vytiahol som z roznych casti MetaIS, ako su kde sluzby evidovane:
Koncove sluzby ORSR sluzby v MetaIS (12):
Správa životného cyklu obchodných spoločností
Evidencia v zbierke listín
Sledovanie obchodných spoločností
Sledovanie stavu spracovania
Sprístupňovanie údajov z európskeho obchodného registra
Generovanie výpisu z Obchodného registra
Podávanie návrhov na zápis obchodných spoločností
Podávanie návrhov na výmaz obchodných spoločností
Sprístupňovanie otvorených údajov
Rezervovanie názvu obchodných spoločností
Podávanie návrhov na zmenu údajov o obchodných spoločnostiach
Sprístupňovanie údajov z Obchodného registra
Koncove sluzby ORSR v studii:
v hlavnom dokumente v obrazkoch (14), navyse su:
Poskytovanie udajov
Spravovanie systemu
a toto je v tabulke v prilohe (1):
Správa životného cyklu obchodných spoločností
Aplikacne sluzby ORSR v MetaIS (sluzby sucasneho systemu pomiesane s novym) (46):
Podanie žiadosti o poskytnutie výpisu z obchodného registra v elektronickej podobe
Podanie žiadosti o výpis z obchodného registra v tlačenej podobe
Podanie žiadosti o vystavenie potvrdenia o tom, že listina nie je uložená v zbierke listín v tlačenej podobe
Podanie žiadosti o zápis, zmenu a výmaz údajov v obchodnom registri
Návrh na podanie podnetu na začatie konania o zhode v obchodnom registri
Podanie žiadosti o uloženie listiny do zbierky listín
Podanie žiadosti o vystavenie potvrdenia o tom, že listina nie je uložená v zbierke listín v el. podobe
Návrh na podanie námietky proti odmietnutiu vykonania zápisu v obchodnom registri
Podanie žiadosti o vyhotovenie kópie listiny uloženej v zbierke listín v elektronickej podobe
Podanie žiadosti o vyhotovenie kópie listiny uloženej v zbierke listín v tlačenej podobe
Príjem/výdaj podaní v obchodnom registri
Evidencia podaní v obchodnom registri
Archivácia v obchodnom registri
Vyhľadávanie údajov o adresách
Označenie záujmovej osoby
Poskytnutie jednoznačného identifikátora fyzickej osoby podľa vyhľadávacích kritérií
Vymazanie údajov z registra právnických osôb
Zápis údajov do registra právnických osôb
Generovanie identifikátora právnickej osoby
Preverenie osoby v registri diskvalifikácií
Manažment zapísaných osôb v registri diskvalifikácií
Oznámenie o diskvalifikácii
UBRIS - • Upozornenie na cezhraničné fúzie v systéme prepojenia obchodných registrov
Oznámenie o zmene pobočky v systéme prepojenia obchodných registrov
Hľadanie v systéme prepojenia obchodných registrov
Synchronizácia dát ohľadom právnických osôb
Zobrazenie reportov z obchodného registra
Sledovanie stavu platieb pre konania obchodného registra
Sledovanie logovania v obchodnom registri
Sledovanie stavu spracovania konania v obchodnom registri
Synchronizácia dát z centrálneho RPO do rezortného RPO
BRIS – Hľadanie
BRIS - Oznámenie o zmene pobočky
BRIS - Upozornenie na cezhraničné fúzie
RD – Oznámenie odiskvalifikácii
RD - Manažment zapísaných osôb
RD - Preverenie osoby
Generovanie IPO
Zápis údajov do RPO
Vymazanie údajov z RPO
Poskytnutie JIFO podľa vyhľadávacích kritérií
Označenie záujmovej osoby
Vyhľadávanie údajov o adresách
Archív
Evidencia podaní
Príjem/výdaj podaní
Podanie žiadosti o výpis z obchodného registra v tlačenej podobe
Podanie žiadosti o vyhotovenie kópie listiny uloženej v zbierke listín v tlačenej podobe
Podanie žiadosti o vystavenie potvrdenia o tom, že listina nie je uložená v zbierke listín v tlačenej podobe
Podanie žiadosti o poskytnutie výpisu z obchodného registra v elektronickej podobe
Podanie žiadosti o vystavenie potvrdenia o tom, že listina nie je uložená v zbierke listín v el. podobe
Podanie žiadosti o vyhotovenie kópie listiny uloženej v zbierke listín v elektronickej podobe
Podanie žiadosti o zápis, zmenu a výmaz údajov v obchodnom registri
Podanie žiadosti o uloženie listiny do zbierky listín
Podanie námietky proti odmietnutiu vykonania zápisu
Podanie návrhu na začatie konania o zhode
A podla mna ani jeden z tychto setov nie je rozumny, najma aplikacne sluzby su podla mna navrhnute nespravne, kedze sa ma jednat o v podstate o API.
Vysledok
Tento chaos v sluzbach uz na zaciatku (vo faze studie) viacero dosledkov, v podstate je to taky zacarovany kruh:
projekt dodava sluzby, t.j. sluzby su dolezite a teda su aj v ZoNFP, pripadne aj dodavatelskych zmluvach,
akonahle su zmluvy podpisane, ich zmena je draha, t.j. ani sluzby sa pocas vyvoja neprisposobuju realnemu stavu, radsej sa to vzdy nejak ohne,
vysledkom je nesulad formalnych sluzieb a realnych sluzieb, s tym spojeny chaos pri integracnych manualoch, v evidencii na MetaIS a v zozname sluzieb na UPVS
Super, normalne som mal minuly tyzden presne takuto myslienku. Uz druhykrat sa potrebujem zorienotvat v stave AS IS pri tvorbe analyzy, ale stav ktory poznam z praxe vobec nesedi so stavom popisanym bv MetaIS.
To cele zaroven suvisi so Studiami Uskutocnitelnosti. Kvitoval som ako to bolo navrhnute a palec hore pre Autorov. Ale ono by to fungovalo len vtedy keby bol nejaky celoslovensky Enterprise Architekt pre verejnu a statnu spravu, ktory by vytvaral standardy a odvetvove kniznice komponentov (aj analytickych) a rozdaval ulohy smerom na rezorty, keby bol na kazdom rezorte rezortny enterprise architekt, ktory akceptuje sefa a vytvara rezortne “enteprise continuum” ale hlavne ma rovnaky vyjadrovaci jazyk ako sef, a kolegovia na inych rezortoch.
Pokial toto nebude riadene zhora, pokial vsetci nebudu pouzivat jednotnu notaciu ak je to úplne kontraproduktívne a miesto zlepšenia to prináša zhoršenie a frflanie. A asi bude lepšie cely tento systém zrušiť, nenútiť ľudí čo chcú písať slohy aby sa trápili s diagramami … Akoby do flotily ponoriek nahnali rybárov a kázali im doplávať niekam … Oni to vedia ale na svojich lodiach … V tomto je straaasny rozdiel medzi zapadom a nami. Tam ked sa do niecoho pustia tak sa to robi dosledne, vratane skoleni a osvety.
Ja si myslim, ze mozno staci Studie Uskutocnitelnosti trochu zjednodusit (+ spravit vzory). Neopustat cely koncept (ten si myslim ze je dobry), ale vyzadovat mozno iba polovicu (alebo 80%), ale zase doslednejsie kontrolovat ci to je spravne. A casom, ked sa to ludia naucia, sa to moze iterativne rozsirovat.
Vsimol som si vo viacerych novych RZ, ze do jedneho projektu davaju uplne nesuvisiace veci. Napr. moje data, redizajn slovensko.sk, 3rd party udelovanie opravneni, rozvoj IAM a chat vsetko v jednom baliku. Chapem, ze je to takto jednoduchsie obstarat a netreba robit X obstaravani a papierovacie voci EU, ale imho takto sa nikdy mensie firmy na relevatne casti egovu nezapoja. Mozno by sme to mohli zakomponovat do redflags, ze by sa to malo kuskovat na logicke celky co spolu suvisia a nedaju sa robit samostatne. cc @lubor@janhargas
Pokiaľ ide o “štúdiu uskutočniteľnosti” tak to nemusí byť problém, v nej sa obvykle ani nepíše ako sa jednotlivé časti “získajú” (teoreticky si ich príslušný úrad môže aj sám naprogramovať). Čiže zo štúdie automaticky nevyplýva že sa to musí obstarať spoločne.
Plán bol toto riešiť v rámci kritéria pracovne nazvaného “súlad s KRIS”, keďže práve KRISy by mali vyjadrovať to enterprise continuum (okrem iného). Ale je to tak choatické (a KRISy zdá sa nebudú mať v dohľadnej dobe podstatnú pridanú hodnotu), že uvažujem celé toto kritérium vypustiť… Ale v pohode si to @panda môžeme spolu prejsť, ako by sa to vyhodnocovalo.
Suhlasim, ze s KRIS to nevyriesis. Podla mna treba vyhodnotit pri kazdej studii, ci riesenie zapada do celkovej arch. koncepcie (a NKIVS plus strateg, priority), ci ju vylepsuje, poskytuje pouzitelne sluzby inym (a ci su nazvane tak aby ich niekto nasiel, resp. aby davali zmysel). V KRIS na to potrebne detaily nie su.
Tak toto môžeme detailnejšie riešiť v “príspevok v informatizácii”. Ale špeciálne pokiaľ ide o koncové/aplikačné služby, neviem aký v tom má byť systém (alebo že by vôbec nejaký systém v tom byť mal).
Samotné “koncové služby” častokrát nie sú to, čo je hlavná úloha IS. Exemplárny príklad bol napr. eDOV - pozri si koncové služby pre OpenData.
System najdes v metodike ArchiMate kde Application services su prelozene spravne ale Business Services su prelozene ako koncove sluzby. Co by teoreticky mohlo aj sediet, ale ludi, co nie su architekti, ale su Manazeri a maju “vyplnit tabulky” vedie k tomu, ze vyplnuju len sluzby viditelne pre VEREJNOST. Co je len cast Akterov.
“A business service represents the added value that an organization delivers to its environment. One can make a distinction between internal and external services: Internal services represent the added value that is being delivered within the domain that the service belongs to. External services represent the added value that is being delivered to other domains or to the environment (for example customers).”
Ja som napriklad v januari modeloval pre Elektornicky sudny spis, a tam naozaj mali v META IS iba sluzby pre verejnost a iba sluzby platene z OPIS … ine IS akoby ani neexistovali. Sluzby pre sudneho uradnika, alebo skeneristu akoby neexistovali … Pritom ta struktura META IS bby metodicky mala zohladnovat vsetkych konzumentov sluzieb / akterov … Ale to je rovnake ako ked do Jumba 747 posadis pilota z vetrona… Je to sice tiez pilot ale na inej urovni … Este k tomu “modeloval” - skoncilo to v dokumente, nie v META IS, a nnie v ich Architektonickom repository. … tam maju pristup len “domaci”
Prispevok v informatizacii nie je moc vystihujuci pojem. Sluzby su pomerne dolezite, vsetky projekty su z eurofondoveho hladiska postavene tak, ze to co dodavaju su sluzby. Su na ne zavesene indikatory, monitorovanie atd. Zaroven sa eviduju v katalogu. Ak tie sluzby nie su vyplnene spravne a zmysluplne a podla systemu (ktory mimochodom popisany je), tak to je na ich evidenciu, spravu a monitorovanie zbytocne vynakladana velka namaha.
Samotné “koncové služby” častokrát nie sú to, čo je hlavná úloha IS. Exemplárny príklad bol napr. eDOV - pozri si koncové služby pre OpenData.
A to je presne o tom, ze nikto sa nepozera na celkovu architekturu ani take v podstate trivialne veci, ako je jednoduche kapacitne planovanie. A da sa to robit na sluzby, ako som argumentoval vyssie.
Moj navrh - zvazit ci by si teda hodnotenie sluzieb zasluzilo vlastnu Red Flags kolonku.
Sledujem red flags k projektom a chcel by som sa opytat aku mate objektivnu metodiku pre vyhodnocovanie, ked skoro kazdy den priadavate alebo uberate hviezdicky? Vyzera to ako keby sa Ferko s Jozkom rano vo vytahu bavili kto dal komu kolko hviezdiciek a potom to zacali upravovat.
To čo je tu na platforme sú drafty, ktoré sa môžu ľubovoľne meniť - aj Ty ich môžeš editovať.
“Naozajstné” hodnotenie je až to čo vypublikujeme na web redflags.slovensko.digital - pred tým si robíme interné review, napr. či sú hodnotenia konzistentné.
Ale je fakt, že napr. ja mám tendenciu byť čím diaľ tým viac kritický.
Pokiaľ ide o metodiku, základné veci sú popísané. Najviac sa snažíme dobre zvážiť, či a v ktorom kritériu je “red flag”. To je vtedy, ak v danej oblasti je nejaký zásadný nedostatok. Či v niektorom kritériu sú 2 alebo 3 hviezdičky naozaj môže byť ovplyvnené tým kto hodnotenie píše. Nejaké nápady ako to ďalej zlepšiť?
Ak to mate takto, tazko radit, navrhol by zaviest nejake predbezne hodnotenie, ktore bude zverejnene a menit ho az na zaklade reakcie tej institucie. Len ked si zoberiem posledne dva prispevky k parkovaniu TZP a kancelarii najvyssieho sudu tak za CBA maju obidve jednu hviezdicku, pricom z mojho pohladu (nehodnotim ostatne casti, primarne ma zaujima biznis ciel a CBA) z hladiska kvality su tie dve studie diametralne odlisne. Mozno by som preto pridal viac kriterii preto aby to bolo objektivnejsie.
. Vo vlastnom záujme.
… tam maju pristup len “domaci”