eRA Migration/Development Strategy

430 views

Published on

Published in: Technology
  • Be the first to comment

eRA Migration/Development Strategy

  1. 1. eRA Migration/Development Strategy Kalpesh S. Patel Ekagra Software Technologies, Ltd.
  2. 2. Strategic Enterprise Architecture <ul><li>Vision </li></ul><ul><ul><li>Define “Where/What is There”? </li></ul></ul><ul><li>Functional Architecture </li></ul><ul><ul><li>End-to-end eRA architecture </li></ul></ul><ul><ul><li>High level UseCase models </li></ul></ul><ul><ul><li>Detailed blue print </li></ul></ul><ul><li>Migration Plan </li></ul><ul><li>Data Architecture </li></ul><ul><ul><li>Database architecture </li></ul></ul><ul><ul><li>Physical & Logical partitioning of data </li></ul></ul><ul><ul><li>Data Security </li></ul></ul><ul><ul><li>Business Intelligence </li></ul></ul><ul><li>Technical Architecture </li></ul><ul><ul><li>Product Capabilities & Usage Guidelines </li></ul></ul><ul><ul><li>Product Integration </li></ul></ul>
  3. 3. Tactical Issues <ul><li>UI Standards </li></ul><ul><li>UI Implementation Templates </li></ul><ul><li>Legacy Integration with J2EE </li></ul><ul><li>Portal Architecture </li></ul><ul><li>Security Architecture </li></ul><ul><li>Development Tools Guidelines </li></ul><ul><li>J2EE Usage guidelines </li></ul><ul><li>Migration Strategy & Order </li></ul>
  4. 4. eRA Portal Security Authentication NIH Portal Portal Integration Architecture eRA NIH OID LDAP 9iAS J2EE Server - eRA Business Apps Web Services JPDK JSP, Servlet eRA Authentication NIH Authentication User Authentication Info +NIH Request + NIH Response User Authentication Info + eRA Request + eRA Response NIH SSO
  5. 5. Migration Strategy Objectives <ul><li>Migration of IMPAC-II applications to J2EE </li></ul><ul><li>Preserve intellectual capital </li></ul><ul><li>Unified enterprise architecture </li></ul><ul><li>IMPAC-II migration sequence </li></ul><ul><li>COMMONS migration sequence </li></ul>
  6. 6. Migration of IMPAC-II Apps <ul><li>8+ common modules </li></ul>
  7. 7. Common Modules <ul><li>Tightly integrated </li></ul><ul><li>Options </li></ul><ul><ul><li>Maintain two copies, J2EE & Oracle Forms </li></ul></ul><ul><ul><li>Integrate J2EE apps with legacy Forms </li></ul></ul><ul><ul><ul><li>Migrate all legacy applications to Web (JInitiator) </li></ul></ul></ul><ul><ul><ul><li>Call Oracle Forms from J2EE </li></ul></ul></ul><ul><ul><ul><li>Call J2EE from Oracle Forms </li></ul></ul></ul>
  8. 8. Migration Order <ul><li>Criteria </li></ul><ul><ul><li>Dependency </li></ul></ul><ul><ul><li>Need to be web based </li></ul></ul><ul><ul><li>Complexity </li></ul></ul><ul><ul><li>Business priority </li></ul></ul><ul><li>Common Modules </li></ul><ul><ul><li>Migrate at the end </li></ul></ul><ul><ul><li>Exceptional case : Migrate with the business area </li></ul></ul>
  9. 9. Next Steps <ul><li>Technical integration between J2EE and Oracle Forms </li></ul><ul><li>Migration Order & Plan </li></ul>
  10. 10. COMMONS
  11. 11. Observations <ul><li>NIH communicates with Grantee through out the life cycle (Paper) </li></ul><ul><li>Formal communication captured by IMPAC-II </li></ul><ul><li>COMMONS - additional communication channel </li></ul><ul><li>Continue to support paper process </li></ul><ul><li>COMMONS functionality overlaps with IMPAC-II </li></ul>
  12. 12. Overlap
  13. 13. Approach <ul><li>COMMONS – Customer facing application </li></ul><ul><li>COMMONS as another business area of IMPAC-II </li></ul><ul><li>Reuse common components </li></ul>
  14. 14. Alignment <ul><li>Close alignment by functional areas - IMPAC-II & COMMONS </li></ul><ul><li>One lead analyst per functional area - ownership </li></ul><ul><li>One scope document per functional area </li></ul><ul><li>Lead analyst to coordinate resolution of all policy issues </li></ul>
  15. 15. Alignment - 2 <ul><li>Requirements – Per functional area </li></ul><ul><ul><li>Identify end-to-end business process (internal & external) </li></ul></ul><ul><ul><li>One set of business use cases & supplementary specs </li></ul></ul><ul><ul><li>Share Actors where possible and address security for them </li></ul></ul><ul><ul><li>Organize/categorize all artifacts by functional area </li></ul></ul><ul><li>Unifying the development </li></ul>
  16. 16. Approach assessment <ul><li>Advantages </li></ul><ul><li>Build Once </li></ul><ul><li>Resource Savings </li></ul><ul><li>Easier maintenance </li></ul><ul><li>Cohesiveness among IMPAC-II & COMMONS </li></ul><ul><li>Disadvantages </li></ul><ul><li>Slower development </li></ul><ul><li>Resource Savings are not linear </li></ul><ul><li>Dependency </li></ul><ul><li>Issues </li></ul><ul><li>Coordination </li></ul><ul><li>Scheduling </li></ul><ul><li>Accountability </li></ul><ul><li>Security </li></ul>
  17. 17. Next Steps <ul><li>Business plans - Review </li></ul><ul><ul><li>Define business processes (e.g. Trainee Appointment, Continuations, cGAP) </li></ul></ul><ul><ul><li>Task plan & Interdependency </li></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><ul><li>Develop Coordination plan </li></ul></ul><ul><ul><li>Resource Allocation Plan </li></ul></ul>
  18. 18. Questions?

×