IS CSRU - Rozbor


#67

Ako sa toto lisi od https://ekosystem.slovensko.digital/? Pretoze to, ze tu mame decentralizovane sluzby, plati uz dnes.


#69

Toto sa lisi hlavne tymto - https://en.wikipedia.org/wiki/Conway's_law.

Ale inak @milosm dobre vravi. Ak sa mam vratit este o krok spat (zabudnime na MUK). Tak @miso tu napisal dva hlavne problemy integracie: Potreba prepajat prostredia (tu by bolo treba ist asi o level nizsie a pozriet sa, ze preco to vlastne treba) a maly poriadok. Ja by som k tomu este pridal, zufaly overhead integracie - naozaj to trva dlho (vseliake IPSec tunely… naozaj to je problem).

Ja vidim dva pristupy:

  • centralizovany - mame SPoF, brutalny vendor lock, ale viac menej poriadok, lebo to drzi pod palcom jeden.
  • decentralizovany - nemame SPoF, nemame vendor lock, HA treba riesit na kazdom uzle (co by nemuselo byt az take strasne, kedze cloud a tak), potrebujeme silnu standardizaciu a minimalizovat bariery na integraciu.

#71

http://ekosystem.slovensko.digital by mal byť jedným z konzumentov dát / služieb. Takých by mohlo byť X - potreby trhu by ukázali koľko a s akými “vyskladanými” službami.

To ako vyzerajú decentralizované služby vidieť pekne na RPO - štát neposkytuje žiadne a prevádzkovateľ systému (ŠÚ SR) chcel za ich vytvorenie ďalších 35 tis. od konzumentov služieb. Ďalším príkladom “decentralizovanej služby” je Register adries - “vypľúvanie” csv súborov nepovažujem za službu.
… vlastne kvôli deficitu týchto služieb vznikol http://ekosystem.slovensko.digital


#72

pre nich môže byť nejaká taká platforma, ktorá im poskytne priestor pre poskytovanie dát / služieb.

Pradoxne však začína integrácia do CSRÚ so systémami, ktoré boli jedny z najväčších a mali končiť decentralizovanými službami, napr. RFO, Register adries a pod. Tie už mali byť dávno napojiteľné cez webservice napriamo.


#74

RFO urcite nie, nakolko to je iny rezort, ktory pod CSRU nespada. Mozno si myslel RPO, to vsak zakon kaze, ze to musi byt spristupnovane cez MUK (nehovorim ze je to spravne). Stale vsak tvrdim ze sluzby existuju, len o nich castokrat nikto nevie, nakolko cele sa to prepajalo ad-hoc. Ambiciu cele to strazit mal MetaIS, aka katalog sluzieb. Vznikol vsak jeden mess.


#75

To som vlastne myslel tym prepajanim prostredi.


#76

Máš pravdu. čo bolo bolo. Naozaj podstatné je čo v súčasnej situácii. A preto je dobre, že UPVII začína koncepciu rozmieňať na drobné.


#77

Potialto sa mi to pacilo (a teda nie len Tvoj komentar ale aj projektopvy zamer: ze teda nahradit integraciu kazdy s kazdym integraciou cez jeden komponent), az kym som v naslednom vycte nedosiel na “sada sluzieb …”, lebo …

… to co pise MilosM (single point of failure) plus aj to, co naznacil Jano (nabobtnavanie funckionality a vendor-lockin).

Cize v zavere by som sa tiez priklanal k:

Co ma nasledne privadza k tomu, co uz napisal @skdd:

Co by bol potom vlastne data.gov.sk (pripadne v nom nejaka “GOV only” verejne nepristupna sekcia, cisto pre G2G, aj ked teda IMHO len malo API by boli kandidati na ciste G2G … lebo Open API).

+1


#78

A ako si to predstavujete v praxi?


#79

Kedze na standardizaciu obcas chodim, tak moja predstava je ze:

  1. standardizacia je uz vcelku OK (aj ked zapasi s existencnymi problemami), ale …
  2. treba ale vyrazne posilnit enforcement (zatial sa IIRC nikomu nic nestalo za to, ze nedodrzal povedzme Vynos 55/2014, pricom boli/su IIRC aj vcelku zasadne porusenia)

#80

Co je to iirc ? Ja poznam len irc ale to asi nebude ono


#81

To si naozaj myslis, ze enforcovanie pouzitia SOAP/HTML a JSON/HTML, co uz vlastne momentalne takmer vsetci robia, nas niekam posunie? Realne tu bojujeme s uplne inymi problemami ako standardizovanim technologii. Nie som tymto postom konstruktivny, viem o tom :wink:


#82

“If I Remember Correctly”

Vramci standardizacie a toho, o com a kvoli comu som ju sem spomenul, tak kratka odpoved by bola “nie, nemyslim”.

Ale enforcement je urcite nutny. Mame tu vcelku vela dobrych zakonov, vynosov, usmerneni, odporucani, strategii, studii, atd. a vsetko to casto zakape na tom, ze sa nedodrziavaju. A tak sa potom pisu dokola dalsie nove zakony, vynosy, … To je taky celospolocensky neduh (ze povedzme urcity odrbavaci na daniach behaju na slobode), ktory sa samozrejme prejavuje aj v stanom IT (ze narp. eID bolo pre Mac a Linux k dispozicii az po rokoch slubovaciek “uz na tom robime, bude to o mesiac”).

Napr. ostatne schvaleny NKIVS bude tiez na nic, ak sa nebude dodrziavat.

Takze preto enforcement.

Ale samozrejme, ani toto nie je silver bullet a nie je jedno, co presne sa enforcuje, a kto enforcuje. Atd.

p.s.: Este perlicka: Aj “no brainer” veci niekedy potrebuju enforcement. Tot mi ktosi spominal, ze niekde v CR nedavno (par mesiacov) prichytili nejake mestske IT pri tom, ze im nejaky typek dodava vlastnu “one of a kind” implementaciu databaze, ktoru bastli uz od 90-tych rokokv s tym, ze samozrejme nic take “one of a kind” nepotrebovali, stalo to viacej nez bezne SQL DB ale sa to na ne zdaleka nechytalo.

Nie je to az take zle. :slight_smile:


#83

Ja sa necitim byt velkym odbornikom na integraciu, ale ja by som ocakaval nieco taketo: https://aws.amazon.com/documentation/apigateway/ Cize len API gateway, na ktoru by sa akykolvek projekt (akokolvek vendor locknuty) integroval a odvtedy by bol dostupny cez standardizovane API. Gateway by tiez enforcovala standardizaciu.

Ano.


#84

to je presne to co som napisal, == integracna platforma


#85

Taky pohlad na tieto problemy zvnutra najdete tu: https://medium.com/@peto.kulich/5-prispevok-interoperabilita-is-vs-s-cim-sa-realne-stretavame-na-implementacnej-urovni-63b70a4b853a#.liz9dk1ng


#87

btw: ak nie teda centralizovane (lebo vendor locking a single point of failure) tak potom v NKIVS životné situácie trocha problém, nie?
Implementáciou orchestračnej platformy, aplikovaním moderných technológií a definovaním konkrétnych ŽS s jasným určením ich hraníc, gestorov a procesných úkonov, ktoré sa optimalizujú a zjednodušia v rámci reformy verejnej správy, sa dospeje k efektívnemu a príjemnému poskytovaniu služieb verejnej správy.


#88

Má zmysel rozlišovať medzi 1) systémom zdieľania údajov, a 2) centralizovanou podporou riadenia procesov VS.
V 1) ide najmä o čítanie údajov, centrálny komponent má zmysel minimalizovať.
V podstate 2) je aj jedným z klientov 1).
Postaviť 1) je imho prioritná vec, má zásadný zmysel aj ak by sa 2) vôbec nespravilo.


#89

Ok, rozumiem asi ako sú myslené tie životné situácie (to nikto nedá dohromady :).
tak späť k 1), vo vlákne byrokracia je asi rozoberané aké utrpenie je riešiť integráciu medzi ISVS. Ak sa prikloníme k decentralizácií - každý s každým, utrpenie sa tým znásobí. V súčasných podmienkach sa stane 1xdost prakticky neriešiteľné. Akože páčila by sa mi predstava, že každý úrad ma sadu svojich služieb a ja si ich naimplementujem, len akosi neverím, že je to prakticky prevediteľné.

btw: 2 dátové centrá (MV vs MF) nie sú single point of failure?


#90

Decentralizácia nemusí znamenať “každý s každým”. Práveže treba správne spraviť centrálne aktivity - a hlavnou je štandardizácia.

Základom musí byť silne štandardizované API, nevidím dôvod prečo by nemalo byť úplne jednotné API na prístup ku každým údajom.

Vymieňať iba štandardizované údaje - dátové prvky a ich sady.

Rovnako treba štandardizovať integráciu do “zdieľania údajov” na sieťovej úrovni. Niečo ako napr… VPN?