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

Эталонная модель
электронного правительства
Александр САМАРИН
Global e-Government Forum 2014
7-8 October, 2014, Astana, Kazakhstan
http://www.unpan.org/GeGF/2014

Содержание
• Контекст
• Эталонная модель электронного правительства
• Проекции эталонной модели
© A. Samarin 2014 Эталонная модель электронного правительства v2 2

Основные определения
• Электронное Правительство (ЭП) – это использование
современных информационных технологий для
повышения эффективности и результативности
государственного сектора
• Электронное правительство (electronic government) и
электронное управление (electronic governance)
рассматриваются совместно как единая система
• ЭП является социально-технической системой
социально-технических систем (необходим совместный
учет социальных и технических аспектов)
• Система – это функциональное целое, состоящее из
взаимодействующих, взаимосвязанных или
взаимозависимых частей

Сложность ЭП как системы
• Неограниченный жизненный цикл
• Непредсказуемая и постепенная эволюция
• Социально-технический характер
• Коллегиальное принятие решений
• Функционирование на уровне современного
предприятия
• Способность к быстрому внедрению инноваций крайне
важна
• Широкое разнообразие услуг
• Высокий уровень безопасности персональных данных

Цифровая эра (1)
• Цифровое побеждает физическое: все становится
цифровым
• Быстрое побеждает медленное: обычная скорость
исполнения - немедленно
• Группа побеждает одиночек: решение современных
сложных проблем возможно только путем
сотрудничества
• Большое побеждает малое: новые масштабы
• Нет времени для ошибок и вмешательства человека в
рутинных операциях и интерфейсах

Цифровая эра (2)
• В дополнение к известным
– дешевле, быстрее, лучше
• надо работать
– более экологично, более гибко, более синергетически (т.е.
IoT), более всеобъемлюще, более безопасно
• Смена фокуса при проектировании систем
– ОТ рассмотрения артефакта как отдельного объекта
– К тому, как артефакт изменяется на
протяжении своего жизненного цикла
– ОБРАЩАЯ ВНИМАНИЕ на то,
как артефакты изменяются совместно
• Цель – обеспечение инноваций, которые
цифровом мире зависят от автоматизации процессов

ПОЧЕМУ Эталонная модель ЭП (1)
• Многие правительственные организации предоставляют
аналогичные услуг, но по-разному
• Очень много общего между правительственными
организациями
Уровни власти
Архитектуры ЭП
Техническая
архитектура
Архитектура
данных
Архитектура
приложений
Бизнес-
архитектура
Муниципальный 100% 100% 100% 100%
Провинциальный 100% 100% 100% 80%
Федеральный 90% 100% 60-80% 70%
Национальный 90% 100% 70% 50%
• Возможна существенная экономия при реализации ЭП

• Существует способ, как объединить разнообразие и
единообразие
• Проблема их сочетания известна в бизнесе, как "общие
службы"
• Пример - Бизнес-подразделения (BU) имеют
различные уровни компьютеризации и стандартное
решение от ИТ подразделения никому не подходит
BU1 BU2 BU3
Общее решение
Уровень
компьютеризации
ИТ подразделение

Уровень
компьютеризации
© A. Samarin 2014
B C A B A B C
BU1 BU2 BU3
1) Стандартное
решение использует
процессы и службы
2) Все подразделения
постепенно переходят
к единой архитектуре
ИТ подразделение
Эталонная модель электронного правительства v2 10

• Становиться возможным избежать дублирования и
необоснованных переделок
– готовые решения, инструменты, модели и архитектуры
– изменения происходят с комфортной скоростью
– становится центром трансформации общества
– наилучшие услуги для каждого гражданина
– плавно включаются инновации
– безопасность в дизайне

КАК работает эталонная модель ЭП
• Использование всей мощи корпоративной архитектуры
(Enterprise Architecture - EA)
– согласованные модели
– платформенная архитектура
– предприятие как система процессов
– модернизация устарелых приложений
• Создание архитектурной группы в программе ЭП
• Архитектурная группа является «зародышем» центра
компетенции ЭП

Корпоративная архитектура (1)
• Архитектор – это индивидуум, который переводит
требования клиента в осуществимый план и
направляет других при выполнении этого плана
• Корпоративная архитектура – это процесс перевода
бизнес-стратегии в эффективное изменение
предприятия путем создания принципов и моделей,
которые описывают будущее состояние предприятия и
обеспечивают его эволюцию

Корпоративная архитектура (2)
• В настоящее время, только корпоративная архитектура
способна объединить разнообразие и единообразие
• Корпоративная архитектура осуществляет
координацию между персоналом, процессами,
проектами и продуктами в 4-мерном пространстве
следующих осей:
– Охват по размеру - подразделение, предприятие, отрасль,
правительство, вся страна, объединение стран, континент …
– Охват по архитектурным областям – бизнес-архитектура,
ИТ-технологии, архитектура безопасности …
– Охват по времени - жизненного цикла программного решения,
технологии, проекта, стратегии, предприятия …
– Охват по секторам экономики – выявление общих и
специфических бизнес-практик

Проекты, решения, платформы …
© A. Samarin 2014

© A. Samarin 2014
Охват по времени

Охват по размеру против охвата по
времени

Охват по размеру против охвата по
архитектурным областям

Архитектурна группа в структуре
программы ЭП
Руководство программой
Программный
офис
Архитектурная
группа
Бюджет
Административная координация Техническая координация Финансовый контроль
Уровень вовлеченности
Внутренняя
команда
Time
Внешняя
команда
Начальная фаза Проектная фаза Эволюционная фаза

Основные роли с архитектурной группе
• Ген. архитектор
• Управление
– экспертный совет
– контроль качества
– финансы
– библиотекарь
• Решения
– архитекторы решений
– аналитики
• Проекты
– лидеры проектов
• Горизонтальные арх.
– бизнес
– приложения
– информация
– безопасность
– инфраструктура
• Вертикальные арх.
– здоровье
– города
– туризм
– …

Архитектурная группа является
«зародышем» центра компетенции ЭП
• Структура центра компетенции ЭП
– Архитектурная группа
– Группа социальных связей
– Группа разработки
– Группа эксплуатации
– Группа преумножения знаний
– Образовательные услуги
– Обучение

Много заинтересованных лиц
• Граждане
• Местный бизнес
• Глобальный бизнес
• Местные власти
• Государственные агентства
• Политические партии
• Местные не правительственные орг.
• Межд. не правительственные орг.
• Производители ПО
• Системные архитекторы
• Руководители проектов

Матрица заинтересованных лиц и
проекций ЭП
An example

Проекции ЭП (1)
• Взаимодействие между гражданином и
правительственным учреждением
• Коммуникационное пространство гражданина
• Стадии реализации ЭП
• Межведомственный обмен данными и документами
• Платформенная архитектура
– Подход
– Практика
– Управление проектами
– Управление развитием платформы
– Архитектурно-обоснованные закупки

Проекции ЭП (2)
• Предприятие как системы процессов
• Использование процессов для усиления
информационной безопасности
• Эталонная модель управления рисками
• Процессная реализация архивного дела
• Многоуровневая модель процессных решений
• Практика процессных решений
• Микро службы
• Модернизация устарелых приложений
• Перенос служб в «облака»

Заключение
• Современные методологии и технологии являются
потенциальной основой общественного прогресса
• Корпоративная архитектура обеспечивает совместное
использование современных методологий и технологий
• Эталонная модель ЭП использует мощь корпоративной
архитектуры для эффективного построения ЭП
• Эталонная модель ЭП – это основа для кооперации
между странами при построении ЭП
• Эталонная модель ЭП применима для секторов как:
– здравоохранение
– «умный город» (smart-city)

• Вопросы?
СПАСИБО
• 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

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

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 partner-initiated-demand may
required several exchanges between the
partner and the government
Government
Time

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)

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)
Time
(ED) exchange
+ BPM discipline
+ process modelling
Technologies:
• standard data schemas
• electronic signature
+ BPM suite

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
lines)
lines)
Technologies:
+ BPM suite

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
Time
Technologies:
• BPM suite
+ ECM
Social collaborative extranet
lines)
lines)

VIEWS (1)
• Partner – governmental entity interaction view
• Partner view

Partner’s view

VIEWS (1)
• Partner view

E-gov application architecture view
Partners
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

E-gov traditional application architecture
Partners
Application
Existing
application
Portal
Application
Existing
application
Application
Existing
application
Government

E-gov introductory application
architecture
Partners
e-gov
service
e-gov
service
e-gov
service
Existing
application
e-Government
Existing
application
Existing
application
Government

E-gov transitional application
architecture
Partners
e-gov
service
e-gov
service
e-gov
service
Existing
application
e-Government
Existing
application
Coordination backbone
Existing
application
Service Service
Government

E-gov target application architecture
Partners
e-Government
e-gov
service
e-gov
service
e-gov
service
Service Service Service

E-social system application architecture
Partners
E-social system
Public
service
Social
service
Private
service
Professional
service
Voluntary
service

Steps of evolution in application
architecture
Introductory
architecture
Target
architecture
E-Social system
architecture
Portal-centric
architecture
Transitional
architecture

VIEWS (1)
• Partner view

Integration process instead of
N-to-N connectivity

Use of many security envelopes
• Business (processing) envelope
• Delivery (addressing) envelope
• Transportation (routing) envelope

VIEWS (1)
• Partner view

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

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

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

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

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

Solutions vs components

VIEWS (1)
• Partner view

Ladder of maturity meta-pattern
• Entities are permitted to advance at different paces in
their ascent to the top of the “ladder”.

Component-oriented design
• The platform is designed to be tools-independent by
standardizing data, information, interfaces and
coordination between various capabilities.

VIEWS (1)
• Partner view

Architecture-based agile project
management
• It combines decomposition with agile implementation of
“architected” components

VIEWS (1)
• Partner view

Structural dependencies between
various artefacts

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

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)

VIEWS (1)
• Partner view

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.

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

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)

Process fragments – patterns
Click for animation
• Business case: typical “claim processing” process – claim,
repair, control, invoicing, and assurance to pay
SI
PAR
SI
IPS

SI animated diagram
Click for
animation

Coordination between processes (1)
• Simple event-based (which looks like a state machine)

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)

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

Enabler group, supporting group and
customer group of clusters

Implicit coordination between CLOPs (1)

Make coordination between CLOPs
explicit (1)
• Business Object (BO) lify-cycle as a process

explicit (2)
• Add enterprise-wide event dispatcher

explicit (3)

Functional view at a system of processes (1)

VIEWS (2)
• Microservices

Dynamic provision of the access

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

• 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

BPM and information security:
• 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)

VIEWS (2)
• Microservices

VIEWS (2)
• Common functional capabilities
• Microservices

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

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

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

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

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)

Several coordination techniques may be
used together
• By processes
• By events (EPN)
• By rules, work-load, etc.

Transformation from typical inter-application
data flows to end-to-end
coordination of services

Using events
• To externalise the flow of control from existing monolith
applications

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

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

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”

Multi-layer implementation model (1)

B C
A
A - SharePoint
B – in-house
development
C – SAP ECC6

SAP BW/BI, etc.
NetWeaver PI,
SolMan, etc.
NetWeaver
BPM, etc.
NetWeaver BRM,
Java, ECC6, etc.
XSD, Java, .Net
SQL Server,
Oracle, etc.

Multi-layer implementation model and
other technologies

• Healthcare
ANNEX

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

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

Modern Healthcare System (MHS)
Hospitals
Clinics
MHS
Virtual Doctor’s
Offices
MHS
MHS
MHS
Patients
Insurance
Social
MHS WEB
& Cloud
MHS
Labs

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

Conclusion
• Let us use the power of modern technologies to enable
and drive societal transformation

• 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

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

Recomendados

Recomendados

Mais conteúdo relacionado

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

Semelhante a Эталонная модель электронного правительства (20)

Mais de Alexander SAMARIN

Mais de Alexander SAMARIN (20)

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

Notas do Editor