SAE2 Application Modernization Process
•Download as PPT, PDF•
3 likes•980 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to SAE2 Application Modernization Process
Similar to SAE2 Application Modernization Process (20)
Recently uploaded
Recently uploaded (20)
SAE2 Application Modernization Process
- 1. SAE2 Application Modernization Process By Lawrence Wilkes Practice Guide
- 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. 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. 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. 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. 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. 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
- 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
- 11. Independent Guidance for Service Architecture and Engineering www.cbdiforum.com www.everware-cbdi.com
Editor's Notes
- Application Modernization (AM) is centered on three main capabilities as shown in Figure 1. Producing As-Is models to understand the current system(s) Producing To-Be models that articulate new business requirements and drive the new implementation Managing the transition from the As-Is to the To-Be, which will include: mapping the one to the other to understand what assets might be reused, what gaps exist, and how they might co-exist during the transition transforming some of the As-Is assets so that they can participate in the To-Be
- These capabilities are described in widely used architecture frameworks shown in Figure 2 and detailed in Table 1. These provide context for different AM scenarios and desired outcomes of AM. Some AM activities will be driven by an Enterprise Architecture initiative that is considering the modernization of a broad portfolio. This may not be as broad as the whole enterprise of course, but an EA style approach is recommended whenever a portfolio of systems requires modernization. To provide the necessary agility and avoid the creation of yet more legacy systems, we would expect a Service Architecture adhering to SOA principles to be one of the key elements of the To-Be model. This is not always the case; frequently legacy transformation activities may just be focused on platform migration, rather than establishing improved architecture and supporting new business requirements. Similarly, many tactical, project-based, application-led scenarios may not include SOA. Though they may deliver some service enabled APIs in the current and or transformed system, there is often insufficient compliance with full SOA principles.
- One of the core tasks in Application Modernization Planning (AMP) is to determine the most suitable approach given the differing modernization requirements and objectives that a business or project may have. There are several approaches to Application Modernization, as outlined in Table 2. In many cases, to achieve the desired objective it may require more than one approach. For example, in order to build a new Service Façade it may require that some current assets are also Service Enabled – so they can be consumed as Underlying Services in the Service Architecture of the façade.
- Level of Activity Subsequently, the approach determines the type and level of activity required in order to perform the modernization. This is illustrated in Figure 3, based on the SEI Horseshoe model, which shows the depth of architectural recovery that is required in order to understand and plan the transition, and the corresponding types of elements that will actually require modernization. At the implementation level it may not be possible to discover the knowledge of, or recover the actual artifacts themselves for potential reengineering. For example, with ‘black box’ software where the author/vendor has long moved on, this may force activity to take place at a higher level than was perhaps hoped, and lead to greater amount of forward engineering. On the other hand, even though knowledge and artifacts can be recovered, decisions to outsource delivery or replace with COTS may mean there is less imperative to do so. Hence it is important that such decisions are made in the planning stage.
- Another factor in determining the approach will be the unit of scope of the modernization requirements. With a broad scope, each of the different sub units may require a different approach. The modernization approach may also be determined by the decision whether the To-Be solution is deemed to be core or context, mission critical or supporting, according to Moore’s quadrant. The factors determining the approach are summarized in Table 3, which also identifies key questions of whether the project possesses the necessary capabilities to perform the activities required, or whether the activities should be outsourced? Based on work published by Geoffrey Moore in the book Dealing with Darwin http://www.dealingwithdarwin.com/ . See Business Strategy Planning for SOA, CBDI Journal May 2005 http://www.cbdiforum.com/secure/interact/2006-05/BSP_for_SOA.php
- As explained in a related white paper, we continue to expand the scope of CBDI-SAE to address these relationships – illustrated by the blue CBDI-SAE box in figure 2. For example we have provided mapping into TOGAF, and now into AM. To this end we have enhanced the SAE Process as illustrated in Figure 4 to detail new disciplines that are focused on AM requirements. SAE2 - Framework for Application Modernization
- It is important to recognize that there are multiple entry and exit points in the Application Modernization process. It isn’t always portfolio-based, nor is it always strategic, nor should it be considered ‘waterfall’ in approach. Figure 5 illustrates in terms of scope that the entry may be at any appropriate level, and subsequent progress is typically down through the decomposition of units of scope. The broader the unit of scope, the more important it becomes to recover the architecture first in order to understand the underlying decomposition. In the horseshoe, progress is either: around the horseshoe in terms of architecture recovery, and subsequent architecture-based development or directly across in terms of modernizing an individual element. The exit point isn’t always at the bottom of the horseshoe as the modernization approach may have been determined to be replacement by buying, or outsourcing the implementation. In which case the architecture and specification levels of detail may be sufficient.
- 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. 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. 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. See http://cbdi.wikispaces.com/Price+List