Massimo Coletti

Daily TOGAFArchitecture Development Method tips for Project breakdown

Where we are

❖ TOGAF: a comprehensive framework for Enterprise Architecture design

❖ ADM: a methodology, part of TOGAF, guiding the design of the Enterprise Architecture

❖ We are planning/managing a change project using TOGAF

❖ Migration planning phase

High level view of ADM process

A. From vision to current architecture design

B. Define opportunities and solutions

C. Manage change

At this moment we have the need of a project planning strategy allowing us to manage agile style overlapping projects and deliverables

Ol' good Project Management

At the end, we are dealing with projects, usually more than one. You have developed a priority schema.

Usually, many projects run in parallel, so you will have two dimensions:

• project list,

• and time.

ADM Guidelines

❖ Introduce the concept of "incremental deliverable", linked to timed, intermediate, transition architectures, as sequential steps along the project life.

Architecture Definition Increments Table

courtesy and copyright of The Open Group

We are using a modeling tool to manage (among other things) requirements, projects breakdown, and deliverables.

I would like to show how TOGAF suggested methodology, for this particular aspect, is implemented in our reality.

Basic elements: Project

❖ We use a modeling tool, based on UML

❖ A project is modeled as a Package element, with <<project>> stereotype

❖ Multiple projects contitutes the "project" dimension

Drilling down: the project Phase

❖ A project is a long-running initiative

❖ During the solution design, the Project Manager identifies some intermediate final statuses, for each project. Each is a project "Phase".

❖ At the end of a Phase, we are able to release a complete subset of the project deliverables

❖ A Phase is the "time" dimension of the migration plan

Phases along time❖ Usually Phases are executed sequentially;

❖ each Phase is based on the deliverables of the previous Phase;

❖ Phases breakdown ensure manageability of changing requirements over time;

❖ Closer Phases are more detailed

Modules: work assignment

❖ The work related to each Phase is assigned to several Modules

❖ Usually, each Module has one Performer (internal IT Dept./Team or external Contractor)

❖ Each Module has its own, identified Deliverables

❖ Color coding for status

Other elements

❖ Within each Module, we identify one or more "Change Items", a Work Breakdown Structure.

❖ Change Items are related to Requirements (input), Test Plans (control) and Deliverables (output)

❖ From the Change Items documentation, we generate the Project Specifications, used for internal approval, and, at the same time, as part of the external assignment contract.

❖ A Change Item is completed when the Deliverables are releases, accepted, and Test Plans are successful.

(The whole details about this part are beyond the scope of this presentation)

Summary

❖ A rich framework, like TOGAF, doesn't require always huge and complex implementation projects

❖ The time dimension management is increasingly important: staying in schedule is not enough

❖ Being Agile is useful: closer milestones are easier to respect, and it is possible to deliver value at each intermediate phase

❖ Phased projects allow also to redefine scope and priority

❖ Using an uniform, UML-based, modeling tool for system design and for project modeling gives the advantage of a uniform and integrated view, from the "major" Enterprise Change initiative, down to the more detailed items of system delivery

TOGAF is a product of The Open Group

UML and BPMN are standard defined by the Object Management Group

Enterprise Architect, by Sparx Software, is the tool used, in my Company, for Process and Enterprise modeling, Project Control, and UML modeling

The author doesn't have any relationship with any of the above organizations

The cover picture is by Peter Samow

Rome, march 2015