The New Hampshire Experience

watermelonroachdaleInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

257 εμφανίσεις

The New Hampshire Experience

A Discussion on Legacy System Incremental Renewal


About New Hampshire


We are a small State, but our job is just as
big


76,000 cases across all programs


150 Eligibility Workers
-

486 cases/worker


Over $4 Million in Cash per month


Over $4.8 Million in Food Stamps per month


Over $59 million in Medicaid per month


About New HEIGHTS


31 Different Programs (100+ Variations)


Cash, Medicaid, Child Care, Food Stamps,
Emergency Assistance, Adoption Subsidy,
Foster Care


Work Programs


Case Review and Error Prone Profiling


Case Worker Dashboard & Work Programs
Dashboard

About New HEIGHTS


Integrated Client Notices


Letters


Automated Scheduling


Policy Manuals Linked to Screens


Extensive Screen Help and Training
Materials


On
-
line Reports


Benefit Issuance & Recoveries


Fair Hearings

About New HEIGHTS


New HEIGHTS Serves


1 in 5 children in New Hampshire


1 in 26 adults


1 in 14 New Hampshire Residents overall



Transfer system was on an IBM mainframe


Infrastructure costs were a consideration


NH was using an IBM Mainframe for our
Child Support System


Mainframe was being under
-
utilized


Plenty of capacity for the eligibility system


Requirement was for a GUI front end


PowerBuilder was selected as the tool


Implemented New HEIGHTS in December,
1998

Our History

Our Current Technical
Environment


IBM z/OS Mainframe


DB2 Database


PowerBuilder Front End


COBOL Back End


Netwise (Middleware)


CICS

Our Challenges


Even though New HEIGHTS is a sound,
stable, and functionally rich system, we are
facing:


Increased maintenance and new development
costs


Because of tight COBOL and PowerBuilder labor
pools


Sustained licensing and maintenance fees


For the mainframe and associated products


Constant updating of system and development
software that is no longer considered
mainstream

Our Challenges


Increased pressure to open up services to the
public using web based technologies


Dwindling knowledge share of State staff
experienced in functionality and business
processes


Budget issues to maintain the system


High level of effort to ensure front
-
end
releases are distributed timely and accurately


Tivoli


SMS

Our Approach


Recognized the need for a near
-
term
technology refresh


Gathered market data on costs


Worked with our vendor to identify high
level options, costs, and timelines for a
technology refresh


Do Nothing


Big Bang Renewal


Incremental Renewal



Less expensive in the short run


More resources to do the ongoing priorities


Harder to find resources with the skills to
maintain the older technology


Continued problems in upgrading system
and development software


Eventual need to do a full system replace

Option 1


Do Nothing

Option 2


Big Bang
Renewal


Quickest way to get to the end result


Very expensive


Resource intensive


both Contractor and
State Staff


Impacts ability to keep up with ongoing
changes


Risk of compromising reliable system
functions


Option 3


Incremental
Renewal


Less cost


Expenses are spread over time


Less burden on State staff


Reduced risk as small increments are easier
to manage


Reuse of portions of existing system
processes while other portions are
rewritten


Dual maintenance of technology


Longer time to meet the ultimate goal



Decision & First Step


Decision was the Incremental Renewal
Approach


First Step


Migrate the front end to web


Goal was to start with a pilot of a small
subsystem


Designed the look and feel of the new web
screens


Began assessing the infrastructure needs

Why we backed off . . .


Department standard for web is .Net


Not compatible with the mainframe


Would require additional middleware


High Costs for hardware and software to
support multiple environments


Maintenance costs higher


Would now need .Net programmers


OIT staff required to manage the hardware
infrastructure


DBA’s for Oracle as well as the mainframe

What We Did Next


For the next 2 years, continued to evaluate
possibilities


Business Priority became providing web
access to apply for services


Problems with the .Net solution remain


We investigated the possibility of a Java
solution


Java


universally portable


There is a mainframe version


Websphere for z/OS

Why Java Works for NH


With the Java solution:


No extra middleware needed to sync up
databases


Less infrastructure cost


Websphere cost approximately $60,000


Existing mainframe DBA’s can be utilized


Can train existing PowerBuilder resources to
code in JAVA


Our Vision


Use the mainframe to get off the
mainframe


Start with a Proof of Concept


When successful, plan for 3 phases over 6
years


Follows NH budget cycle

Proof of Concept


NH EASY (New Hampshire Electronic
Application SYstem)


Focusing on providers assisting clients to
submit applications via the web


Technology Update


Purchased Websphere


Installed, configured, and tuned


Developed software, tested and tuned


Trained PowerBuilder Resources in Java


Implemented Pilot 9/1/06


Phase 1


Convert all front
-
end screens to
web


2 year timeframe to convert all front end
screens


Anticipated cost of $4 million


Phase 2


Convert back
-
end and batch
programs to Java


Start with stand
-
alone batch programs


Gradually phase in various subsystems

Planned Phases

Planned Phases


Phase 2 (Continued)


Keep eligibility determination subsystems until
last (most complicated)


Anticipated cost of $6 million over 2


3 years


Gradually train COBOL programmers in Java


Phase 3


Convert database from DB2 to
UDB


Anticipated cost of $2 million over 1


2 years

How We Got Buy
-
in


Cost/Benefit Analysis shows clearly that
Incremental Renewal using Websphere is
the most cost effective option


Met with CIO to present findings


Met with Commissioner