Opportunity

An opportunity refers to a positive external factor that can be leveraged to improve a process, workflow, or journey. It is a chance or possibility that can be seized to create benefits and enhance outcomes. For example, in a customer journey map, an opportunity might refer to a new market or a gap in the market that can be filled.

Outcome : Archimate

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.
Outcome names should unambiguously identify end results that have been achieved in order to avoid confusion with actions or goals. At a minimum, outcome names should consist of a noun identifying the end result followed by a past-tense verb or adjective indicating that the result has been achieved. Examples include “First-place ranking achieved” and “Key supplier partnerships in place”. Outcome names can also be more specific; e.g., “2015 quarterly profits rose 10% year over year beginning in Q3”.

Package

A package is a general purpose grouping mechanism.

Package properties

The Package tab

Property  Metamodel name Description
Short Description ShortDescription
Display contents Display Initial value is off.
Visibility Visibility Choices are:
Protected
Public
Private
Package
Owns Owns Links to: All templates.

The References tab

Property  Metamodel name Description
References References Links to: All templates.

The Extensions tab

Property  Metamodel name Description
Stereotype Stereotype Links to: Stereotype.
Constraints HasConstraints Links to: Constraint.
Tagged values HasTaggedValues Links to: TagDefinition.

Parameter

Description of a parameter to or from an operation.

Parameter properties

The Parameter tab

Property  Metamodel name Description
Default value DefaultValue
Kind Kind Choices are:
in
out
inout
return
Type HasType Links to: DataType, Interface, Class.
Transfer method TransferMethod Choices are:
value
reference
pointer

The Extensions tab

Property  Metamodel name Description
Stereotype Stereotype Links to: Stereotype.
Constraints HasConstraints Links to: Constraint.
Tagged values HasTaggedValues Links to: TagDefinition.

Partner Link

A PartnerLink is a physical place where a process is running

Path : ArchiMate

A path is used to model the logical communication (or distribution) relations between nodes. It is realized by one or more communication networks (or distribution networks when modeling physical elements; see Chapter 11), which represent the physical communication (or distribution) links. The properties (e.g., bandwidth, latency) of a path are usually aggregated from these underlying networks.
A path connects two or more nodes. A path is realized by one or more networks. A path can aggregate nodes.

Path properties

The Path tab

Property  Metamodel name Description
Short description ShortDescription
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Peripheral

A peripheral can be any type of item which exists in the infra structure which you want to add to a InfraStructureDiagram. Typically it is a hardware device which is physically defined by a HardwareComponent.

Peripheral properties

The Peripheral tab

Property  Metamodel name Description
Short Description ShortDescription A short description of the item
Type PeripheralType The type of the peripheral.
Show ShowType Display the type next to the symbol on diagrams.
Initial value is off.
Hardware Hardware The hardware or computer that implements the peripheral.
Links to: Computer, HardwareComponent.
IP Address IPAddress The IP address of the device if the address is fixed
Logical name/address LogicalAddress The logical name or address of the item.
Show ShowNetworkName Display the network name next to the symbol on diagrams.
Initial value is off.
Vendor Vendor The vendor of the item. The vendor might for instance be an internal organisation unit or an external supplier.
Links to: BusinessConnection, ExternalEntity, OrganizationUnit.
Support Support The support provider.
Links to: BusinessConnection, Person, ExternalEntity, OrganizationUnit.

The Economy tab

Property  Metamodel name Description
Date of purchase DateOfPurchase When the item was purchased
Warranty expires WarrantyExpires When the warranty of the item expires
Contracts HasContract All the different contracts connected to the item.
Links to: Contract.

Plateau : ArchiMate

An important premise in the TOGAF framework is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the ADM, a Baseline Architecture and Target Architecture are created, describing the current situation and the desired future situation. In Phase E (Opportunities and Solutions), so-called Transition Architectures are defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage.
In order to support this, the plateau element is defined.Plateau propertiesThe Plateau tab

Property  Metamodel name Description
Short description ShortDescription
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Policy

A policy is a symbol that represents a set of rules or guidelines that govern an organization’s behavior, decisions, or actions. Policies can be depicted in various types of diagrams, such as Requirement Model, Strategy Model, or Value Chain Model, among others.

Here are some examples of policies that could be represented as symbols in diagrams:

  • Acceptable Use Policy: a policy that outlines acceptable and unacceptable behaviors when using an organization’s technology or network resources.
  • Security Policy: a policy that defines how an organization’s information and technology assets should be protected from unauthorized access, use, disclosure, disruption, modification, or destruction.
  • Privacy Policy: a policy that informs individuals how their personal information is collected, used, stored, and shared by an organization.
  • Environmental Policy: a policy that establishes an organization’s commitment to sustainability and outlines its approach to minimizing its environmental impact.
  • Human Resources Policy: a policy that governs employee conduct, benefits, leave, compensation, and other employment-related matters within an organization.
  • Compliance Policy: a policy that outlines an organization’s commitment to complying with relevant laws, regulations, standards, and guidelines in its operations and activities.

These are just a few examples of policies that could be represented as symbols in diagrams. The specific content and format of policies may vary depending on the organization’s industry, size, mission, values, and other factors.

Pool

A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g, a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer).

Graphically, a Pool is a container for partitioning a Process from other Pools, when modeling business-to-business situations, although a Pool need not have any internal details (i.e., it can be a “black box”). ° A Pool is a square-cornered rectangle that MUST be drawn with a solid single black line. One, and only one, Pool in a diagram MAY be presented without a boundary. If there is more than one Pool in the diagram, then the remaining Pools MUST have a boundary.

To help with the clarity of the Diagram, A Pool will extend the entire length of the Diagram, either horizontally or vertically. However, there is no specific restriction to the size and/or positioning of a Pool. Modelers and modeling tools can use Pools (and Lanes) in a flexible manner in the interest of conserving the “real estate” of a Diagram on a screen or a printed page.

A Pool acts as the container for the Sequence Flow between activities. The Sequence Flow can cross the boundaries between Lanes of a Pool, but cannot cross the boundaries of a Pool. The interaction between Pools, e.g., in a B2B context, is shown through Message Flow.

Another aspect of Pools is whether or not there is any activity detailed within the Pool. Thus, a given Pool may be shown as a “White Box,” with all details exposed, or as a “Black Box,” with all details hidden. No Sequence Flow is associated with a “Black Box” Pool, but Message Flow can attach to its boundaries.

For a “White Box” Pool, the activities within are organized by Sequence Flow. Message Flow can cross the Pool boundary to attach to the appropriate activity.
All BPDs contain at least one Pool. In most cases, a BPD that consists of a single Pool will only display the activities of the Process and not display the boundaries of the Pool. Furthermore, a BPD may show the “main” Pool without boundaries. In such cases there can be, at most, only one invisibly-bounded pool in the diagram and the name of that pool SHALL be the same as the diagram. Consequently, the activities that represent the work performed from the point of view of the modeler or the modeler’s organization are considered “internal” activities and need not be surrounded by the boundaries of a Pool, while the other Pools in the Diagram must have their boundary.

In QualiWare, the user can specify if the Pool is of a scope of Private (Internal), Abstract (Public), or Collaborative (Global).
The Participant field identifies the role associated with the Pool, or the process that is being executed within the Pool. Since there can be multiple Pools in one BusinessProcessDiagram in QualiWare, it is sometimes important to define the role that is being fulfilled within the Pool.

The Uses Parameter field in QualiWare, on the Pool tab of the Pool Object Editor, permits the user to specify if there is some specific parameter or value essential to the execution of the process that the Pool contains.

The Included in Service field allows the user to specify if there is a unique service associated with the process that is contained in the Pool.

The Target Namespace field allows the QualiWare user to define the scope of the process that is contained in the Pool.