The potential of ArchiMate viewpoints from usual EA modeling to PLM

Introduction

After using Open Group’s ArchiMate language and framework, and studying carefully the practices of the community, I’ve been continuously surprised by the very weak usage of the viewpoints proposed in ArchiMate 2.1

I discovered them through the excellent free open source solution Archi, developed by Phillip Beauvoir, which highlights a very clever way the potential of views for guiding the different stakeholders willing to produce a comprehensive model of the architecture of the organizations they are considering.

I took advantage of it when working on PLM Interoperability, by being able to highlight the value created by contextualized open standards related to Manufacturing Data Exchange, Sharing and Long Term Archiving, PLM processes, Model Based System Engineering or Enterprise-Factory integration.

I think Knowing and understanding the viewpoints is as important as knowing the about 60 constructs of the ArchiMate language.

The goal of this article has been evolving with the time. Initially aiming at presenting the Views and Viewpoints mechanism as I discovered it in ArchiMate 2.1 with Archi, it then aimed at stressing the evolution with ArchiMate 3.1 and to introduce how it can be used for multi-scale modeling within PLM context, with some planned concrete example on how it was used for PLM interoperability (still to come in a next version of the article). Before that, I felt the need to reshape the article after studying more deeply the last version of ISO 42010 related to Architecture Framework. Why? Because ArchiMate just applied the best practices and concepts defined in this standard, which has been also adopted by several other architecture description languages and framework.

Part 1 — Views and viewpoints as defined in ISO 42010

“Viewpoint” as considered by ArchiMate is in fact a concept defined in the ISO/IEC/IEEE 42010 standard: “Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.” The last version, ISO/IEC/IEEE 42010:2011, defines requirements on the description of system, software and enterprise architectures. It aims to standardise the practice of architecture description by defining standard terms, presenting a conceptual foundation for expressing, communicating and reviewing architectures and specifying requirements that apply to architecture descriptions, architecture frameworks and architecture description languages. Following its predecessor, IEEE Std 1471, the standard makes a strict distinction between Architecture and Architecture Descriptions.

ISO 42010 makes a strict distinction between architecture and architecture description!

The following concepts are defined by the standard:

• Architecture viewpoint: work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns
• Architecture view: work product expressing the architecture of a system from the perspective of specific system concerns
• Concern: interest in a system relevant to one or more of its stakeholders. A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
• Model kind: conventions for a type of modeling. An architecture view consists of multiple models, each following one model kind.
• Stakeholder : individual, team, organization, or classes thereof, having an interest in a system
• Architecture description (abbreviation ‘AD’): work product used to express an architecture
• Architecture description language (abbreviation ‘ADL’): any form of expression for use in architecture descriptions

ISO/IEC 42010 requires an architecture description language (ADL) conforming to the standard to specify the concerns framed by the ADL, the typical stakeholders who hold these concerns, the model kinds implemented by the ADL that frame these concerns and any correspondence rules linking those model kinds.An architecture description language may specify one or more architecture viewpoints, but need not have any.

Examples of Architect Description Languages are BPMN, SysML, UML and … ArchiMate.

Views are an ideal mechanism to convey information on purpose about architecture areas. In general, a view is defined as a part of an architecture description that addresses a set of related concerns and is addressed to a set of stakeholders. A view is specified by means of a viewpoint, which prescribes the concepts, models, analysis techniques, and visualizations that are provided by the view.

Simply put, a view is what you see and a viewpoint is where you are looking from.

The metamodel proposed by ISO/IEC 42010 for the architecture description of a system is the following:

The architecture description context, with the system, its environment, the stakeholders with concerns and purpose, the architecture exhibited by the systems and its descriptions. It is all about descriptions.

The architecture description meta-model, with the identified system of interest, stakeholders and concerns. Description expresses the architecture exhibited by the system of interest and encompasses architecture rationale, correspondance (with rules) and views aggregating different kinds of models, the views being governed by viewpoints.

The AD elements and correspondences meta-model captures that AD elements can relate each others, with some correspondance rules.

The architecture rational meta-model captures the rationale of architecture decisions, pertained by concerns and affecting the AD elements.

The Architecture Framework meta-model identifies stakeholders and concerns, and encompasses a set of architecture viewpoints aggregating model kinds, with some correspondance rules.

The Architecture description language identifies stakeholders and the concerns they have, and encompasses architecture viewpoints with model kinds having some correspondance rules.

Several languages are considered as ADL according ISO 42010, in particular SysML and ArchiMate.

Let’s explore it for ArchiMate 2.1 and ArchiMate 3, with a particular focus on views and viewpoints.

Part 2 — Views and Viewpoints as defined in ArchiMate 2.1

Complexity of establishing and maintaining a coherent enterprise architecture was identified a long time ago. Framework have been establish by researchers, for classifying and positioning the various architectural descriptions, e.g. with the Zachman framework. Unfortunately, proposed approaches are more categorising and dividing architectural descriptions rather than providing insight into their coherence.

It is why ArchiMate adopted a more flexible approach, in which architects and other stakeholders can define their own views on the enterprise architecture. It is made by mean of viewpoints, as it is defined within ISO 42010. Let’s discover the way it was used with ArchiMate. It is illustrated by the following picture:

The model is accessed by a set of views, which are structured by the mean of the viewpoints in order to facilitate the communication and the collaboration between the different kind of concerned stakeholders.

ArchiMate 2.1 proposes classifications for the viewpoints:

• Designing, Deciding or Informing for respectively designers (who are using UML), managers having to make a decision through analysis (who are using analytic technics) and finally for any stakeholder having to be informed (who are using illustrations).
• Overview, Coherence and Details for

This is summarized by the following picture which is included in Version 2.1 of the specification:

We can see that the different kind of models, stakeholders and purposes are identified. It should be highlight that ArchiMate is not the only language used, and that other representations like drawings can be used for informing, or models using more specialized languages for software designers (UML) or Business Process Architects (BPMN).

The usage of viewpoints can be combined with the ArchiMate layers: Business, Application, Technology (ICT), Motivation and Implementation&Migration (I don’t like the usage of “layer” for motivation or implementation&migration, I should have prefer “perpective”). All the modeling elements allowed by a viewpoint can belong to a single layer, or to several layers. With about 25 viewpoints and about 60 modelling constructs, how to simply visualised it. In order better understanding and explaining their usage for establishment of PLM Interoperability, I produced two posters for ArchiMate 2.

This first poster describes ArchiMate viewpoints, their contents and how they are related to layers. Attributing a given color to each ArchiMate layer, I then displayed viewpoints as boxes with these colors indicating where the constructs used in the viewpoints are coming from. The repartition per layer is roughly represented by the percentage used per color for coloring the boxes. The boxes are contained in boxes representing the layers. These boxes are intersecting, and it is then possible to clearly view which viewpoints are 100% dedicated to a layer, and which viewpoints are concerning links between layers. These last viewpoints are dedicated to collaboration between different architects, e.g. Business Process Architect and Information system Architect.

One very particular viewpoint is the Information viewpoint, with concerns all of the business, applicative and Information&Communication Technologies (ICT) layers, when many other Enterprise Architecture framework are considering an information layer.

The second poster provides the positioning of information structures for « macro » objects represented with ArchiMate viewpoints. What are these « macro » objects? Considering the names of the viewpoint of Archi, you will find Business Processes, Business Product, Organizations, Project, etc. Each of them are modeled by the means of a set of interconnect elements types using the ArchiMate language. They are consequently a mean to described composite objects with a higher level of organisation.

With the proposed representation, you can visualise that some are included within a layer, and that some are cross layers, so dedicated to the relate several perspective. E.g. Application Usage aims at relating the Application Layer and the Business layer, explaining how the applications are used by Business in order to create value.

I particularly enjoyed the way Archi provides features related to views and viewpoints. It is illustrated in the part 5 of this article.

Also, usage of the tool in different projects made emerge the need for a “macro object” concepts, which is develop later in the article.

I was quite happy with viewpoints proposed by ArchiMate V2.1 and the value it brings. Unfortunately, ArchiMate 3.1 came with some changes and with less emphasis on viewpoints. Let’s explore it in the next chapter.

Part 3 — Evolution with ArchiMate 3.1

I produced a new set of representation forArchiMate 3.1, reflecting the new set of viewpoints considered by the new version, and indicating viewpoints which don’t exist anymore.

The stakeholders concerned by the viewpoints are indicated, and the viewpoints are related to views which are positioned on the overall framework, e.g. on the layers defined by ArchiMate.

Main changes:

• Introduction of views related to the strategy, with strategy, outcome realisation, capability map and resource map viewpoints.
• Physical view, with introduction of equipments, facilities, distribution networks and materials (support of virtual manufacturing and logistic). Should it be part of the technology layer, or business layer where physical elements also exist: physical products and people?
• 10 viewpoints were removed

In addition, the viewpoints are now indicative, and not anymore part of the specification. Even if some tailoring is most of the time required within organisations, I must admit I’m a little bit disappointed by the lower importance given to a set of predefined viewpoints with ArchiMate, as it can be considered as a core set of viewpoints ensuring some harmonisation concerning enterprise practices. I consider that the viewpoint mechanism is the hook for defining methodology related to ArchiMate usage.

This second proposed poster illustrates the links with other standards.

STEP which deals with Manufacturing data exchange, sharing and long term archiving provides application protocols with an activity model in IDEF0, with information flows between functions. I illustrated in other articles it can be easily translated in ArchiMate, with flows between functions: representation of business objects between business functions, or data between applicative functions, adopting a functional analysis approach. Then, assigning the function to organisations or processes (business) or to applicative components (application), the process is contextualised and actual flow in operation have to be realised applying the protocols. Information models (ARM and AIM) are included in Information views.

For Model Driven Architecture or OMG’s standardised languages, I also positioned models in the framework.

Finally, I positioned the different Business Modelling languages according to their intended usage with concerned stakeholders.

All these languages are more specialised than ArchiMate, and aims at providing more detailed models. It is important to consider that ArchiMate doesn’t aim at replacing them, but at providing a common vocabulary and metamodel for ensuring collaboration between different kinds of specialist.

A third poster maps modeling constructs and views related to such or such viewpoints to the ArchiMate layers. I also highlighted active, behavior and passive modeling constructs.

Considering that ArchiMate 3 came with new modeling constructs (capability, course of actions, facility, material, equipment), new viewpoints were required. But some disappeared. As a consequence, usage of older viewpoints with Archi supporting ArchiMate 3 is not possible anymore. It has some impacts in terms of compatibility, in particular if willing to reuse practices which were built on these viewpoints.

Another question which arises: should ArchiMate viewpoints be hardcoded in the tools, are subject to parameterization of the tool, with support of different sets of viewpoints: ArchiMate 2.1 viewpoints, ArchiMate 3 viewpoints, those defined specifically by organisations using ArchiMate or finally those defined by such or such methodology, such as TOGAF?

In any case, defining viewpoints for governing views produced for producing architecture description is key. And it allows providing interesting features for modeling tools. The next chapter aims at illustrating it with Archi, the open source implementation of reference for ArchiMate.

Part 4 — Illustration wit Archi

Usage of views and viewpoints may look very abstract. However, due to the way Archi implements it, it becomes very powerful. When creating a diagram with Archi, which corresponds to a view, it is possible to associate one of the viewpoint defined by ArchiMate to the view. What is the effect? If it is a new diagram, it changes the palette and proposes only the modelling elements concerned by the viewpoint.

E.g. the following snapshot shows a view on a model with no viewpoint selected. The palette at the right side shows all the modelling elements of ArchiMate.

Now the “Physical” viewpoints is selected. The palette shows only the modelling constructs related to the Physical viewpoint. Also, all the other element of the view are ghosted.

It is a very practical way for highlight subparts of a global view which concerns only such or such stakeholder. It is a very convenient filtering feature, which can be used for analysis of the enterprise model.

Finally. as concerns/purposes are associated to viewpoints governing the views, it facilitates producing accurate views aligned with explicitely defined purpose and facilitates reuse for communication, collaboration and analysis. We retrieve here the rational for ArchiMate relying on ISO 42010, and also how ArchiMate used this standards for being considered as an ADL, with all the advantages it brings. Let’ note the same occurs with SysML which is also an ADL.

In the projects I was involved too, I had to use ArchiMate and Archi for describing complex systems of systems. I faced some limitations related to the way Viewpoints are defined by ArchiMate and implemented in Archi. It is described in the next chapter of the article.

Part 5 — Introduction to multi-scale modeling

Considering the terminology for naming the viewpoints, it also appears that views can be a way to describe upper “macro” objects, such as a project or an organisation, which are not considered by the modellng constructs of the language: no model element called project or organisation.

Using ArchiMate in several research projects (cf. “Project Managers and ArchiMate viewpoints”) aiming at preparing and building PLM interoperability, it appeared that considering these composite « macro » objects offers a high potential when willing to master the complexity of the emerging Dynamic Manufacturing Network. Such potential has been explored through published papers of IMAGINE or Standard Interoperability PLM research projects. But as ArchiMate provides “flat models”, it was required to propose a new approach called “modelling over UML2/SysML”, which is described in one of my LinkedIn article: “Dynamic Manufacturing Network — from flat Semantic Graphs to Composite Models”, with associated recently published research paper. Don’t hesitate to explore then and to provide feedback.

Roughly, it consists in modeling ArchiMate in UML, not as a profile, but as a class model, including relationships which are captured as UML relation class. The same can be done with SysML block diagram. Then macro objects corresponding to some viewpoints (Organisation, Project, etc.) are also modeled as composite model elements, which are at a higher level of decomposition than the usual modeling construct of ArchiMate. Finally, enterprise architecture models are produced as Object Diagrams with creation of linked instance specifications, typed using the produced ArchiMate model.

So we are still using the ArchiMate language with about no changes, only extension with “macro objects” allowing to switch from flat modeling to multi-scale modeling, which is very convenient for systems of systems. For some views governs by some viewpoints, we are not only providing a diagram, but also a model contained on the macro object related to the view (e.g. project A, Enterprise B, etc.). For networks of enterprises and complex programs encompassing many projects, it is particularly relevant and useful. It is in particular the case when dealing with PLM interoperability

Part 6 — Views, Viewpoints and PLM Interoperability

If many definitions exist, comming from industrial companies or solution providers, the definition I adopted for PLM and I’m still considering is the one provided by CIMDATA.

PLM is a strategic business approach that applies a consistent set of business solutions that support the collaborative creation, management, dissemination, and use of product definition information. PLM supports the extended enterprise (customers, design and supply partners, etc.). PLM spans from concept to end of life of a product or plant. PLM integrates people, processes, business systems, and information. PLM is not a definition of a piece, or pieces, of technology (as often made by solution providers) but the definition of a business approach to solving the problem of managing the complete set of product definition information — creating that information, managing it through its life, and disseminating and using it throughout the lifecycle of the product. However, it relies on solutions such as Product Data Management Systems (Design Phase) (often call PLM solutions today by vendors), but other COTS are also concerned such as ERPs (Production phase ) or MCO solutions (Support phase).

In order to ensure universal, secure, managed access and use of product definition information, for which integrity is managed with regards to the business processes used to create, manage, disseminate, share, and use the information, it is important to capture the business context. In my past activities related to the establishment of PLM interoperability for efficient Product & Process data sharing, exchange and long term archiving (for traceability purpose), enterprise modeling appeared as an important enabler.

However, PLM experts and Enterprise Architects are two disciplines which don’t know each other very well. PLM experts are more “Product & Process Data centric”, having to consider a whole supply chain (so many enterprises), when Enterprise Architect standards are more “Enterprise Information System centric” considering one enterprise. ArchiMate adresses very weakly the ability to describe a manufactured Product, with a single construct: Product. For manufacturing data and PLM, different kind of product breakdown are to be considered, as well as configuration items, which are key for quality, contracts and digital continuity.

It impacts the way to define the set of concerned stakeholders, considering roles which are not proposed by default by ArchiMate. It also bring the need to be able to consider a dynamic network of enterprises, each enterprise and his information system constituting a node of the network, and having his set of viewpoints which are one enterprise centric, one phase of the product life cycle centric or global to the network of enterprises. Phase centric or global network centric viewpoints should be shared by the supply chain partners and if possible standardized for more efficient digital collaboration and PLM strategy. The following model captures a supply chain around the Airbus 380, from data captured on Internet. Different roles as kind of stakeholders are proposed, which are related to manufactured products which are to be integrated, operated, certified and supported. The considered scale is not the one usually considered by ArchiMate and associated practices.

The considered business processes, related to PLM, can be private and one enterprise internal, public and part of an extended enterprise being part of the network, or public and cross organisations, being managed at the network level (all the enterprise at the same level). This last case is unusual in aeronautic or defense, and more common in the furniture industry. However, it could be quite an enabler for ensuring PLM interoperability and efficient digital collaboration at an acceptable cost, considering that uniformisation of PLM solutions over a supply chain and over the time can’t be achieved.

ArchiMate and the viewpoint mechanism proposed by ISO42010 remain accurate when used in a PLM context, but it requires some adaptation of the practices and usage of the modeling language. The most adapted modeling solutions are combining ArchiMate with other ADLs bringing composite modeling and extensibility capabilities. SysML/UML2 modeling environments are quite good for this. It can be done using UML profile and ability to combine models with different languages (as proposed by Sparx Enterprise Architect) or using ArchiMate modeling over UML2/SyML, as proposed in one of my research paper and demonstrated with Magic Draw.

Conclusion

I think that the viewpoint mechanism is one of the most important feature of ArchiMate for supporting shared production of an enterprise model, reflecting and aggregating all the views of the numerous involved stakeholders. With layers and aspects, it guides the people for providing similar set of views a consistent way.

My research activities led me to explore them in detail for ArchiMate 2.1 then 3.1, and to produce posters capturing the complete set of viewpoints, how they are positioned across the layers and what ArchiMate modeling constructs to use with them.

I latter made the link with ISO 42010 standard about architecture framework, highlighting that ArchiMate is an Architecture Description Language as defined by the standards.

Usage of ArchiMate can be extended relying on some innovative practices in order to produce multi-scale models representing a supply chain around an industrial product, relevant when studying PLM interoperability. It has been the subject of many of my research papers (concepts) and LinkedIn articles (practical usage).

I hope that this article will give you the desire for rediscovering and exploring further the potential of ArchiMate viewpoints, and that you will find the posters and return on experience useful.

Don’t hesitate to react, comment, explore my other articles, provide feedback and to like the articles if you think they bring value.