Reference Modeling and Lifecycle Management for e-Government Services

Reference Modeling and Lifecycle Management for e-Government Services

Knut Hinkelmann, Barbara Thönssen, Fabian Probst

Knowledge and Business EngineeringKnowledge and Business Engineering

Prof. Dr. Knut Hinkelmann 2

The Goal

bridging the gap between decision making and technical realisation of e-Gov services Supporting all back-office phases (design, configure,

deploy, run)

considering the lifecycle of e-Gov services Simplified implementation of uniform process Supporting the management of changes in e-Gov services

(preserve consistency, detect inconsistencies, propagate changes, implement changes)

making knowledge explicit capturing knowledge about e-Gov services tracing design decisions leading to e-Gov service models

Improve the (back-office) management of e-Gov services


X

Programmers write code

Start Process 1 Process 2 Process 3 EndStart Process 1 Process 2 Process 3 End

Managers decide how to implementthe law

Politicians define the law

Citizens deal with eGov services

law is revised

activities have to be changed

software is to be modified

eGov-services are updated

The Problem

X


E-Government Today – One Solution per Municipality


Example: ‘Announcement of Move’

DeregistrationRegistration

Deregistration Registration

Municipality A(Olten)

Municipality B(Allschwil)

Citizen

E-Government Today

Citizen


Situation

All municipalities provide nearly identical services, but … Implementation takes place individually and is

continuously repeated

Changes (e.g. in law) must be put into action for each implementation

…


Web services interfaces to existing legacy systems

Ontology ManagementModeling EnvironmentLifecycle Management

Business Modeling Component

Configuration Component

Run-time Component

I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2

I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2

I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2

I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2

I1I2

O1O2O3

WS2I1I2

O1O2O3

WS2

OntoGov Framework: Service Modelling

• Create service ontologies• Modifiy ontologies• Store ontologies• Query ontologies• Trigger changes


Levels of Reference Models

R1PM_IA

R2PM_IAa R2PM_IAb

Abstraction / Specialisation

General(e.g. state)

Specific(municipality)

R3PM_IAa

Abstraction / Specialisation Abstraction / Specialisation

R3PM_IAbR3PM_IAaR3PM_IAb


Ontological Process Modelling in OntoGov

Commit

CheckApplication

R1PM_FAFM (File an Application for Move)

eGov Form:ApplicationForMove

[ContentNOK]

[noExtension]

Key:

eGov-WS

eGov Form:Upload Documents

CheckApplicationExtension

eGov Form:ExtensionApplicationForMove PA-2-deregister

[ContentOK;]

Fill in Applicationfor Move

eGov Form:ExtensionApplicationFor

Move PA-2-register <<pre-condition>>{additional infomationis needed}

<<pre-condition>>{additional infomationis needed}

<<pre-condition>>{already filled in information isprovided }

<<pre-condition>>{already filled in information isprovided }

Notification

[Extension]

CheckApplication_AFM

eGov Form:ApplicationForMove

ProvideInformation Of

Application

Application Data /Process-ID

Sub Process

<<note>>{PAs responsible for(de)registration}

<<note>>{PAs responsible for(de)registration}

ProvideInformation Of

Application

<<note>>{citizens‘ notification}<<note>>{citizens‘ notification}

Standard UML model

Semantic Model Interface Ontological Representation


Service Ontology: Concepts and Instances


• What changed?• By whom was it

changed?• When did it change?• What was the reason

for?

Tracking Changes


Idea: Explicit Documentation of Process Model Adaptations

LegalReasonhasReferenceisReasonFor

FillInApplicationForMove

CheckApplication

Extension?

R1PM_FAFM (Service Ontology)

FillInApplicationForMoveOLTEN

CheckApplication

Extension?

R2PM_FAFM (Service Ontology)

DesignDecisionReplaceService

Lifecycle OntologyLegalOntology


Dependencies between reference process models

Reference

ReferenceProcessModel

Add Service (B)

Replace Service ( with A)

Delete Service ()

DesignDecisions

A

Derivation

states the relations betweenreference process models

B

ReferenceProcessModel‘


Specialization of process model for municipality

(1)

(2)

(3)

Fill in Applicationfor Move

CheckApplication

Extension?

R1PM_FAFM (Application for Move)

Check ApplicationExtension

Content OK?

Commit

Provide Informationof Application


Inform Applicant

Fill in Applicationfor Move for Olten

CheckApplication

R1PM_FAFM (Application for Move Olten)

Upload Docs

Content OK?

Commit



Inform Applicant(1) Replace by municipality-

specific activity(2) Delete an activity(3) Insert additional acitivity


Lifecycle Management of (Reference) Models

R1PM_V1

R2PM_V2a

Specialisation‘

automatically derived copy of R2PM_V1a as draftDesign decision give hints for adaptation

R2PM_V1a

Specialisation

Documentingchangesas designdecision

R1PM_V2

New version

(manually copied)

Documenting changes as design decision


DD1

DD2

DD3

Design Decisions (DD):

• every service must have at least one Design Decision

• every Design Decision must have at least one Reason

• every Reason must have at least one reference

• a Design Decision may become a reason for another Design Decision

Design Decisions: Making Process Knowledge explicit


Decision

Reason

Design Decision

Excerpt: Lifecycle Meta Ontology


Decision Reason Chains

Decision

DecisionDecision

Decision

Decision

Decision Decision

Reason

isReasonFor

isReasonFor

isReasonForisReasonFor

isReasonFor

isReasonFor

isReasonFor

isReasonFor

isReasonFor

Any entity in a- legal Ontology- domain Ontology- organisational Ontology

Reason

Reason

Reason

isAffectedBy

isAffectedBy

isReasonFor

Decision reason chains are represented in the lifecycle ontology

Decision

Reason

Design Decision


R_I

DD_1

R_II

DD_2

R_III

DD_3

R_IV

DD_4

R_V

Legal Ontology

Organ.Ontology

Documentation of Lifecycle Aspects

LifecycleOntology


• What services are affected?• What activities are affectet?X

Example: Change of a Law


R_I

_toBeChecked

R_II

DD_2

R_III

DD_3

R_IV

DD_4

R_V

Legal Ontology

Organ.Ontology

Lifecycle Management: Service Consistency

LifecycleOntology

_toBeChecked

DD_1 _toBeChecked

_toBeChecked

_toBeChecked


R_I

_toBeChecked

R_II

DD_2

R_III

DD_3

R_IV

DD_4

R_V

Legal Ontology

Organ.Ontology

Lifecycle Management: Service Consistency

_toBeChecked

DD_1 _toBeChecked

_toBeChecked

_toBeChecked

LifecycleOntology


Summary: Reference Model Specialisation

R2PM_IAa

R2PM_IAb

Deregistration

Registration

R3PM_IAa

RegistrationDeregistration


R3PM_IAb

R3PM_IAb

Deregistration

Registration


R3PM_IAa


DeregistrationRegistration

Announcement

Deregistration Registration



Citizen

Outlook: One-stop E-Government

R3PM_IAaR3PM_IAb

R3PM_IAb

R3PM_IAa

R2PM_IAa

R2PM_IAb

User interacts with general reference modelAutomatic delegation to specific implementation