The Mechanics behind EService, A Real Challenge

1
The Mechanics behind E-Service, A Real
Challenge

• October 25, 2001

2
Introduction
Ronald W Modes First bullet I suggest you
delete this one. The second bullet says it
better and is more relevant to the
presentation. Sixth bullet Replace key Federal
counties with Administration of Children and
Families, and and key county representatives.
Patty Nelson oops - I like the first
bullet second bullet - my slight rewrite Strong
relationship with FTB we know the executives, we
understand FTB culture, and we have delivered
successfully in similar capacities third bullet
- eliminate the first with (replace with colon or
dash). I do not care for vying contenders - how
about potential solution providers fifth bullet
- should this be in not of?

• John Gray, Visionary Integration Professionals
• 16 years of diverse information technology
  experience
• Extensive project management, technical
  architecture, and web development experience
• VIPs Chief Technology Officer and member of
  VIPs Executive Leadership team

3
Presentation Objectives

• Overview of e-Government (e-Service)
• Review evolution of eGovernment
• Look at the mechanics
• Key success factors
• Highlight challenges

4
Levels of sophistication
Level 1 Publishing Information
Current
Level 2 Interactions
Next!
Level 3 Transactions
Level 4 Fully integrated
5
Things that can go wrong?

• Access by the wrong people
• Data corruption
• Hacking
• Destructive
• Fraudulent
• All leading to your agency in the news!

6
When things that go right ?

• If an eGovernment system is implemented
  successfully you gain
• Efficiency
• Time saving
• Cost savings
• Your members gain
• Convenience (sitting on the phone, no lines,
  travel, available after hours, faster processing)

7
So, why do it?

• Your members want it. They can bank online,
  trade online, manage their 401k, IRA
• Sooner or later you will have to!

8
eGovernment Overview

• eGovernment is a very broad subject
• eGovernment is about evolution not invention
• Assessment methodology used to create this
  presentation, focuses on
• Symptoms
• Approach
• Solution

Symptoms
Solutions
Approach
9
Symptoms

• Review symptoms within
• Performance Make it faster
• Costs Save money
• Effectiveness Do it better
• Satisfaction Keep them happy

10
Solutions

• Typically involve a combination of
• Strategy
• Process
• People
• Technology

Process
Strategy
People
Technology
11
Approach
Understand Scope
Assess Current Environment
Investigate Best Practices
Describe the possibilities/challenges
Develop an implementation plan
12
eGovernment Scope
Agencies
Institutions

• Who
• Active members (C to G)
• Retired members (C to G)
• Other agencies (G to G)
• Institutions (B to G)
• Employers (G to G B to G)

Retirement System
Employers
Retired Members
Active Members
13
eGovernment Scope What

• C to G transaction types
• General member info (inquiry only)
• Retirement calculations (inquiry only)
• Purchase service credit (inquiry only)
• Annual Statement (inquiry only)
• Change Demographics (update)
• Change Beneficiary (update)
• Application for benefits (update)

14
eGovernment What

• G to G and B to G transactions
• Member payments and contributions (update, from
  employers)
• Member status change (update)
• Member demographic change (update)
• Payment of health benefit (retirement sys -gt HMO)
• Medical examination results from contracted 3rd
  party providers (disability info)

Internet
15
Assess Current Environment

• Current systems and processes include a mixture
  of
• Manual paper based processes
• Imaging systems
• Legacy systems ( mainframe c/s)
• Web calculators
• Web front ends with data marts

16
Levels of sophistication
Level 1 Publishing Information
Current
Level 2 Interactions
Next!
Level 3 Transactions
Level 4 Fully integrated
17
Determine best practices

• Look at what the banks, mutual funds, and
  financial institutions are doing.

18
Analyze the possibilities

• Possibilities many transactions online, but not
  all
• Change of beneficiary probably not!
• Inquiry only is significantly easier, both
  technically and policy wise.

19
Implementation - Plan

• Develop a e-Government Strategic plan
• Prioritize, organize, identify, plan
  eGovernment initiatives
• Link eGovernment initiatives to specific business
  objectives that will deliver business value
• Consider cost/benefit
• Consider consequence of error
• Consider transaction volume
• Consider reduction of user burden

20
Implementation Doing it

• Use adapted SDLC (eSDLC!)
• Pilot/proof of concept
• Start with inquiry only
• Review requirements
• Inquiry transactions
• Update transactions
• Establish environments
• Design, focus on
• Security
• Architecture
• User interface
• Define procedural changes
• Define organizational changes
• Do rigorous testing

Analyze
Design
Build
Test
Deploy
21
eGov Establish environments

• eGovernment technical architecture
• (Need separate dev, test, production)

22
Inquiry only transactions

• Security approach
• Use personal information (SSN plus DOB) over SSL
• Application architecture
• Inquiry only access to back end system. Lower
  risk.
• User Interface
• Appropriate to members needs tasks
• Intuitive avoid phone calls. No training.

23
Update transactions

• Security approach
• PIN
• Application architecture
• Update access to back end system
• Transaction control

24
Focus

• Technology
• Security
• Architecture
• User interface design
• Process change management
• People/Organizational

25
Security Complexity

• Evolution of security complexity
• Mainframe terminal access
• Client server LAN/WAN access
• eGovernment anyone with internet access!

26
Security - Architecture

• n-tier eGovernment Architecture with DMZ

27
Security - Hardware

• Hardware components
• Boarder router
• Perimeter Firewall
• Hardened Web servers

28
Security - Legacy

• Backend security
• Application security
• Database security

29
Security Considerations

• Authentication
• Authorization
• Custom software bugs lead to security
  vulnerabilities

30
Security - Authentication
As risk increases use stronger authentication
PKI
Transaction Risk
PIN SSL
Shared Secrets SSL
Public Info - No Authentication
31
Security Monitoring CIRT

• Vigilance is key
• Active monitoring and management
• Readiness CIRT (Computer Incident Response Team)

32
Architecture - Challenges

• Integration with legacy system
• Closed design
• Data integrity transaction control
• Downtime
• Exposure of frailties of legacy system
• Performance load planning peak retirement
  times?

33
Architecture Considerations

• What technologies to use
• Microsoft (ASP, )
• Sun (Java,)
• Other
• Your staff
• What skill sets does your team have
• What will you need

34
Architecture Considerations

• Be design heavy try to design and develop a
  foundation for the future.
• Restrict scope to allow rapid implementation.
  Get real experience quickly.

35
User Interface - Considerations

• Understand user needs, tasks, level of
  sophistication, browser type
• Consider business objectives
• Minimize phone calls
• Self training
• Dont just webify
• Be careful with language

36
Process Policy - Considerations

• Impact of Internet time
• Critical/sensitive updates change of
  beneficiary
• In general think about extremes technology
  typically makes the extremes more extreme!
• Electronic signature
• Get your policy approved before project starts
  for example, security.

37
People Considerations

• Cuts across organization
• Legacy dev team
• Web dev team
• Security
• Networking
• Policy setters
• Creates new roles and units
• CIRT, ISO
• Skill sets

38
Summary

• Plan Develop a e-Government Strategic plan
• Organize Organize around e-Government
• Use eSDLC Follow SDLC with extra focus on
  security, architecture/design, and user interface
• Use a pilot Do a pilot/proof-of-concept
• Use experience Use an experienced team (legacy,
  web, policy, security, )
• Evolve Expect to have, and leverage, lessons
  learned!

39
Questions?

• John Gray,
• Chief Technology Officer
• Visionary Integration Professionals (VIP)
• Jgray_at_vipincorp.com
• [phone]