Enterprise Architecture can quickly become difficult to communicate.
A business executive talks about customer outcomes. A product manager talks about products and capabilities. A software architect talks about applications, APIs, and microservices. An infrastructure architect talks about Kubernetes clusters, networks, databases, and cloud platforms.
All of them may be discussing the same system — but using completely different languages.
This is the problem that ArchiMate® is designed to solve.
ArchiMate is an open Enterprise Architecture modelling language maintained by The Open Group. It provides architects with a standardized vocabulary for describing organizations, business processes, applications, information, technology infrastructure, strategy, motivation, and transformation.
The current specification is ArchiMate 3.2, released in October 2022.
In this tutorial, we will learn enough ArchiMate to start creating useful architecture models without attempting to memorize the entire specification.
More importantly, we will look at four practical examples showing how ArchiMate can support architects working according to the Open Agile Architecture™ (O-AA™) Standard.
What is the relationship between ArchiMate and O-AA?
Before looking at the notation, it is important to distinguish the two.
Open Agile Architecture (O-AA) provides an approach to architecture suitable for digital and Agile organizations.
Among other things, O-AA emphasizes:
- business outcomes
- customer experience
- digital products
- product-centric organizations
- Agile teams
- continuous evolution
- architecture supporting Agile at scale
- product and operations architecture
- Agile Security Architecture
The Open Group describes O-AA as an outcome-based, customer-focused, and product-centered approach to architecture.
ArchiMate, on the other hand, gives us a language with which we can draw those architectures.
Think of the distinction like this:
O-AA tells us how to think about Agile Architecture. ArchiMate gives us a language for describing what we have designed.
They are therefore highly complementary.
The Open Group has also published guidance specifically addressing Agile Architecture modelling using the ArchiMate language, including using models to support communication, collaboration, decision-making, and enterprise agility.
Why use ArchiMate instead of ordinary boxes and arrows?
Most architects can draw something resembling architecture with PowerPoint, Visio, draw.io, or a whiteboard.
The problem is that a box labelled “Payment Engine” could mean almost anything.
Is it:
- a business capability?
- a business service?
- an application?
- an application service?
- a software component?
- a technology service?
- an entire product?
ArchiMate removes much of this ambiguity.
A particular type of element has a defined architectural meaning.
That makes models easier to:
- understand
- compare
- maintain
- analyze
- exchange between architecture teams
- use for impact analysis
- connect across business and technology domains
The Open Group describes ArchiMate’s value as providing a common language for describing and relating business processes, organizational structures, information flows, IT systems, and technical infrastructure.
The easiest way to understand ArchiMate
Do not begin by memorizing dozens of symbols.
Instead, remember this chain:
WHY → WHAT → HOW → WITH WHAT → CHANGE
In ArchiMate terms, this roughly becomes:
Motivation → Strategy → Business → Application → Technology → Implementation
Consider a digital bank.
The bank might say:
WHY
Customers abandon our account-opening journey.
Therefore:
STRATEGY
We need a Digital Customer Onboarding capability.
Which requires a:
BUSINESS
Customer Verification Process.
Supported by an:
APPLICATION
KYC Application Service.
Provided by an:
APPLICATION COMPONENT
Identity Verification Platform.
Running on:
TECHNOLOGY
Kubernetes and cloud infrastructure.
Delivered through a:
CHANGE INITIATIVE
Digital Onboarding Modernization Program.
That entire chain can be represented using ArchiMate.
And that is where ArchiMate becomes considerably more powerful than drawing disconnected infrastructure diagrams.
The main ArchiMate domains
A useful beginner’s mental model is to divide ArchiMate into several areas.
1. Motivation
Motivation explains why something should change.
Common elements include:
- Stakeholder
- Driver
- Assessment
- Goal
- Outcome
- Principle
- Requirement
- Constraint
For example:
Driver: Customers expect instant onboarding
↓
Goal: Reduce onboarding time
↓
Requirement: Identity verification must complete within 30 seconds
Motivation is particularly important in an O-AA environment because architecture should be connected to business and customer outcomes, rather than technology existing for its own sake.
2. Strategy
The Strategy domain helps describe what the organization needs to be capable of doing.
Important elements include:
- Capability
- Resource
- Course of Action
- Value Stream
A capability answers:
What must the enterprise be able to do?
Examples might include:
- Digital Customer Onboarding
- Fraud Management
- Payment Processing
- Customer Authentication
- Regulatory Reporting
- Data Analytics
Notice that a capability does not specify which software performs the work.
That separation is extremely useful.
You might replace ten applications over five years while the Payment Processing Capability remains necessary.
3. Business Layer
The Business Layer describes what the organization actually does.
Typical elements include:
- Business Actor
- Business Role
- Business Process
- Business Function
- Business Service
- Business Object
- Product
For example:
Business Role
Customer Service Agent
↓
performs
Business Process
Resolve Customer Dispute
↓
uses
Business Object
Dispute Case
The Business Layer provides the connection between high-level strategy and the systems that support the organization.
4. Application Layer
The Application Layer describes software systems and the services they provide.
Some of the most useful beginner elements are:
- Application Component
- Application Service
- Application Interface
- Application Process
- Application Function
- Data Object
For example:
Application Component
Fraud Management System
↓
provides
Application Service
Transaction Risk Scoring
↓
serves
Business Process
Authorize Payment
This distinction between a component and a service is important.
The component is the software.
The service represents functionality that software exposes to its consumers.
5. Technology Layer
The Technology Layer describes the infrastructure supporting applications.
Common elements include:
- Node
- Device
- System Software
- Technology Service
- Technology Interface
- Artifact
- Communication Network
For example:
Application Component
Payment API
↓
deployed on
Node
Kubernetes Cluster
↓
uses
Technology Service
Managed PostgreSQL Service
↓
hosted within
Node
Cloud Platform
This lets an architect trace dependencies from a business capability all the way down to infrastructure.
6. Implementation and Migration
Architects must model not only the current and future states but also how the organization moves between them.
Useful elements therefore include:
- Work Package
- Deliverable
- Plateau
- Gap
- Implementation Event
For example:
Current Plateau
Monolithic Payments Platform
↓
Gap
Cannot scale payment services independently
↓
Work Package
Payments Microservices Migration
↓
Target Plateau
Cloud-Native Payments Platform
This becomes particularly valuable when architecture is treated as something that continuously evolves, rather than a document produced once every three years.
Structure, Behavior, and Information
There is another useful ArchiMate concept beginners should understand.
Within the core layers, elements broadly describe three things.
Active Structure — WHO or WHAT performs something
Examples:
- Business Actor
- Application Component
- Node
Behavior — WHAT happens
Examples:
- Business Process
- Application Function
- Technology Process
Passive Structure — WHAT is acted upon
Examples:
- Business Object
- Data Object
- Artifact
A simple example is:
Customer Service Application
Active Structure
↓
performs
Update Customer Details
Behavior
↓
accesses
Customer Record
Passive Structure
This structure-behavior-information pattern repeats throughout ArchiMate and makes the language much easier to learn.
Relationships: The grammar of ArchiMate
Knowing the elements is only half of the language.
The other half is understanding how they relate.
Fortunately, beginners can do a great deal with only a handful of relationships.
Composition
Means:
This thing consists of these things.
For example:
Digital Banking Platform
composed of
- Mobile Banking
- Internet Banking
- API Banking
Assignment
Generally expresses responsibility for performing behavior.
For example:
Fraud Analyst
assigned to
Investigate Fraud Alert
Realization
Means that something implements or provides a more abstract concept.
For example:
Payment Processing Function
realizes
Payment Processing Service
Serving
Means that one element provides functionality to another.
For example:
Authentication Service
serves
Mobile Banking Application
Access
Shows that behavior or structure reads or changes information.
For example:
Payment Processing Function
accesses
Transaction Data
Flow
Represents the transfer of something.
For example:
Payment Gateway
flows transaction information to
Fraud Detection System
Triggering
Represents a temporal or causal relationship.
For example:
Receive Payment Request
triggers
Validate Payment
which triggers:
Fraud Check
which triggers:
Authorize Transaction
You do not need to master every ArchiMate relationship before producing useful models.
Start with these.
Views and Viewpoints: Don’t show everything at once
One of the most important ArchiMate lessons is:
The complete model is not the diagram.
Your architecture repository might contain thousands of interconnected elements.
A CEO should not see all of them.
Neither should a developer.
Instead, you create views showing only the information relevant to a particular concern.
The ArchiMate community guidance describes a viewpoint as conventions used to create a view addressing a known stakeholder concern.
For example:
Executive view
Show:
Strategy → Outcomes → Capabilities → Products
Product Owner view
Show:
Product → Value Stream → Business Processes → Applications
Solution Architect view
Show:
Applications → Services → APIs → Data
Infrastructure Architect view
Show:
Applications → Runtime Platforms → Networks → Databases
Security Architect view
Show:
Requirements → Applications → Information → Security Controls
All of these views can come from the same underlying ArchiMate model.
Now let’s use ArchiMate with O-AA
The following four examples show how ArchiMate can help architects apply important ideas associated with Open Agile Architecture.
The diagrams below use simplified text notation for readability:
[Element Type: Element Name]
Arrows illustrate architectural relationships conceptually rather than attempting to reproduce every graphical symbol from the specification.
Example 1 — Modelling Architecture Around a Customer Outcome
Scenario
A digital bank discovers that 35% of prospective customers abandon account registration before completing identity verification.
The traditional architecture response might immediately be:
“We need to replace the KYC system.”
But that jumps from problem to solution.
An O-AA-style approach starts with the desired outcome.
O-AA explicitly emphasizes outcome-based and customer-focused architecture.
ArchiMate allows us to maintain that traceability.
Step 1 — Model the motivation
[Stakeholder: Prospective Customer]
↓
[Driver: Simple Digital Banking Experience]
↓
[Goal: Reduce Account Opening Friction]
↓
[Outcome: Account Opened in Under 5 Minutes]
Now we understand why architecture needs to change.
Step 2 — Identify the capability
[Outcome: Account Opened in Under 5 Minutes]
↓
[Capability: Digital Customer Onboarding]
The organization needs the ability to perform digital onboarding effectively.
Step 3 — Model the business journey
[Value Stream: Become a Customer]
│
├── Submit Details
│
├── Verify Identity
│
├── Perform Compliance Check
│
└── Activate Account
Now we can identify where the customer experiences friction.
Step 4 — Connect technology
The Verify Identity stage might depend on:
[Business Process: Verify Customer Identity]
↓ served by
[Application Service: Identity Verification]
↓ realized by
[Application Component: Digital KYC Platform]
↓ supported by
[Technology Service: Container Runtime Platform]
We now have traceability from:
Customer → Outcome → Capability → Journey → Process → Application → Infrastructure
That is much more valuable than simply drawing a diagram containing “KYC Server”.
How this supports O-AA
It keeps architects focused on the question:
“What customer or business outcome are we trying to achieve?”
rather than:
“What technology should we deploy?”
It also allows Agile teams to change the implementation without losing the architectural intent.
Example 2 — Modelling a Product-Centric Architecture
Product-centricity is a major feature of Open Agile Architecture.
Instead of creating temporary projects that disappear after delivery, O-AA describes product-centric organizations using cross-functional teams responsible for developing and operating products and services.
Consider a company launching a:
Digital Wallet Product
We could start with:
[Product: Digital Wallet]
│
├── Customer Registration Service
├── Wallet Management Service
├── P2P Transfer Service
├── Merchant Payment Service
└── Transaction History Service
Now add the systems providing those capabilities.
[Product]
Digital Wallet
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
[Business [Business [Business
Service] Service] Service]
P2P Transfer Merchant Pay Wallet Mgmt
│ │ │
▼ ▼ ▼
[Application Components]
Wallet API
Payment Engine
Ledger Service
Fraud Engine
Notification Service
And underneath them:
[Technology Services]
Kubernetes Platform
API Gateway
PostgreSQL Database
Message Broker
Identity Platform
Observability Platform
But we can go further.
The product also has ownership.
[Business Role: Digital Wallet Product Team]
↓
[Product: Digital Wallet]
The team might include:
Product Owner
Software Engineers
Security Engineer
SRE / Operations Engineer
UX Designer
Data Analyst
The architecture therefore becomes much more than an application diagram.
It captures:
Product
↓
Customer Services
↓
Business Processes
↓
Applications
↓
Technology
↓
Team Ownership
Why this matters
Imagine the Ledger Service will be changed.
Using an architecture repository, we can ask:
- Which product uses it?
- Which business services depend on it?
- Which customer journeys could be affected?
- Which team owns it?
- Which databases does it use?
- Which capabilities depend on it?
That is architectural impact analysis.
How this supports O-AA
This model makes the product the architectural center of gravity, rather than treating systems as independent IT assets.
Architecture therefore becomes directly useful to autonomous product teams.
Example 3 — Modelling a Value Stream to Find Architectural Bottlenecks
Another useful application of ArchiMate in an Agile enterprise is connecting value delivery to technology dependencies.
Consider a payment company.
The customer wants one thing:
Pay a merchant successfully.
We could model a value stream:
[Value Stream: Complete Merchant Payment]
│
├── 1. Capture Payment
│
├── 2. Authenticate Customer
│
├── 3. Assess Fraud Risk
│
├── 4. Authorize Payment
│
├── 5. Post Transaction
│
└── 6. Notify Customer
Now map capabilities to stages.
Capture Payment
↓
[Capability: Payment Acceptance]
Authenticate Customer
↓
[Capability: Digital Identity]
Assess Fraud Risk
↓
[Capability: Fraud Management]
Authorize Payment
↓
[Capability: Payment Processing]
Post Transaction
↓
[Capability: Financial Ledger Management]
Notify Customer
↓
[Capability: Customer Communications]
Next, connect the applications.
Payment Acceptance
↓
Payment Gateway
Digital Identity
↓
Identity Service
Fraud Management
↓
Fraud Engine
Payment Processing
↓
Payment Switch
Ledger Management
↓
Core Ledger
Customer Communications
↓
Notification Service
Suppose architecture analysis identifies the following:
Payment Gateway 100 ms
Identity Service 150 ms
Fraud Engine 1800 ms
Payment Switch 120 ms
Ledger 200 ms
Notification 50 ms
Suddenly the architecture tells a story.
The majority of transaction latency is associated with:
Fraud Assessment
And that stage depends on:
Fraud Engine
The architecture team can therefore investigate that part of the architecture rather than launching a broad “payment performance improvement project”.
Perhaps the fraud service is synchronous when part of its workload could become asynchronous.
Or the problem might be:
- an external API dependency
- excessive database calls
- an obsolete fraud platform
- network latency
- badly designed integration
- insufficient scaling
How this supports O-AA
Agile Architecture should help teams make better and faster decisions.
The Open Group’s Agile Architecture modelling guidance specifically emphasizes using architecture models iteratively to support communication, prioritization, collaboration, and the management of architectural and technical debt.
Instead of producing architecture merely as documentation, this model becomes an instrument for improving value flow.
Example 4 — Modelling Security as Part of Agile Architecture
Security architecture is frequently handled badly in Agile environments.
One team develops the application.
Another team performs security review shortly before release.
Problems are discovered.
The release is delayed.
O-AA explicitly includes Agile Security Architecture among its practitioner competencies.
ArchiMate gives security architects a useful mechanism for making security requirements traceable through the architecture.
Consider an Internet Banking platform.
Start with the business concern.
[Stakeholder: CISO]
↓
[Driver: Account Takeover Risk]
↓
[Goal: Protect Privileged Administrative Access]
↓
[Requirement: Privileged Access Requires MFA]
Now connect the requirement to the architecture.
[Requirement]
Privileged Access Requires MFA
↓
[Application Service]
Administrator Authentication
↓
[Application Component]
Identity and Access Management Platform
↓
[Technology Service]
Multi-Factor Authentication Service
Additional requirements could include:
[Requirement]
All administrative activity must be auditable
↓
[Application Service]
Security Audit Logging
↓
[Application Component]
Central Logging Platform
And:
[Requirement]
Administrative interfaces must not be Internet accessible
↓
[Technology Service]
Private Administrative Network
↓
[Node]
Management VPC
Now the security architect can trace:
Risk → Requirement → Control → Application → Infrastructure
Suppose the existing system does not satisfy these requirements.
We can model the transformation.
[Plateau]
Current Internet Banking Platform
↓
[Gap]
Privileged authentication lacks MFA
↓
[Work Package]
Privileged Access Modernization
↓
[Deliverables]
IAM Integration
MFA Integration
Central Audit Logging
Private Management Network
↓
[Plateau]
Hardened Internet Banking Platform
This model can evolve alongside the product backlog.
Individual deliverables can become epics or features for Agile teams.
How this supports O-AA
Security is no longer represented by a document attached after architecture has been designed.
It becomes part of the architecture itself.
As the product changes, architects can immediately determine:
- which security requirements apply
- which components implement them
- which controls could be affected by a change
- which modernization items remain outstanding
That supports continuous security architecture rather than stage-gated security review.
Putting the four examples together
These examples demonstrate four particularly valuable ways ArchiMate can complement an O-AA architecture practice.
| O-AA concern | ArchiMate can model | Example |
|---|---|---|
| Outcome-based architecture | Drivers, goals, outcomes, capabilities | Digital onboarding |
| Product-centric architecture | Products, services, components, teams | Digital wallet |
| Agile value delivery | Value streams, capabilities, processes, applications | Merchant payments |
| Agile Security Architecture | Drivers, requirements, applications, technology and migration | Internet banking security |
The important point is that these are not four disconnected diagrams.
They can exist inside one architecture model.
For example:
Customer Outcome
↓
Capability
↓
Value Stream
↓
Product
↓
Business Service
↓
Business Process
↓
Application Service
↓
Application Component
↓
Technology Service
↓
Infrastructure
That traceability is one of the biggest benefits of Enterprise Architecture modelling.
Your first ArchiMate model
If you are just starting, resist the temptation to model your entire organization.
Choose one problem.
For example:
“How does our online payment service work?”
Start with approximately ten elements.
Step 1 — Define the outcome
[Outcome]
Fast and Reliable Online Payment
Step 2 — Identify the capability
[Capability]
Digital Payment Processing
Step 3 — Identify the main business process
[Business Process]
Process Online Payment
Step 4 — Identify the application service
[Application Service]
Payment Authorization
Step 5 — Identify the software
[Application Component]
Payment Switch
Step 6 — Identify infrastructure
[Node]
Payment Kubernetes Cluster
Now connect them:
[Outcome]
Fast and Reliable Online Payment
↓
[Capability]
Digital Payment Processing
↓
[Business Process]
Process Online Payment
↓
[Application Service]
Payment Authorization
↓
[Application Component]
Payment Switch
↓
[Node]
Kubernetes Cluster
Congratulations.
You have created the beginning of an Enterprise Architecture model.
Then ask architectural questions
Once the basic model exists, start asking questions.
Business questions
What outcome does this system contribute to?
Capability questions
What enterprise capability does the system enable?
Product questions
Which product owns this functionality?
Dependency questions
What other systems depend upon it?
Data questions
Which information does it create or consume?
Infrastructure questions
Where does it run?
Security questions
Which requirements apply?
Ownership questions
Which team is responsible?
Transformation questions
What changes are planned?
Every answer adds another useful piece to the model.
Don’t try to model source-code-level detail
One of the easiest mistakes for new ArchiMate users is trying to turn ArchiMate into UML.
That is not its purpose.
For example:
ArchiMate might say:
[Application Component]
Payment Processing Service
For internal software design you might then use UML, C4, or another software modelling notation to describe:
PaymentController
PaymentValidator
PaymentRepository
AuthorizationAdapter
SettlementAdapter
Likewise, ArchiMate might represent:
[Business Process]
Customer Onboarding
while BPMN contains the detailed workflow.
ArchiMate should provide the architectural map connecting these domains together.
The recent ArchiMate 101 guidance from The Open Group community makes the same general recommendation: use ArchiMate for a coherent architectural overview and use more specialized languages when detailed domain modelling is necessary.
Five common mistakes beginners should avoid
1. Modelling everything
More elements do not automatically produce better architecture.
Create views for specific questions.
2. Creating diagrams instead of a model
A diagramming tool may allow you to draw ArchiMate symbols.
A modelling repository understands that the Payment Switch appearing in ten diagrams is the same architectural object.
That distinction becomes important as architecture grows.
3. Starting with technology
A diagram beginning with:
AWS
Kubernetes
PostgreSQL
Kafka
Redis
may be technically accurate but tells us very little about why the architecture exists.
Whenever possible, trace technology upward to:
Applications → Business → Capability → Outcome
4. Using every ArchiMate element
You don’t receive bonus architecture points for using all the symbols.
The Open Group’s practical ArchiMate guidance itself recommends beginners work initially with a useful subset of the language rather than becoming overwhelmed by every concept.
5. Treating architecture as permanent documentation
This is particularly important when combining ArchiMate with O-AA.
Architecture should evolve alongside the organization.
The Open Group’s Agile modelling guidance recommends an iterative and risk-based approach: create enough architecture detail for the decisions being made, and progressively add detail where risks or complexity justify it.
A useful starter vocabulary
If I were teaching ArchiMate to an architecture team tomorrow, I would initially focus on roughly these elements:
Motivation
- Stakeholder
- Driver
- Goal
- Outcome
- Requirement
Strategy
- Capability
- Value Stream
Business
- Business Actor
- Business Role
- Business Process
- Business Service
- Product
Application
- Application Component
- Application Service
- Data Object
Technology
- Node
- Technology Service
Transformation
- Work Package
- Plateau
- Gap
Learn those well and you can already describe a surprisingly large proportion of a real enterprise.
Add additional ArchiMate concepts only when your architecture needs them.
A practical modelling workflow
A productive Agile architecture team can use a workflow such as:
1. Identify stakeholder concern
↓
2. Define desired outcome
↓
3. Identify affected capabilities
↓
4. Identify value streams
↓
5. Identify affected products
↓
6. Map business processes
↓
7. Map application dependencies
↓
8. Map technology dependencies
↓
9. Add security requirements
↓
10. Identify architectural gaps
↓
11. Define work packages
↓
12. Deliver incrementally
↓
13. Update the architecture model
↓
14. Repeat
Notice something important.
There is no:
“Create the final Enterprise Architecture document.”
Architecture is continuously evolving.
That is much closer to the philosophy of Open Agile Architecture.
Architecture models should answer questions
The best measure of an ArchiMate model is not how attractive the diagram looks.
It is whether the architecture repository can answer questions.
For example:
Which business processes depend on PostgreSQL?
Which products depend on the legacy payment switch?
Which customer outcomes would be affected if the identity platform failed?
Which applications contribute to our Fraud Management capability?
Which security requirements apply to the Digital Wallet?
Which systems will be changed by the cloud migration?
Which teams own services supporting the Merchant Payment value stream?
Which capabilities depend on technology that reaches end-of-life next year?
If your architecture model can answer questions like these, it has become an operational decision-making asset rather than simply documentation.
ArchiMate and Agile Architecture are not opposites
Some Agile practitioners initially regard architecture modelling as bureaucracy.
That criticism is sometimes justified — particularly when architecture involves producing enormous documents months before delivery teams begin implementation.
But architecture modelling does not have to work that way.
ArchiMate models can be:
- small
- iterative
- problem-focused
- collaboratively created
- continuously updated
- connected to product development
- connected to architecture decisions
- connected to technical debt
- connected to security requirements
The Open Group’s Agile Architecture guidance specifically identifies architecture modelling as useful for expressing business intent, supporting communication between Agile teams, managing complexity, and helping organizations address architectural and technical debt.
That makes ArchiMate particularly useful when the goal is not Big Architecture Up Front, but rather just enough architecture to make good decisions continuously.
Final thoughts
ArchiMate initially looks more complicated than it really is.
There are many symbols, relationships, layers, and viewpoints, but you do not need to learn everything before gaining value from it.
Start with one simple idea:
Why → Capability → Business → Application → Technology
Then gradually add:
Outcomes, products, value streams, security, and transformation.
When combined with the Open Agile Architecture approach, this becomes especially powerful.
O-AA encourages architects to focus on:
outcomes, customers, products, Agile teams, continuous evolution, and digital transformation.
ArchiMate gives architects a consistent language for showing how those concepts connect to:
business processes, applications, information, technology, security requirements, and transformation initiatives.
The result is an architecture practice that can move beyond drawing systems and begin answering much more valuable questions:
Why does this system exist?
Which outcome does it support?
Which product owns it?
Which capabilities depend on it?
What happens if we change it?
And how do we evolve it safely?
That is where Enterprise Architecture modelling starts becoming genuinely useful.
Further reading
The Open Group maintains the ArchiMate standard and describes it as an open and independent modelling language for Enterprise Architecture.
The Open Agile Architecture Standard provides an Agile, outcome-based, customer-focused and product-centered architecture approach for digital enterprises.
The Open Group also maintains resources specifically covering Agile Architecture modelling using the ArchiMate language.
A newer community-produced ArchiMate 101: A Practical Introduction is also available through The Open Group’s ArchiMate community resources and is particularly useful for beginners.
