eRA Migration/Development Strategy

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?