Monday, 4 January 2010

SAE2 - Supporting the Application Modernization Process

We start the new decade at CBDI Forum with a major focus on Application Modernization (AM). The need to reuse existing assets in new SOA solutions is not itself new, and we have covered this before in various reports, whilst the CBDI-SAE SOA Process has always included a ‘Legacy to Service Transition Planning’ discipline.
Equally, at Everware-CBDI, we have considerable practical experience in AM via a number of engagements our consultants have worked  on,  primarily in the CA Gen domain. We also recently announced the SOA4GEN  program along with partners Jumar Solutions.
However, we recognize that in many organizations AM has increased in priority, whilst SOA is becoming ‘business as usual’. That doesn’t mean AM is replacing SOA, rather it puts SOA in context. AM is the objective, and SOA is one of the key elements in achieving it.  Consequently, we wanted to increase our coverage of AM in our research and guidance, and further explore the relationship between AM and SOA.
One of my focuses in this work has been on the process. To date, our CBDI-SAE SO Process has been focused primarily on disciplines covering the planning and provisioning of the Service Portfolio, and its use in solution delivery.  To support AM, we have now begun to document additional disciplines such as Application Modernization Planning and Knowledge Discovery (understand the As-Is system, and extract knowledge of the current assets), and give them equal weight and depth of coverage to these in comparison with the existing  SO disciplines and detail how they interact.

An overview of the CBDI-SAE SO Process is shown below. Such is the degree of change that we decided to label this SAE2 as it is effectively a new version of our CBDI-SAE SO Process framework.
(click to expand)
I have created the following SlideShare to provide an overview of the AM process. Subscribers to our CBDI Journal and Knowledgebase can find out more detail of the process units and tasks in the December 2009 Journal.

There are many approaches to Application Modernization as outlined in the table below, and many factors determining which approach to follow.
Objective ApproachDescription
ReplaceReplace (Build) New build

in-house or outsourced
Replace (Buy) New COTS
RationalizeConsolidate and rationalize
Modernize -Component ReengineeringRe-skin New UI

Web 2.0 enablement
Re-process New Business Process
RecodeReengineer implementation
RestructureComponentize implementation
Re-platform Migrate to new platform
Re-hostMigrate to new servers

Modernize - Service ReengineeringService EnableNew Service Interface

New Data Service

Underlying or Exclusive service
Service FacadeNew Core Business Services layer

New Process services layer

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.
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.
Subsequently, the approach determines the type and level of activity required in order to perform the 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.
The factors determining the approach are summarized below, 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?
ObjectiveWhat approaches are necessary for the given objective?
Unit of Scope What approaches are necessary for the given scope?
Entry/Exit PointWhat depth of knowledge can be discovered? What exit point is relevant to the To-Be requirements, and decisions on sourcing the To-Be?
CapabilitiesDoes the project possess the capabilities required to accomplish the modernization? May determine build or buy, outsourcing.

No comments:

Post a Comment