Contributed on October 9, 2014

2.2K

1.4K

E-government reference model

Description

E-government �reference model (see PPT notes for URLs with explanation of some views)

Transcript

E-government
reference model
Alexander SAMARIN
Global e-Government Forum 2014
7-8 October, 2014, Astana, Kazakhstan
http://www.unpan.org/GeGF/2014
About me
• A digital enterprise architect
– from a programmer to a systems architect
– creator of systems that work without me
– broad experience: company, canton, country, continent
• I believe that many improvements in operational
excellence and strategy execution are achievable
relatively easy
• HOW I do what I do
– architecting synergy between strategies, technologies, tools and
good practices for the client’s unique situation, and knowledge
transfer
• WHAT is the result of my work for clients
– less routine work, less stress, higher performance, higher security,
less risk, higher predictability of results, better operations, less
duplication and liberation of business potentials
© A. Samarin 2014 E-government reference model v3 2
Agenda
• Context
• E-government reference model
• Views
© A. Samarin 2014 E-government reference model v3 3
Introduction
• E-government is the use of Information and
Communication Technologies (ICTs) to improve the
activities of public sector organisations
• E-governance is the use of ICTs to improve the manner in
which power is exercised in the management of the affairs
of a nation, and its relations with other nations
• E-government is a sociotechnical system of systems
• Relationships between socio and technical elements
should lead to the emergence of productivity and
wellbeing
• A system is a set of interacting or interdependent
components forming an integrated whole
© A. Samarin 2014 E-government reference model v3 4
Complexity of e-government
• Unlimited life-cycle (unpredictable and incremental
evolution)
• Socio-technical system
• Collaborative system
• Industrialised system
• Ability for rapid innovation is important
• Variety of services (several hundred governmental
services are listed in the Swiss e-government catalogue)
• High level of security for personal data
© A. Samarin 2014 E-government reference model v3 5
Digital age (1)
• Digital eats physical: Everything becomes digital:
products, information, content, documents, records,
processes, money, rights, communications.
• Fast eats slow: As digital is intangible thus news tools
and new execution speed immediately.
• Group eats single: It is mandatory to collaborate to
address modern complex problems.
• Big eats small: Digital things are at new scale.
• With this new speed and scale, there is no time for human
intervention and errors in routine operations and at
interfaces
© A. Samarin 2014 E-government reference model v3 6
Digital age (2)
• Transparency is increasing with bad and good
consequences
• In addition to being
– cheaper, faster, better
• it is mandatory to become
– cleaner
– greener
– more agile
– more synergetic (i.e. IoT)
– more comprehensive
© A. Samarin 2014 E-government reference model v3 7
Digital age (3)
• In systems architecting the focus is changing
– FROM the thing (strategy, policy, service, rule, application,
process, etc.)
– TO how the thing changes
– SUBJECT how things change together
• To avoid “house of cards” effect
• To enable innovations
– “in the digital age innovation depends on process automation”
© A. Samarin 2014 E-government reference model v3 8
Agenda
• Context
• E-government reference model
• Views
© A. Samarin 2014 E-government reference model v3 9
WHY e-Gov reference model (1)
• Many governmental entities deliver the same services,
albeit in a different manner
• Many potential similarities
Technical
architecture
Data
architecture
Application
architecture
Business
architecture
Communal 100 % 100 % 100 % 100 %
Provincial 100 % 100 % 100 % 80 %
Ministerial 90 % 100 % 60-80 % 70 %
National 90 % 100 % 70 % 50 %
• Realisation of the e-government need a systemic
approach
© A. Samarin 2014 E-government reference model v3 10
WHY e-Gov reference model (2)
• There is a way to combine diversity and uniformity
• The problem of combining them is also known in the
business as “shared services”
• Example – Business units (BUs) have different levels of
computerisation
– a standard solution from the IT department is not always good for
everyone
BU1 BU2 BU3
Standard
solution
Level of
computerisation
IT department
© A. Samarin 2014 E-government reference model v3 11
WHY e-Gov reference model (3)
Level of
computerisation
© A. Samarin 2014
B C A B A B C
BU1 BU2 BU3
1) Standard
solution is based
on processes and
shared services
2) Each BU is
moving to a similar
architecture
IT department
E-government reference model v3 12
WHY e-Gov reference model (4)
• Considers together all implementations and architects
the ability to reproduce results
– ready-to-use solutions, tools, patterns and architectures
– offers the best possible services for each citizen
– becomes the centre of societal transformation
– seamlessly incorporates innovations
– implementable at your pace
– secure by design
© A. Samarin 2014 E-government reference model v3 13
HOW does e-Gov reference model work
• Apply the power of Enterprise Architecture (EA)
– commonly-agreed model
– platform-based implementation
– enterprise-as-a-system-of-processes
– modernisation of legacy applications
• Bring EA group into an e-Gov programme
• EA group as a seed for an e-Gov competence centre
© A. Samarin 2014 E-government reference model v3 14
EA explained (1)
• Architect is a person who translates a customer’s
requirements into a viable plan and guides others in its
execution
• Enterprise Architecture (EA) is the process of translating
business vision and strategy into effective enterprise
change by creating, communicating, and improving the
key requirements, principles, and models that describe
the enterprise’s future state and enable its evolution and
transformation.
© A. Samarin 2014 E-government reference model v3 15
EA explained (2)
• EA is the right “tool” to address the challenge of diversity
& uniformity because EA is a systemic coordinator of
people, processes, products and projects in 4 dimensions:
– Business zones span – organisational unit, segment, enterprise,
supply chain, municipality, governorate, ministry, country, region,
continent, etc.
– Architectural domains span – business, data, application,
security, information, technology, etc.
– Time span – solution life-cycle, technology life-cycle, tool life-cycle,
project life-cycle, enterprise life-cycle, etc.
– Sector span – detecting and re-using common patterns (good
business practices) in unique processes from different sectors
© A. Samarin 2014 E-government reference model v3 16
EA views: projects, solutions,
© A. Samarin 2014
capabilities and platforms
E-government reference model v3 17
© A. Samarin 2014
EA views: time-span
E-government reference model v3 18
EA views: business zones vs time span
© A. Samarin 2014 E-government reference model v3 19
EA views: architectural domains vs
business zones
© A. Samarin 2014 E-government reference model v3 20
EA group in an e-Gov program organigram
Steering Committee
PMO EA group Budget
Administrative coordination Technical coordination Financial control
Degree of involvement
Time
External
team
Local
team
Initiation phase Projects-based phase Maintenance phase
© A. Samarin 2014 E-government reference model v3 21
EA group structure by main roles
• Chief Architect
• Governance group
– review board
– quality assurance
– budget
– librarian
• Solution group
– solution architects
– business analysts
• PMO group
– project leaders
• Domain group
– business architects
– application architects
– information architects
– security architects
– infrastructure architects
• Vertical group
– healthcare
– smart-cities
– tourism
– …
© A. Samarin 2014 E-government reference model v3 22
EA group as a seed for an
e-Gov competence centre
• Potential structure of the e-Gov competence centre
– EA group
– Communication group
– Application Development group
– Operations group
– Knowledge Management group
– Education services
– Training services
© A. Samarin 2014 E-government reference model v3 23
EA – Many stakeholder (participants)
• Citizens
• Local businesses
• Global businesses
• Government authorities
• Local government stakeholders
• National regulatory agencies
• Political parties
• Local NGOs
• External NGOs
• Funding bodies
• Public service providers
• IT vendors
• Architects
• Project managers
© A. Samarin 2014 E-government reference model v3 24
Matrix between stakeholders and views
An example
© A. Samarin 2014 E-government reference model v3 25
WHAT RM – many 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 E-government reference model v3 26
WHAT RM – many 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 E-government reference model v3 27
Agenda
• Context
• E-government reference model
• Views
© A. Samarin 2014 E-government reference model v3 28
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 E-government reference model v3 29
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 E-government reference model v3 30
A partner-initiated-demand may
required several exchanges between the
partner and the government
Government
Time
© A. Samarin 2014 E-government reference model v3 31
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 E-government reference model v3 32
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 E-government reference model v3 33
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 E-government reference model v3 34
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 E-government reference model v3 35
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 E-government reference model v3 36
Partner’s view
© A. Samarin 2014 E-government reference model v3 37
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 E-government reference model v3 38
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
E-government reference model v3
E-gov traditional application architecture
Partners
Application
Existing
application
Portal
Application
Existing
application
Application
Existing
application
Government
© A. Samarin 2014 40
E-government reference model v3
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
E-government reference model v3
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
Service Service
Government
© A. Samarin 2014 42
E-government reference model v3
Existing
application
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
E-government reference model v3
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
E-government reference model v3
Steps of evolution in application
architecture
Introductory
architecture
Target
architecture
E-Social system
architecture
Portal-centric
architecture
Transitional
architecture
© A. Samarin 2014 E-government reference model v3 45
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 E-government reference model v3 46
Integration process instead of
N-to-N connectivity
© A. Samarin 2014 E-government reference model v3 47
Use of many security envelopes
• Business (processing) envelope
• Delivery (addressing) envelope
• Transportation (routing) envelope
© A. Samarin 2014 E-government reference model v3 48
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 E-government reference model v3 49
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 E-government reference model v3 50
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 E-government reference model v3 51
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 E-government reference model v3 52
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 E-government reference model v3 53
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 E-government reference model v3 54
Solutions vs components
© A. Samarin 2014 E-government reference model v3 55
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 E-government reference model v3 56
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 E-government reference model v3 57
Component-oriented design
• The platform is designed to be tools-independent by
standardizing data, information, interfaces and
coordination between various capabilities.
© A. Samarin 2014 E-government reference model v3 58
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 E-government reference model v3 59
Architecture-based agile project
management
• It combines decomposition with agile implementation of
“architected” components
© A. Samarin 2014 E-government reference model v3 60
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 E-government reference model v3 61
Structural dependencies between
various artefacts
© A. Samarin 2014 E-government reference model v3 62
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 E-government reference model v3 63
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 E-government reference model v3 64
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 E-government reference model v3 65
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 E-government reference model v3 66
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 E-government reference model v3 67
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 E-government reference model v3 68
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 E-government reference model v3 69
SI animated diagram
Click for
animation
© A. Samarin 2014 E-government reference model v3 70
Coordination between processes (1)
• Simple event-based (which looks like a state machine)
© A. Samarin 2014 E-government reference model v3 71
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 E-government reference model v3 72
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 E-government reference model v3 73
Enabler group, supporting group and
customer group of clusters
© A. Samarin 2014 E-government reference model v3 74
Implicit coordination between CLOPs (1)
© A. Samarin 2014 E-government reference model v3 75
Implicit coordination between CLOPs (2)
© A. Samarin 2014 E-government reference model v3 76
Implicit coordination between CLOPs (3)
© A. Samarin 2014 E-government reference model v3 77
Make coordination between CLOPs
explicit (1)
• Business Object (BO) lify-cycle as a process
© A. Samarin 2014 E-government reference model v3 78
Make coordination between CLOPs
explicit (2)
• Add enterprise-wide event dispatcher
© A. Samarin 2014 E-government reference model v3 79
Make coordination between CLOPs
explicit (3)
© A. Samarin 2014 E-government reference model v3 80
Functional view at a system of processes (1)
© A. Samarin 2014 E-government reference model v3 81
Functional view at a system of processes (2)
© A. Samarin 2014 E-government reference model v3 82
Functional view at a system of processes (3)
© A. Samarin 2014 E-government reference model v3 83
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 E-government reference model v3 84
Dynamic provision of the access
© A. Samarin 2014 E-government reference model v3 85
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
E-government reference model v3 86
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
E-government reference model v3 87
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)
E-government reference model v3 88
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 E-government reference model v3 89
Embed risk management into functional
• Normal activities are enriched by “check-points”
© A. Samarin 2014
processes
E-government reference model v3 90
© A. Samarin 2014
ERM reference model
E-government reference model v3 91
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 E-government reference model v3 92
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 E-government reference model v3 93
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 E-government reference model v3 94
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 E-government reference model v3 95
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 E-government reference model v3 96
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 E-government reference model v3 97
Several coordination techniques may be
used together
• By processes
• By events (EPN)
• By rules, work-load, etc.
© A. Samarin 2014 E-government reference model v3 98
Transformation from typical inter-application
data flows to end-to-end
coordination of services
© A. Samarin 2014 E-government reference model v3 99
Using events
• To externalise the flow of control from existing monolith
applications
© A. Samarin 2014 E-government reference model v3 100
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 E-government reference model v3 101
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 E-government reference model v3 102
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 E-government reference model v3 103
Process-centric solutions
Multi-layer implementation model (1)
© A. Samarin 2014 E-government reference model v3 104
Process-centric solutions
Multi-layer implementation model (2)
B C
A
A – SharePoint
B – in-house
development
C – SAP ECC6
© A. Samarin 2014 E-government reference model v3 105
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 E-government reference model v3 106
Multi-layer implementation model and
other technologies
© A. Samarin 2014 E-government reference model v3 107
• Healthcare
ANNEX
© A. Samarin 2014 E-government reference model v3 108
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 E-government reference model v3 109
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 E-government reference model v3 110
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 E-government reference model v3 111
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 E-government reference model v3 112
Conclusion
• Let us use the power of modern technologies to enable
and drive societal transformation
© A. Samarin 2014 E-government reference model v3 113
• 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 v3 114
© A. Samarin 2014