SOA in ePlanning : A Case Study

1. SOA in ePlanning: A Case Study Rick LoveMayo County CouncilIreland

2. Overview • About Mayo County Council • Evolution of SOA in Mayo’s Planning Service • Leveraging SOA for ePlanning • Role of SOA in a National Planning Portal • Q & A?

3. Mayo County Council • Local government for County Mayo, Ireland • Delivers a variety of services including: • Planning and Development • Housing • Water • Roads

4. The Planning Process GeoMedia CRM iPlan DocuWare Each step in the process needs a different support system.

5. Evolution of Mayo’s Planning System • 1990’s Tracking System (iPlan) • 2000 GIS Spatial Analysis (PlanReg) • 2002 Planning Info on Mayococo.ie • 2003 Document Management (DocuWare) • 2005 Water/Sewer Connections (bespoke) • 2009 Online Planning Submissions and Applications (Mayococo.ie and MyMayo.ie)

6. Legacy Systems “Low Tech” SOA • SOA achieved via • Popup windows • Querystring links • JavaScript data passes • Shared databases

7. First Steps… • Planning permission is the prerequisite for accessing other services. • For example, you cannot connect to public water/sewer unless you have received Planning permission.

8. Generic Lookup • We created a generic lookup tool in Classic ASP which could be used as a popup window from other systems. • Very basic. 3 web pages had to be deployed and customised for each system, but used the same SQL stored procedures to minimise changes from upgrades.

9. Generic Lookup • Staff click on link in Sewer connection system to access the lookup tool. If a valid permission is on record, one click updates the parent system.

10. Generic Lookup • Staff click on link in Sewer connection system to access the lookup tool. If a valid permission is on record, one click updates the parent system.

11. Newer Systems Linked with Webservices • Webservices used like train couplers • Link any two items together with shared standard • Allows either system to change so long as it can use its half of the webservice

12. How do they interact?

13. Webservices Key to ePlanning • Online Submissions (aka Objections) • Follow a number of rules— • Only accepted during the first 4 weeks after an application has been received –or— • During a 2 week window after Further Information has been received –or— • During a 3 week window after Further Information has been received, if there was an EIS

14. Webservices Key to ePlanning • We initially wanted to add a note to our online Planning info to indicate whether or not a person could make a Submission (e.g. was the application in or out of the Submission window) • Built a simple webservice that accepts the Planning Reference Number and returns a bit of text indicating yes/no and the final day on which Submissions can be accepted (VB.NET 2.0 accessing SQL).

15. Newer Systems Linked with Webservices • We use VB.NET 2.0 to create webservices • Various consumers include VB.NET and simple JavaScript

16. Webservices Key to ePlanning • When we began building our Online Submissions system, we needed to ensure that staff didn’t process Submissions received after the deadline. • So, we modified our existing webservice slightly (adding a numeric flag to accompany the text) and reused it on our staff processing screen.

17. Webservices Key to ePlanning • The same webservice highlights timing issues to staff.

18. Online Applications • Our online applications system was similarly built by adding a single staff processing screen to the existing mix. • When staff approve an incoming application, the system updates all of the existing systems at once.

19. ePlanning Modules Current Status Each system passes its data via a secure method and stores only what it needs to function to avoid duplication.

20. Planning in Ireland • Planning authorities in Ireland • 34 city and county councils • Approx 50 smaller Planning authorities (including 3 Town Councils in Mayo)

21. Planning in Ireland • 3+ Planning tracking systems in use (iPlan, APAS, Odyssey) • At least 5 different document management systems in use • At least 3 different GIS systems in use • How do we move forward together?

22. A National Portal • Irish local authorities are in the early stages of designing a shared national Planning portal where customers can submit Applications, Submissions, etc. to any Planning authority in Ireland and monitor what they’ve already done.

23. A National Portal • Requirements: • Portal would do as little as possible to minimise development & maintenance • All processing and most data storage to be done in each Planning authority to allow early adopters to move quickly and continue work already in progress • In the future, a generic system would be available to allow smaller authorities to offer these services online

24. Division of Labour

25. How to link them? Planning Authority National PlanningPortal Planning Authority Customer

26. How to link them? Planning Authority National PlanningPortal Planning Authority Web Services will be used to send/receive query data to be displayed to customers on the portal.

27. Secure Handoffs and Webservices • Within the national portal, customer would choose the Planning authority they want to do business with. • They would then download or complete forms online (forms would live on the Planning authority’s own websites, but would be available seamlessly via link, iFrame or new windows)

28. Secure Handoffs and Webservices Planning Authority Customers will use secure https connections to upload data and complete transactions directly with Planning Authorities. Customer

29. Secure Handoffs and Webservices • Customer transaction summaries would be stored in the national portal, but details of each transaction would be available from the Planning authorities, as needed, via webservices. • Documents will be stored only at local authorities.

30. Advantages • Most maintenance/support is in dealing with customers (this effort is shared) • Each Planning authority can move at its own pace (or wait for the generic system) • Reduced overall costs for Planning authorities • If some sites are offline, the national portal is unaffected • Customers need only one portal and set of credentials • One-stop-shop for customers with tracking similar to online banking • Improved customer service

31. Considerations • Distributed systems must be in fixed locations (ex. urls cannot move, webservice locations cannot move) • Significant changes to the overall system will require cooperation/coordination of all parties and could result in down-time if not carefully managed.

32. Conclusions • SOA allows systems to interact easily with little formal integration between them. • Systems can be linked together in a number of ways: • Links • Generic windows with shared SQL • RSS • Webservices

33. Conclusions • SOA allows needed resources to be shared, allowing each system to specialise • Webservices are especially well suited to connect different services because they act as generic links between their consumer and underlying back-end systems • Well planned SOA between agencies can reduce overall costs by sharing services

34. Q & A Thanks! For more information, contact: Rick Love rlove@mayococo.ie Mayo County Council Ireland Thanks to: David Reddington, Alex Fleming, Pat Carroll of Mayo County Council.