240 likes | 365 Views
Knowledge and Business Engineering. Reference Modeling and Lifecycle Management for e-Government Services. Knut Hinkelmann , Barbara Thönssen, Fabian Probst. The Goal. Improve the (back-office) management of e-Gov services.
E N D
Knowledge and Business Engineering Reference Modeling and Lifecycle Management for e-Government Services Knut Hinkelmann, Barbara Thönssen, Fabian Probst
The Goal Improve the (back-office) management of e-Gov services • 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
Managers decide how to implement the law Start Start End End Process 1 Process 1 Process 2 Process 2 Process 3 Process 3 Programmers write code Citizens deal with eGov services The Problem Politicians define the law X law is revised activities have to be changed X software is to be modified eGov-services are updated
E-Government Today Example: ‘Announcement of Move’ Citizen Citizen Registration Deregistration Registration Deregistration Municipality A (Olten) Municipality B (Allschwil)
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 • …
OntoGov Framework: Service Modelling Business Modeling Component Ontology Management Modeling Environment Lifecycle Management Configuration Component Run-time Component • Create service ontologies • Modifiy ontologies • Store ontologies • Query ontologies • Trigger changes Web services interfaces to existing legacy systems
Abstraction / Specialisation R1PM_IA R2PM_IAa R2PM_IAb Abstraction / Specialisation Abstraction / Specialisation R3PM_IAa R3PM_IAb R3PM_IAa R3PM_IAb Levels of Reference Models General (e.g. state) Specific(municipality)
Ontological Process Modelling in OntoGov Standard UML model Semantic Model Interface Ontological Representation
Tracking Changes • What changed? • By whom was it changed? • When did it change? • What was the reason for?
FillInApplicationForMove FillInApplicationForMoveOLTEN R2PM_FAFM (Service Ontology) R1PM_FAFM (Service Ontology) CheckApplication CheckApplication Extension? Extension? LegalOntology Lifecycle Ontology hasReference isReasonFor DesignDecisionReplaceService LegalReason Idea: Explicit Documentation of Process Model Adaptations
R1PM_FAFM (Application for Move) R1PM_FAFM (Application for Move Olten) (1) Fill in Applicationfor Move Fill in Applicationfor Move for Olten CheckApplication CheckApplication Extension? Content OK? (2) Check ApplicationExtension Content OK? (3) Upload Docs Commit Commit Provide Informationof Application Provide Informationof Application Provide Informationof Application Provide Informationof Application Inform Applicant Inform Applicant Specialization of process model for municipality • Replace by municipality-specific activity • Delete an activity • Insert additional acitivity
Documenting changes as design decision R1PM_V1 R1PM_V2 New version (manually copied) Documentingchanges as designdecision Specialisation Specialisation‘ R2PM_V2a R2PM_V1a automatically derived copy of R2PM_V1a as draftDesign decision give hints for adaptation Lifecycle Management of (Reference) Models
Design Decisions: Making Process Knowledge explicit DD2 • 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 DD1 DD3
Reason Decision Design Decision Excerpt: Lifecycle Meta Ontology
Reason Decision Design Decision Decision Reason Chains Decision reason chains are represented in the lifecycle ontology
Documentation of Lifecycle Aspects Organ.Ontology Legal Ontology LifecycleOntology R_V R_III DD_4 R_II R_IV R_I DD_2 DD_1 DD_3
X Example: Change of a Law • What services are affected? • What activities are affectet?
Lifecycle Management: Service Consistency Organ.Ontology Legal Ontology LifecycleOntology R_V R_III _toBeChecked DD_4 R_II R_IV R_I _toBeChecked _toBeChecked DD_3 DD_2 _toBeChecked _toBeChecked DD_1
Lifecycle Management: Service Consistency Organ.Ontology Legal Ontology LifecycleOntology R_V R_III _toBeChecked DD_4 R_II R_IV R_I _toBeChecked _toBeChecked DD_3 DD_2 _toBeChecked _toBeChecked DD_1
R2PM_IAa R2PM_IAb Registration Deregistration Registration Deregistration Municipality A (Olten) Municipality B (Allschwil) R3PM_IAa R3PM_IAb R3PM_IAa R3PM_IAb Summary: Reference Model Specialisation Deregistration Registration
R2PM_IAa R2PM_IAb R3PM_IAa R3PM_IAb R3PM_IAa R3PM_IAb Outlook: One-stop E-Government User interacts with general reference model Automatic delegation to specific implementation Announcement Citizen Registration Deregistration Registration Deregistration Municipality A (Olten) Municipality B (Allschwil)