Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Эталонная модель 
электронного правительства 
Александр САМАРИН 
Global e-Government Forum 2014 
7-8 October, 2014, Astana...
Содержание 
• Контекст 
• Эталонная модель электронного правительства 
• Проекции эталонной модели 
© A. Samarin 2014 Этал...
Основные определения 
• Электронное Правительство (ЭП) – это использование 
современных информационных технологий для 
пов...
Сложность ЭП как системы 
• Неограниченный жизненный цикл 
• Непредсказуемая и постепенная эволюция 
• Социально-техническ...
Цифровая эра (1) 
• Цифровое побеждает физическое: все становится 
цифровым 
• Быстрое побеждает медленное: обычная скорос...
Цифровая эра (2) 
• В дополнение к известным 
– дешевле, быстрее, лучше 
• надо работать 
– более экологично, более гибко,...
Содержание 
• Контекст 
• Эталонная модель электронного правительства 
• Проекции эталонной модели 
© A. Samarin 2014 Этал...
ПОЧЕМУ Эталонная модель ЭП (1) 
• Многие правительственные организации предоставляют 
аналогичные услуг, но по-разному 
• ...
ПОЧЕМУ Эталонная модель ЭП (2) 
• Существует способ, как объединить разнообразие и 
единообразие 
• Проблема их сочетания ...
ПОЧЕМУ Эталонная модель ЭП (3) 
Уровень 
компьютеризации 
© A. Samarin 2014 
B C A B A B C 
BU1 BU2 BU3 
1) Стандартное 
р...
ПОЧЕМУ Эталонная модель ЭП (4) 
• Становиться возможным избежать дублирования и 
необоснованных переделок 
– готовые решен...
КАК работает эталонная модель ЭП 
• Использование всей мощи корпоративной архитектуры 
(Enterprise Architecture - EA) 
– с...
Корпоративная архитектура (1) 
• Архитектор – это индивидуум, который переводит 
требования клиента в осуществимый план и ...
Корпоративная архитектура (2) 
• В настоящее время, только корпоративная архитектура 
способна объединить разнообразие и е...
Проекты, решения, платформы … 
© A. Samarin 2014 
Эталонная модель электронного правительства v2 15
© A. Samarin 2014 
Охват по времени 
Эталонная модель электронного правительства v2 16
Охват по размеру против охвата по 
времени 
© A. Samarin 2014 Эталонная модель электронного правительства v2 17
Охват по размеру против охвата по 
архитектурным областям 
© A. Samarin 2014 Эталонная модель электронного правительства v...
Архитектурна группа в структуре 
программы ЭП 
Руководство программой 
Программный 
офис 
Архитектурная 
группа 
Бюджет 
А...
Основные роли с архитектурной группе 
• Ген. архитектор 
• Управление 
– экспертный совет 
– контроль качества 
– финансы ...
Архитектурная группа является 
«зародышем» центра компетенции ЭП 
• Структура центра компетенции ЭП 
– Архитектурная групп...
Много заинтересованных лиц 
• Граждане 
• Местный бизнес 
• Глобальный бизнес 
• Местные власти 
• Государственные агентст...
Матрица заинтересованных лиц и 
проекций ЭП 
An example 
© A. Samarin 2014 Эталонная модель электронного правительства v2 ...
Содержание 
• Контекст 
• Эталонная модель электронного правительства 
• Проекции эталонной модели 
© A. Samarin 2014 Этал...
Проекции ЭП (1) 
• Взаимодействие между гражданином и 
правительственным учреждением 
• Коммуникационное пространство граж...
Проекции ЭП (2) 
• Предприятие как системы процессов 
• Использование процессов для усиления 
информационной безопасности ...
Заключение 
• Современные методологии и технологии являются 
потенциальной основой общественного прогресса 
• Корпоративна...
• Вопросы? 
СПАСИБО 
• EKSALANSI website: http://www.eksalansi.org 
• Blog: http://improving-bpm-systems.blogspot.com 
• L...
VIEWS (1) 
• Partner and governmental-entity interaction view 
• Partner view 
• Evolution of implementation view 
• The g...
Four communication patterns for 
exchanges between a partner and the 
government 
Partners (citizen, business, and other o...
A partner-initiated-demand may 
required several exchanges between the 
partner and the government 
Government 
Time 
© A....
The partner may need to deal with some 
ministries 
Government 
Ministry A Ministry B Ministry C 
Methodologies: 
+ data m...
E-gov coordinates partner’s interactions 
Methodologies: 
• data modelling 
• electronic document 
Process 
with the gover...
E-gov unifies the communication 
between the partner and the ministries 
Methodologies: 
• data modelling 
• electronic do...
E-gov provides a social collaborative 
Methodologies: 
• data modelling 
• ED exchange 
• BPM discipline 
• process modell...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Partner’s view 
© A. Samarin 2014 Эталонная модель электронного правительства v2 37
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
E-gov application architecture view 
Partners 
Social collaborative extranet 
e-gov 
service 
e-gov 
service 
e-gov 
servi...
E-gov traditional application architecture 
Partners 
Application 
Existing 
application 
Portal 
Application 
Existing 
a...
E-gov introductory application 
architecture 
Partners 
Social collaborative extranet 
e-gov 
service 
e-gov 
service 
e-g...
E-gov transitional application 
architecture 
Partners 
Social collaborative extranet 
e-gov 
service 
e-gov 
service 
e-g...
E-gov target application architecture 
Partners 
Social collaborative extranet 
e-Government 
e-gov 
service 
e-gov 
servi...
E-social system application architecture 
Partners 
Social collaborative extranet 
E-social system 
Public 
service 
Socia...
Steps of evolution in application 
architecture 
Introductory 
architecture 
Target 
architecture 
E-Social system 
archit...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Integration process instead of 
N-to-N connectivity 
© A. Samarin 2014 Эталонная модель электронного правительства v2 47
Use of many security envelopes 
• Business (processing) envelope 
• Delivery (addressing) envelope 
• Transportation (rout...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Platform-based architecture (1) 
• Business concern: How to deliver many similar 
applications for various highly-diverse ...
Platform-based architecture (2) 
• Principles 
– The platform frees up resource to focus on new opportunities 
– Successfu...
Overall platform governance 
• There are two primary types of activity. 
– On-going and centralised platform evolution 
– ...
Advantages of the corporate 
ECM platform 
D 
E 
V 
E 
L 
O 
P 
M 
E 
N 
T 
Functionality 
Process-centric 
integration 
C...
Financial estimations 
• Current development cost & time for a collaborative 
application 
– Cost: 40 – 200 K $ 
– Time: 0...
Solutions vs components 
© A. Samarin 2014 Эталонная модель электронного правительства v2 55
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Ladder of maturity meta-pattern 
• Entities are permitted to advance at different paces in 
their ascent to the top of the...
Component-oriented design 
• The platform is designed to be tools-independent by 
standardizing data, information, interfa...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Architecture-based agile project 
management 
• It combines decomposition with agile implementation of 
“architected” comp...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Structural dependencies between 
various artefacts 
© A. Samarin 2014 Эталонная модель электронного правительства v2 62
Dynamic relationships between various 
Business 
initiatives 
(business-specific 
demand) 
Manage 
business by 
processes ...
Implications and example 
• Implications 
– A formal way to discover points of the most leverage 
– The decision-making pr...
VIEWS (1) 
• Partner – governmental entity interaction view 
• Partner view 
• Evolution of implementation view 
• The gov...
Architecture-based procurement 
• Separation of duties 
• Architecture group: selection of IT 
• Procurement group: acquis...
VIEWS (2) 
• Enterprise as a system of processes 
• Enhancing information security by the use of processes 
• Enterprise R...
Enterprise as a system of processes 
• In the context of enterprise functioning, business 
activities must be coordinated ...
Process fragments – patterns 
Click for animation 
• Business case: typical “claim processing” process – claim, 
repair, c...
SI animated diagram 
Click for 
animation 
© A. Samarin 2014 Эталонная модель электронного правительства v2 70
Coordination between processes (1) 
• Simple event-based (which looks like a state machine) 
© A. Samarin 2014 Эталонная м...
Coordination between processes (2) 
1. state-machine 
2. synchronous invocation 
3. asynchronous invocation 
4. fire and f...
CLuster Of Processes (CLOP) 
• CLOPs are usually formed with functional processes 
which are implemented a particular busi...
Enabler group, supporting group and 
customer group of clusters 
© A. Samarin 2014 Эталонная модель электронного правитель...
Implicit coordination between CLOPs (1) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 75
Implicit coordination between CLOPs (2) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 76
Implicit coordination between CLOPs (3) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 77
Make coordination between CLOPs 
explicit (1) 
• Business Object (BO) lify-cycle as a process 
© A. Samarin 2014 Эталонная...
Make coordination between CLOPs 
explicit (2) 
• Add enterprise-wide event dispatcher 
© A. Samarin 2014 Эталонная модель ...
Make coordination between CLOPs 
explicit (3) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 80
Functional view at a system of processes (1) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 81
Functional view at a system of processes (2) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 82
Functional view at a system of processes (3) 
© A. Samarin 2014 Эталонная модель электронного правительства v2 83
VIEWS (2) 
• Enterprise as a system of processes 
• Enhancing information security by the use of processes 
• Enterprise R...
Dynamic provision of the access 
© A. Samarin 2014 Эталонная модель электронного правительства v2 85
Extra relationships between activities 
© A. Samarin 2014 
Mandatory: different actors because of 
the separation of dutie...
Extra relationships between activities 
• There are security-related relationships between activities 
• Example 
– “Activ...
BPM and information security: 
Extra relationships between activities 
• Doing the work 
– To which ROLES the work can be ...
VIEWS (2) 
• Enterprise as a system of processes 
• Enhancing information security by the use of processes 
• Enterprise R...
Embed risk management into functional 
• Normal activities are enriched by “check-points” 
© A. Samarin 2014 
processes 
Э...
© A. Samarin 2014 
ERM reference model 
Эталонная модель электронного правительства v2 91
VIEWS (2) 
• Common functional capabilities 
• Enterprise as a system of processes 
• Enhancing information security by th...
Typical problems with legacy software 
• Symptoms of becoming legacy 
– ad-hoc integration 
– difficult incorporation of n...
The goal of modernisation 
• Implement end-to-end processes with the maximum 
reuse of existing IT applications and infras...
How to carry out the modernisation 
• Step-by-step technical transformation by: 
1. Disassemble into services 
2. Add, if ...
Monolithic applications are decomposed into 
interconnected services 
Monolith 
application 
GUI GUI screen 1 1 GUI GUI sc...
How to coordinate? 
• Only the flow of data is traceable 
• Flow of control is explicit, because 
the primary importance i...
Several coordination techniques may be 
used together 
• By processes 
• By events (EPN) 
• By rules, work-load, etc. 
© A...
Transformation from typical inter-application 
data flows to end-to-end 
coordination of services 
© A. Samarin 2014 Этало...
Using events 
• To externalise the flow of control from existing monolith 
applications 
© A. Samarin 2014 Эталонная модел...
Co-existence of a legacy application and 
a process solution 
• The danger of “DOUble Master” (DOUM) anti-pattern – 
parti...
Process-centric solutions 
Assemble via processes (1) 
• Business processes make bigger services from smaller 
services 
•...
Process-centric solutions 
Assemble via processes (2) 
• Who (roles) is doing What (business objects), When 
(coordination...
Process-centric solutions 
Multi-layer implementation model (1) 
© A. Samarin 2014 Эталонная модель электронного правитель...
Process-centric solutions 
Multi-layer implementation model (2) 
B C 
A 
A - SharePoint 
B – in-house 
development 
C – SA...
Process-centric solutions 
Multi-layer implementation model (3) 
SAP BW/BI, etc. 
NetWeaver PI, 
SolMan, etc. 
NetWeaver 
...
Multi-layer implementation model and 
other technologies 
© A. Samarin 2014 Эталонная модель электронного правительства v2...
• Healthcare 
ANNEX 
© A. Samarin 2014 Эталонная модель электронного правительства v2 108
N 
E 
E 
D 
S 
R 
E 
S 
U 
L 
T 
S 
Healthcare reference model (1) 
Enrich 
Knowledge 
Improve 
Operations 
acquisition 
c...
Healthcare reference model (2) 
ECM RBAC 
BPM 
Knowledge Mgmt. Procedures 
Healthcare Platform 
acquisition 
channels 
dis...
Healthcare reference model (3) 
Modern Healthcare System (MHS) 
Hospitals 
Clinics 
MHS 
Virtual Doctor’s 
Offices 
MHS 
M...
ANNEX Smart-city implementation 
reference model 
• All smart-cites deliver the same services, albeit in a 
different mann...
Conclusion 
• Let us use the power of modern technologies to enable 
and drive societal transformation 
© A. Samarin 2014 ...
• QUESTIONS? 
Thanks 
• EKSALANSI website: http://www.eksalansi.org 
• Blog: http://improving-bpm-systems.blogspot.com 
• ...
Upcoming SlideShare
Loading in …5
×

Эталонная модель электронного правительства

1,069 views

Published on

Эталонная модель электронного правительства

Published in: Technology
  • Be the first to comment

Эталонная модель электронного правительства

  1. 1. Эталонная модель электронного правительства Александр САМАРИН Global e-Government Forum 2014 7-8 October, 2014, Astana, Kazakhstan http://www.unpan.org/GeGF/2014
  2. 2. Содержание • Контекст • Эталонная модель электронного правительства • Проекции эталонной модели © A. Samarin 2014 Эталонная модель электронного правительства v2 2
  3. 3. Основные определения • Электронное Правительство (ЭП) – это использование современных информационных технологий для повышения эффективности и результативности государственного сектора • Электронное правительство (electronic government) и электронное управление (electronic governance) рассматриваются совместно как единая система • ЭП является социально-технической системой социально-технических систем (необходим совместный учет социальных и технических аспектов) • Система – это функциональное целое, состоящее из взаимодействующих, взаимосвязанных или взаимозависимых частей © A. Samarin 2014 Эталонная модель электронного правительства v2 3
  4. 4. Сложность ЭП как системы • Неограниченный жизненный цикл • Непредсказуемая и постепенная эволюция • Социально-технический характер • Коллегиальное принятие решений • Функционирование на уровне современного предприятия • Способность к быстрому внедрению инноваций крайне важна • Широкое разнообразие услуг • Высокий уровень безопасности персональных данных © A. Samarin 2014 Эталонная модель электронного правительства v2 4
  5. 5. Цифровая эра (1) • Цифровое побеждает физическое: все становится цифровым • Быстрое побеждает медленное: обычная скорость исполнения - немедленно • Группа побеждает одиночек: решение современных сложных проблем возможно только путем сотрудничества • Большое побеждает малое: новые масштабы • Нет времени для ошибок и вмешательства человека в рутинных операциях и интерфейсах © A. Samarin 2014 Эталонная модель электронного правительства v2 5
  6. 6. Цифровая эра (2) • В дополнение к известным – дешевле, быстрее, лучше • надо работать – более экологично, более гибко, более синергетически (т.е. IoT), более всеобъемлюще, более безопасно • Смена фокуса при проектировании систем – ОТ рассмотрения артефакта как отдельного объекта – К тому, как артефакт изменяется на протяжении своего жизненного цикла – ОБРАЩАЯ ВНИМАНИЕ на то, как артефакты изменяются совместно • Цель – обеспечение инноваций, которые цифровом мире зависят от автоматизации процессов © A. Samarin 2014 Эталонная модель электронного правительства v2 6
  7. 7. Содержание • Контекст • Эталонная модель электронного правительства • Проекции эталонной модели © A. Samarin 2014 Эталонная модель электронного правительства v2 7
  8. 8. ПОЧЕМУ Эталонная модель ЭП (1) • Многие правительственные организации предоставляют аналогичные услуг, но по-разному • Очень много общего между правительственными организациями Уровни власти Архитектуры ЭП Техническая архитектура Архитектура данных Архитектура приложений Бизнес- архитектура Муниципальный 100% 100% 100% 100% Провинциальный 100% 100% 100% 80% Федеральный 90% 100% 60-80% 70% Национальный 90% 100% 70% 50% • Возможна существенная экономия при реализации ЭП © A. Samarin 2014 Эталонная модель электронного правительства v2 8
  9. 9. ПОЧЕМУ Эталонная модель ЭП (2) • Существует способ, как объединить разнообразие и единообразие • Проблема их сочетания известна в бизнесе, как "общие службы" • Пример - Бизнес-подразделения (BU) имеют различные уровни компьютеризации и стандартное решение от ИТ подразделения никому не подходит BU1 BU2 BU3 Общее решение Уровень компьютеризации ИТ подразделение © A. Samarin 2014 Эталонная модель электронного правительства v2 9
  10. 10. ПОЧЕМУ Эталонная модель ЭП (3) Уровень компьютеризации © A. Samarin 2014 B C A B A B C BU1 BU2 BU3 1) Стандартное решение использует процессы и службы 2) Все подразделения постепенно переходят к единой архитектуре ИТ подразделение Эталонная модель электронного правительства v2 10
  11. 11. ПОЧЕМУ Эталонная модель ЭП (4) • Становиться возможным избежать дублирования и необоснованных переделок – готовые решения, инструменты, модели и архитектуры – изменения происходят с комфортной скоростью – становится центром трансформации общества – наилучшие услуги для каждого гражданина – плавно включаются инновации – безопасность в дизайне © A. Samarin 2014 Эталонная модель электронного правительства v2 11
  12. 12. КАК работает эталонная модель ЭП • Использование всей мощи корпоративной архитектуры (Enterprise Architecture - EA) – согласованные модели – платформенная архитектура – предприятие как система процессов – модернизация устарелых приложений • Создание архитектурной группы в программе ЭП • Архитектурная группа является «зародышем» центра компетенции ЭП © A. Samarin 2014 Эталонная модель электронного правительства v2 12
  13. 13. Корпоративная архитектура (1) • Архитектор – это индивидуум, который переводит требования клиента в осуществимый план и направляет других при выполнении этого плана • Корпоративная архитектура – это процесс перевода бизнес-стратегии в эффективное изменение предприятия путем создания принципов и моделей, которые описывают будущее состояние предприятия и обеспечивают его эволюцию © A. Samarin 2014 Эталонная модель электронного правительства v2 13
  14. 14. Корпоративная архитектура (2) • В настоящее время, только корпоративная архитектура способна объединить разнообразие и единообразие • Корпоративная архитектура осуществляет координацию между персоналом, процессами, проектами и продуктами в 4-мерном пространстве следующих осей: – Охват по размеру - подразделение, предприятие, отрасль, правительство, вся страна, объединение стран, континент … – Охват по архитектурным областям – бизнес-архитектура, ИТ-технологии, архитектура безопасности … – Охват по времени - жизненного цикла программного решения, технологии, проекта, стратегии, предприятия … – Охват по секторам экономики – выявление общих и специфических бизнес-практик © A. Samarin 2014 Эталонная модель электронного правительства v2 14
  15. 15. Проекты, решения, платформы … © A. Samarin 2014 Эталонная модель электронного правительства v2 15
  16. 16. © A. Samarin 2014 Охват по времени Эталонная модель электронного правительства v2 16
  17. 17. Охват по размеру против охвата по времени © A. Samarin 2014 Эталонная модель электронного правительства v2 17
  18. 18. Охват по размеру против охвата по архитектурным областям © A. Samarin 2014 Эталонная модель электронного правительства v2 18
  19. 19. Архитектурна группа в структуре программы ЭП Руководство программой Программный офис Архитектурная группа Бюджет Административная координация Техническая координация Финансовый контроль Уровень вовлеченности Внутренняя команда Time Внешняя команда Начальная фаза Проектная фаза Эволюционная фаза © A. Samarin 2014 Эталонная модель электронного правительства v2 19
  20. 20. Основные роли с архитектурной группе • Ген. архитектор • Управление – экспертный совет – контроль качества – финансы – библиотекарь • Решения – архитекторы решений – аналитики • Проекты – лидеры проектов • Горизонтальные арх. – бизнес – приложения – информация – безопасность – инфраструктура • Вертикальные арх. – здоровье – города – туризм – … © A. Samarin 2014 Эталонная модель электронного правительства v2 20
  21. 21. Архитектурная группа является «зародышем» центра компетенции ЭП • Структура центра компетенции ЭП – Архитектурная группа – Группа социальных связей – Группа разработки – Группа эксплуатации – Группа преумножения знаний – Образовательные услуги – Обучение © A. Samarin 2014 Эталонная модель электронного правительства v2 21
  22. 22. Много заинтересованных лиц • Граждане • Местный бизнес • Глобальный бизнес • Местные власти • Государственные агентства • Политические партии • Местные не правительственные орг. • Межд. не правительственные орг. • Производители ПО • Системные архитекторы • Руководители проектов © A. Samarin 2014 Эталонная модель электронного правительства v2 22
  23. 23. Матрица заинтересованных лиц и проекций ЭП An example © A. Samarin 2014 Эталонная модель электронного правительства v2 23
  24. 24. Содержание • Контекст • Эталонная модель электронного правительства • Проекции эталонной модели © A. Samarin 2014 Эталонная модель электронного правительства v2 24
  25. 25. Проекции ЭП (1) • Взаимодействие между гражданином и правительственным учреждением • Коммуникационное пространство гражданина • Стадии реализации ЭП • Межведомственный обмен данными и документами • Платформенная архитектура – Подход – Практика – Управление проектами – Управление развитием платформы – Архитектурно-обоснованные закупки © A. Samarin 2014 Эталонная модель электронного правительства v2 25
  26. 26. Проекции ЭП (2) • Предприятие как системы процессов • Использование процессов для усиления информационной безопасности • Эталонная модель управления рисками • Процессная реализация архивного дела • Многоуровневая модель процессных решений • Практика процессных решений • Микро службы • Модернизация устарелых приложений • Перенос служб в «облака» © A. Samarin 2014 Эталонная модель электронного правительства v2 26
  27. 27. Заключение • Современные методологии и технологии являются потенциальной основой общественного прогресса • Корпоративная архитектура обеспечивает совместное использование современных методологий и технологий • Эталонная модель ЭП использует мощь корпоративной архитектуры для эффективного построения ЭП • Эталонная модель ЭП – это основа для кооперации между странами при построении ЭП • Эталонная модель ЭП применима для секторов как: – здравоохранение – «умный город» (smart-city) © A. Samarin 2014 Эталонная модель электронного правительства v2 27
  28. 28. • Вопросы? СПАСИБО • EKSALANSI website: http://www.eksalansi.org • Blog: http://improving-bpm-systems.blogspot.com • LinkedIn: http://www.linkedin.com/in/alexandersamarin • E-mail: alex@eksalansi.org • Twitter: @samarin • Mobile: +41 76 573 40 61 • Book: www.samarin.biz/book E-government reference model v2 28 © A. Samarin 2014
  29. 29. VIEWS (1) • Partner and governmental-entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Paperless or digital work view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 29
  30. 30. Four communication patterns for exchanges between a partner and the government Partners (citizen, business, and other organisations) Government 2. Patrner-declaration 1. Government-announce 4. Partner-demand Spread in time 3. Government-demand Spread in time 1. Government-announcement, e.g. broadcasting changes in a law 2. Partner-declaration, e.g. communicating a change of the partner’s address 3. Government-demand, e.g. inviting to pay taxes 4. Partner-demand, e.g. requesting a certificate (fishing license) © A. Samarin 2014 Эталонная модель электронного правительства v2 30
  31. 31. A partner-initiated-demand may required several exchanges between the partner and the government Government Time © A. Samarin 2014 Эталонная модель электронного правительства v2 31
  32. 32. The partner may need to deal with some ministries Government Ministry A Ministry B Ministry C Methodologies: + data modelling + electronic document exchange Time Tools: + standard data schemas + electronic signature • data flow (black dashed lines) © A. Samarin 2014 Эталонная модель электронного правительства v2 32
  33. 33. E-gov coordinates partner’s interactions Methodologies: • data modelling • electronic document Process with the government + + + + Government • control flow (black solid lines) • data flow (black dashed lines) Ministry A Ministry B Ministry C Time (ED) exchange + BPM discipline + process modelling Technologies: • standard data schemas • electronic signature + BPM suite © A. Samarin 2014 Эталонная модель электронного правительства v2 33
  34. 34. E-gov unifies the communication between the partner and the ministries Methodologies: • data modelling • electronic document (ED) exchange + BPM discipline + process modelling … … Process -- Government 2b Ministry B Time 2a x 2c • control flow (black solid lines) • data flow (black dashed lines) Technologies: • standard data schemas • electronic signature + BPM suite © A. Samarin 2014 Эталонная модель электронного правительства v2 34
  35. 35. E-gov provides a social collaborative Methodologies: • data modelling • ED exchange • BPM discipline • process modelling + ED management + records management + collaboration + social Process extranet for partners + + + + Government Ministry A Ministry B Ministry C Time Technologies: • standard data schemas • electronic signature • BPM suite + ECM Social collaborative extranet • control flow (black solid lines) • data flow (black dashed lines) © A. Samarin 2014 Эталонная модель электронного правительства v2 35
  36. 36. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 36
  37. 37. Partner’s view © A. Samarin 2014 Эталонная модель электронного правительства v2 37
  38. 38. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 38
  39. 39. E-gov application architecture view Partners Social collaborative extranet e-gov service e-gov service e-gov service Coordination and integration backbone Existing application e-Government Existing application Existing application Government Technologies: • BPM suite • SOA orientation • ECM © A. Samarin 2014 39 Эталонная модель электронного правительства v2
  40. 40. E-gov traditional application architecture Partners Application Existing application Portal Application Existing application Application Existing application Government © A. Samarin 2014 40 Эталонная модель электронного правительства v2
  41. 41. E-gov introductory application architecture Partners Social collaborative extranet e-gov service e-gov service e-gov service Coordination and integration backbone Existing application e-Government Existing application Existing application Government © A. Samarin 2014 41 Эталонная модель электронного правительства v2
  42. 42. E-gov transitional application architecture Partners Social collaborative extranet e-gov service e-gov service e-gov service Coordination and integration backbone Existing application e-Government Existing application Coordination backbone Existing application Service Service Government © A. Samarin 2014 42 Эталонная модель электронного правительства v2
  43. 43. E-gov target application architecture Partners Social collaborative extranet e-Government e-gov service e-gov service e-gov service Coordination and integration backbone Service Service Service © A. Samarin 2014 43 Эталонная модель электронного правительства v2
  44. 44. E-social system application architecture Partners Social collaborative extranet E-social system Public service Social service Coordination and integration backbone Private service Professional service Voluntary service © A. Samarin 2014 44 Эталонная модель электронного правительства v2
  45. 45. Steps of evolution in application architecture Introductory architecture Target architecture E-Social system architecture Portal-centric architecture Transitional architecture © A. Samarin 2014 Эталонная модель электронного правительства v2 45
  46. 46. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 46
  47. 47. Integration process instead of N-to-N connectivity © A. Samarin 2014 Эталонная модель электронного правительства v2 47
  48. 48. Use of many security envelopes • Business (processing) envelope • Delivery (addressing) envelope • Transportation (routing) envelope © A. Samarin 2014 Эталонная модель электронного правительства v2 48
  49. 49. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 49
  50. 50. Platform-based architecture (1) • Business concern: How to deliver many similar applications for various highly-diverse clients; define everything up-front is not possible (typical BPM or ECM project) • Logic – Developing individual applications will bring a lot of duplications – The provisioning of solutions should be carried out incrementally with the pace of the target client – Consider a platform 1. must standardise and simplify core elements of future enterprise-wide system 2. for any elements outside the platform, new opportunities should be explored using agile principles © A. Samarin 2014 Эталонная модель электронного правительства v2 50
  51. 51. Platform-based architecture (2) • Principles – The platform frees up resource to focus on new opportunities – Successful agile innovations are rapidly scaled up when incorporated into the platform – An agile approach requires coordination at a system level – To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives – Existing elements of the platform also need periodic challenge Delivery by applications Delivery by solutions A2 A1 A3 S2 S … 1 Platform S3 Functionality Scope © A. Samarin 2014 Эталонная модель электронного правительства v2 51
  52. 52. Overall platform governance • There are two primary types of activity. – On-going and centralised platform evolution – Rapid implementation of solutions as mini-projects • Platform evolution is carried out by an inter-organisational- units coordination committee • The roles within mini-projects – A stakeholder – The team lead for administrative coordination – The product owner for functional coordination – The solution architect for technical coordination – The team member © A. Samarin 2014 Эталонная модель электронного правительства v2 52
  53. 53. Advantages of the corporate ECM platform D E V E L O P M E N T Functionality Process-centric integration Company-specific features Advanced features of a common ECM platform Basic features of a common ECM platform Generic web- environment 3 development platforms Dev env 1 Dev env 2 Development © A. Samarin 2014 Эталонная модель электронного правительства v2 53
  54. 54. Financial estimations • Current development cost & time for a collaborative application – Cost: 40 – 200 K $ – Time: 0,5 – 2 years • Corporate platform program cost & time – Cost: 600 K $ – Time: 1 year $$ • Expected development cost & time for a collaborative application within the corporate platform – Cost: 20 - 60 K $ – Time: 1 - 3 months N apps. N≈8 Without common platform With common platform © A. Samarin 2014 Эталонная модель электронного правительства v2 54
  55. 55. Solutions vs components © A. Samarin 2014 Эталонная модель электронного правительства v2 55
  56. 56. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 56
  57. 57. Ladder of maturity meta-pattern • Entities are permitted to advance at different paces in their ascent to the top of the “ladder”. © A. Samarin 2014 Эталонная модель электронного правительства v2 57
  58. 58. Component-oriented design • The platform is designed to be tools-independent by standardizing data, information, interfaces and coordination between various capabilities. © A. Samarin 2014 Эталонная модель электронного правительства v2 58
  59. 59. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 59
  60. 60. Architecture-based agile project management • It combines decomposition with agile implementation of “architected” components © A. Samarin 2014 Эталонная модель электронного правительства v2 60
  61. 61. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 61
  62. 62. Structural dependencies between various artefacts © A. Samarin 2014 Эталонная модель электронного правительства v2 62
  63. 63. Dynamic relationships between various Business initiatives (business-specific demand) Manage business by processes Business capabilities (business-generic demand) Manage processes BPM suite IT capabilities (IT-generic supply) Roadmap programmes (from AS-IS to TO-BE) Business demand IT supply Business strategic objectives Governance 1 2 3 2 2->5 2->4 1->3 1->4 2->5 2->4 1->3 2->4 3->4 5 4 3 4 Business priority Requested maturity Maturity improvement 1 2 3 4 4 1 1 2 3 2 2 4 4 5 3 IT tools (IT-specific supply) 3->5 3->4 1->4 3->4 2->4 3 Programme priority 5 4 3 4 4 artefacts © A. Samarin 2014 Эталонная модель электронного правительства v2 63
  64. 64. Implications and example • Implications – A formal way to discover points of the most leverage – The decision-making process is explicit and transparent – A strategy adjustment and validation becomes a routine on-going activity during its implementation (like functioning of the GPS navigator) © A. Samarin 2014 Эталонная модель электронного правительства v2 64
  65. 65. VIEWS (1) • Partner – governmental entity interaction view • Partner view • Evolution of implementation view • The governmental entities integration view • Platform-based implementation view – Platform-based approach – Platform-based implementation practices – Project management practices – Implementation governance view – Architecture-based procurement view © A. Samarin 2014 Эталонная модель электронного правительства v2 65
  66. 66. Architecture-based procurement • Separation of duties • Architecture group: selection of IT • Procurement group: acquisition of such IT components (licensees, installation, training, documentation, operations, etc.) • Of course, the architecture group must make the selection logic as explicit as possible. © A. Samarin 2014 Эталонная модель электронного правительства v2 66
  67. 67. VIEWS (2) • Enterprise as a system of processes • Enhancing information security by the use of processes • Enterprise Risk Management reference model • Records management as an BPM application • Multi-layered implementation model • Agile solution delivery practices • Microservices • Various technologies around the implementation model • Modernisation of applications to become process-centric • Moving services to clouds © A. Samarin 2014 Эталонная модель электронного правительства v2 67
  68. 68. Enterprise as a system of processes • In the context of enterprise functioning, business activities must be coordinated • Coordination maybe strong (e.g. as in the army) or weak (e.g. as in an amateurs football team) • Coordination maybe implicit or explicit • Coordination maybe declarative (laws) and imperative (orders) • Based on coordination, let us think about “levels of cohesion” 1. process patterns (coordination within processes) 2. processes 3. cluster of processes (coordination between processes) 4. system of processes (coordination between clusters of processes) © A. Samarin 2014 Эталонная модель электронного правительства v2 68
  69. 69. Process fragments – patterns Click for animation • Business case: typical “claim processing” process – claim, repair, control, invoicing, and assurance to pay SI PAR SI IPS © A. Samarin 2014 Эталонная модель электронного правительства v2 69
  70. 70. SI animated diagram Click for animation © A. Samarin 2014 Эталонная модель электронного правительства v2 70
  71. 71. Coordination between processes (1) • Simple event-based (which looks like a state machine) © A. Samarin 2014 Эталонная модель электронного правительства v2 71
  72. 72. Coordination between processes (2) 1. state-machine 2. synchronous invocation 3. asynchronous invocation 4. fire and forget 5. parallel processes 6. co-processes (pattern SI) © A. Samarin 2014 Эталонная модель электронного правительства v2 72
  73. 73. CLuster Of Processes (CLOP) • CLOPs are usually formed with functional processes which are implemented a particular business function, e.g. Field Services • And a “halo” of extra processes 1. monitoring 2. operating 3. governance © A. Samarin 2014 Эталонная модель электронного правительства v2 73
  74. 74. Enabler group, supporting group and customer group of clusters © A. Samarin 2014 Эталонная модель электронного правительства v2 74
  75. 75. Implicit coordination between CLOPs (1) © A. Samarin 2014 Эталонная модель электронного правительства v2 75
  76. 76. Implicit coordination between CLOPs (2) © A. Samarin 2014 Эталонная модель электронного правительства v2 76
  77. 77. Implicit coordination between CLOPs (3) © A. Samarin 2014 Эталонная модель электронного правительства v2 77
  78. 78. Make coordination between CLOPs explicit (1) • Business Object (BO) lify-cycle as a process © A. Samarin 2014 Эталонная модель электронного правительства v2 78
  79. 79. Make coordination between CLOPs explicit (2) • Add enterprise-wide event dispatcher © A. Samarin 2014 Эталонная модель электронного правительства v2 79
  80. 80. Make coordination between CLOPs explicit (3) © A. Samarin 2014 Эталонная модель электронного правительства v2 80
  81. 81. Functional view at a system of processes (1) © A. Samarin 2014 Эталонная модель электронного правительства v2 81
  82. 82. Functional view at a system of processes (2) © A. Samarin 2014 Эталонная модель электронного правительства v2 82
  83. 83. Functional view at a system of processes (3) © A. Samarin 2014 Эталонная модель электронного правительства v2 83
  84. 84. VIEWS (2) • Enterprise as a system of processes • Enhancing information security by the use of processes • Enterprise Risk Management reference model • Records management as an BPM application • Multi-layered implementation model • Agile solution delivery practices • Microservices • Various technologies around the implementation model • Modernisation of applications to become process-centric • Moving services to clouds © A. Samarin 2014 Эталонная модель электронного правительства v2 84
  85. 85. Dynamic provision of the access © A. Samarin 2014 Эталонная модель электронного правительства v2 85
  86. 86. Extra relationships between activities © A. Samarin 2014 Mandatory: different actors because of the separation of duties Potentially: different actors because of performance impact – avoid assigning mechanical (low-qualified “red”) activities and added-value (“green”) activities to the same actors Эталонная модель электронного правительства v2 86
  87. 87. Extra relationships between activities • There are security-related relationships between activities • Example – “Activitiy_B” relates to Activity_A as “Validating the work” – These activities may be in different processes – No actors must be assigned to both “Role_1” and “Role_2” © A. Samarin 2014 (3) Activity_A Carry out the work Activity_B Carry out the work Validating the work Role_1 Role_2 Эталонная модель электронного правительства v2 87
  88. 88. BPM and information security: Extra relationships between activities • Doing the work – To which ROLES the work can be delegated – To which ROLES the work can be send for review • Assuring the work – other ACTIVITIES to audit (1st, 2nd and 3rd party auditing) – other ACTIVITIES to evaluate the risk (before the work is started) – other ACTIVITIES to evaluate the risk (after the work is completed) • Validating the work – Other ACTIVITIES to check the output (errors and fraud prevention) • Some ACTIVITIES must be carried out by the same actor, some ACTIVITIES must not © A. Samarin 2014 (4) Эталонная модель электронного правительства v2 88
  89. 89. VIEWS (2) • Enterprise as a system of processes • Enhancing information security by the use of processes • Enterprise Risk Management reference model • Records management as an BPM application • Multi-layered implementation model • Agile solution delivery practices • Microservices • Various technologies around the implementation model • Modernisation of applications to become process-centric • Moving services to clouds © A. Samarin 2014 Эталонная модель электронного правительства v2 89
  90. 90. Embed risk management into functional • Normal activities are enriched by “check-points” © A. Samarin 2014 processes Эталонная модель электронного правительства v2 90
  91. 91. © A. Samarin 2014 ERM reference model Эталонная модель электронного правительства v2 91
  92. 92. VIEWS (2) • Common functional capabilities • Enterprise as a system of processes • Enhancing information security by the use of processes • Enterprise Risk Management reference model • Records management as an BPM application • Multi-layered implementation model • Agile solution delivery practices • Microservices • Various technologies around the implementation model • Modernisation of applications to become process-centric • Moving services to clouds © A. Samarin 2014 Эталонная модель электронного правительства v2 92
  93. 93. Typical problems with legacy software • Symptoms of becoming legacy – ad-hoc integration – difficult incorporation of new technologies – old programming techniques – expensive maintenance – heavy releases and upgrades – availability of industrial products for previously unique functionality (e.g. event management) – some functionality is a commodity right now (e.g. BPM and BRM) – just slow to evolve • What is the root cause? – Emergent/historical grow and not architected evolution © A. Samarin 2014 Эталонная модель электронного правительства v2 93
  94. 94. The goal of modernisation • Implement end-to-end processes with the maximum reuse of existing IT applications and infrastructure • Agile (with the pace of business) provisioning of business solutions • From disparate IT applications to a coherent business execution platform which will “liberate” people for business innovations • Business evolution to drive technical transformation • BUT Application as a unit of deployment is too big © A. Samarin 2014 Эталонная модель электронного правительства v2 94
  95. 95. How to carry out the modernisation • Step-by-step technical transformation by: 1. Disassemble into services 2. Add, if necessary, more services 3. Assemble via processes • Combine various tactics: assemble, rent, buy, build, outsource, standardised, re-engineered • Incremental improvements and refactoring within a well-defined big picture • Intermix business evolution and technical transformation • Keep the users happy and feel secure © A. Samarin 2014 Эталонная модель электронного правительства v2 95
  96. 96. Monolithic applications are decomposed into interconnected services Monolith application GUI GUI screen 1 1 GUI GUI screen 2 2 GUI GUI screen 3 3 Business Business logic logic BO1 BO1 persistence persistence BO2 BO2 persistence persistence Business logic service Interactive service 1 Interactive service 2 Interactive service 3 Coordination BO1 persistence service BO2 persistence service Assembled solution © A. Samarin 2014 Эталонная модель электронного правительства v2 96
  97. 97. How to coordinate? • Only the flow of data is traceable • Flow of control is explicit, because the primary importance is the result of working together, but not individual exchanges (think about football) © A. Samarin 2014 Эталонная модель электронного правительства v2 97
  98. 98. Several coordination techniques may be used together • By processes • By events (EPN) • By rules, work-load, etc. © A. Samarin 2014 Эталонная модель электронного правительства v2 98
  99. 99. Transformation from typical inter-application data flows to end-to-end coordination of services © A. Samarin 2014 Эталонная модель электронного правительства v2 99
  100. 100. Using events • To externalise the flow of control from existing monolith applications © A. Samarin 2014 Эталонная модель электронного правительства v2 100
  101. 101. Co-existence of a legacy application and a process solution • The danger of “DOUble Master” (DOUM) anti-pattern – particular data (actually a business object) are modified via application or process but not either • Few techniques – lock-down the data manipulation interface in the application (a screen) and provide a similar functionality in the process – dynamic provisioning of the access to a screen for a staff member who is carrying out a related activity (see next slide) – decomposition of a screen into separate functions, e.g. Create (out-of-process), Update (within-process) and Delete (separate-process) – combination of previous ones © A. Samarin 2014 Эталонная модель электронного правительства v2 101
  102. 102. Process-centric solutions Assemble via processes (1) • Business processes make bigger services from smaller services • The relationship between services and processes is “recursive” – All processes are services – Some operations of a service can be implemented as a process – A process includes services in its implementation © A. Samarin 2014 Эталонная модель электронного правительства v2 102
  103. 103. Process-centric solutions Assemble via processes (2) • Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators) • Make these relationships explicit and executable What you model is what you execute “The map is the app” © A. Samarin 2014 Эталонная модель электронного правительства v2 103
  104. 104. Process-centric solutions Multi-layer implementation model (1) © A. Samarin 2014 Эталонная модель электронного правительства v2 104
  105. 105. Process-centric solutions Multi-layer implementation model (2) B C A A - SharePoint B – in-house development C – SAP ECC6 © A. Samarin 2014 Эталонная модель электронного правительства v2 105
  106. 106. Process-centric solutions Multi-layer implementation model (3) SAP BW/BI, etc. NetWeaver PI, SolMan, etc. NetWeaver BPM, etc. NetWeaver BRM, Java, ECC6, etc. XSD, Java, .Net SQL Server, Oracle, etc. © A. Samarin 2014 Эталонная модель электронного правительства v2 106
  107. 107. Multi-layer implementation model and other technologies © A. Samarin 2014 Эталонная модель электронного правительства v2 107
  108. 108. • Healthcare ANNEX © A. Samarin 2014 Эталонная модель электронного правительства v2 108
  109. 109. N E E D S R E S U L T S Healthcare reference model (1) Enrich Knowledge Improve Operations acquisition channels for external data/ information/ knowledge dissemination channels of internal data/ information/ knowledge Methods, practices, laws, international regulations, etc. Knowledge for Healthcare … … … Processes & Services Diagnostic Preliminary analysis Treatment Recovery Coordination PaPratnrtenrer PaPrtanretnrer Partners © A. Samarin 2014 Эталонная модель электронного правительства v2 109
  110. 110. Healthcare reference model (2) ECM RBAC BPM Knowledge Mgmt. Procedures Healthcare Platform acquisition channels dissemination channels Specialised Apps. Specialised Apps. Specialised Apps. Web access Mobile access Patient CRM Web access Mobile access Doctor CRM Access EDI Enrichment Storage ECM Coordination BI BPMs PaPratnrtenrer PaPrtanretnrer Partners © A. Samarin 2014 Эталонная модель электронного правительства v2 110
  111. 111. Healthcare reference model (3) Modern Healthcare System (MHS) Hospitals Clinics MHS Virtual Doctor’s Offices MHS MHS MHS Patients Insurance Social MHS WEB & Cloud MHS Labs © A. Samarin 2014 Эталонная модель электронного правительства v2 111
  112. 112. ANNEX Smart-city implementation reference model • All smart-cites deliver the same services, albeit in a different manner • Realisation of smart-city potentials would benefit from a holistic approach • BSI standard PAS 181:2014 © A. Samarin 2014 Эталонная модель электронного правительства v2 112
  113. 113. Conclusion • Let us use the power of modern technologies to enable and drive societal transformation © A. Samarin 2014 Эталонная модель электронного правительства v2 113
  114. 114. • QUESTIONS? Thanks • EKSALANSI website: http://www.eksalansi.org • Blog: http://improving-bpm-systems.blogspot.com • LinkedIn: http://www.linkedin.com/in/alexandersamarin • E-mail: alex@eksalansi.org • Twitter: @samarin • Mobile: +41 76 573 40 61 • Book: www.samarin.biz/book E-government reference model v2 114 © A. Samarin 2014

×