1 / 26

eRA Migration/Development Strategy

eRA Migration/Development Strategy. Kalpesh S. Patel patelk@od.nih.gov Ekagra Software Technologies, Ltd. 4/9/2002. Agenda. Migration Strategy - Review Migration/Development Order Proposed Schedule Enterprise Architecture Development Process. Strategic Enterprise Architecture. Vision

kipling
Download Presentation

eRA Migration/Development Strategy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. eRA Migration/Development Strategy Kalpesh S. Patel patelk@od.nih.gov Ekagra Software Technologies, Ltd. 4/9/2002

  2. Agenda • Migration Strategy - Review • Migration/Development Order • Proposed Schedule • Enterprise Architecture Development Process

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

  4. Migration StrategyObjectives • Migration of IMPAC II applications to J2EE • Develop unified enterprise architecture • Maintain enterprise nature • Preserve intellectual capital • IMPAC II migration order • COMMONS migration/development order

  5. Alignment

  6. Approach • COMMONS – Customer facing application • COMMONS as another business area of eRA • Reuse common components

  7. 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

  8. 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

  9. Migration/Development Order • Criteria • Dependency • Complexity • Business priority • Need to be Web-based

  10. IMPAC II Apps – Dependencies 8+ common modules

  11. Migration/Development Order • Phased Approach • Phase 1 – Low dependency • Phase 2 – Medium dependency, High business priority • Phase 3 – High dependency, Medium business priority, High complexity

  12. Phase 1

  13. Phase 2

  14. Phase 3

  15. Business Timeline • Overall schedule • Need to reevaluate (bi) annually

  16. Phase 1

  17. Phase 2

  18. Phase 3

  19. Issues • Need to align internal & external business plans • Resource allocation • Analysts allocation – done • Development allocation - ? • Dollars - ?

  20. Enterprise Architecture Development Process

  21. Objectives • Develop end-to-end eRA enterprise functional architecture • Help define projects • Maintain enterprise nature of the system • Ensure that the vision is carried out in the implementation

  22. Enterprise Functional Architecture Business Use Case Specifications Business Level Object Model 1 2 3 4 6 5 • Current Efforts • Use Cases • Object Model FunctionalArchitecture

  23. SystemsDesign Analyst Group Ad Enterprise Functional Architecture Use Case Specifications Refined Use Case Specifications Team Lead Architect 4 1 3 3 6 5 7 8 2 Refined Object Model Object Model J2EE Practice Scope Document

  24. SystemsDevelopment 4 3 1 6 5 8 9 2 7 Enterprise Functional Architecture Architect Analyst Refined Use Case Specifications Refined Object Model Group Ad UI, JSP EJB, Persistence, Business Rules Assembly Application

  25. To be done • Organization • Architect, Analysts, Group Advocate, Development • Process Flow • Ownership of the artifacts • Feedback loop • QA process when the objects are moved • Security requirements verification

  26. Questions?

More Related