| Title: |
The Agile Application Modernization Project |
| Author: |
Lawrence Wilkes and Denzil Wasson |
| Publication Date: |
29 January 2010 |
| Report Type: |
Journal |
| Report Class: |
Best Practice |
| Abstract: |
In a previous report we introduced the Application Modernization process decomposing it into Disciplines, Process Unit and Tasks. In this report, we discuss an agile project structure and organization and provide a detailed breakdown of the Application Modernization process in terms of Project Phases and Work Packages, starting with the Assess and Plan phases.
This approach to application modernization will allow an escalation from a solution specific modernization effort to an enterprise SOA effort over time. It can be viewed as the pragmatic middle ground between a difficult to motivate enterprise level SOA and successive SOA projects that will inevitably lead to service anarchy. |
| Backgrounder: |
In CBDI-SAE we use Disciplines as a way of separating out the different capabilities required by an organization. For example the capabilities required to deliver the Service Architecture – such as skills or tools - will be different to that required to deliver Service Implementations. Disciplines are also responsible for one or more key deliverables in Application Modernization and SOA. Application Modernization Planning produces the Application Modernization Plan; Service Oriented Architecture & Design produces the Service Portfolio Plan, and so on.
The process decomposition of Disciplines, Process Units and Tasks forms the basic ‘building blocks’ from which various types of project plans can be assembled to meet different needs. Think of Disciplines as the ‘service providers’ to an IT process.
Most projects will be focused on delivering a solution to a business requirement. The project will be tasked with understanding the requirement, mapping out the architecture, provisioning and implementing the various components and services, and finally assembling and deploying the solution. Consequently it will be using the ‘services’ provided by a number of Disciplines.
However, not all Application Modernization projects are exactly the same.
* A project that deals with a larger unit of scope may require iteration through some activities, whereas a smaller one may not.
* One project may have a strategic focus that requires significant investment in planning and architecture, whereas another may be more tactical and start with an existing architecture that needs little refinement.
* Most projects should be business-driven in response to new business requirements, whereas some may be more IT-driven, for example retiring an obsolete platform, and consequently have less need to identify business improvements or build business models.
Mapping the process decomposition to appropriate project phases and into work packages enables us to explore these different options and to construct various types of project plans.
In this report we use a generic project lifecycle. We recognize that readers may follow frameworks such as RUP or various agile approaches that provide their own lifecycle phases. Mapping to these should be straightforward. |
| Report Size: |
16 pages |
| Report Access Type: |
 | Silver/Gold (Premium) |
|
| Available for separate purchase |
Single copies of recent CBDI Journals may be purchased |
| Login |
|
Home