1 / 24

Reference Modeling and Lifecycle Management for e-Government Services

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.

Download Presentation

Reference Modeling and Lifecycle Management for e-Government Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Knowledge and Business Engineering Reference Modeling and Lifecycle Management for e-Government Services Knut Hinkelmann, Barbara Thönssen, Fabian Probst

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

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

  4. E-Government Today – One Solution per Municipality

  5. E-Government Today Example: ‘Announcement of Move’ Citizen Citizen Registration Deregistration Registration Deregistration Municipality A (Olten) Municipality B (Allschwil)

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

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

  8. 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)

  9. Ontological Process Modelling in OntoGov Standard UML model Semantic Model Interface Ontological Representation

  10. Service Ontology: Concepts and Instances

  11. Tracking Changes • What changed? • By whom was it changed? • When did it change? • What was the reason for?

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

  13. Dependencies between reference process models

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

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

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

  17. Reason Decision Design Decision Excerpt: Lifecycle Meta Ontology

  18. Reason Decision Design Decision Decision Reason Chains Decision reason chains are represented in the lifecycle ontology

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

  20. X Example: Change of a Law • What services are affected? • What activities are affectet?

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

  22. 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 

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

  24. 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)

More Related