180 likes | 334 Views
eRA Migration/Development 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
E N D
eRA Migration/Development 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
9iAS J2EE Server - eRA User Authentication Info +NIH Request + NIH Response Business Apps JSP, Servlet User Authentication Info + eRA Request + eRA Response Web Services JPDK NIH SSO NIH Authentication OID LDAP eRA Authentication Portal Integration Architecture eRA NIH NIH Portal eRA Portal Security Authentication
Migration StrategyObjectives • 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 • 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
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
Approach • COMMONS – Customer facing application • COMMONS as another business area of IMPAC-II • Reuse common components
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
Advantages Build Once Resource Savings Easier maintenance Cohesiveness among IMPAC-II & COMMONS Disadvantages Slower development Resource Savings are not linear Dependency Approach assessment 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