ArchiMate® 3.0 Visio 2003-2010 Stencils Download ZIP package ArchiMate 3.0 Visio 2003-2010 Stencil set v1.0.zip This work is licensed under CC BY-NC-ND license.

1. The ArchiMate Specification, an Open Group Standard, is an open and independent modeling language for Enterprise Architecture modeling. This article provides an overview of the ArchiMate 3.0 Specification which is a major update to the ArchiMate 2.1 Specification and was published as an Open Group Standard in June 2016.
2. A new set of ArchiMate 3.0 shapes has been added in draw.io.
3. A new set of ArchiMate 3.0 shapes has been added in draw.io.

Archi^® fulfils the needs of most Enterprise Architects and associated stakeholders, and has been designed to elegantly provide the main features required for ArchiMate modelling and is used globally by banks, insurance companies, industry, EA consultants, training organisations, universities, and students. It is probably the most popular ArchiMate modelling tool and is downloaded on average about 5,000 times every month.

Download Archi

The latest release of Archi supports the latest version of the ArchiMate language – ArchiMate 3.1. It also includes the ability to exchange models with The Open Group’s ArchiMate exchange format. The exchange format means that you can share your models between different ArchiMate tools and access your model data with other modelling frameworks. The latest release of Archi also contains many new features and fixes. Each new release just gets better and better!

Support Archi

If you find Archi useful in your work and you’d like to help us maintain Archi, a donation would be most welcome, and we accept PayPal, or you could become a patron on Patreon. All development work and support is done for free. A small donation would be much appreciated!

Fully featured

Supporting the ArchiMate® 3.1 language

The Archi® modeller is targeted toward all levels of Enterprise Architects and Enterprise Modellers. It offers an open source software solution to modellers who may be making their first steps in the ArchiMate language. Easily and intuitively create all ArchiMate elements and relations in all of the ArchiMate views. Use the magic connector to create the right connections. Refine your model with user-defined properties, and colourise your diagram with your own colour scheme.

Dynamic Viewpoints

Dynamic Viewpoints let you change the ArchiMate Viewpoint at any time. Any elements that are not permitted for that Viewpoint are “ghosted” out or hidden. Dynamic Viewpoints allow you to change your mind. You don’t have to decide up-front what the Viewpoint will be. You can experiment with different Viewpoints for the same View. And if you decide to keep the Viewpoint, you can simply remove any disallowed elements from the View. You could even set up one master View and apply different Viewpoints in a “what if” scenario.

Hints View

Helping you understand ArchiMate.

If you’re not sure what element to use, or what relationship to connect, simply fire up the Hints view. All ArchiMate elements, relationships and viewpoints are described to provide you with the right information at your fingertips, just when you need it.

The Visualiser

Connecting the dots.

The Visualiser displays the selected model element and all of its relationships with other model elements in a radial-tree graphic. It is the graphical equivalent of the Navigator. Selecting an element or relationship in the Model Tree, the Navigator or in a Diagram View will update the selection in the Visualiser. Drill in to see more connections.

Cross Platform

Windows, Mac or Linux? We’ve got you covered.

Archi is fully cross-platform as it is written in Java on the Eclipse Rich Client Platform. Therefore it works on Windows 7, 8 and 10, Mac OS X, and most Linux distros right out of the box. You don’t have to worry about sharing models across installations. A portable version and an installer version is available for Windows.

Sketch View

Sketching your ideas.

Brainstorm your ideas with elements written on “stickies”. Quickly design and create “soft” models, capturing the essence of your modelling process without worrying about the technicalities of the language. Share and refine your ideas before transforming them to ArchiMate views.

Canvas Modelling Toolkit

Create your own canvas world.

The Canvas Modelling Toolkit provides the tools for you to create and edit your own canvasses. With the Canvas Modelling Toolkit you can design and create re-usable Canvas Templates to share with colleagues or you use it as a pre-design tool to sketch out ideas and models.

6.1Motivation Elements Metamodel

Figure 34 gives an overview of the motivation elements and their relationships.

Figure 34: Motivation Elements Metamodel

Note: This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7. The full specification of permitted relationships can be found in Appendix B.

6.2.1Stakeholder

A stakeholder represents the role of an individual, team, or organization (or classes thereof) that represents their interests in the effects of the architecture.

This definition is based on the definition in the TOGAF framework [4]. A stakeholder has one or more interests in, or concerns about, the organization and its Enterprise Architecture. In order to direct efforts to these interests and concerns, stakeholders change, set, and emphasize goals. Stakeholders may also influence each other. Examples of stakeholders are the Chief Executive Officer (CEO), the board of directors, shareholders, customers, business and application architects, but also legislative authorities. The name of a stakeholder should preferably be a noun.

Figure 35: Stakeholder Notation

6.2.2Driver

A driver represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.

Drivers that are associated with a stakeholder are often called “concerns” of that stakeholder. Stakeholder concerns are defined in the TOGAF framework [4] as “an interest in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.” Examples of internal drivers are customer satisfaction and profitability. Drivers of change may also be external to the enterprise (e.g., economic changes or changing legislation) and need not have a stakeholder associated with them. The name of a driver should preferably be a noun.

Figure 36: Driver Notation

6.2.3Assessment

An assessment represents the result of an analysis of the state of affairs of the enterprise with respect to some driver.

An assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These need to be addressed by adjusting existing goals or setting new ones, which may trigger changes to the Enterprise Architecture.

Strengths and weaknesses are internal to the organization. Opportunities and threats are external to the organization. Weaknesses and threats can be considered as problems that need to be addressed by goals that “negate” the weaknesses and threats. Strengths and opportunities may be translated directly into goals. For example, the weakness “Customers complain about the helpdesk” can be addressed by defining the goal “Improve helpdesk”. Or, the opportunity “Customers favor insurances that can be managed online” can be addressed by the goal “Introduce online portfolio management”. The name of an assessment should preferably be a noun or a (very) short sentence.

Figure 37: Assessment Notation

The stakeholder “Chief Marketing Officer (CMO)” is concerned with the driver “Market Share”, the stakeholder “Chief Executive Officer (CEO)” is concerned with the drivers “Market Share” and “Profitability”, and the stakeholder “Chief Financial Officer (CFO)” is concerned with the driver “Profitability”. The driver “Profitability” is composed of two other drivers: “Revenue” and “Costs”. Several assessments are associated with these drivers (e.g., the assessment “Market Share Is Declining” is associated with driver “Market Share”), and assessments may influence each other in a positive or negative way (e.g., “Market Share Is Declining” results in “Revenue Is Declining”, which in turn results in “Profitability Is Declining”).

Example 18: Stakeholder, Driver, and Assessment

The motivation of an organization or individual to achieve certain results is represented by goals, principles, requirements, and constraints. Goals represent that a stakeholder wants to realize a certain outcome; e.g., “Increase customer satisfaction by 10%”. The end results realized by capabilities that realize these goals are outcomes. Principles and requirements represent desired properties of solutions – or means – to realize the goals. Principles are normative guidelines that guide the design of all possible solutions in a given context. For example, the principle “Data should be stored only once” represents a means to achieve the goal of “Data consistency” and applies to all possible designs of the organization’s architecture. Requirements represent formal statements of need, expressed by stakeholders, which must be met by the architecture or solutions. For example, the requirement “Use a single CRM system” conforms to the aforementioned principle by applying it to the current organization’s architecture in the context of the management of customer data.

A goal represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.

In principle, a goal can represent anything a stakeholder may desire, such as a state of affairs, or a produced value. Examples of goals are: to increase profit, to reduce waiting times at the helpdesk, or to introduce online portfolio management. Goals are typically used to measure success of an organization.

Goals are generally expressed using qualitative words; e.g., “increase”, “improve”, or “easier”. Goals can also be decomposed; e.g., “increase profit” can be decomposed into the goals “reduce cost” and “increase sales”. However, it is also very common to associate concrete outcomes with goals, which can be used to describe both the quantitative and time-related results that are essential to describe the desired state, and when it should be achieved.

Figure 38: Goal Notation

6.3.2Outcome

Outcomes are high-level, business-oriented results produced by capabilities of an organization, and by inference by the core elements of its architecture that realize these capabilities. Outcomes are tangible, possibly quantitative, and time-related, and can be associated with assessments. An outcome may have a different value for different stakeholders.

The notion of outcome is important in business outcome-driven approaches to Enterprise Architecture and in capability-based planning. Outcomes are closely related to requirements, goals, and other intentions. Outcomes are the end results, and goals or requirements are often formulated in terms of outcomes that should be realized. Capabilities are designed to achieve such outcomes.

When modeling a future state, an outcome models an end result that is expected to have been achieved at that future point in time. Unlike goals, outcomes can also be used to model potentially unwanted end results; for example, in order to design appropriate mitigating measures.

Outcome names should unambiguously identify end results that have been achieved or are expected to be achieved at a definite point in the future. Examples include “First-place customer satisfaction ranking achieved” and “Key supplier partnerships in place”. Outcome names can also be more specific; e.g., “10% year-over-year quarterly profits increase in 2018”.

Figure 39: Outcome Notation

A principle represents a statement of intent defining a general property that applies to any system in a certain context in the architecture.

The term “system” is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again. Therefore, a system may refer to any active structural element, behavior element, or passive structural element of some organization, such as a business actor, application component, business process, application service, business object, or data object.

Principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context, whereas a requirement defines a property that applies to a specific system as described by an architecture. For example, the principle “Information management processes comply with all relevant laws, policies, and regulations” is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.

Figure 40: Principle Notation

6.3.4Requirement

A requirement represents a statement of need defining a property that applies to a specific system as described by the architecture.

In the end, a business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system.

Requirements model the properties of these elements that are needed to achieve the “ends” that are modeled by the goals. In this respect, requirements represent the “means” to realize goals.

Nitro pdf editor free. download full version 64 bit. During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties that can be exhibited by systems. At this point, goals can be realized by requirements that demand these properties from the systems.

For example, two alternative requirements may be identified to realize the goal “Improve portfolio management”:

•By assigning a personal assistant to each customer, or

•By introducing online portfolio management

The former requirement can be realized by a human actor and the latter by a software application. These requirements can be decomposed further to define the requirements on the human actor and the software application in more detail.

Figure 41: Requirement Notation

6.3.5Constraint

A constraint represents a factor that limits the realization of goals.

In contrast to a requirement, a constraint does not prescribe some intended functionality of the system to be realized but imposes a restriction on the way it operates or may be realized. This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), a restriction on the implementation process (e.g., time or budget constraints), or a restriction on the functioning of the system (e.g., legal constraints).

Figure 42: Constraint Notation

6.3.6Example

The goal “Improve Profitability of Service Offering” is realized by the outcome “Increased Profit by 10% in Next Fiscal Year”. This outcome is influenced positively by the outcomes “Increased Revenue by 20% in Next Fiscal Year” and “Reduced Cost of Customer Acquisition by 25%”. The outcome “Increased Revenue by 20% in Next Fiscal Year” is influenced positively by an outcome “Increased Market Share by 10% in Next Fiscal Year”. There is also a negative outcome: “Increased Technology Expenditure by 10%”. These outcomes are realized by a combination of two principles: “Serve Customers Wherever They Are” and “Serve Customers Whenever They Need Our Help”. Both of these principles are realized by a combination of two requirements: “Mobile Applications Shall Run On All Popular Mobile Platforms” and “Services Shall Be Accessible Through Mobile Browsers”. The goal “Reduced Cost Of Customer Acquisition by 25%” is realized by a principle “Respond To Changing Customer Needs, Preferences, And Expectations Quickly And Efficiently”, which in turn is realized by a constraint “Mobile Applications Shall Be Built With Cross-Platform Frameworks”.

Example 19: Goal, Outcome, Principle, Requirement, and Constraint

Different stakeholders may attach a different value to outcomes, since they may have different interests. Similarly, they may give their own meaning or interpretation to core elements of the architecture.

Meaning represents the knowledge or expertise present in, or the interpretation given to, a concept in a particular context.

A meaning represents the interpretation of a concept of the architecture. In particular, this is used to describe the meaning of passive structure elements (for example, a document, message). It is a description that expresses the intent of that element; i.e., how it informs the external user.

It is possible that different users view the informative functionality of an element differently. For example, what may be a “registration confirmation” for a client could be a “client mutation” for a CRM department (assuming for the sake of argument that it is modeled as an external user). Also, various different representations may carry essentially the same meaning. For example, various different documents (a web document, a filled-in paper form, a “client contact” report from the call center) may essentially carry the same meaning.

A meaning can be associated with any concept. To denote that a meaning is specific to a particular stakeholder, this stakeholder can also be associated to the meaning. The name of a meaning should preferably be a noun or noun phrase.

Figure 43: Meaning Notation

6.4.2Value

Value represents the relative worth, utility, or importance of a concept.

Value may apply to what a party gets by selling or making available some product or service, or it may apply to what a party gets by buying or obtaining access to it. Value is often expressed in terms of money, but it has long since been recognized that non-monetary value is also essential to business; for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though value can hold internally for some system or organizational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship.

A value can be associated with any concept. To model the stakeholder for whom this value applies, this stakeholder can also be associated with that value. Although the name of a value can be expressed in many different ways (including amounts, objects), where the “functional” value of an architecture element is concerned it is recommended to try and express it as an action or state that can be performed or reached as a result of the corresponding element being available.

Figure 44: Value Notation

6.4.3Example

Sending push notifications has a value of “Cost Efficiency” for the stakeholder “Insurer”, and a value of “Being Informed” and “Peace of Mind” (which is partly due to a value of “Certainty”) for the stakeholder “Customer”. Different meanings can be assigned to the different specific types of notification messages. A “Confirmation Of Receipt Message” has the meaning “Claim Has Been Received”, a “Review Complete Message” has the meaning “Claim Review Complete”, and a “Payment Complete Message” has the meaning “Claim Has Been Paid”.

Example 20: Meaning and Value

6.5Summary of Motivation Elements

Archimate Diagrams

Table 4 gives an overview of the motivation elements, with their definitions.

Table 4: Motivation Elements

The purpose of the motivation elements is to model the motivation behind the core elements in an Enterprise Architecture. Therefore, it should be possible to relate motivation elements to core elements.

As shown in Figure 45, a requirement (and, indirectly, also a principle, outcome, and goal) can be related directly to a structure or behavior element by means of a realization relationship. Also, the weaker influence relationship is allowed between these elements. Meaning and value can be associated with any structure or behavior element.

Figure 45: Relationships Between Motivation Elements and Core Elements

Downloads

Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to anyorganization wishing to use ArchiMate documentation entirely for internal purposes.A book is also available from The Open Group Library as document C197.

Archimate Visio