Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

SAE2 Application Modernization Process

In this presentation we provide an overview of how the SAE process can evolve to support Application Modernization, by introducing new disciplines to cover the planning and architectural aspects of Application Modernization, the discovery of knowledge encapsulated in the applications, and finally to perform the reengineering that may result in new business requirements.

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Livres audio associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir
  • Soyez le premier à commenter

SAE2 Application Modernization Process

  1. 1. SAE2 Application Modernization Process By Lawrence Wilkes Practice Guide
  2. 2. What is the core of Application Modernization? AS-IS TO-BE Transition Understanding current implementation Detailing new implementation Managing the transition Supporting new business requirements mapping
  3. 3. Contextual Framework Relationships CBDI-SAE ‘ Enterprise’ Architecture e.g. TOGAF Legacy Transformation Service Oriented Architecture e.g. CBDI-SAE + SEA Provides the TO-BE Provides the overall context Provides the overall context e.g. SEI Horseshoe, OMG ADM Architecture Function Code Source AS-IS TO-BE Transition mapping Business Requirements Application Modernization
  4. 4. Application Modernization Approaches Objective Approach Description Replace Replace (Build) New build in-house or outsourced Replace (Buy) New COTS Rationalize Consolidate and rationalize Modernize -Component Reengineering Re-skin New UI Web 2.0 enablement Re-process New Business Process Recode Reengineer implementation Restructure Componentize implementation Re-platform Migrate to new platform Re-host Migrate to new servers Virtualization/Cloud Modernize - Service Reengineering Service Enable New Service Interface New Data Service Underlying or Exclusive service Service Facade New Core Business Services layer New Process services layer
  5. 5. Approach Determines Type/Level of Activity Implementation Architecture Implementation Deployment Architecture Technology Architecture Service Specification Architecture Service Implementation Architecture Internal Architecture <<component>> If, then, else Service Specification <<database>> <<message>> <<module>> If, then, else Logical Physical Application Architecture <<database>> <<database>> table, column AS-IS Business Model TO-BE Business Model Replace (Build) Replace (Buy) Rationalize Re-skin Re-process Service Facade Service Enable Recode Restructure Architecture Recovery Architecture-based Development Re-platform Re-host <<component>> <<component>> <<module>> <<module>> <<Application>> <<Application>>
  6. 6. Summary of Factors Determining Approach Factor Determinants Comment Objective What approaches are necessary for the given objective? See table 1 Unit of Scope What approaches are necessary for the given scope? See table 1, table 2 Core/Context Is the target Core or Context? Mission critical or Supporting? See figure 2 See ’s quadrant Entry/Exit Point What depth of knowledge can be discovered? What exit point is relevant to the To-Be requirements, and decisions on sourcing the To-Be? See AM Process Capabilities Does the project possess the capabilities required to accomplish the modernization? May determine build or buy, outsourcing. See Roadmap
  7. 7. SAE2 Process Solution Assembly/ Implementation Business Modeling Service Implementation Business Improvement Solution Architecture & Design Legacy to Service Reengineering Solution Provisioning Service Provisioning Solution/Service Deployment Solution/Service Platform Design & Installation Enable Solution/Service Platform Architecture Solution/Service Operations & Management Modernization Change Management SOA Quality Management Manage SOA Delivery Management Consume Provide Information Architecture SOA Governance SOA Adoption & Excellence Service Oriented Architecture & Design Application Modernization Planning Legacy Application Reengineering Knowledge Discovery
  8. 8. SAE2 Process Disciplines – Planning and Architecture <ul><li>Application Modernization Planning (AMP) </li></ul><ul><ul><li>Defines outline architecture for AM </li></ul></ul><ul><ul><li>Delivers increment to Application Portfolio Plan </li></ul></ul><ul><ul><li>Goals are to understand the As-Is architecture, identify candidate components for reengineering or reuse in the To-Be architecture, and to plan transition </li></ul></ul><ul><ul><li>Provides architecture level mapping of candidates to the To-Be Solution and Service Architectures </li></ul></ul><ul><li>Knowledge Discovery (KD) </li></ul><ul><ul><li>Defines detailed architecture and design for AM and transformation </li></ul></ul><ul><ul><li>Goals are to understand the As-Is system, and extract knowledge of the current assets </li></ul></ul><ul><ul><li>at the Architecture level: This maps to the Knowledge Discovery Metamodel (KDM) Abstractions Layer – providing Current Systems Models </li></ul></ul><ul><ul><li>at the detailed level: This maps to KDM Resource, Program Elements and Infrastructure packages, capturing the business rules, code structure, etc, in the current asset(s) </li></ul></ul><ul><ul><li>Provides detailed level mapping of As-Is resources and elements to the components and services in the To-Be Solution and Service Architectures </li></ul></ul><ul><li>Information Architecture (IA) </li></ul><ul><ul><li>IA will be responsible for deliverables that are used in other disciplines: </li></ul></ul><ul><ul><li>Service Information Models form part of the Service Specification produced in Service Provisioning </li></ul></ul><ul><ul><li>Message schemas are used both in the Service Specification and at run-time </li></ul></ul><ul><ul><li>Data Exchange Mappings that provide the translation of information between current systems and new Services </li></ul></ul>
  9. 9. Entry and Exit Points Portfolio application element Enterprise or Division Entry Point Entry Point Entry Point Entry Point Entry Point can be at any Unit of Scope Entry Point Entry Point Entry Point Entry Point Entry Point Entry and Exit Point can be at any level Progress from higher level is down Progress is around horseshoe (see SEI Horseshoe Model) Or directly across Depending on objective, scope Exit point often matched to entry Exit Point Exit Point Exit Point Exit Point Exit Point
  10. 10. Next Steps <ul><li>In this paper we have outlined the SAE2 Application Modernization Process. The SAE2 process is distinctive in that it is strongly architecture driven with considered choice of modernization approach. </li></ul><ul><li>Via our subscription services you can explore these topics in greater detail. The December 2009 edition of our monthly CBDI Journal expands the Application Modernization process by providing the process and task decomposition and identification of key deliverables. </li></ul><ul><li>Our SAE Knowledgebase provides a fully cross referenced structure for the SO Process as well as detailing the techniques, patterns and meta model, as well as useful templates and tools. </li></ul><ul><li>See http://cbdi.wikispaces.com/Price+List </li></ul>
  11. 11. Independent Guidance for Service Architecture and Engineering www.cbdiforum.com www.everware-cbdi.com

×