eRA eRA Migration/Development Migration/Development

StrategyStrategy

Kalpesh S. PatelKalpesh S. PatelEkagra Software Technologies, Ltd.Ekagra Software Technologies, Ltd.

Strategic Enterprise ArchitectureStrategic Enterprise Architecture• VisionVision

– Define “Where/What is There”?Define “Where/What is There”?• Functional ArchitectureFunctional Architecture

– End-to-end eRA architectureEnd-to-end eRA architecture– High level UseCase modelsHigh level UseCase models– Detailed blue printDetailed blue print

• Migration PlanMigration Plan• Data ArchitectureData Architecture

– Database architectureDatabase architecture– Physical & Logical partitioning of dataPhysical & Logical partitioning of data– Data SecurityData Security– Business IntelligenceBusiness Intelligence

• Technical ArchitectureTechnical Architecture– Product Capabilities & Usage GuidelinesProduct Capabilities & Usage Guidelines– Product IntegrationProduct Integration

Tactical IssuesTactical Issues

• UI StandardsUI Standards• UI Implementation TemplatesUI Implementation Templates• Legacy Integration with J2EELegacy Integration with J2EE• Portal ArchitecturePortal Architecture• Security ArchitectureSecurity Architecture• Development Tools GuidelinesDevelopment Tools Guidelines• J2EE Usage guidelinesJ2EE Usage guidelines• Migration Strategy & OrderMigration Strategy & Order

eRAPortal

Security Authentication

NIH Portal

OIDLDAP

9iAS J2EE Server - eRA

Business Apps Web S

ervices

JPDK

JSP, Servlet

eRA Authentication

NIH Authentication

User Authentication Info+NIH Request + NIH Response

User Authentication Info+ eRA Request + eRA Response

Portal Integration ArchitectureeRA

NIH

NIH SSO

Migration StrategyMigration StrategyObjectivesObjectives

• Migration of IMPAC-II applications to J2EEMigration of IMPAC-II applications to J2EE• Preserve intellectual capitalPreserve intellectual capital• Unified enterprise architecture Unified enterprise architecture • IMPAC-II migration sequenceIMPAC-II migration sequence• COMMONS migration sequenceCOMMONS migration sequence

Migration of IMPAC-II AppsMigration of IMPAC-II Apps

8+ common modules8+ common modulesCommon Modules

Notes Application PeopleGrant Folder GUM SubProject ICSTORe

Edit Checker

Customizable checklist

Electronic 901

Email Registration & Notification

Workflow Architecture Portal

Can be used Independently? X X X X X X

Integrated with other applications? X X X X X X X X

Volatility of Changes? Low Low High

IMPAC-II

Business CriticalReceipt R&R X X X ? ?

Council & Peer Review CM XPeer Review X X X X X X X X X X

Summary Statement GenerationInternet Assisted Review XPortal

Program, IC Support & Council ECB

ICO/DEA X X X ? X X X XPopulation Tracking

Future Program Module X X X X ? X X XD Program Portal

SITSARA

GM & Finance Grants Payment MgmtFuture Budget Portal

Grants Management X X X X X X X

Common ModulesCommon Modules

• Tightly integratedTightly integrated• OptionsOptions

– Maintain two copies, J2EE & Oracle FormsMaintain two copies, J2EE & Oracle Forms– Integrate J2EE apps with legacy FormsIntegrate J2EE apps with legacy Forms

• Migrate all legacy applications to Web (JInitiator)Migrate all legacy applications to Web (JInitiator)• Call Oracle Forms from J2EECall Oracle Forms from J2EE• Call J2EE from Oracle FormsCall J2EE from Oracle Forms

Migration OrderMigration Order

• CriteriaCriteria– DependencyDependency– Need to be web basedNeed to be web based– ComplexityComplexity– Business priorityBusiness priority

• Common ModulesCommon Modules– Migrate at the endMigrate at the end– Exceptional case : Migrate with the business areaExceptional case : Migrate with the business area

Next StepsNext Steps

• Technical integration between J2EE and Oracle Technical integration between J2EE and Oracle FormsForms

• Migration Order & PlanMigration Order & Plan

COMMONSCOMMONS

ObservationsObservations

• NIH communicates with Grantee through out NIH communicates with Grantee through out the life cycle (Paper)the life cycle (Paper)

• Formal communication captured by IMPAC-IIFormal communication captured by IMPAC-II• COMMONS - additional communication COMMONS - additional communication

channelchannel• Continue to support paper processContinue to support paper process• COMMONS functionality overlaps with COMMONS functionality overlaps with

IMPAC-IIIMPAC-II

Business Process IMPAC-II Application COMMONS Application 1. SNAP continuation GM

ICO e-SNAP

2. Trainee TA & Payback X-Train 3. Competitive Grant Applications GUM

R&R Subprojects

c-GAP

4. Institution Profile IPF Self Service IPF 5. Personal Profile Common Person Module Self Service PPF 6. Review Peer Review

Summary Statements Internet Assisted Review

7. Committee Management 8. Status Grant Folder

ICSTORe Application Status View Summary Statement View NGA

9. Administrative User Administration Account Administration 10. Population Population Tracking Population Tracking 11. CRISP+ CRISP on the Web 12. Approval Process Needed in IMPAC-II Needed in COMMONS 13. Checklists Customization checklist COMMONS will needed it 14. ARA processing ARA processing Submit ARA 15. Email notification Internal

External External

16. Close Out GM Close Out FSR

Submit FSR Final Progress report

OverlapOverlap

ApproachApproach

• COMMONS – Customer facing applicationCOMMONS – Customer facing application• COMMONS as another business area of IMPAC-IICOMMONS as another business area of IMPAC-II• Reuse common componentsReuse common components

COMMONS Data Model

Persistence, O/R mapping Layer

Business Process/Rules Tier

Presentation Tier, JSP

IMPAC-II Data Model

AlignmentAlignment

• Close alignment by functional areas - IMPAC-II Close alignment by functional areas - IMPAC-II & COMMONS& COMMONS

• One lead analyst per functional area - ownershipOne lead analyst per functional area - ownership• One scope document per functional areaOne scope document per functional area• Lead analyst to coordinate resolution of all Lead analyst to coordinate resolution of all

policy issuespolicy issues

Alignment - 2Alignment - 2

• Requirements – Per functional areaRequirements – Per functional area– Identify end-to-end business process (internal & Identify end-to-end business process (internal &

external)external)– One set of business use cases & supplementary specsOne set of business use cases & supplementary specs– Share Actors where possible and address security for Share Actors where possible and address security for

themthem– Organize/categorize all artifacts by functional areaOrganize/categorize all artifacts by functional area

• Unifying the developmentUnifying the development

Approach assessmentApproach assessment

AdvantagesAdvantages• Build OnceBuild Once• Resource SavingsResource Savings• Easier maintenanceEasier maintenance• Cohesiveness among Cohesiveness among

IMPAC-II & COMMONSIMPAC-II & COMMONS

DisadvantagesDisadvantages• Slower developmentSlower development• Resource Savings are not Resource Savings are not

linearlinear• DependencyDependency

Issues• Coordination• Scheduling• Accountability• Security

Next StepsNext Steps

• Business plans - ReviewBusiness plans - Review– Define business processes (e.g. Trainee Define business processes (e.g. Trainee

Appointment, Continuations, cGAP)Appointment, Continuations, cGAP)– Task plan & InterdependencyTask plan & Interdependency– ScheduleSchedule– Develop Coordination planDevelop Coordination plan– Resource Allocation PlanResource Allocation Plan

Questions?Questions?