A short flash about practical application of one tecnique suggested in the TOGAF framework for ADM

1. Massimo Coletti
Daily TOGAF
Architecture Development
Method tips for Project
breakdown

2. 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

3. 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

4. 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.

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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)

12. 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

13. 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