Project management and ArchiMate viewpoints

Introduction

From my experience as project manager in the research area, one of the usual tool of project managers is the project management tool, allowing to define project work packages, tasks and resources. Project are structured by mean of planning, Gantt and PERT. This allows to plan and to follow the realisation of a project, with different milestones which are associated to the phases of a project, and where project management board decides about continuation of the project relying on the reporting provided by the project manager. The project manager is guided by the objectives and the constraints given by the project management board, in particular in terms of resources. All these information are usually provided in a Description of Work (DoW) associated with the project. Example given is the description of work of the European Research HYCON2 at https://www.hycon2.eu/, which is similar to all the research projects I participated to. The structure of the web site reflects a traditional DoW description, with the "Overview" section, which provides objectives from aims and assessments, with the "Workpackages" section and with the "Deliverables" sections.

What can be modeled with ArchiMate

Very often, in such a document, the description of the AS IS architecture and of the TO BE architecture are poorly described. The links between the components of these architectures and the project structure in terms of work and deliverables are difficult to establish through the DoW document. A tool is missing in order responding to such a need.

This article aims at illustrating how ArchiMate can provide the missing modeling language (with an associated modeling tool, here Archi), with in particular a focus on the usage of ArchiMate viewpoints for structuring the ArchiMate model views.

It occurs that ArchiMate can be the appropriate missing tool for a project manager, to be used in conjunction with project management systems, in order responding to such a difficulty, in particular for complex projects related to the strategy of the enterprise in terms of governance of the information system.

Reusing the terminology (and modeling constructs) of ArchiMate, a traditional project structure can first be captured, with workpackes, deliverables and partners, through a view with as associated viewpoint "Project".

Similarly, motivations of the project can be captured with a view corresponding to a viewpoint "Motivation".

It also allows capturing for the project of the evolution from an AS IS situation to a TO BE situation, which could be related to the captured motivation and project elements (Work package, deliverables, partners).

We start from a current plateau, with defines the AS IS situation, in order to put in place a targeted plateau, which defines the TO BE situation. The current plateau is defined by current processes (business), information system supporting them, and technology used for realisation of this information system. The way to define the targeted plateau is similar, with targeted processes, information system and technology. The definition of the project, with the work packages and the deliverables, is derived from the gaps between AS IS and TO BE situations, and always related with the motivation of the project by the mean of an ArchiMate model with multiple views structured according to the viewpoints defined by ArchiMate specifications (cf. "PLM Interoperability: the potential of ArchiMate viewpoints").

About usage of viewpoints in a project

In the previous views of the project model, I used "project", "Motivation" and "Migration" viewpoints. Many other viewpoints were defined by ArchiMate. E.g., for more detailed views, the viewpoint "Implementation and Migration" can be used with an extended set of constructs which can be used. If no legacy, the AS IS situation will not be provided. It is also possible to make a roadmap of the project, with different milestone and a targeted plateau for each of the milestone. Proceeding this way, the project can be followed more easily by all the project participants and project clients, through usage of a set of views properly structure with a set of relevant viewpoints.

In order to illustrated the numerous viewpoints and what their usage are for structuring views of interest for a project, I used drawing and not modeling (as ArchiMate intent is not to represent viewpoints and their usage).

Different ArchiMate viewpoints can easily be mapped to these blocks which constitute a project, as illustrated by the following figure.

Each block is associated to a particular group of architects: business, information system or technology - software or hardware.

Other ArchiMate viewpoints can be mapped with the intersection of these different blocks, and are related to the collaboration between these actors of the project:

Between Process Architects and Information System Architects:

Between Information Architects and Technology Architects:

Between the Project Manager and the Project Management Board:

Such an approach, illustrated with HYCON2, was adopted with success for research projects dealing with PLM interoperability, such as IMAGINE - for the Aeronautic Living Lab - and for the Standard Interoperability PLM SystemX project.

If considering that a research project main outcomes are Proof of Concepts, nothing prevents making the link with the controlled urbanisation of the Information System of each parter and eventually collaboration between partners, relying on enterprise modelling and on ArchiMate.

This is particularly accurate when willing to put in place a PLM strategy with rationalisation of Product Data Exchange, Sharing and Long Term retention relying on open standards (ISO STEP application protocols) for a Dynamic Manufacturing Network. It is the reason why ArchiMate is one of the standard tracked by the Aeronautic Space&Defense Strategic Standardisation Group.

Conclusion

This article aimed at showing how usage of ArchiMate can be used to complement the traditional tools of project management, taking as an illustration the HYCON2 project, and pointing out which viewpoint can be used for structuring the views of an ArchiMate model.

Let's note that I used the viewpoints as defined in ArchiMate 2, which were part of the specifications. Unfortunately ot changes in ArchiMate, the community considering they should be only illustrative. Based on the way it is supported by Archi, and because of the high added value it provided, I think it is a mistake, as viewpoints can be the "hooks" to methodologies and practices related to Enterprise Architecture, being for controlled urbanisation, solution design or project roadmaping.

What do you think?

Don't hesitate to react and to share if you think this article provides value ;)