ArchiMate 3.0

by Phil Chudley, Principal Consultant at Dunstan Thomas Consulting

  The Open Group released the official specification of ArchiMate 3.0 in June 2016, and this new specification is supported in Enterprise Architect version 13. This article summarises the new features and changes within ArchiMate 3.0 and provides an example of how to migrate an existing ArchiMate 2.0 model to ArchiMate 3.0 model using Enterprise Architect v.13.

Summary of Changes

The following is a summary of the changes made within ArchiMate 3.0:

• Motivation Extension;
  • New element for modelling Outcomes.
  • New set of Strategy Elements, Resource, Capability, Course of Action.
• Business Layer;
  • Representation of the Contract element modified so as to be different from the Business Object Element.
  • Location element removed (although Enterprise Architect has re-located this element to the Technology Layer – Physical Extension).
• Application Layer;
  • Two new elements added, Application Process and Application Event
• Technology layer;
  • Elements called Infrastructure in ArchiMate 2.0 are now called Technology in ArchiMate 3.0.
  • Four new elements added, Technology Process, Technology Interaction, Technology Event and Technology Collaboration.
  • New set of Physical Elements, Equipment, Facility, Distribution Network and Material. These elements are known as the Physical Extension.
• Implementation and Migration Extension;
  • One new element added, Implementation Event.
• Relationships;
  • Representation of Assignment modified to have a directional arrow.
  • Bi-directional Access relationship added.
  • Plus (positive) and Minus (negative) symbols added to Influence Relationship.
  • New relationship, Serving.

Detail of Changes

The following tables provided an example of the changes for each of the sections listed in the Summary of Changes above.

Motivation Extension

Element	Definition	Notation
Outcome	An end result that has been achieved.
Resource	An asset owned or controlled by an individual or organisation.
Capability	An ability that an active structure element, such as an organisation, person, or system possesses.
Course of Action	An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal.

Business Layer

Element	Definition	Notation
Contract	A formal or informal specification of an agreement between a provided and consumer that specifies the rights and obligations associated with a product.

Application Layer

Element	Definition	Notation
Application Process	A sequence of application behaviours that achieves a specific outcome.
Application Event	An application behaviour element that denotes a state change.

Technology Layer

Element	Definition	Notation
Technology Collaboration	An aggregate of two or more nodes that work together to perform collective technology behaviour.
Technology Process	A sequence of technology behaviours that achieves a specific outcome.
Technology Event	A technology behaviour element that denotes a state of change.
Technology Interaction	A unit of collective technology behaviour performed by (a collaboration of) two or more nodes.
Equipment	One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
Facility	A physical structure or environment.
Distribution Network	A physical network used to transport materials or energy.
Material	Tangible physical matter or physical elements.

Implementation & Migration Extension

Element	Definition	Notation
Implementation Event	A behaviour element that denotes a change of state related to an implementation or migration.

Relationships

Element	Definition	Notation
Assignment	Expresses the allocation of responsibility, performance of behaviour, or execution.
Serving	Models that an element provides its functionality to another element.
Access	Models the ability of behaviour and active structure elements to observe or act upon passive structure elements.
Influence	Models that an element affects the implementation or achievement of some motivation element.

Implications to existing ArchiMate models

If an organisation has modelled their Enterprise Architecture using Enterprise Architect and ArchiMate 2, and are now using Version 13 of Enterprise Architect, they have two courses of action:

1. Continue to model using ArchiMate 2.0. In this case no action is required either for Enterprise Architect or the model repository. An organisation would continue to model using ArchiMate 2.0 if they do not wish to make use of any of the new features in ArchiMate 3.0.
2. Migrate their existing ArchiMate 2.0 model to ArchiMate 3.0, and then continue to model using ArchiMate 3.0. An organisation would continue to model using ArchiMate 2.0 if they wish to make use of any of the new features in ArchiMate 3.0.

My own personal opinion is that an organisation should consider moving to Enterprise Architect version 13 (mainly due its new feature of “Time Aware Modelling”) and ArchiMate 3.0. One of the main reasons, is due to inherent ambiguity (due to the lack of direction indication) in the assigns relationship in ArchiMate 2.0, which has been eliminated in ArchiMate 3.0 by making the assigns relationship directional.

Migrating an ArchiMate 2.0 model to ArchiMate 3.0

Enterprise Architect version 13 provides a migration script for this purpose. The following steps are used to perform the migration:

1. Take a backup copy of the existing model repository.
2. Using the Configure | Manage Technology ribbon, ensure that both ArchiMate 2.0 and ArchiMate 3.0 MDG technologies are enabled.
3. Using the Code | Scripting ribbon, make the scripting window visible:
   
4. Select the topmost package (or view) that contains the model to migrate:
   
5. Select the script Migrate ArchiMate 2 to ArchiMate 3 in the scripting window.
6. Right-click and select Run Script from the menu.
7. The progress of the migration, together with any errors / warnings will be displayed in the system output window.
8. Review the diagrams (you may have to tidy some of the relationships).
9. Turn off the MDG ArchiMate 2.0 using the Configure | Manage Technology ribbon.

NOTE: It appears that composition relationships are NOT HIDDEN, when using nested structures in ArchiMate 3.0. I suspect this is an Enterprise Architect version 13 issue. This is likely to be fixed and should not deter migration, as these relationships can always be hidden using the Visible Relations function in Enterprise Architect. (Layout | Manage ribbon and select Show and Hide Relationships… from the menu).

Phil Chudley
Principal Consultant
Dunstan Thomas Consulting
@SparxEAGuru

You'll find lots of useful Enterprise Architect videos on our YouTube Channel.

Introduction

Straight out of the box, Sparx Enterpise Architect provides support for multiple modeling notations. Using a synergy of notations can result in a better description of business architecture. This article considers how ArchiMate, BPMN and UML can be combined into a model that is focused at a high-level of abstraction, whilst still allowing for some critical details to be explored.

Revealing layers of abstraction

As explained in Marc Lankhorst's book Enterprise Architecture at Work (third edition, p. 117), modeling notations provide a way to represent knowledge. The process of building, sharing and transforming the model can foster a new level of understanding amongst the participants. This refined knowledge is (at least) as valuable as the resulting model artifacts (the representation). Effective communication of that knowledge requires consideration for the target audience and an appropriate level of detail.

ArchiMate is good for:

• People who have a job title like Enterprise Architect or Business Architect.
• Presenting high-level and layered abstractions of the business itself, along with the software and technology that are used to support it.
• Tracing and illustrating how the motivating strategy is realised by the business.
• Planning the evolution and transformation of a business.
• Supporting concepts that are similar to those found within TOGAF.

By design, the ArchiMate 2.1 specification does not (explicitly) provide for detailed:

• Business process modeling
• Data modeling

Meanwhile:

• BPMN (Business Process Modeling and Notation) is focused on the detailed modeling of business processes; naturally enough, BPMN is increasingly used amongst the Business Analyst community.
• UML Class diagrams may be used to detail data types, along with the relationships between data types; they are widely recognized amongst software developers, and a good alternative to using entity relationship diagrams for logical data modeling.

Coordinating multiple notations in a single model repository

UML is the native metamodel and notation of Sparx Enterprise Architect. Each additional notation (such as ArchiMate and BPMN) is provided as a MDG (Model-Driven Generator) technology within the tool. The UML specification provides for semantic extension of the UML through the mechanism of Profiles, Stereotypes and Tagged Values. Profiles are the heart of each MDG Technology, enhanced with Sparx tool specific details supporting new types of diagram notations and diagram toolboxes.

Using multiple notations within a single repository requires a disciplined approach in order maintain clarity. In brief, the best practice is to:

• Restrict the elements of each notation to a separate root node.
• Use the UML «Trace» dependency to provide an elegant way of relating elements belonging to different notations.

Add root node to your Sparx Enterprise Architect repository

You might not have realised that the File|New Project… menu option is something of a misnomer. Both EAP and FEAP files are actually self-contained model repositories, and can therefore contain multiple root nodes (just like a RDBMS hosted shared repository, whether accessed through an ODBC or Cloud connection). As a reminder, you can add a new root node into a repository by performing the following steps:

1. If necessary, click View|Project Browser to open the Project Browser window.
2. Right-click inside the blank (white) area of the Project Browser window and then click Add|Add Root Node….
3. The Create New Model (root node) window is displayed. Type MyCorporation (ArchiMate) into the Model Name field.
4. In a similar way, create root nodes for:
   • MyCorporation (BPMN)
   • MyCorporation (UML)

Create a «Trace» dependency between elements belonging to different notations

As stated in the Unified Modeling Language 2.5 specification (p246):

"Models can have Abstraction Dependencies between them: refinement (stereotyped by «Refine» from the Standard Profile) or mapping (for example stereotyped by «Trace» from the Standard Profile). These are typically represented in more detail by Dependencies between the elements contained in the Models. Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete. However, they are useful for tracing refinements and for keeping track of cross-references between models."

ArchiMate for an architectural understanding

For example, an ArchiMate Business Process Viewpoint diagram for Purchase Item might look as follows:

This provides a high-level overview of a core business process, with enough detail to inform stakeholders and decision making at a whole-enterprise level of abstraction.

BPMN for detailing business processes

BPMN can be used to detail the ArchiMate Business Process concept, as follows:

UML for detailing the data entites

UML Classes can be used to detail the ArchiMate Business Object concept, as follows:

Usually, diagrams should only contain a single notation. In the examples above, multiple notations are deliberately used to visualise «Trace» dependencies between the ArchiMate, BPMN and UML elements.

How-to add «Trace» dependencies between elements model elements

Best practice for adding «Trace» dependencies using a diagram is to:

1. Temporarily add the required elements of the foreign notation to a diagram.
2. Draw the «Trace» depencies between elements.
3. Remove the foreign notation elements from the diagrams, whilst retaining the traceablity links within the model repository. (So, delete the foreign elements from the diagram, but NOT the repository).

Alternatively, you could use the Relationship Matrix functionality of Sparx Enterprise Architect (click Tools|Relationship Matrix to get started).

Summary

The UML specified «Trace» dependency (relationship) is an elegant way of tracing between different modeling notations. Sparx Enterprise Architect provides a wide coverage of modeling notations, by leveraging the UML Profiles mechanism, and enhancing it with MDG technologies. In practice, this enables a synergy of the ArchiMate, BPMN and UML notations. Models can be constructed as layered abstractions, moving from one notation to another to suit the level of detail required by the user and intended audience.

When to consider the use of ArchiMate?

The Open Group recently released the ArchiMate 2.1 specification; I think that there are five principle reasons to consider using the notation to describe the architecture of your enterprise. By design, ArchiMate is focused toward:

• Providing a high-level of abstraction
• Facilitating the construction of a layered enterprise architecture
• Illustrating how business concepts are supported by IT systems, comprising both hardware and software
• Tracing stakeholder concerns through to their realization by the enterprise architecture
• Showing the possible, and actual, evolution of an enterprise architecture through a number of recognizable intermediate states.

How does ArchiMate handle these things?

Approaching abstraction

In a similar way to modeling notations such as the UML and SysML, ArchiMate relies on a simple but powerful approach to creating a useful abstraction of a complex domain:

• Identify the specific types of things that are pertinent
• Identify the relationships between the types of things
• Provide a graphical notation to illustrate the above

Types of concept

ArchiMate divides the specific types of things to be modeled into three core layers:

• Business concepts (including actor, role, function, process, service and interface)

Figure 1: A subset of the business layer concepts

• Application concepts (including component, function, service and interface)

Figure 2: A subset of application layer concepts

• Technology concepts (including device, system software, function and interface)

Figure 3: A subset of the technology layer concepts

ArchiMate supplements the core types of things with two extensions for:

• Motivation (including driver, goal, requirement, principle and constraint)
• Implementation and migration (work package, deliverable, plateau and gap)

Relationships between concepts

ArchiMate specifies ten types of relationship that may be used between elements:

• Composition
• Aggregation
• Assignment
• Specialization
• Realization
• Used by
• Access
• Association
• Triggering
• Flow

Direct relationships

ArchiMate specifies the set of valid relationships that may exist between concepts. Relationships are restricted for both concepts belonging within a single core layer or extension, and also across layers. The detailed specification of all valid relationships between types is tabulated in Appendix B: Relationship Tables of the ArchiMate 2.1 specification (ISBN 978-94-018-0003-7).

Figure 4: A syntactically (but not necessarily semantically) correct example showing all the available ArchiMate relationships

Derived relationships

ArchiMate also specifies rules for abstracting over a chain of relationships between three or more concepts:

Transitively applying this property allows us to replace a “chain” of structural relationships (with intermediate model elements) by the weakest structural relationship in the chain. – p. 94, ArchiMate 2.1 specification

Figure 5: A chain of relationships, along with the derived relationship

How using an ArchiMate modeling tool can help

In theory, it is not necessary to use a dedicated modeling tool in order to draw ArchiMate diagrams. You could create a custom stencil with Microsoft Visio (for example) containing all the basic shapes of the elements and relationships. However, a good modeling tool can be used to positively enhance both:

• Productivity in creating models
• The correctness of the models

Both enhancements depend on automated model validation, at either the syntactic or semantic level.

Checking for errors in direct relationships [enhance correctness]

Ideally, your modeling tool should not allow you to draw an invalid relationship between two concepts in the first place. This can be prevented a priori whilst creating the initial drawing, by greying out or eliding the options to create invalid relationships. Alternatively (or additionally), the modeling tool can validate the relationships between elements within each diagram, highlighting where invalid relationships have been made, and suggesting valid alternatives.

Automatically deriving relationships between elements [enhance productivity]

Due to ArchiMate’s rules for abstracting over a chain of relationships, your modeling tool should be able to insert a correctly derived relationship between any two elements in a diagram, or at least inform you that no relationship can be derived at all.

Automating ArchiMate viewpoints

ArchiMate specifies twenty-six viewpoints that may be constructed using different combinations of element types and relationships. Ideally, your tool should be able to:

• Validate any viewpoint(s) that you have already created. [enhance correctness]
• Provide automated assistance with creating new diagrams through re-using existing model elements and their relationships. [enhance productivity]

How to do it? Let us help you!

The existing functionality of Sparx Enterprise Architect provides a good basis for fully automating the validation of ArchiMate models. Please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. if you would like to discuss how you can gain access to our solution.

New courses released onto the DT schedule & virtual learning environment!

With no small amount of effort we have managed to bring forward the release of the phase 2 online training courses available via the Dunstan Thomas virtual learning environment.

The list of options now available is; 

• An Introduction to UML
• Reporting with Enterprise Architect
• SysML 1.3 Made Practical with Enterprise Architect
• Putting TOGAF into Practice with Enterprise Architect
• Business Process Modelling using BPMN and Enterprise Architect
• Enterprise Architect; The Practicalities
• An Introduction to ArchiMate
• Enterprise Architecture Modelling using Enterprise Architect and ArchiMate 2.0
• UML with Enterprise Architect for Beginners
• UML with Enterprise Architect for Business Analysts
• UML with Enterprise Architect for UML Practitioners

You can find all these sessions in the training directory on our website; 

Visit our online training page & use the subscription calculator to get a quote for your online training needs.

New to our classroom offering... 

Modelling Applications for Mobile Devices using Enterprise Architect 

This two day training course for Sparx Systems UML modelling tool, Enterprise Architect. It is designed to provide Business Analysts and Solution Architects with the necessary practical skills to create, using Enterprise Architect, design solution models for applications that will be running on mobile devices. 

For any information on these or any of our other courses or services please do not hesitate to contact us. 

This new training course teaches ArchiMate business, application and technology layers as well as motivation and implementation & migration extensions (providing full support for TOGAF).

http://www.hippo-software.co.uk/pages/EAforArchitectureandStrategy.htm

ArchiMate is an industry standard notation developed by The Open Group for the graphical modeling of enterprise architectures. The notation has evolved to be fully aligned with TOGAF. Many companies recognise the value of these architectural models in understanding the dependencies between their people, processes, applications, data and hardware. Using ArchiMate allows them to integrate their business and IT strategies.

Gillian Adens, Director of Hippo Software, demonstrates how Enterprise Architect can be used to create ArchiMate models and viewpoints to help in understanding, documenting and communicating knowledge of the enterprise architecture. The webinar:

Last chance to register.

ArchiMate is an industry standard notation developed by The Open Group for the graphical modelling of enterprise architectures. The notation has evolved to be fully aligned with TOGAF. Many companies recognise the value of these architectural models to understand the dependencies between their people, processes, applications, data and hardware. Using ArchiMate allows them to integrate their business and IT strategies.

This webinar will demonstrate how Enterprise Architect can be used to create ArchiMate models and viewpoints to understand, document and communicate knowledge of the enterprise architecture. The webinar will:

• Explain the purpose of ArchiMate and how it supports TOGAF
• Show how to model business organisation, processes and products using ArchiMate business layer viewpoints
• Illustrate an application landscape and explore dependencies using ArchiMate application layer viewpoints
• Show how to catalogue company infrastructure (hardware, system software and networks) using ArchiMate technology layer viewpoints
• Demonstrate how to identify stakeholders, drivers, goals and requirements using the ArchiMate motivation extension

To learn more about using ArchiMate within Enterprise Architect, please register for this webinar today.

Guest Presenter: Gillian Adens, Director of Hippo Software.

Learn how to use ArchiMate and Enterprise Architect to model your enterprise architecture. Understand the complex inter-dependencies between people, processes, applications, data and hardware. Use ArchiMate to align your business and IT strategies. Register now to attend on 18th or 19th June 2014.

http://www.sparxsystems.com/resources/webinar/partners/archimate/archimate-introduction-hippo.html

This new training course teaches delegates how to create ArchiMate business and motivation viewpoints in Enterprise Architect. Learn to model business organisation, processes and products and identify stakeholders, drivers, goals and requirements.

Introduction

In the last year I have done a number of projects for a Dutch government agency as a data architect. This organisation has an architecture team with four members. There is a problem in producing architecture documents like Project Start Architectures, it takes too much time and the result has limited value for the projects.  This is mainly caused by the lack of overview on the baseline and the target architecture. There is no overview of the business processes, the application and the infrastructure.

For every project, an architect has to do a lot of research on the baseline architecture first, sometimes this activity takes weeks to get a architecture view that is input for working on the target architecture. Another problem is that every architect has his own tools and techniques for the architecture notations and documents. Although there is an architecture document template, there are large differences in the quality and presentation of these documents. However due to the differences in tools and techniques, every architect starts from scratch for every project.

To tackle these problems the team decided to synchronize their activities, techniques, notation and tools. Therefore the following questions where formulated:

·         Which notation is best to support our architecture documents and diagrams?

·         Based on the selected notation, which tool can help us to make our documents more efficiently?

·         What do we have to change in our team to encourage reuse of existing documents and diagrams?

Below I will describe how we looked for answers to these questions and what lessons we have learned.

ArchiMate

In the Netherlands, there are a lot of architecture methods available like Togaf, Zachman, Dragon1, Demo, DyA and ArchiMate.  Each method has its own characteristics. However which are important for our own organisation. The architecture team did an interactive workshop to formulate the following requirements for the architecture methodology:

·         It must be an open standard and is used in other government agencies for exchanging models.

·         Applicable for all aspects of an enterprise architecture, from business to infrastructure and data architecture.

·         It must be easy to use and easy to read for non IT professionals.

In this interactive workshop a number of extra requirements where formulated and most important we defined a multiplier define the importance for each requirement. The requirements were mapped on a number of architecture methodologies and ArchiMate was the methodology with the highest score.

ArchiMate is an open standard with a powerful notation for all the aspects of enterprise architecture. Since ArchiMate 2.0 there are even extensions for motivation like principles, requirements and stakeholders and project management for plateaus, gaps and work packages. In the figure below you see a sample ArchiMate 2.0 diagram.

Figure 1 Sample ArchiMate notation

After this methodology selection the next step was to evaluate it in a number of projects. For ArchiMate there are Visio Stencils and a number of open source tools. Every architect used the notation for a period of time and during this period we organized a number of sessions to discuss the results. We also organized an interactive session with our non IT stakeholders to evaluate the selected methodology.

In these evaluations we discovered that the ArchiMate notation is valuable for describing the architecture in our organisation. For the notation instruction material was made with example diagrams and describing when to use what ArchiMate viewpoints. However the notation is too rich for most of the situations. So the following categories were introduced:

·         Primary diagrams, should be present in every architecture document

·         Secondary diagrams, only available in complex documents for extra description

During the evaluations it became clear that the Visio stencils and open source tooling had insufficient functionality for the next phase, the implementation of the methodology.

Using Enterprise Architect

Like we did with the notation we formulated a number of requirements including a multiplier for each architect and compared a number of tools with each other. This was done with a simple spreadsheet. In the figure below a part of the spreadsheet

Figure 2: Requirement-Tool matrix

Based on the results of this matrix Enterprise Architect had the best score and we introduced the product. This introduction was done in a number of planned steps. There was a risk that the organisation returned to old habits of working in an unstructured way and introducing a architecture methodology combined with tooling has to be embedded in all the activities of the architects.

In the following sessions I will describe a number of important aspects for introducing Enterprise Architect with ArchiMate.

Repository setup

Already in an early phase of the tool introduction we discovered that the repository content can become messy when you do not think about structuring the elements. Although there is a good project browser search function structuring the project so you can browse for elements is a good aid for the users of the system.

The repository is divided in three sections:

·         Projects,  actual project documents in various stages of completion

·         Reference architecture, elements and diagrams from previous projects that are generic and probably reusable in future projects. This section is subcategorized in a structured manner comparable with the ArchiMate layers and columns

·         Archive, diagrams and elements from projects that are probably not reusable.

Figure 3: Repository setup

Document generation

Introducing an architecture methodology in combination with tooling asks a lot of effort from the involved professionals. It was therefore important to seek for a solution to reduce the production time of the architecture documents, this was the reason why we started this project in the first place.

Already in an early phase of the project document generation was investigated as part of the overall solution. Document generation proved to be a great help to achieve this goal. The standard document templates were changed to our own corporate layout and the layout of the elements was changed for a better readability. The repository setup was changed so it was possible to change ordering and exclude packages from the document generation.

Sharepoint Wiki

In the organisation Microsoft SharePoint is the application for team- and project collaboration. The architecture team used this already and has made a lot of information available in a SharePoint wiki. First approach was to transfer this information to Enterprise Architect. However making links to files and Wiki content from the Enterprise Architect packages and elements turned out to be a good solution. With the links from the screens and the generated documentation to the wiki content people can easily get access to background information.

Custodian

In the repository setup a distinct difference is made to project data and generic data of the reference architecture. Especially this reference architecture is an important aspect of introducing standardization and reusability. Therefore the reference architecture needs special governance. The team decided to introduce a custiodian role. This custodian is responsible for the reference architecture package in the repository. To keep this reference architecture up to date the custodian has the following activities:

·         Give information and instructions to team members about the setup of the reference architecture and how to use the elements and diagrams.

·         Give feedback on diagrams and notation made by team members in project documentation.

·         Select generic diagrams and elements from project documentation for transfer to the reference architecture.

This custodian role turned out to be a very good decision to help introduce the ArchiMate notation, the new methodology and the usage of the tooling in a right manner.  

Lessons Learned

In one year the organisation introduced a new architecture methodology, notation and tooling. Furthermore the production of architecture documents changed dramatically. Some aspects were successful, while others werenot. The most important lessons we learned are

·         Team involvement,  this is most important to make this a success. Every team member must see the advantages of the new methodology. Furthermore, everybody must be an ambassador and therefore should have sufficient influence on the final product.

·         Notation governance, especially in projects under time pressure, it is so tempting to make an simple diagram in Visio or PowerPoint for a few team members. The role of the custodian is in this important to keep everybody involved!

·         Communicate! A new architecture methodology, notation and tooling has a great impact, not only for the team members but for every stakeholder in the organisation. Take care of informing everybody about results, products and other notifications. We made a number of posters of architecture diagrams for important projects and that helped a lot (see figure 4)

·         ArchiMate 1 and 2, there are two versions of ArchiMate in notation and in Enterprise Architect. At first we decided that we used these notation together. This turned out to be a wrong decision. Not only was it confusing, the tooling has strange behaviour when using the versions simultaneous.

Figure 4 Project Poster

Conclusion

The introduction of ArchiMate in combination with tooling was not always easy. There are a lot of options and it was difficult to make the right choice, especially for the methodology. Introducing a new working proceedure was not simple for evberybody. The custodian role helped a lot here. Enterprise Architect in combination with ArchiMate 2.0 turned out to be a good choice. The tooling is easy to use, has sufficient search capabilities, can be adapted easily for document generation and connection with existing applications like SharePoint.