eRA Migration/Developme nt Strategy Kalpesh S. Patel Ekagra Software

eRA Migration/Developme nt Strategy Kalpesh S. Patel Ekagra Software Technologies, Ltd.

Strategic Enterprise Architecture Vision – Define “Where/What is There”? Functional Architecture – End-to-end eRA architecture – High level UseCase models – Detailed blue print Migration Plan Data Architecture – – – – Database architecture Physical & Logical partitioning of data Data Security Business Intelligence Technical Architecture – Product Capabilities & Usage Guidelines – Product Integration

Tactical Issues UI Standards UI Implementation Templates Legacy Integration with J2EE Portal Architecture Security Architecture Development Tools Guidelines J2EE Usage guidelines Migration Strategy & Order

Portal Integration Architecture eRA NIH 9iAS J2EE Server - eRA JPDK Services JSP, Servlet Web Business Apps User Authentication Info NIH Request NIH Response User Authentication Info eRA Request eRA Response NIH Authentication eRA Portal eRA Authentication Security Authentication NIH Portal NIH SSO OID LDAP

Migration Strategy Objectives Migration of IMPAC-II applications to J2EE Preserve intellectual capital Unified enterprise architecture IMPAC-II migration sequence COMMONS migration sequence

Migration of IMPAC-II Apps 8 common modules Common Modules Notes Application Can be used Independently? Integrated with other applications? People Grant Folder GUM X X X X X Low Low High R&R X X CM Peer Review Summary Statement Generation Internet Assisted Review Portal X X X Volatility of Changes? SubProject ICSTORe Email Edit Customizable Electronic Registration & Workflow Checker checklist 901 Notification Architecture X X X X X X X X IMPAC-II Business Critical Receipt Council & Peer Review Program, IC Support & Council Future D GM & Finance Future ECB ICO/DEA Population Tracking Program Module Program Portal SITS ARA Grants Payment Mgmt Budget Portal Grants Management X ? ? X X X X X X X X ? X X X X X ? X X X X X X X X X X X X X X X X Portal X X

Common Modules Tightly integrated Options – Maintain two copies, J2EE & Oracle Forms – Integrate J2EE apps with legacy Forms Migrate all legacy applications to Web (JInitiator) Call Oracle Forms from J2EE Call J2EE from Oracle Forms

Migration Order Criteria – – – – Dependency Need to be web based Complexity Business priority Common Modules – Migrate at the end – Exceptional case : Migrate with the business area

Next Steps Technical integration between J2EE and Oracle Forms Migration Order & Plan

COMMONS

Observations NIH communicates with Grantee through out the life cycle (Paper) Formal communication captured by IMPAC-II COMMONS - additional communication channel Continue to support paper process COMMONS functionality overlaps with IMPAC-II

Overlap 1. Business Process SNAP continuation 2. 3. Trainee Competitive Grant Applications 4. 5. 6. Institution Profile Personal Profile Review 7. 8. Status 9. 10. 11. 12. 13. 14. 15. Administrative Population 16. Close Out Approval Process Checklists ARA processing Email notification IMPAC-II Application GM ICO TA & Payback GUM R&R Subprojects IPF Common Person Module Peer Review Summary Statements Committee Management Grant Folder ICSTORe User Administration Population Tracking CRISP Needed in IMPAC-II Customization checklist ARA processing Internal External GM Close Out FSR COMMONS Application e-SNAP X-Train c-GAP Self Service IPF Self Service PPF Internet Assisted Review Application Status View Summary Statement View NGA Account Administration Population Tracking CRISP on the Web Needed in COMMONS COMMONS will needed it Submit ARA External Submit FSR Final Progress report

Approach COMMONS – Customer facing application COMMONS as another business area of IMPAC-II Reuse common components Presentation Tier, JSP Business Process/Rules Tier Persistence, O/R mapping Layer COMMONS Data Model IMPAC-II Data Model

Alignment Close alignment by functional areas IMPAC-II & COMMONS One lead analyst per functional area - ownership One scope document per functional area Lead analyst to coordinate resolution of all policy issues

Alignment - 2 Requirements – Per functional area – Identify end-to-end business process (internal & external) – One set of business use cases & supplementary specs – Share Actors where possible and address security for them – Organize/categorize all artifacts by functional area Unifying the development

Approach assessment Advantages Build Once Resource Savings Easier maintenance Cohesiveness among IMPAC-II & COMMONS Disadvantages Slower development Resource Savings are not linear Dependency Issues Coordination Scheduling Accountability Security

Next Steps Business plans - Review – Define business processes (e.g. Trainee Appointment, Continuations, cGAP) – Task plan & Interdependency – Schedule – Develop Coordination plan – Resource Allocation Plan

Questions?