Архитектура на електронното управление

Архитектура на електронното управлениеБожидар Божанов

Vanity slide• Все още програмист• http://blog.bozho.net• http://techblog.bozho.net• http://twitter.com/bozhobg• съветник за електронно управление на

вицепремиера Р.Бъчварова

Електронно управление

Имаме електронно управление, когато държавата не занимава гражданите с

глупости

Сложна задача?• 20% техническа• 20% правна• 60% организационна

Първични регистри• Регистър = база данни• Първичен - източник на истина за

дадени обстоятелства• ЕСГРАОН, БДС, Търговски регистър,

Булстат, регистър КАТ, Имотен регистър, Кадастър.

Свързване на регистри• задачаТА• Правно - вече е регламентирано• Технически - има 2 незаработили

реализации• Организационно - причината за

неработещите реализации

Еднократно събиране• 2 закона (ЗЕУ, АПК) забраняват на

администрацията да събира данни, които вече има

• Автоматизирано събиране от първичните регистри

Как?• Децентрализирана архитектура

• или разпределена?• Адресиране на правните пречки

• “Това не се отнася за нас”• “Ние си имаме специален закон”• Споразумения!

• Организациони пречки: морков и тояга

Изисквания• Много участващи организации

• вкл. от частния сектор• Защита на личните данни

• 100% отчетност на достъпа• Сигурна идентификация на системите

• PKI, HSM• Синхронни, асинхронни и subscribe

заявки• Управление на промените

Microservices?• Сходно• … но не са micro• .... и не са в рамките на една

организация

История• “Ведомствените ИС ще си “говорят”, най-

после” (TechNews, юни 2006-та)• 1-ви опит: ЕСОЕД

• неуспешен• 2-ри опит: RegiX

• засега не се ползва• Рамка за оперативна съвместимост

• a.k.a WSDL

Meanwhile in Estonia...• X-Road функционира от 2001-ва• Свързани регистри: 200+• Институции: 900+• Транзакции: 600 милиона / година• Спестени човекочасове годишно: 47

милиона

Технологичните минуси не са причината за неуспеха

Фундаментален въпрос

Документи, данни или услуги?

• “Електронен документ”• Wrapper на данни?• Вътрешна услуга за предоставяне на

документи/данни• Основно разграничение:

• Документооборот с/у обмен на данни

Архитектурен въпрос

ESB или P2P?

Източник: МТИТС

ЕСОЕД• ESB/Message Queue• Работи изцяло с електронни документи• Проверява и рутира заявки• Сложна интеграция

• липса на достъпни библиотеки• Съвет по вписванията• VPN?

Източник: МТИТС

ЕСОЕД - как?• Вписване на всички схеми в регистър

(ръчно)• SOAP заявка с destinationURI• Асинхронен отговор• Криптиране, подписване

RegiX• ESB (sort of)• Адаптира legacy регистри като им

expose-ва уеб-услуги• Централен компонент рутира заявките• Нужно е надграждане на централния

компонент за всеки нов регистър• Не поддържа Subscribe

RegiX + ESB• ESB в допълнение на RegiX• Автентикация на информационни

системи• В допълнение с вграденото в RegiX

• Проверка на достъпа в регистър на достъпа• В допълнение на вградената в RegiX

• ...

Източник: презентация на BulSI за МТИТС

RegiX - как?• SOAP заявка към централния сървър

• с идентификатор на услуга • с данни за заявителя

• Централният сървър препраща на адаптера. • Проверява достъпа• Записва събитието (но без данните)

• Адаптерът “бърка” в базата и връща отговор

NoESB• ESB-тата са single point of failure

• Колкото и да ги “резервираме”• Магическите им способности са само на

книга• Добрите интерфейси и управление на

версиите отменят нуждата от ESB*

X-Road• p2p• Security server (proxy) + adapter server -

интеграционни компоненти• Security server вместо централизирано

ESB

X-Road

X-Road - как?• Комуникация: само със security server• Security server-ът се грижи за logging и

автентикация• Security server-ът е proxy• Локален кеш• Load balancing

X-Road protocol• Стандартен протокол за adapter server

• SOAP• Списък с налични услуги и техните дефиниции• Версии

• Всеки adapter server се вписва в регистър, който автоматично извлича метаданни

• Адаптерите са силно интегрирани с ИС• поддържат subscribe

UK: Registers• Един софтуер за всички регистри• Multi-tenant deployment• RESTful интеграция

Security server?• Допълнителните сървъри усложняват

инфраструктурата• Вместо отделни сървъри - стандартни

компоненти• Цена• Вместо сертифициран security server -

координатор на транзакции

Данни, освен услуги• Гранулярност: данни• Стандартен протокол за автоматично

поддържане на описания на данните• Заявка: тип/версия/идентификатор

Разпределена архитектура?• Съхраняване на данните в blockchain

• Криптирани• ...с личния частен ключ на гражданите• ...и с ключа на институцията (ако човек загуби

своя)• Естония: здравни записи

Privacy• Контрол на достъпа• Лог (журнал на събитията)• Достъп за граждани

• + известия за четене на данни• Правни последици за нерегламентиран

достъп

So...• Стандартен протокол• Стандартни SDK-и и компоненти

• Имплементиращи протокола• Централни регистри с метаинформация

• Контрол на достъпа, типове данни, регистри• Лог/журнал на достъпа• Достъпна документация и sandbox

KISS• С минимален брой компоненти• С минимална човешка намеса• Сложността убива

Сложна задача?• Не• Архитектурата (може да) е проста• Организационният и човешкият фактор

са сложни

Благодаря!