ArchiMate application and data architecture layer - Simplify the models

Competensis®
Christine Dessus
chdessus@competensis.com
+336 31 09 73 54
www.competensis.com
COMPETENSIS® est une marque déposée. Ce document n’est pas libre de droit et ne doit pas être utilisé sans le consentement écrit de son ou ses auteurs.

ArchiMate Application Layer
Christine DESSUS – January 2022

Sources
• https://pubs.opengroup.org/architecture/archimate3-doc/
• www.archimatetool.com
• https://www.linkedin.com/in/benoit-arsenne-5b2297133/
Thank you Benoit for our collaboration and the hard work we did between 2019 and 2021 to deploy ArchiMate.
COMPETENSIS - ArchiMate Application & data Layer
3

Hardware
Servers,
computers, virtual
or physical
Network
components
New advanced
devices: chatbot,
IOT, robot, any
piece of
automation
Softwares
Components
software
Databases,
middleware
Data Files
Human
resources
Company leaders
Designers
Support teams
Users
Customers
Supplyers,
providers, partners
Roles &
responsabilities
Organisations
Entreprise(s)
Departments,
groups
Job description
Culture
Operating
procedures
Environment
Regulations
•RGPD in France
•Any other suitable for
your business
Any political,
social, economic
factror
Competitors
activities
Information
&
Data
Informations
received from the
outside
Informations
transformed
Informations sent
to the outside
Digital data
Documents: paper
or digital (any
representation)
Information system
Human aspects Environnement Informations &
Data
Technology aspects
5 COMPETENSIS - ArchiMate Application & data Layer

Open-group standards
Togaf®
ArchiMate®

EnterpriseArchitecture
• Any collection of organizations that has a common set of goals and/or a single ‘bottom
line’.
• Define your scope of modeling with LOCATIONS, BUSINESS FUNCTIONS, BUSINESS
PROCESSES and CAPABILITIES

Define the scope
• Always define the scope of modeling:
✓ Breadth: the enterprise as a whole or a
specific set of organizations, business
processes, business functions, capabilities…
✓ Architecture domains/Layers:Technology,
Application, Data, Business
✓ Depth: level of details expected
8
https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html

Define the scope
• A model is a simple (or simplified) representation of reality to answer a question, a
need
• A single model cannot answer all the questions, all the needs
• Before to start modeling with ArchiMate, always defined the expectations:
✓ What are the application services used, internal, external?
✓ Are the application services already modeled by someone else? How can I reuse it?
Duplicate the existing model (generally not a very good idea) or make a link to the
existing model?
✓ Connect-the-dots with theTechnology layer, Business layer and Capability Maps
✓ Do we need to identify services that are provided by external partners?

Architect
Role & Responsibility

Open discussion: Clarify Roles & Responsibilities
•Architect
OR
•Designer
Sometimes
•Both
Architect:
▪ Ensure a systemic vision and focus on a global, holistic vision
▪ Focus on integration with other layers: business, technology
building blocks
▪ Focus also on integration of all application building blocks
▪ Is a generalist in charge of providing the global vision
Designer:
▪ Focus on solutions provided
▪ Focus on requirements
▪ Could be a building block « specialist » to deploy subsystems
▪ Has a project mindset, focus on realizations

Architect:
building blocks
Designer:
•Architect
OR
•Designer
Sometimes
•Both
Is able to provide ArchiMate high level
maps/viewes for all/some layers (Atlas)
Is able to provide ArchiMate solution
modeling for the technologies
promoted/proposed

Architect:
building blocks
Designer:
•Architect
OR
•Designer
Sometimes
•Both
Ensure that global maps/viewes shared by
everyone are always up-to-date and coherent
During the project phases, ensure that solutions
are modeled according to architectural decisions.
During operational maintenance phases, ensure
that maps/viewes are always up-to-date

Architect First
Role:
Ensures the
vertical systemic
vision
• The architect is a "generalist" who has a global vision of the
application stacks on which systems and subsystems are
based.
• He/She understands the challenges and risks
• He/She must be aware of all the layers on which the system
and subsystems is built
• He/She must understand the requirements from the business
(WHY):
✓Upper architecture layers : business processes (and business
functions), contribution to capabilities, application layers
• He/She must understand the constraints and requirements
from the technology layer
• He/She has a global knowledge of all projects having an
impact on the system/subsystem description
https://www.linkedin.com/in/benoit-arsenne-5b2297133/

Architecture Principles
and Architecture
Decisions

Architecture Principles
• A principle is a rule that has to be followed
• A code of conduct for a specific system or
behaviour
• Architects and Designers should accept
these rules or principles as the fundamental
elements to build systems and make
decisions
• Application Maps/Viewes should reflect the
acceptance of these rules
In many companies, principles are tacit.
Valid in a team but not in another one
Use of habits, oral knowledge
Lead to variation in decisions and
integration discrepencies
Use ArchiMate to model Principles

Architecture Decisions
• A decision is a choice that you make about something
• A decision is the result of deciding:
✓After a design process that shows the various open solutions that meet the Architecture
Principles
• Decisions are always justified by a Principle
• Could be good to document decisions with a SWOT analysis (example)
• Use ArchiMate to model at least the final decision
✓Decision process can remain in PPT documents but… Do not forget to provide URL links to
the decision process documents

Architecture Decisions
• Subject Area: Driver
• (explaining the) Issue: Assessment
• Architecture Decision: Goal
• Assumption: Constraint
• Justification (Rationale): Principle
• Derived Requirements: Requirements
https://forum.archimatetool.com/index.php?topic=668.0

Layers Integration
• Key to perform impact analysis
✓What-if an important business process or organization
change occurs? What impact on applications and technology
layer?
✓What-if a technology obsolescence change process occurs?
What impact on business activities?
• Key to define the system and subsystems parts
Recommendation:
EachArchiMate view shows
the relationship with the
“upper” and/or “lower”
layer.

Layers Integration
• Each layer has the responsibility to link with at least one other layer
• Each ArchiMate view should show these relationships
Layer Linked to
Business Application
Capability
Application Business
ITTechnology
Capability
ITTechnology Application
Capability
Strategy/Capability Business
Application
ITTechnology

Layers Integration | Examples of most common relationships
• Business layer WITH Application layer

• Application layer WITH Technology layer

• 3 layers integration
✓Please, keep it simple
✓Do not overload diagrams with all detailed
information

Complex integration of Architecture Layers
EXEMPLE

Complex integration of Architecture Layers
Make or Buy:
- Brewing beer
- Purchase & logistics
Serving beer
Brewing beer equipment
Purchase application
Manufacturing & production system
EXAMPLE

RELATIONS (Reminder)
• Composition
• Aggregation
• Realization
• Assignment
• Serving
• Access
• Influence
• Triggering
• Flows
• And
• Or
• Specialization
• Association
Structural Dependency Dynamic Connectors Other
27
A connection between a source and target building blocks

ArchiMate® 3.1
Aspects
Core layers

Application layer specificity
•Application layer covers both Data architecture and
Application architecture
•A consensus layer owned by:
✓Business teams
✓IT teams
30

Application building blocks
•Used to describe the application layer
•Identify:
✓New application building blocks being introduced
✓Existing application building blocks to be carried over and supported.

Data building blocks
•Used to describe data architecture
•Identify:
✓New data building blocks being introduced
✓Existing data building blocks to be carried over and supported.

Recommendations
•Make simple simple simple simple simple models
•No technology description
•Vocabulary should be « end-user » accessible, business value
oriented, no need for a translator of IT technology vocabulary.

Application building
blocks
Most used building blocks

APPLICATION COMPONENT
• Category:Active Structure element
• An encapsulation of application functionality aligned to implementation
structure, which is modular and replaceable.
• A self-contained unit
✓It is independently deployable, re-usable, and replaceable.
✓Performs one or more Application Functions. It encapsulates its contents: its
functionality is only accessible through a set of Application Interfaces.
• CooperatingApplicationComponents are connected via Application
Collaborations.
• Examples: invoicing system,CRM, payroll system…
Definition based on
SOA principles
Technically, an
application
component may be
realised by one or
more system
softwares

APPLICATION SERVICE
• Category: behaviour
• An explicitly defined exposed application behaviour.
• Exposes the functionality of components to their environment.This
functionality is accessed through one or more Application Interfaces.
• An Application Service is realized by one or more Application Functions that
are performed by the component. It may require, use, and produce Data
Objects.
• An Application Service should provide a unit of behaviour that is useful to its
users. It has a purpose, which states this utility to the environment :
✓AnApplication Service may serve Business Processes, Business Functions
✓AnApplication Function may realize an Application Service.
✓AnApplication Service may access Data Objects.
• The name of an Application Service should preferably be a verb ending with
"ing".
• Examples:Transaction Processing, Payment Service, Customer Admin
Service.

APPLICATION SERVICE & APPLICATION COMPONENT
Source Relation type Target Description
ApplicationComponent
Serve
Application Service
Contributes to but may not be sufficient to fully realize the service
Trigger TheApplication Service may be an external service not supported by an
application under the responsibility of the organisation.
It may be an external service purchased from a supplier.
Realize Fully realize the application service
Application Service Is assigned to ApplicationComponent The responsibility to realize the service has been assigned to a specific
application component in a specific context. Could be a different application
component in another context. Maybe in another context, no application
component has been defined.

APPLICATION FUNCTION
• Category: Behaviour
• Automated behaviour that can be performed by anApplication
Component.
• Describes the internal behaviour of an ApplicationComponent.
If this behaviour is exposed externally, this is done through one or
more services.
• May realize one or more Application Services
✓Application Services of other Application Functions andTechnology
Services may serve an Application Function.
✓AnApplication Function may access Data Objects.
✓AnApplication Component may be assigned to an Application Function
(which means that the Application Component performs the Application
Function).
• The name of anApplication Function should preferably be a verb
ending with "ing".

APPLICATION FUNCTION & APPLICATION COMPONENT
Source Relation type Target Description
ApplicationComponent
Serve
Application Function
Contributes to but may not be sufficient to fully realize the function
Trigger TheApplication Function may be an external function not supported by an
application under the responsibility of the organisation.
It may be an external function purchased from a supplier.
Realize Fully realize the application function
Application Function Is assigned to ApplicationComponent The responsibility to realize the function has been assigned to a specific
application component in a specific context. Could be a different application
component in another context. Maybe in another context, no application
component has been defined.

APPLICATION FUNCTION & APPLICATION SERVICE &
APPLICATION COMPONENT
Describes the internal behaviour of an Application
Component; for the user of an Application Component that
performs an Application Function, this function is invisible.
Describes the exposed behaviour to end-users of an
Application Component
Describes a modular set of functionalities that could be
Application Services or Application Functions
No COMPOSITION or
AGGREGATION relations ➔
Modular, SOA vision
FLOW RELATIONSHIPS are
described with the « solution
concept » description

LOCATION
• Category: Composite
• A conceptual or physical place or position where building
blocks are located (e.g., structure elements) or performed
(e.g., behavior elements).
• Very often used to describe places where applications are used

GROUPING
• Category: Composite
• The Grouping element aggregates or composes
building blocks that belong together based on some
common characteristic.
• An Aggregation or Composition relationship is used
to link the Grouping element to the grouped
building blocks.
• Example: Aggregate two Processes and a Business
Object that together Realize a Service, define a
subsystem composition.

Application building
blocks
Building blocks used in specific
circumstances

Building Blocks used in specific circumstances
• Application Interface/ Active Structure
✓A point of access where application services are made available to a
user, another application component, or a Node.
✓Specifies how the functionality of a Component can be accessed by
other elements. AnApplication Interface exposes Application Services
to the environment.
✓An Application Interface may be part of an ApplicationComponent
• Application Process/ Behaviour
✓A sequence of application behaviors that achieves a specific result.
✓Describes the internal behaviour performed by an Application
Component that is required to realize a set of services.
✓May realizeApplication Services.
• Application Event/Behaviour
✓an application state change
✓Examples: data received

Building Blocks used in specific circumstances
• Application Collaboration/Active Structure
✓An aggregate of two or more application internal active structure
elements that work together to perform collective application
behavior
• Application Interaction/ Behaviour
✓Forget it
✓Prefer the use of Application Service or Application Function

DATA OBJECT
• Category: Passive Structure element
• A set of data structured for automated
processing.
• A Data Object should be a self-contained
piece of information with a clear meaning to
the business, not just to the application level.
• An Application Function or process can
operate on Data Objects.
• The name of a Data Object should preferably
be a noun.

DATA OBJECT
• A Data Object may realize a Business Object and may be realized by an Artifact.
Business Concept
Automated set of data. No technology concern
Automated set of data. Database, tables, attributes may be defined

DATA OBJECT
• A Data Object may be accessed by a Business Process, Business Function in order to show that these
behavioural elements are using automated data

DATA OBJECT
• A Data Object may haveAssociation, Specialization,Aggregation, or Composition relationships with other
Data Objects.
• Same relationships inUML used for Class Diagramming

DATA OBJECT
• A Data Object may be communicated via interactions
FLOW

DATA OBJECT
• A Data Object may be used or produced by Application Services. A Data Object can be accessed by an
Application Function or Application Service.

Context Diagram
Solution Concept
(TOGAF®)

Data exchange
• The Application ComponentA trigger B
➔ Relation =Triggering
• C is sending data to D
➔ Relation = Flows
• H is sending data to I.The Data Object is
associated to the Flow relationship
between H and I.
➔ Relation = Flows between H and I
55

Data exchange
• Application components E,F,G,H,I are
sharing a same set of data.
• Applications E and G update data (WRITE)
• Applications F and I are reading data
(READ)
• Application I is readinig and updating data
(READ/WRITE)
• For some applications (H), we do not know
yet the access type (ACCESS)
➔ Relation = ACCESS.The relationship from the dataset
to the application component shows the reading access.
The relationship from the application component to the
dataset shows a writing access
56

Specific use of FLOW relationships
• Application Components,Application
Services and Application Functions can
exchange data with FLOW relationships.
57

ArchiMate application and data architecture layer - Simplify the models

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ArchiMate application and data architecture layer - Simplify the models

Similar to ArchiMate application and data architecture layer - Simplify the models (20)

More from COMPETENSIS

More from COMPETENSIS (20)

Recently uploaded

Recently uploaded (20)

ArchiMate application and data architecture layer - Simplify the models