# Presentation: 935057

## Payment Application    Modernization (PAM)

- Austin Regional Financial Center
- Agency Forum
- August 15-16, 2007
- Jesse Chavez

## Agenda

- Background
- Development Approach
- Status of Project
- Recent and Future Development Activities
- Platform/Environment Dates
- Production Release Schedule
- Benefits & Goals of PAM
- Impact to Agencies

**Notes:**
Highlights of what we will cover today include the background of the project, a status of the project today, upcoming activities and expected release dates. Jesse will then discuss the benefits of the application and the impact it will have on the agencies. 

## Background

- The PAM project was initiated to replace 30+ applications currently used to process payment requests
- Because a substantial percentage of the payment functionality is common to all payment types, development of a single, modular application is the appropriate course of action
- Develop and deploy a robust, standardized application (Payment Automation Manager) employing new technologies where appropriate
- Meet all functional and nonfunctional business requirements set forth by FMS users and business owners

**Notes:**
The project began as a result of Y2K efforts during which FMS realized that they had many systems with generally the same functionality that would benefit from updating

Back in early 2004, a Request for Information was released so the early members of the project team could hear first hand how industry leaders and service providers would propose to solve the issues and questions raised regarding the payment needs of FMS

The purpose of the RFI was to obtain industry information as to likely technical solutions that would address the business problems presented by the current payment environment.  The Review Team concluded that the PAM goals and FMS’s objectives could best be met with an integrated multi-tiered architecture.  The recommended architecture would leverage FMS’s current hardware and software at the database level while exploiting new, more flexible technologies that maximize the use of commercial software products.  Additionally, JAVA/J2EE custom code would provide functionality not included in the commercial software products.

The system we develop will replace 30+ systems currently in use today that were written back in the 70’s in programming languages (COBOL and Assembler) that are now outdated

The systems currently process a billion payments annually with a value of 1.5 trillion dollars- as you can see it has a very broad and significant impact. RO is responsible for issuing NTDO payments disbursed by the 4 RFCs.

Broad stakeholder community alone which consists of:
200+ Federal Program Agencies (FPAs), such as Social Security Administration, IRS, Veterans Administration, Federal payroll, vendor payments, and a host of others
Millions of benefits recipients
RFC’s, OPM, SS Benefits, VA, RRB, Tax refunds and others (Fed Salary, vendor, and Misc. pymts)

Working with SPS and GWA to accommodate changes required for the agencies

The system will meet the needs of nearly 230 different agencies and will produce payments in the forms of  checks, wire transfers, and ACH deposits

The ultimate goal of the project is to ensure payments are made right the first time and on time, every time

## Development Approach

- Take a phased approach to the development and delivery
- Focus on Knowledge Transfer
- Development by FMS, FRB, and Geniant
- Development at Kansas City and Dallas FRBs
- Proof of Concept (Elaboration)
- Paired Programming
- On-site and Remote
- UP / Iterative Process

**Notes:**
PAM will take an iterative approach to the development and delivery.  This is very different from what the government and FMS is accustomed to.  We are used to a waterfall approach where we develop and implement the system as a whole.

Knowledge Transfer is a key component of the development effort. FMS/FRB and Geniant staff are working together to determine the best architecture for the system; Development work occurs at the KC and Dallas reserve banks in the team rooms; Team members meet/conference daily to discuss progress, identify problems, and check status

Geniant is accountable for thorough knowledge transfer to FMS staff, the end goal is for Geniant to withdraw from the project and for FMS to be able to support, modify, and update the final PAM system independently.

Developers will work in pairs to ensure FMS staff has adequate exposure, training, and experience for future self sufficiency. FMS will still work with the agencies as they do today

The team selected the UP for PAM because they saw significant benefits in being able to focus on and “drive out” the riskiest aspects of the project as early in the development phase as possible.  This is precisely the focus of the Elaboration Phase

Take an iterative approach using the Unified Process (UP) development process 
The UP emphasizes the following: 
Iterative development
Building and proving out an application’s architecture early
Addressing high risk and high value components first
Continuously engaging customers for evaluation and feedback (working with SSA and OPM—continuously meeting with agencies and interfacing applications)
Continuously testing for quality throughout the development lifecycle

Agile development is a set of beliefs that are captured in four key aspects, which value: 
Interactions with individuals (over process and tools); Working software (over comprehensive documentation).; Customer collaboration (over contract negotiation); Responding to change (over following a plan).  

## Status of Project Today

- Elaboration Phase - Demonstrate that a working subset of the application will run on the proposed architecture
- Integration of Components / Technologies
- Throughput Measurement
- Security
- Techniques and Methods
- Baseline for Production Releases

**Notes:**
Within the Elaboration Phase, developers will produce a thin thread, or slice, of the application.  The intent is to ensure that the application and tools selected for use are appropriate and produce the expected results when integrated and deployed.

This approach minimizes the risk of failure later in the project lifecycle when it becomes more costly to correct.  Treasury ultimately will benefit from this initial 6-8 month Elaboration effort as it will demonstrate through hands-on development and testing that the selected tools and technologies will indeed provide the functionality and performance that will meet Treasury’s business requirements.

Throughput is important b/c we want to make sure the application can handle the current volume.

Want to ensure the information you, the agencies, send will be secure. 
We will be certifying the system as new functionality is implemented (iteratively); in other words, when you payment type is implemented.

Not a production release

## Status of Project Today

- Production Release 1
- SSI ACH only
- Single RFC view
- Restart/Recovery work-arounds
- Minimal User Interface (UI) for RFC’s

**Notes:**
Re-scoped Production Release 1.0 (because of schedule delays associated with the original ETL tool)

Obtained SSA commitment to participate in PAM Production Releases 1.0 and 2.0. Originally Release 1.0 was to include both ACH and Check. 

Will affect the KC RFC only (and Philadelphia for contingency) and contingency/back-up plans will be available. 

Work on the GUI is beginning during this iteration but it is expected that minimal UI will be available for the first Production Release. This UI is for the RFCs only. Because only 1 payment type will be included in Release 1.0, not much is even needed.

## Next Steps for Development

- Continue Elaboration
- Expect completion at end of April
- Complete Prototype in 4 Iterations
- Performance Testing
- 4 million records per hour
- Construction Phase
- April through mid-August 2007
- Overlaps with Elaboration Phase
- Evaluate roll-out schedule in light of business drivers
- Train 4 additional FMS developers

**Notes:**
Target the completion of Elaboration at the end of April/beginning of May; currently working in 4th of 4 iterations.

Jesse will discuss benefits more, but one aspect of PAM is that files will be free flowing. Performance Testing is important b/c we want to ensure the application can handle the files coming in; 4 million records per hour surpasses any requirements known today

You’ll notice that the Construction Phase began in April as well; Some Elaboration and Construction activities will occur in parallel

Will work to ensure that all functionality that affects other systems will be worked into the timeline. (For example, functionality needed for GWA will be incorporated by mid-2008.) Also, we wouldn’t want to convert IRS during the middle of tax season. 

4 new FMS developers will join the project in the August timeframe; they will complete a set of prerequisite courses before the hands-on experience and training in the team room. 

## Platform/Environment Dates

- _Quality Assurance_ (QA) – March 1, 2007
- Completed February 26, 2007
- _Permanent Development_ – May 1, 2007
- Transition from FRB hosted development to FMS hosted development
- _User Acceptance_ (UA) – June 1, 2007
- _Production_ – August 1, 2007
- _Disaster Recovery_ (DR) – November 1, 2007

**Notes:**
Slide depicts some dates that could impact our schedule. 

Note the DR environment. Even though it will be available in November for Release 1.0, we will still have the Legacy applications to fall back on. Legacy will be around until PAM is fully converted and is successful. 

Queues and channels needed to facilitate communication among the components and tiers within the QA environment are still being set up. The PAM team is also planning to share the QA environment for both UA and QA, since UA will not be available until June 1.

The Federal Reserve Banks have built the initial development environments and the developers will have to move their work through several test environments before the code would be considered “production ready”

Environments are currently being built in the FMS infrastructure that will eventually be the location for the system and the storage of all code

## PAM Production Release Schedule

- PAM Release 1 – November 2007
- PAM Release 2 – April-June 2008
- PAM Release 3 – 4 to 6 months after Release 2
- Will include TOP offset functionality & holds

**Notes:**
Despite computing environment and DS delays in 2006, the project team had worked to outline a plan and associated strategies for achieving a FY2007 production release.  

The MSG agreed during its January 2007 meeting that the proposed schedule was overly optimistic and compromised knowledge transfer objectives.  The team was asked to re-cast the schedule to include reinitiating knowledge transfer activities in the first quarter.  

The resulting schedule is tight but continues to target a November 2007 Production Release 1.0 implementation for December SSI ACH payments. Processing will begin mid-November.

OPM has been targeted for the 2nd Release. 

## PAM Processing Flow:

## Benefits & Goals of PAM

- Standardized Payment System
- Use of new technologies and methodologies
- 85% decrease in manual processing
- Real time access to payment status information
- Enhanced Disaster Recovery
- Payments made through the system are done right the first time: on time, every time

## Agency’s View of PAM

- Trace number and check numbers assigned in the order received
- Internal process automation
- Reduces workload
- Increases accuracy
- Moves payments thru the system quicker
- Increases FMS’s visibility into processing
- Response to inquiries
- Improves ability to recover from outages
- System more flexible to changing needs

**Notes:**
Agency can derive check number based on check range and position in file
Things move faster; this will be a culture change, because there is currently a delay for all of the matching to take place.  File will immediately be processed when the file is certifying, this will create a much shorter timeframe

## Impact on Agencies

- Free Flowing Files
- Brownout / Blackout Procedures
- Timeline For Rollout
- Service Level Agreement (SLA)

**Notes:**
You (the agencies) are not going to have to change anything technically; you will have to change your thinking though.  You send a file and certify it, you will no longer be able to change files after certifying.  This will be a culture change, because there is currently a delay for all of the matching to take place.  Immediately will be processed when the file is certifying, this will create a much shorter timeframe.

## Impact on Agencies

- Review Payment Type Requirements (Benefit Agencies)
- Testing
- Notification of Planned Agency Changes
- Enhancements
- New Systems
- Legislation Changes

## Impact on Agencies

- PAM Standard Agency Format
- Status of Format Development
- Format Structure
- Target Completion Date for Format
- Posting of Standard Format to FMS Website
- GWA TAS/BETC Requirements

## Impact on Agencies

- 100 unique TAS / BETC within certification per payment
- PAM will not stop payments based on TAS / BETC validation
- MOU from agencies for deriving TAS / BETCs
- One for One (ALC / BETC)

## Impact on Agencies

- Type “A” Payments
- Agencies will define TAS/BETC combinations for:
- Default rules
- Classification translations
- SAM will validate TAS/BETC Combination
- Agencies are expected to transition to TAS/BETC reporting during October 2006 through August 2009.
- Work with RFC Staffs

## RFC/Agency Roles

- User Acceptance Testing (UAT)
- Testing and Training
- Business Requirements
- Document “As Is”
- Subject Matter Experts
- Workgroup Representation

## Contacts

- Jesse Chavez, FMS Program Analyst
- 816-414-2108
- Julie Jensen, FMS Program Analyst
- 816-414-2112
**    ****Any**** ****Questions?**