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.

In context with Application Modernization, the phases cover:

  • Assess: Obtain initial business requirements and assess current system status, structure, issues and opportunities, functional backlog and agility potential.
  • Plan:  Produce plans and architectures including the Business improvement plan, Service and Solution architectures (at an outline level), the Application modernization plan, and any Reference Architecture that will underpin the work.
  • Analyze: Produce detailed To-Be models and architectures as well as models of current systems, for the scope of the modernization project.
  • Deliver: Realize the plan by provisioning new or reengineering existing assets, and assembling and deploying the solution.
  • Evolve: Transition (go live) to the new business and solution, then measure/monitor and produce refinements (to the assessment, plans or realizations).

continued in PDF

Document Download: The Agile Application Modernization Project (pdf)


The Agile Application Modernization Project (pdf)

Type: pdf

File Size: 277KB

Published: 1 Jul 2011 00:00


You must confirm your screen name on your profile in order to comment.

Please sign in if you wish to comment.