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.

SAE2 Application Modernization Process

View more presentations from LawrenceWilkes.

There are many approaches to Application Modernization as outlined in the table below, and many factors determining which approach to follow.

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

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?

Factor	Determinants
Objective	What approaches are necessary for the given objective?
Unit of Scope	What approaches are necessary for the given scope?
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?
Capabilities	Does the project possess the capabilities required to accomplish the modernization? May determine build or buy, outsourcing.