O metodike Red Flags


#21

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 :slight_smile: . Vo vlastnom záujme.


#22

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…


#23

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 :slight_smile: Aktualne su tam na sec infra dvaja.


#24

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?


#25

Jakze nie? V podkladoch k obstaravaniu predsa vidis ci je pozadovane napr. to co som pisal vyssie.


#26

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
  • Spracovanie agendy obchodného registra
  • Zverejňovanie www.orsr.sk
  • Zverejňovanie obchodného vestníka
  • Administrácia užívateľov
  • Sprístupnenie vygenerovanej dávky z obchodného registra
  • Konfigurácia generovania dávky z obchodného registra
  • Podanie žiadosti o uloženie listiny do zbierky listín
  • 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 vystavenie potvrdenia o tom, že listina nie je uložená v zbierke listín v el. 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 výpis z obchodného registra v tlačenej podobe
  • Podanie žiadosti o poskytnutie výpisu z obchodného registra v elektronickej podobe
  • Podanie žiadosti o vyhotovenie kópie listiny uloženej v zbierke listín v tlačenej podobe
  • Návrh na podanie námietky proti odmietnutiu vykonania zápisu v obchodnom registri
  • Návrh na podanie podnetu na začatie konania o zhode v obchodnom registri

Aplikacne sluzby ORSR v studii

Z obrazkov v hlavnom dokumente (8):

  • Sluzby zivotneho cyklu pripadu
  • Poskytnutie informacii o pripade
  • Notifikacne sluzby pripadov
  • Vykonanie uloh pripadu
  • Upravy udajov v registroch
  • Poskytovanie informativnych udajov z registrov
  • Poskytovanie zavaznych udajov z ragistrov
  • Datova integracia - hromadne exporty udajov z registrov

Z tabulky v prilohach (36)

  • Konfigurácia generovania dávky
  • Sprístupnenie vygenerovanej dávky
  • Administrácia užívateľov
  • Zverejňovanie OV
  • Zverejňovanie www.orsr.sk
  • Spracovanie agendy
  • Sledovanie stavu spracovania
  • Sledovanie logovania
  • Sledovanie stavu platieb
  • Zobrazenie reportov
  • 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

Harmonogram OPII projektov na 2018
#27

#28

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.


#29

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.


#30

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


#31

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.


#32

Nové projekty sa začínajú obstarávať, načim pohnúť aj s metodikou k RF.
Draft metodiky pre fázu

Komentujte!


#33

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.


#34

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.


#35

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. :smiley: … tam maju pristup len “domaci”


#36

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.

Vsak to je ten problem…


#37

Vsimol som si diskusiu k eID v threade k eHealth

Áno, súhlasím, pri lucídnom riadení projektu muselo byť okamžite jasné, že žiadny z týchto parametrov nebude pre eHealth stačiť
Pozrel som teda s nádejou do MetaIS:
https://metais.finance.gov.sk/monitoras?serviceUuid=59e809ec-b21e-434e-8b99-fd92510bd206
A tam - taktiež nič…
Ale určite pomôže investovať 10M do lepšieho MetaIS…

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.


#38

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.


#39

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ý. :wink:

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ť?


#40

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.