E-government reference model

E-government reference model

Alexander SAMARIN

Global e-Government Forum 2014

7-8 October, 2014, Astana, Kazakhstan

http://www.unpan.org/GeGF/2014

E-government reference model v3 2

• 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

About me


• Context

• E-government reference model

• Views

© A. Samarin 2014

Agenda


• 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

Introduction


• 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

Complexity of e-government


• 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

Digital age (1)


• 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

Digital age (2)


• 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

Digital age (3)


• Context


• Views

© A. Samarin 2014

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

© A. Samarin 2014

WHY e-Gov reference model (1)

Technical architecture

Dataarchitecture

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 %


• 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

© A. Samarin 2014


BU1 BU2 BU3

Standardsolution

Level of computerisation

IT department

E-government reference model v3 12© 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


• 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



• 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

HOW does e-Gov reference model work


• 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

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

© A. Samarin 2014

EA explained (2)


EA views: projects, solutions, capabilities and platforms


EA views: time-span


EA views: business zones vs time span


EA views: architectural domains vs business zones


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

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

© A. Samarin 2014

EA group structure by main roles

• Domain group

– business architects

– application architects

– information architects

– security architects

– infrastructure architects

• Vertical group

– healthcare

– smart-cities

– tourism

– …


• 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

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


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

© A. Samarin 2014

WHAT RM - many views (1)


• 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

WHAT RM - many views (2)


• Context


• Views

© A. Samarin 2014

Agenda


• Partner and governmental-entity interaction view

• Partner view



• Paperless or digital work view


© A. Samarin 2014

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)

© A. Samarin 2014


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

partner and the government

Government

Time© A. Samarin 2014

1 2 3 4


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)

© A. Samarin 2014


Process

+ + + +

E-gov coordinates partner’s interactions with the government

Government

• control flow (black solid lines)



Time

1 2 3 4

Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

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

1

2 3

4

5

6

7

8

© A. Samarin 2014


Process --

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

Government

Ministry B

Time

1

2

3

45

2

2a 2cx

2b



Methodologies:• data modelling• electronic document

(ED) exchange+ BPM discipline+ process modelling

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

© A. Samarin 2014

… …


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



© A. Samarin 2014



• Partner view




© A. Samarin 2014

VIEWS (1)


Partner’s view

© A. Samarin 2014



• Partner view




© A. Samarin 2014

VIEWS (1)

E-government reference model v3

Partners

Existing application

Coordination and integration backbone

e-Government

© A. Samarin 2014 39

E-gov application architecture view


e-gov service



Government

Technologies:• BPM suite• SOA orientation• ECM

e-gov service

e-gov service


Partners



E-gov traditional application architecture

Portal



Government

Appl

icati

on

Appl

icati

on

Appl

icati

on


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



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


Steps of evolution in application architecture

Introductory architecture

Target architecture

E-Social system architecture

Portal-centric architecture

Transitional architecture



• Partner view




© A. Samarin 2014

VIEWS (1)


Integration process instead of N-to-N connectivity


• Business (processing) envelope

• Delivery (addressing) envelope

• Transportation (routing) envelope

© A. Samarin 2014

Use of many security envelopes



• Partner view




© A. Samarin 2014

VIEWS (1)


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


• 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

© A. Samarin 2014

Platform-based architecture (2)

A2A1

A3Platform

S2…S

1S3

Functionality

Delivery by solutions Delivery by applications

Scope


• 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

Overall platform governance


Advantages of the corporate ECM platform

Dev env 1 Dev env 2

Development environment 3Generic web-

development platforms

DEVELOPMENT

Functionality

Basic features of a common ECM platform

Advanced features of a common ECM platform

Company-specific features

Process-centric integration

• 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

© A. Samarin 2014 E-government reference model v3 54

Financial estimations

N apps.

$$

N≈8

Without common platform

With common platform


Solutions vs components



• Partner view




© A. Samarin 2014

VIEWS (1)


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

© A. Samarin 2014

Ladder of maturity meta-pattern


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

© A. Samarin 2014

Component-oriented design



• Partner view




© A. Samarin 2014

VIEWS (1)


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

© A. Samarin 2014

Architecture-based agile project management



• Partner view




© A. Samarin 2014

VIEWS (1)


Structural dependencies between various artefacts


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

© A. Samarin 2014

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)

© A. Samarin 2014

Implications and example



• Partner view




© A. Samarin 2014

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.

© A. Samarin 2014

Architecture-based procurement



© A. Samarin 2014

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)

© A. Samarin 2014

Enterprise as a system of processes


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

© A. Samarin 2014

Process fragments – patterns

SI

PAR

SI

IPS

Click for animation

© A. Samarin 2014 E-government reference model v3 70

SI animated diagram

Click for animation


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

© A. Samarin 2014

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)


• 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

CLuster Of Processes (CLOP)


Enabler group, supporting group and customer group of clusters


Implicit coordination between CLOPs (1)


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

© A. Samarin 2014

Make coordination between CLOPs explicit (1)


Functional view at a system of processes (1)


Dynamic provision of the access


Extra relationships between activities

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

Extra relationships between activities (3)

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

BPM and information security: Extra relationships between activities

(4)


ERM reference model


• 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

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© A. Samarin 2014

Typical problems with legacy software


• 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

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

© A. Samarin 2014

How to carry out the modernisation


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



Coordination

BO1persistence service

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

© A. Samarin 2014

How to coordinate?


• By processes

• By events (EPN)

• By rules, work-load, etc.

© A. Samarin 2014

Several coordination techniques may be used together


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

coordination of services


• 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

Co-existence of a legacy application and a process solution


• 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

© A. Samarin 2014

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”

© A. Samarin 2014

Process-centric solutionsAssemble via processes (2)



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


NEEDS

RESULTS

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

analysis Treatment Recovery

PartnerPartnerPartnerPartnerPartners

Coordination

© A. Samarin 2014

Healthcare reference model (1)


Healthcare Platform

acquisition channels

disseminationchannels

Specialised Apps.

Specialised Apps.

Specialised Apps.

Web access

Mobile access

PatientCRM

Web acces

s

Mobile access

DoctorCRM

Access

EDI

Enrichment

RBACKnowledge Mgmt. Procedures

BPMECM

StorageECM

Coordination

BPMsBI

PartnerPartnerPartnerPartnerPartners

Healthcare reference model (2)

© A. Samarin 2014


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

© A. Samarin 2014


• 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

ANNEX Smart-city implementation reference model


• QUESTIONS?

• EKSALANSI website: http://www.eksalansi.org

• 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.eksalansi.org/



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

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

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

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

mailto:[email protected]

http://www.twitter.com/samarin

http://www.samarin.biz/book

E-government reference model

Technology

Transcript of E-government reference model