E-government reference model · 2014-11-05 3 • Digital triumphs physical: Everything becomes...

2014-11-05

1

E-government reference model

Alexander SAMARIN

e-Government Symposium

4 November, 2014, Bern, Switzerland

http://www.egovernment-symposium.ch/

• A digital enterprise architect– from a programmer to a systems architect – creator of systems that work without me– broad experience: company, canton, confederation, 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 v1 2

About me

2014-11-05

2

• Context

• E-government reference model

• Views


Agenda

• 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


Complexity of e-government

2014-11-05

3

• Digital triumphs physical: Everything becomes digital: products, information, content, documents, records, processes, money, rights, communications.

• Fast triumphs slow: As digital is intangible thus news tools and new execution speed immediately.

• Group triumphs single: It is mandatory to collaborate to address modern complex problems.

• Big triumphs 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


Digital age (1)

• Transparency is increasing with bad and good effects

• In addition to being

– cheaper, faster, better

• it is mandatory to become

– cleaner, greener, more agile, more synergetic (i.e. IoT), more comprehensive

• In systems architecting the focus is changing– FROM the thing– TO how the thing changes – SUBJECT how things change together

• To enable innovations

– “in the digital age innovation depends on process automation”


Digital age (2)

2014-11-05

4

• Context


• Views


Agenda

• Many governmental entities deliver the same services, albeit in a different manner

• Many potential similarities

• Realisation of the e-government need a systemic approach


WHY e-Gov reference model (1)

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 %

2014-11-05

5

• 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

Standardsolution

Level of computerisation

IT department

© A. Samarin 2014


BU1 BU2 BU3

Level of computerisation

A CBB BAC

1) Standardsolution is based on processes and

shared services

2) Each BU is moving to a similar architecture

IT department

E-government reference model v1 10

2014-11-05

6

• Considers together all implementations and develops 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



• 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


HOW does e-Gov reference model work

2014-11-05

7

• 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.


EA explained (1)

• 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


EA explained (2)

2014-11-05

8


EA group in a national e-Gov program

Steering Committee

PMO EA group Budget

Administrative coordination Technical coordination Financial control

Degree of involvement

Time

External team

Localteam

Initiation phase Projects-based phase Maintenance phase

• Chief Architect

• Governance group

– review board

– quality assurance

– budget

– librarian

• Solution group

– solution architects

– business analysts

• PMO group

– project leaders


EA group structure by main roles

• Domain group

– business architects

– application architects

– information architects

– security architects

– infrastructure architects

• Vertical group

– healthcare

– smart-cities

– tourism

– …

2014-11-05

9

• Potential structure of the e-Gov competence centre

– EA group

– Communication group

– Application Development group

– Operations group

– Knowledge Management group

– Education services

– Training services


EA group as a seed for ane-Gov competence centre


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

2014-11-05

10


Matrix between stakeholders and views

An example

• 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


WHAT RM - many views (1)

2014-11-05

11

• 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


WHAT RM - many views (2)

• Context


• Views


Agenda

2014-11-05

12

• Partner and governmental-entity interaction view

• Partner view



• Paperless or digital work view







VIEWS (1)

Four communication patterns for exchanges between a partner and the

government

Government

2. Patrner-declaration

1. Government-announce

4. Partner-demand

Spread in time

3. Government-demand

Spread in time

Partners (citizen, business, and other organisations)

1. Government-announcement, e.g. broadcasting changes in a law2. Partner-declaration, e.g. communicating a change of the partner’s address3. Government-demand, e.g. inviting to pay taxes4. Partner-demand, e.g. requesting a certificate (fishing license)


2014-11-05

13

A partner-initiated-demand may required several exchanges between the

partner and the government

Government

Time© A. Samarin 2014 E-government reference model v1 25

The partner may need to deal with some ministries

Government

Ministry A Ministry B Ministry C

Time

Methodologies:+ data modelling+ electronic document exchange

Tools:+ standard data schemas+ electronic signature

• data flow (black dashed lines)


2014-11-05

14

Process

+ + + +

E-gov coordinates partner’s interactions with the government

Government

• control flow (black solid lines)



Time

Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite


Process --

E-gov unifies the communication between the partner and the ministries

Government

Ministry B

Time

2a 2cx

2b



Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

Technologies:• standard data schemas• electronic signature+ BPM suite


……

2014-11-05

15

Process

+ + + +

E-gov provides a social collaborative extranet for partners

Government


Time

Methodologies:• data modelling• ED exchange• BPM discipline• process modelling+ ED management+ records management+ collaboration+ social

Technologies:• standard data schemas• electronic signature• BPM suite+ ECM

Social collaborative extranet





• Partner view









VIEWS (1)

2014-11-05

16

Partner’s view



• Partner view









VIEWS (1)

2014-11-05

17

Partners

Existing application

Coordination and integration backbone

e-Government

© A. Samarin 2014 33

E-gov application architecture view


e-gov service



Government

Technologies:• BPM suite• SOA orientation• ECM

e-gov service

e-gov service

E-government reference model v1

Partners



E-gov traditional application architecture

Portal



Government

Ap

plic

atio

n

Ap

plic

atio

n

Ap

plic

atio

n


2014-11-05

18

Partners



e-Government


E-gov introductory application architecture


e-gov service



Government

e-gov service

e-gov service


Partners



e-Government


E-gov transitional application architecture


e-gov service


Government

e-gov service

e-gov service

Coordination backbone

Service Service



2014-11-05

19

Partners


e-Government


E-gov target application architecture


e-gov service

e-gov service

e-gov service

ServiceService Service


Partners


E-social system


E-social system application architecture


Public service

Private service

Professionalservice

Social service

Voluntary service


2014-11-05

20


Steps of evolution in application architecture

Introductory architecture

Target architecture

E-Social system architecture

Portal-centric architecture

Transitional architecture


• Partner view









VIEWS (1)

2014-11-05

21


Integration process instead of N-to-N connectivity


• Partner view









VIEWS (1)

2014-11-05

22

• Faster and more systematic implementation of business solutions

• Agile and easier introduction of small modifications

• Less non-justified variations of tools

• Liberation of people for innovations

• Clear path to clouds

• Solutions convergence for the business (similar GUI, ECM, processes, security, etc.)


Platform-based architecture drivers


• Standardise and simplify core elements of future enterprise-wide system

• For any elements outside the platform, new opportunities should be explored using agile principles (low-code)


Platform pattern

A2

A1A3

Platform

S2…

S1S3

Functionality

Delivery by solutions Delivery by applications

Scope


2014-11-05

23

• 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


Platform practices



What – platform functional structure

Dev env 1 Dev env 2

Development environment 3Generic development

environments

DEVELOPMENT

Functionality

Basic off-the-shelf features

of the platform

Advanced off-the-shelf

features of the platform

Company-specific features

Process-centricity


2014-11-05

24


Financial benefits

N applications

N≈5-6

Without common platform

With common platform

Cumulative cost


Platform cost

• There are three primary types of activity

1. Agile implementation of business solutions as mini-projects (low code)

2. Classic projects for new versions of platform components

3. Absorption of new mini-processes and micro-services by the platform

4. On-going and centralised planning platform evolution


Impact - governance


2014-11-05

25

• The platform governance is carried out by an inter-organisational-units coordination committee

• Mini-projects are carried-out by platform solution architects

• Platform implementation resources are provided by the ICT department and by a set of authorised service providers

• Platform configuration management supports the full life-cycle of common mini-processes and micro-services

• Operational team provides integration and release of solutions into production


Impact – platform team structure


• Partner view









VIEWS (1)

2014-11-05

26

• Entities are permitted to advance at different paces in their ascent to the top of the “ladder”.


Ladder of maturity meta-pattern

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


Component-oriented design

2014-11-05

27


• Partner view









VIEWS (1)

• It combines decomposition with agile implementation of “architected” components


Architecture-based agile project management

2014-11-05

28


• Partner view









VIEWS (1)


Structural dependencies between various artefacts

2014-11-05

29

Business initiatives (business-specific demand)

Business capabilities(business-generic demand)

IT capabilities (IT-generic supply)

Roadmap programmes(from AS-IS to TO-BE)

Business demand IT supply

Business strategicobjectives

Governance

Maturity improvement Requested maturity Business priority

1

2

3

2

2->5

2->4

1->3

1->4

2->4

1->3

2->5

2->4

3->4

4

4

5

3

1

2

3

4

4

1

1

2

3

2

2

4

4

5

3

3->4

1->4

3->5

3->4

2->4

IT tools(IT-specific supply)

3

Programme priority

5

4

3

4

4

Dynamic relationships between various artefacts


Manage business by processes

Manage processes BPM suite

• 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)


Implications and example

2014-11-05

30


• Partner view









VIEWS (1)

• 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.


Architecture-based procurement

2014-11-05

31







• Microservices





VIEWS (2)

• 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. processes3. cluster of processes (coordination between processes)4. system of processes (coordination between clusters of processes)


Enterprise as a system of processes

2014-11-05

32

• Business case: typical “claim processing” process – claim, repair, control, invoicing, and assurance to pay


Process fragments – patterns

SI

PAR

SI

IPS

Click for animation


SI animated diagram

Click for animation

2014-11-05

33

• Simple event-based (which looks like a state machine)


Coordination between processes (1)


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)

2014-11-05

34

• 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


CLuster Of Processes (CLOP)


Enabler group, supporting group and customer group of clusters

2014-11-05

35


Implicit coordination between CLOPs (1)



2014-11-05

36



• Business Object (BO) lify-cycle as a process


Make coordination between CLOPs explicit (1)

2014-11-05

37

• Add enterprise-wide event dispatcher





2014-11-05

38


Functional view at a system of processes (1)



2014-11-05

39









• Microservices





VIEWS (2)

2014-11-05

40


Dynamic provision of the access

© A. Samarin 2014

Extra relationships between activities (1)

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


2014-11-05

41

• 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


Activity_A

Activity_B

Carry out the work

Carry out the work Validating the work

Role_1

Role_2


• 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



2014-11-05

42


Process-enhanced security for electronic medical records







• Microservices





VIEWS (2)

2014-11-05

43

• Normal activities are enriched by “check-points”

© A. Samarin 2014

Embed risk management into functional processes


© A. Samarin 2014

ERM reference model


2014-11-05

44

• Common functional capabilities







• Microservices





VIEWS (2)

• 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


Typical problems with legacy software

2014-11-05

45

• 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


The goal of 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


How to carry out the modernisation

2014-11-05

46


Monolithic applications are decomposed into interconnected services

Monolith

application

GUI screen 2GUI screen 1 GUI screen 3

Business logic

BO1 persistence BO2 persistence

Business

logic service

Interactive

service 1

Interactive

service 2

Interactive

service 3

Coordination

BO1

persistence serviceBO2

persistence service

Assembled

solution

GUI screen 2GUI screen 1 GUI screen 3

Business logic

BO1 persistence BO2 persistence

• Only the flow of data is traceable

• Flow of control is explicit, becausethe primary importance is the result of working together, but not individual exchanges(think about football)


How to coordinate?

2014-11-05

47

• By processes

• By events (EPN)

• By rules, work-load, etc.


Several coordination techniques may be used together


Transformation from typical inter-application data flows to end-to-end

coordination of services

2014-11-05

48

• To externalise the flow of control from existing monolith applications


Using events

• 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


Co-existence of a legacy application and a process solution

2014-11-05

49

• 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 servicesin its implementation


Process-centric solutionsAssemble via processes (1)

• 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”


Process-centric solutionsAssemble via processes (2)

2014-11-05

50


Process-centric solutionsMulti-layer implementation model (1)



B C

A

A - SharePoint

B – in-house development

C – SAP ECC6

2014-11-05

51



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

2014-11-05

52

• Healthcare


ANNEX

N

E

E

D

S

R

E

S

U

L

T

S

Enrich Knowledge

Improve Operations

acquisition channels for external data/information/ knowledge

disseminationchannels of internal data/information/ knowledge

Methods, practices, laws, international regulations, etc.

Knowledge for Healthcare

Processes & Services

… … …

DiagnosticPreliminary

analysisTreatment Recovery

PartnerPartnerPartnerPartnerPartners

Coordination


Healthcare reference model (1)

2014-11-05

53

Healthcare Platform

acquisition channels

disseminationchannels

Specialised Apps.

Specialised Apps.

Specialised Apps.

Web access

Mobile access

Patient

CRM

Web access

Mobile access

DoctorCRM

Access

EDI

Enrichment

RBAC

Knowledge Mgmt. Procedures

BPMECM

Storage

ECMCoordination

BPMsBI

PartnerPartnerPartnerPartnerPartners

Healthcare reference model (2)


Healthcare reference model (3)Modern Healthcare System (MHS)

Hospitals Clinics

MHS

Virtual Doctor’s Offices

MHS

MHS

MHS

Insurance Social

PatientsMHS WEB & Cloud

MHS

Labs


2014-11-05

54

• 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


ANNEX Smart-city implementation reference model

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


Conclusion

2014-11-05

55

• QUESTIONS?

• Personal website: http://www.samarin.biz

• Blog http://improving-bpm-systems.blogspot.com

• LinkedIn: http://www.linkedin.com/in/alexandersamarin

• E-mail: [email protected]

• Twitter: @samarin

• Mobile: +41 76 573 40 61

• Book: www.samarin.biz/book


Thanks

© A. Samarin 2014

http://www.samarin.biz/

http://improving-bpm-systems.blogspot.com/

http://www.linkedin.com/in/alexandersamarin

mailto:[email protected]

http://www.twitter.com/samarin

http://www.samarin.biz/book

Date post:	06-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

E-government reference model · 2014-11-05 3 • Digital triumphs physical: Everything becomes...

Documents