Michigans website ' ' ' is a maze of permitting information without clear explanation of the expecte

1
(No Transcript)
2
(No Transcript)
3
(No Transcript)
4

• Michigans website . . . is a maze of permitting
  information without clear explanation of the
  expected time necessary to complete each phase
  suggesting a complex, uncertain process.
  --Center for Automotive Research, Sept. 2003
• Executive Directive Dec. 8, 2003

5
MiTAPS History
6
(No Transcript)
7

• A cross-agency team was created to support the
  implementation of a state-wide enterprise
  solution in response to Governor Granholms
  12/08/03 Directive.

8

• Weekly team meetings began December, 2003
• Project headed by Department of Labor and
  Economic Growth (DLEG)
• Utilize the strengths of a pending IT solution
  identified by the Department of Environmental
  Quality
• Partnered with enfoTech to provide enterprise
  solution for MiTAPS (May 2004)

9
(No Transcript)
10
(No Transcript)
11

• Online permit applications in Michigan are taking
  a major step toward an integrated one-stop
  process.

12
MiTAPS Goals
13

• Goals
• single point of entry (one-stop)
• find permits needed/relevant
• payments accepted on-line
• link to existing web pages
• reduce complexity
• shorten processing time
• allow progress tracking
• retain legacy databases
• link to existing applications

14
(No Transcript)
15
(No Transcript)
16
MiTAPS Architecture
17
Design Goals

• Follow the paper permit
• Integrate with existing business process
  databases
• Be user friendly secure
• Allow data validation
• Accept attachments (files)
• Accept payments (CEPAS)
• Provide notification tracking
• Be configurable by program admin
• Provide financial reports

18
(No Transcript)
19
Technologies

• hijacked DEQ ePermitting app.
• contracted with enfoTech (NJ)
• .Net Framework 1.0 / 1.1
• Server 2000 2003
• IIS 5.0 / 6.0
• SQL Server 2000
• XML (configuration data files)
• XML-SOAP (web services)
• Coded in C
• .DLLs in middle tier
• IE 6.0

20
3 Types of Permits

• Level 1 (DLEG)
• click through (Wizard)
• est. cost 1,000
• Level 2
• single sign on
• must merge with another app.
• Level 3 (DEQ)
• full implementation
• est. cost 10K 200K

21
Major System Components

• Web-based UI
• User configurable (templates/help)
• Notification system (email)
• E2 engine (XML, task services)
• Data transfer storage (XML)
• Security (SSL, CROMERR)
• Attachment transfer (to file servers)
• CEPAS integration ( fees)
• Transaction manager ( reports)

22
Decision Tree Design

• Search Mechanisms (3 user types)
• 1.) free text input (no prior permit knowledge)
• 2.) browse activity type for permit (some
  application knowledge)
• 3.) locate by name /number (expert knows what
  they want)
• Scalability and Build for Changes
• number of permits
• associations / linkages can be altered
• configurable by program admin

23
(No Transcript)
24
Web Services Architecture
UDDI Registry
WSDL
Point to description
Describe Services
Register (publish WSDL)
Find Services (retrieve WSDL)
Communicates with XML-based Messaging
SOAP
Web Services Requestor
Web Services Provider
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
Architecture Overview - Deployment
SSL
SSL
SSL
DMZ
SSL
30
Login Tracking Overview
Submit Application
Prepare Applications
1. Print 2. Pay fee 3. Certify
1. Forms organized by Program/ Unit/ Type 2.
Multiple applications 3. Partially completed 4.
Attachments (map) 5. Virus scanning
Data Collection Server

• System keeps Chain-of-Custody
• Confirmation ID
• User info
• Submitting date
• Receipt date
• TCP/IP
• Processing status

31
Permit Revisions
32
MiTAPS Project Management
33
(No Transcript)
34
Guiding Principles for MiTAPS

• Sponsors goals / schedule
• Governors goals
• Available funding
• Resource availability
• Project Management Methodology
• Murphys Law

35
Two (2) Project Managers

• 1 - enterprise (Kim Gearns)
• steering committee chair.
• initial startup and design.
• find eligible permits.
• 2 - technical (Mark Breithart)
• work with DEQ staff vendor.
• system architecture design.
• permit development testing.
• assistance by Megan Voruganti and Sainey Drammeh.

36
Project Management Tools

• Charter and Feasibility
• Project Plan Schedule
• Change Control
• Status Updates
• Risk Analysis
• Financial Tracking
• Email

37
System Development Steps

• Decision tree / search engine.
• Revision tracking.
• Pay-more later.
• Attachments (now and later).
• Email templates.
• Notification options.
• Transaction Mgr (accounting).
• Consultant-owner relationship.
• Web services work-around.

38
Permit Development Steps

• Review paper permits complete questionnaire.
• Alpha Spec (web screens).
• Beta Spec (MiTAPS db).
• Final Spec (legacy db).
• Configuration options.
• Testing.
• Acceptance by DEQ staff.

39
Architecture Overview - Scalability
Setup 3 XML Configuration Files
Permit Flow
Permit Application Form Agent
e-Permitting System Engine
40
Project Meetings

• Existing business process documentation.
• Requirements gathering.
• UI design function.
• Data validation criteria.
• Database mapping.
• Testing (plan exe.).
• Monthly / bi-monthly.
• 1 5 day duration.

41
DIT Services

• Agency Services
• Project Management
• web installation hosting
• database installation hosting
• Enterprise Security
• Infrastructure Services
• server teams 10 6
• telecommunications

42
Successes

• 1st (?) multi-department application.
• multiple DEQ Divisions.
• DEQ staff bought into project.
• able to host on DEQ servers.
• live with 3 permits on 9/1/2004.
• 1st permit 9/7/2004 (Labor Day).
• MiTAPS is being used daily.
• 11 of 13 permits live (85).

43
Production Statistics

• As of 900 AM October 19, 2005
• Number of registered users 1892
• Number of applications received 696
• Number permits approved 486
• Payments
• Total 11,910
• Credit card 7,254
• DEQ-WHMD SiteID application
• 214 applications worth 10,500

44
Lessons Learned (architecture)

• not ready for web services
• software architecture
• complexity (maintenance)
• performance (page return time)
• design app for available hardware
• assimilation of existing apps
• UI design a challenge to some
• dial-up connections impractical

45
Lessons Learned (schedule)

• too aggressive a schedule
• business processes were ill-defined
• scope creep (not locked in)
• on-the-fly design changes
• DEQ resource availability
• DIT resource availability
• hardware limitations
• web services work around

46
Lessons Learned (hosting)

• resource availability (DIT)
• server capacity
• test not the same as production environment
• scheduling of patches
• coordinating setup
• coordinating testing-debugging
• architecture changes

47
Lessons Learned (misc.)

• selling idea to DEQ staff
• secure the right SMEs
• good business process documentation is rare
• reliance on another team (accounting engine)
• reliance on another system (CEPAS daily file)

48
Lessons Learned (comm.)

• one of the first problems to surface
• best to keep everyone informed
• no matter how well you explain something, someone
  will misunderstand it
• get it in writing (email)
• on-site development best

49
Lessons Learned (enterprise)

• who sits on governance committee?
• who pays for long term maintenance?
• how to allocate DIT resources?
• how to choose next permits?
• how to keep interest high?

50
Lessons Learned (DIT)

• know the players (whos who)
• get on the same page (priorities)
• communications single points of contact (email
  who?)
• encourage ownership (see it through)
• Remedy tickets (ownership)
• central PM site (news, status)
• document management needed

51
URL

• Primary MiTAPS Portal
• www.michigan.gov/mitaps
• DCO Test Site
• dlegtapsdw1.state.mi.us/epermits