Mastering Archimate Edition Iii A Serious

Introduction To The Archimate Enterprise

Architecture Modeling Language Illustrated
Gerben Wierda download
https://ebookbell.com/product/mastering-archimate-edition-iii-a-
serious-introduction-to-the-archimate-enterprise-architecture-
modeling-language-illustrated-gerben-wierda-42578466

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Mastering Collaboration In A Product Team 70 Techniques To Help Teams

Build Better Products 1st Edition Natasha Hampshire Glaudia Califano
David Spinks

https://ebookbell.com/product/mastering-collaboration-in-a-product-
team-70-techniques-to-help-teams-build-better-products-1st-edition-
natasha-hampshire-glaudia-califano-david-spinks-44875474

Mastering Collaboration In A Product Team 70 Techniques To Help Teams

Build Better Products 1st Edition Natasha Hampshire

https://ebookbell.com/product/mastering-collaboration-in-a-product-
team-70-techniques-to-help-teams-build-better-products-1st-edition-
natasha-hampshire-44915468

Mastering Gnome A Beginners Guide 1st Edition Sufyan Bin Uzayr

https://ebookbell.com/product/mastering-gnome-a-beginners-guide-1st-
edition-sufyan-bin-uzayr-46082774

Mastering Flutter A Beginners Guide 1st Edition Sufyan Bin Uzayr

https://ebookbell.com/product/mastering-flutter-a-beginners-guide-1st-
edition-sufyan-bin-uzayr-46082778
Mastering Rust A Beginners Guide 1st Edition Sufyan Bin Uzayr

https://ebookbell.com/product/mastering-rust-a-beginners-guide-1st-
edition-sufyan-bin-uzayr-46151622

Mastering Rust A Beginners Guide 1st Edition Sufyan Bin Uzayr

https://ebookbell.com/product/mastering-rust-a-beginners-guide-1st-
edition-sufyan-bin-uzayr-46191750

Mastering Primary Science Amanda Mccrory Kenna Worthington

https://ebookbell.com/product/mastering-primary-science-amanda-
mccrory-kenna-worthington-46236134

Mastering Ubuntu Server Explore The Versatile Powerful Linux Server

Distribution Ubuntu 2204 With This Comprehensive Guide 4th Edition 4th
Jay Lacroix

https://ebookbell.com/product/mastering-ubuntu-server-explore-the-
versatile-powerful-linux-server-distribution-ubuntu-2204-with-this-
comprehensive-guide-4th-edition-4th-jay-lacroix-46242660

Mastering Python Scripting For System Administrators Ganesh Sanjiv

Naik

https://ebookbell.com/product/mastering-python-scripting-for-system-
administrators-ganesh-sanjiv-naik-46242670
Mastering

Edition III.TC1
ArchiMate By
Gerben Wierda

A Serious Introduction to
the ArchiMate® Enterprise
Architecture Modeling
Language,Version 3.0.1
 ISBN 978-90-819840-8-9

9 789081 984089

Copyright © 2017 by Gerben Wierda, The Netherlands

Published by A , The Netherlands
R&
Edition III.TC1. First Printing. This is the Screen Edition. Please read Section 4 “License & Legal” on page 15.
Neither the author, nor the publisher, nor the printer, nor the distributor, nor the seller accept any responsibility or liability
for loss or damage occasioned to any person or property through using the material, instructions, methods or ideas con-
tained in or distributed with this book, or acting or refraining from acting as a result of such use. The author, publisher,
printer, distributor, and seller expressly disclaim all implied warranties, including merchantability of fitness for any partic-
ular purpose.
ISBN PDF: 978-90-819840-8-9
ISBN hardcover: 978-90-819840-9-6
License Info: see “License & Legal” on page 15
Contact info: info@masteringarchimate.com

Page 2 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Mastering
ArchiMate

Edition III.TC1

 Page 3
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
Praise
Praise for Mastering ArchiMate Edition II
Mastering ArchiMate Edition II received almost uniquely 4 and (mostly) 5 star reviews on Amazon:
This is a superb way to learn ArchiMate, don’t think you are going to read it once and get everything out of it. This is
a read and re read. I rarely give reviews but this is an outstanding read for anyone who is trying to model Enterprise
Architecture
This is an excellent book and I was able to grasp concepts faster when compared to [the] ArchiMate Spec doc.
So many others are all theory, but this book provides detail rational on how to model in ArchiMate using real life practi-
cal examples
I very much liked the author’s style of combining both theory and practice in an explicit and honest way, discussing
also the limits of ArchiMate and the pros and cons of proposed patterns
If you want to apply ArchiMate in practice, I know of no better resource.
A thorough and practical book on ArchiMate that does exactly what it’s title promises: it introduces you to the basics
concepts and builds on that foundation to more complicated stuff and always using real life examples, hence enabling
you to truly grasp the intricacies of the modeling stuff.
Excellent book to learn the formalism ArchiMate. Many concrete examples. Best practices, pitfalls to avoid. An essential
complement to the standard document of the Open Group.
Whilst I’m not new to architecture or Enterprise Architecture I am new to ArchiMate and this book has been a fantastic
primer on the subject. [...] I’ve been using this [...] on a complex project and found it extremely helpful!
I’ve found the book to be well written and very thorough, [...] not only great for beginners in ArchiMate, but will also
serve as an excellent reference for more experienced modellers.
[...] goes beyond the trivial examples that most instructional books provide [...] If you are learning ArchiMate, you
should absolutely buy this book. It is a bargain at twice the price!
This book is a masterpiece. [...] On top of modeling, it indirectly also educates on design principles. [...] boosted my
productivity [...] The best bang for the buck in EA!
Mastering ArchiMate should be required reading for accelerating the knowledge and skills of serious Enterprise Archi-
tects.

Praise for Chess and the Art of Enterprise Architecture

Chess and the Art of Enterprise Architecture has received only 5 out of 5 stars on Amazon so far. Here are some quotes:
I read this as part of a work book club last year and the conversations it generated, as well as the observations that
have stuck with me, have been invaluable. For me this book was packed with points I keep coming back to. It was also
enjoyable to read and thankfully short. [...] I would recommend the book to any senior architect or senior IT leader.
This book captures the challenges faced by Enterprise Architecture in a clearly articulated and entertaining style based
on pragmatic experience from the author. It is easily the best book I have read on the topic. It may not have all the an-
swers but explains very clearly why there are problems in this area and gives good guidance on how to navigate around
them and avoid the pitfalls of the past. It is easily understandable for a non technical audience and I would strongly
recommend it for any one in IT or Business Change management.
Anyone working in architecture should have copies of this on their shelves to hand out to stakeholders so that they
understand what architecture is about. Students could read this and pick up invaluable insights

Page 4 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Forewords
In the 15 years since its inception, the ArchiMate language I discovered ArchiMate in mid 2011 while trying to find a
for enterprise architecture modeling has come a long way. I standard notation for architecture that would go beyond
have had the privilege of being part of its development from UML. I decided to read the official standard, which (in my
the start, first as project manager of the R&D project that de- opinion) is much easier to digest than the UML one. De-
veloped the language, a collaboration of the Dutch Telemati- spite being easy to understand, the ArchiMate standard itself
ca Instituut and its partners, and later, after it was transferred wasn’t of any help to start practicing (it contains descriptions
to The Open Group in 2008, by leading the team that further of elements and relationships but it doesn’t provide guid-
developed and extended the standard. ance). So I started a quest for information and examples…
Over the years, the popularity of ArchiMate has grown I must admit that the small number of articles or blog posts
tremendously, supported by an increasing number of useful about ArchiMate worried me. But, one day, I discovered
resources. Gerben’s book has been one such resource and Gerben’s blog and my quest ended. In a short amount of
is of great value to anyone who wants to use ArchiMate time, thanks to Gerben’s insightful posts, I was able to really
in practice. The book gives an in-depth analysis and ex- understand key concepts, and I finally had examples of real
planation of the language, complemented by many useful ArchiMate use. Almost a year after having discovered Archi-
examples, modeling patterns and working practices. It goes Mate, I was finally able to understand and use ArchiMate,
beyond a mere explanation of ArchiMate, but also provides just in time for a big and exciting company project for which
excellent insights in more general considerations of architec- architecture description was a key success factor.
ture and design.
Then the first edition of this book was published. Based on
The discipline of Enterprise Architecture is evolving, and Ar- my experience with the blog, I expected much from it, and
chiMate has evolved with it. Since version 1, we have added I was not disappointed: the book was presenting ArchiMate
concepts for expressing the rationale behind architectures, the right way, allowing people without any prior knowledge
for describing how their implementation is planned and ex- to understand it in a few days. It enabled me to quickly train
ecuted, for relating architectures to business strategy, and for my colleagues. Plenty of examples were already included,
modeling the physical world (something often overlooked helping me and my team to quickly provide value, thanks to
by architects with an IT background). This has also served to ArchiMate.
align ArchiMate with other architecture approaches such as
The title — Mastering ArchiMate — sounds exaggerated.
TOGAF and BIZBOK.
How many books are there that promise you to ‘master’
Now this book of course offers Gerben’s personal perspec- something, while at the end you’ve barely learnt anything?
tive on ArchiMate, and we don’t always agree. But the But in this case it is real.
ArchiMate community is a big tent and the language can
Together with Enterprise Architecture at Work by Marc
be used for many more things than it was designed for. As a
Lankhorst, Mastering ArchiMate is the book that any serious
self-confessed ‘ArchiMate fanboy’, he is nonetheless critical
Enterprise Architect should possess, to learn ArchiMate fast.
of what he sees as weaknesses in the language, and rightly
This clearly is the kind of book that changes your practice
so. Several of his past suggestions for improvement have
as it also provides insightful comments about the standard
been included in the current version of the language.
itself, its limitations and how to overcome them. In this third
Next to the team who originally developed ArchiMate, edition, Mastering ArchiMate covers all new concepts and
Gerben is probably the most knowledgeable expert on the domains of ArchiMate 3. It also provides numerous new or
language, and the book you are now reading condenses improved examples that will certainly echo several of your
much of this expertise. Where the ArchiMate Specification needs (virtualization, DevOps…).
contains the formal definition of the language and the book
This is the book that has had the largest influence on my ca-
Enterprise Architecture at Work describes the background
reer. Without it I would not have learnt ArchiMate the right
of its design, Mastering ArchiMate provides you with the
way, and I certainly would not have joined The Open Group
perspective of what I would call a ‘rigorous practitioner’. All
ArchiMate Forum. I recommend it to everyone that joins an
self-respecting enterprise architects should have these three
ArchiMate training: a training helps you for a week, but this
next to each other on their bookshelves.
book helps you for years.
Marc Lankhorst Jean-Baptiste Sarrodie
Managing Consultant & Chief Technology Evangelist Vice-Chair of the ArchiMate Forum
BiZZdesign Enterprise Architect at Arismore, part of Accenture
Enschede, The Netherlands, August 2017 Paris, France, August 2017
Forewords Page 5
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Contents
Table of
fo elbaT
stnetnoC

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005

 Table of
Contents
Introduction..................................................... 11 8.2 (Formal) Collaboration and Interaction................... 33
1. Why This Book?.......................................... 11 8.3 The Association Relation......................................... 34
1.1 Uncle Ludwig......................................................... 11 8.4 Specialization in the Meta-model........................... 34
2. Enterprise Architecture................................ 12 8.5 The Specialization Relation in an Actual Model...... 35
2.1 Where are the principles and guidelines?............... 14 8.6 Representation....................................................... 37
2.2 The Why, the How and the What............................ 14 8.7 Location................................................................. 37
2.3 Disclaimer.............................................................. 14 8.8 The Complete Core................................................. 37
3. Gratitude.................................................... 14 9. Derived Relations....................................... 39
4. License & Legal.......................................... 15 9.1 Derived Structural and Dependency Relations........ 39
5. Release Notes for Edition III.TC1................ 15 9.2 Derived Dynamic Relations.................................... 41
ArchiMate Basics............................................. 17 9.3 Are derived relations real relations?........................ 41
6. An ArchiMate Map..................................... 17 9.4 How useful are derived relations?........................... 42
7. Main Core Elements and Relations............. 18 10. Non-Core ArchiMate domains.................. 42
7.1 Application and Business........................................ 18 10.1 Strategy................................................................ 42
7.2 The double use of the Serving relation.................... 21 10.2 Implementation & Migration................................. 43
7.3 Function versus Process.......................................... 21 10.3 Motivation............................................................ 45
7.4 Business Actor........................................................ 22 11. Some Beginner’s Pitfalls............................ 46
7.5 Adding Technical Infrastructure to the Mix.............. 22 11.1 Pitfalls of Derived Relations.................................. 46
7.6 System Software and Device................................... 24 11.2 Don’t trust the language or the tool blindly: know what
you are doing............................................................... 47
7.7 Composition and Aggregation................................ 24
11.3 Misunderstanding the standard meta-model diagram.48
7.8 Nesting................................................................... 25
7.9 Using a Node to encapsulate infrastructure............ 25
12. Some Noteworthy Aspects of ArchiMate... 48
12.1 Licensing.............................................................. 48
7.10 Event, Trigger and Flow......................................... 26
12.2 ArchiMate, the modeling language....................... 49
7.11 Modeling the Physical.......................................... 27
12.3 Separation of ‘actor’ and ‘behavior’...................... 50
7.12 Junctions.............................................................. 28
12.4 One View Type..................................................... 50
7.13 Grouping.............................................................. 28
12.5 On the direction of structural relations under the as-
7.14 Automated Processes............................................ 29
sumption of ‘worst case’............................................... 51
7.15 Distribution of data and matter (Path and Network).29
12.6 On the limitations of derived relations.................. 51
7.16 Who is in Charge?................................................ 30
12.7 Why two types of software?.................................. 52
7.17 Abstractions.......................................................... 31
12.8 There is more than one-to-one.............................. 53
8. Other Core Elements and Relations............ 32 12.9 Detailed or not?.................................................... 53
8.1 Product and Contract.............................................. 32
Page 7
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 12.10 Layering Ambiguity............................................. 54 16.2 Using the Association Relation............................. 86
12.11 The Use of the Non-core Domains...................... 54 16.3 Using properties too much................................... 86
12.12 Why model?....................................................... 55 17. An Example from the Real World.............. 87
13. From ArchiMate 2.1 to ArchiMate 3.0.1.... 55 18. Business Function and Business Process... 91
Style & Patterns............................................... 57 18.1 On ArchiMate’s divide between behavior and struc-
ture.............................................................................. 91
14. Aesthetics (Style)....................................... 57
18.2 Business Function or Business Process?................ 92
14.1 Why aesthetics matters......................................... 57
18.3 Good Old Fashioned Business Function............... 95
14.2 Arranging relations............................................... 57
18.4 The ‘End-to-end’ Business Process........................ 95
14.3 Sizing and Arranging elements............................. 59
18.5 Business Process Modeling versus Business Layer Archi-
14.4 Using color.......................................................... 60
tecture.......................................................................... 96
14.5 Visual grouping..................................................... 61
18.6 Dividing your enterprise’s behavior into Business Func-
14.6 About labels......................................................... 61 tions............................................................................. 97
14.7 Don’t Use the ‘Children’s Visuals’......................... 62 18.7 Concurrent Functional Landscapes..................... 100
15. Patterns..................................................... 62 18.8 Application/Technology Process or Function...... 103
15.1 The Use of Patterns............................................... 62 19. Secondary and Tertiary Architecture........ 104
15.2 A Basic TI Pattern: A Database.............................. 63 19.1 Introduction....................................................... 104
15.3 Modeling Spreadsheet Applications...................... 65 19.2 Primary Architecture........................................... 104
15.4 Modeling an Internet Browser............................... 67 19.3 Secondary Architecture: Development................ 104
15.5 More ‘application platforms’................................ 68 19.4 Intermezzo......................................................... 105
15.6 Infrastructure ‘Building Blocks’............................. 69 19.5 Secondary Architecture: System Exploitation...... 105
15.7 Deployment Pattern: Standalone PC Application.. 70 19.6 Secondary Architecture: Application Maintenance.106
15.8 Deployment Pattern: Standalone PC Application with 19.7 Tertiary Architecture: Application Owner............ 106
File Server based Data.................................................. 70
19.8 Tertiary Architecture: other roles......................... 107
15.9 Deployment Pattern: Classic Two-Tier Client-Server
19.9 Making it Practical: shortcuts.............................. 108
Application.................................................................. 71
19.10 Exploiting ArchiMate 3’s improved flexibility.... 110
15.10 Deployment Pattern: Two-Tier Client-Server Applica-
tion with mounted Client Application and two databases.72 20. Modeling Risk & Security with Motivation Ele-
15.11 Deployment Pattern: Two-Tier Client-Server with a
ments........................................................... 111
Remote Server.............................................................. 73 20.1 Security Architecture.......................................... 111
15.12 Deployment Pattern: Three-Tier Application........ 73 20.2 Risk.................................................................... 111
15.13 Deployment Pattern: Software as a Service (SaaS).75 20.3 Modeling Risks and Controls.............................. 111
15.14 We only model what we can see/‘change’.......... 76 21. Using the Implementation and Migration Ex-
15.15 Deployment Pattern: Providing a local SaaS........ 76
tension......................................................... 114
15.16 The Use of Patterns (reprise)................................ 76
22. Organizational Structure......................... 115
22.1 Basic Organizational Structure........................... 115
15.17 Infrastructure Pattern: Database Replication........ 78
22.2 Using an ArchiMate landscape to design an object
15.18 Infrastructure Pattern: High-Available Database Clus-
model......................................................................... 116
ter................................................................................ 78
15.19 Infrastructure Pattern: High-Available Server....... 80
23. Virtual Machines (Parallelization)............ 118
15.20 Using Collections and Abstraction in a model.... 81
24. Modeling Information Aspects................ 123
24.1 Messages and File Copies................................... 123
15.21 External Data Services........................................ 81
24.2 Informational Structure....................................... 124
15.22 Multiple Realizers.............................................. 82
24.3 Status Change of Informational Objects.............. 125
15.23 Other Parallel Relations...................................... 83
24.4 Access passive element from internal or external behav-
15.24 Summary of Basic Patterns.................................. 83
ior?............................................................................. 126
16. Some Anti-patterns................................... 84 24.5 Low Level Data Entry.......................................... 126
16.1 Application Collaboration is an Anthropomorphism.84
25. Integration.............................................. 128
Page 8 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 25.1 Service-Oriented Architecture / The API Economy.128 34.2 Better Insight...................................................... 200
25.2 Who is Serving Who Anyway?............................ 128 34.3 Overrated and Underrated.................................. 201
25.3 Associating with Trigger and Flow....................... 129 35. Using Abstractions.................................. 202
25.4 Routing and Orchestrating Middleware (ESB and 35.1 The price one pays.............................................. 202
APIs)........................................................................... 129
35.2 Too much detail?................................................ 203
26. Additional elements for model use......... 133 Discussing ArchiMate................................... 207
26.1 Using extra elements to facilitate analysis........... 133
36. Proposed Improvements for ArchiMate 3.207
26.2 Keeping in sync with other administrations......... 134
36.1 Fragmentation of element types.......................... 207
26.3 Reducing clutter through Aggregation................. 136
36.2 Remove historical baggage................................. 207
27. Complex Environments........................... 138 36.3 Issues with abstractions...................................... 208
27.1 Server Farm........................................................ 138
36.4 Issue with Metamodel-Specialization.................. 209
27.2 Citrix.................................................................. 140
36.5 Service as Composite Part of Function/Process.... 209
27.3 Complex Software Stacks.................................... 141
36.6 Automated Processes.......................................... 211
27.4 A completely alternative platform approach....... 143
36.7 Changing the Strength of Assignment and Realiza-
27.5 Complex Application Components..................... 144 tion............................................................................ 212
27.6 Business logic at the infrastructure level............. 147 36.8 A better derivation algorithm.............................. 213
27.7 Bitcoin (Blockchain)........................................... 148 36.9 Allow multiple parents in a Composition............ 215
28. The Data Center...................................... 150 36.10 Make the Access relation multi-directional....... 216
28.1 Networking........................................................ 150 36.11 Why change ArchiMate?................................... 217
28.2 DevOps Ready Data Center (DRDC).................. 151 Tooling............................................................. 219
BPMN and ArchiMate................................... 159 37. Multiple Models of One Reality.............. 219
29. A Very Short BPMN Primer..................... 159 38. Tool Requirements.................................. 220
30. A Possible Linking of BPMN and Archi- Index................................................................ 223
Mate............................................................. 164 List of Figures................................................. 230
30.1 An ArchiMate–BPMN Linkage Pattern................. 165
Finger............................................................... 237
30.2 BPMN/ArchiMate: Multiple Roles performing a Single
Process ...................................................................... 169
30.3 BPMN/ArchiMate: A Process calling another Pro-
cess............................................................................ 172
30.4 BPMN/ArchiMate: BPMN has no Architecture ‘Lay-
ers’............................................................................. 173
30.5 The Process Landscape in BPMN........................ 175
30.6 The Process Landscape in ArchiMate.................. 179
30.7 Processes handling Artifacts................................ 181
30.8 Processes communicating via an ESB................. 182
Model Use & Maintenance.......................... 189
31. Construction & Use Views...................... 189
31.1 Exceptional Construction Views.......................... 193
32. Model Maintenance............................... 195
32.1 The Satellite Model Approach............................. 195
Reflections...................................................... 199
33. The Role of ArchiMate in Enterprise Architec-
ture............................................................... 199
34. Why Model? (And for Whom?)................ 200
34.1 Two modeling purposes...................................... 200

Table of Contents Page 9

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 ntroductio
noitcudortnI

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005

 Introduction
1. Why This Book?
This book grew out of the desire to share the things I learned patterns. No introduction I had seen explained the language
over the course of several years with respect to seriously well enough and I did not see introductions that actually
employing the ArchiMate® Enterprise Architecture Modeling prepared you for sizable modeling work. This was certainly
language. As Lead Enterprise Architect, working for the Asset true also of the official certifying courses and training, which
Management unit of on of the largest Fiduciary Managers generally taught you only to reproduce the standard.
in the world, I introduced the use of ArchiMate in 2010,
This book intends to do three things:
because it seemed to me — for a variety of reasons — the
only reasonable choice for our modeling in the line of our • Give a decent initial introduction in the concepts and
Enterprise Architecture work. The choice was based on an relations that make up the language;
estimate of the practicality of the language, and I grew very
• Present a number of patterns and uses that may be use-
satisfied with how it worked in daily practice. This practice
ful when modeling in the language;
included — next to models for projects and target architec-
tures — the maintenance of a single very large (tens of thou- • Give enough content so you can develop a feel for the
sands of objects and relations) ‘current state’ model of our language.
enterprise, built along strict guidelines and used for analysis, The latter means that you will find some pretty deep and
reporting and as source for other systems, as well as use for arcane discussions and examples in this book, here and
future state and project architectures. The scope and detail there. These are not meant as practical examples to follow,
of our modeling taught us very valuable lessons about Archi- but they are there because thinking about at the ‘edges of
Mate modeling, which I have shared in the various editions practicality’ improves your choice and understanding of
of this book: Edition I in 2012 (ArchiMate 1) and Edition II practical solutions.
in 2014 (ArchiMate 2). Now that ArchiMate 3.0.1 (a bug-fix
release for version 3.0) has been released, it is time for a In the end, understanding is about being able to apply what
new Edition, which is based on ArchiMate 3. you know. Understanding is know how, not know what. If
you master the use of something, you understand something.
When we started using ArchiMate, I decided to stick almost Hence: Mastering ArchiMate.
religiously to the official definitions and not think or talk
about diverging until we had a reasonable body of experi-
ence. After all, only when you have enough experience are 1.1 Uncle Ludwig
you capable of really estimating the effect of the choices you Here and there, partly for fun, you will find references to
have when changing the language. We still stay very close an ‘Uncle Ludwig’. Uncle Ludwig stands for the twenti-
to what ArchiMate prescribes to this day, even if the depth of eth century philosopher Ludwig Wittgenstein, who some
our experience has led me to some criticism and improve- characterize as the most important analytic philosopher (as
ment proposals (see Chapter “Discussing ArchiMate” on opposed to, say, moral philosopher) to date. Wittgenstein in
page 207). his entire philosophical life concentrated on ‘meaning’. His
This book also grew out of the desire to provide a better result came in two parts. The first part in his youth, where
introduction than what was available at the time. What he tried to build meaning on top of logic. The results were
was available was often pretty limited in scope and in my limited (but sadly had the most influence in the computer
opinion sometimes even damaging in its explanations, as science discipline of all of his work). Later in life he tried to
it would not teach the things to become a good modeler answer what meaning then was for all the rest of what we
in ArchiMate. At best they would teach you some random say, where logic does not give you the definitive answer. He
patterns without for instance learning the pitfalls of those came up with the solution ‘meaning lies hidden in correct
Page 11
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
use’. Given that ArchiMate is in part a service- (and thus by P.M.S. Hacker. Wittgenstein has been misinterpreted by
use-) oriented language, this maxim is useful here and there. many (e.g. when people misinterpret him as having stated
Actually, I find the maxim extremely useful for work even that “meaning is equivalent to use”). Hacker not only under-
beyond modeling, e.g. wondering about the actual use of stands Wittgenstein (he has written extensive and insightful
documents sheds light about their meaning. analyses) but he also can explain it rather well. Wittgenstein
often sounds daunting to people, but in my experience it
If you want to know more about Wittgenstein, I suggest
can be pretty practical.
“Wittgenstein’s Place in 20th Century Analytical Philosophy”

2. Enterprise Architecture
So you’re working in an organization. The organization In large organizations, all these applications and files that
consists of many people, organized in organizational struc- support (or even are) the business have become an almost
ture, in groups, departments and sections, and — if large impossible to control, complex landscape, where many
enough— business units or even separate companies. If you things can and do go wrong and where change is fraught
look at what these people do, you look at business functions with peril. Because changing something here will crash
— say, ‘after-sales’ — or business processes — say ‘handling something somewhere else over there, in a landscape that is
a warranty claim from a customer’. These business functions one big web of dependencies of business and IT. And even
and processes are a way to look at the behavior of your if that was not the case, translating business strategy and
organization. requirements to the right IT-support, or using IT-innovations
to improve your business are difficult. Because, contrary to
Now, these days, you have computers to support your work.
popular belief and partly as a result of that inertia-building
You might not look at them anymore as computers (e.g. the
web of dependencies, IT does not change fast. Mostly be-
iPhone or iPad you are reading a book on), but they are.
cause its rigid logic lacks the flexibility of human compen-
And if your work is not shoe repair, plumbing, building,
sating behavior. Building a new office is generally a process
etc., your work will involve handling information. And even
that takes less time than implementing (let alone building
if it is shoe repair, the informational aspects of your work
and/or implementing) a new core IT system.
(planning, billing, accounting, etc.) are supported by IT. You
use IT in the line of your work. The IT that supports people This web of objects (physical and virtual products, bank
also has structure and behavior, just like the business itself. accounts, bills, roles and actors, applications, data, servers,
You use applications, and these ‘running’ applications have files, networks, etc.) and relations between them is what
functions (i.e. behavior) and deliver services (support) to the Enterprise Architecture is about. It is about the design of
business process. The applications themselves need an IT your business and the IT that supports it. It is about having
infrastructure to ‘run’, maybe large servers, maybe just your the right business organization, having the right IT for your
laptop or iPhone (where the applications are called ‘Apps’), business and letting the business innovate, now and in the
and there have to be all kinds of networks so all these sys- future. Especially, it is meant to lead to better IT choices,
tems can communicate with each other. because, as stated above, (the complex landscape made
possible by) IT is often more difficult to change than the stuff
And not only is there IT that supports people, some of it op-
humans do Humans are flexible. Digital computers have
erates independently. Software that runs robots in a factory.
enabled a landscape full of brittle dependencies that shows
Web sites that completely handle the customer’s interac-
many forms of inertia: resistance to change. But change is
tions.
what we want and need.
For about half a century now, the information revolution
The appearance of Enterprise Architects in this field is rela-
has moved most data from paper and other non-electronic
tively recent. Not too long ago, if you would try to find that
media to IT systems, even the data that eventually is printed
role you would end up looking at an organizations manage-
on paper. Not a multimedia, but a unimedia revolution has
ment. ‘The’ Architect of an ‘enterprise’ is its manager. He or
taken place: from all kinds of different storage and transport
she finally decides on how the business is organized, how it
media, the information has been digitized and been moved
is run and what IT is implemented. But the field has become
to being small electrically charged or magnetized spots,
complex enough that a special function has appeared: the
each of these spots representing a single yes/no choice: a
(Enterprise) Architect. The management has in fact out-
bit. We hardly think about that level, but we all know what a
sourced the (rough) design of its solutions to a specialized
file is these days, and generally we do not think of the paper
function, whose task it is to handle all that complexity. Here
original that the term originally stood for.
at least is already one important point: Enterprise Architec-
And next to much of the stuff of business, the behavior of ture should be the responsibility of (organizational manage-
business has also become more and more digitized. And ment of) the business, not of the IT provider. It is meant to
even our physical products have sometimes felt the result. help management to make fundamental decisions, not leave
Mass customization (the fact that you can have both scale them to someone else with some requirements and then say
and variation in production) is possible because we have “make it so”.
computers handling all the diversity.

Page 12 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Now, the Enterprise Architecture function has proliferated fulfill (amongst other things) a role comparable to that of the
and also fragmented. There are now business architects, ‘Lead Legal Counsel’).
security architects, application architects, data architects,
You can forget all of this, except for one thing: in the context
information architects, integration architects, enterprise
of ArchiMate, ‘Enterprise Architecture’ says nothing about
architects, infrastructure architects, domain architects, IT
being in the top of the organization, but about the fact that
architects, solution architects, integration architects, the list
an ‘enterprise’ is a coherent landscape that can be divid-
seems endless. And to make matters worse: the same job
ed in business, application and technology layers (or very
name may mean quite something different depending on
roughly: people, software and hardware) and Enterprise
who and where you ask for the definition. What one com-
Architecture is about all of them.
pany calls a business architect, the other company calls an
enterprise architect or a lead architect and what one compa- A second division, is often made in our field: a division
ny calls an enterprise architect another may call information between ‘architects’ and ‘designers’. For me, there is no
architect, etc.. fundamental difference between the two, both are forms of
design and the only difference is the level of detail they are
So, I am going to lay out my own definition and fragmenta-
concerned with. Leaving out details is not to be taken lightly,
tion of Enterprise Architecture. First, in line with the Enter-
though. It is one of the most difficult aspects of Enterprise Ar-
prise Architecture modeling language ArchiMate, I divide
chitecture. In my view, an Enterprise Architect is concerned
Enterprise Architecture into the following (ad hoc) practical
with all details, but sparingly goes into those details. Archi-
perspectives:
tecture is (in part) “the art of leaving out irrelevant details”.
• Business Perspective (processes, roles, abstract business Leaving out details, sadly, often derails into religiously ig-
objects such as ‘account’, etc.) noring details. The key word, however, is ‘irrelevant’: as the
Chinese proverb says: people stumble over molehills, not
• IT (‘virtual’) Perspective (IT systems, data, programs, IT
over mountains. An architect consciously leaves out details
integration, data transport, etc.)
that he or she has decided are irrelevant to the decisions to
• Physical Perspective (physical goods, tools, transport, be made.
hardware, etc.)
In the early 90’s, I had to follow a basic course on safety
These perspectives are tightly linked. when working as a contractor for Shell. Here I learned a
very valuable lesson: working safely is not about avoiding
Enterprise Architecture for me has nothing to do with the
risks, it is about consciously taking acceptable risks. There is
organizational unit (department, business unit, project) that
no such thing as not taking risks. For me, the same applies
the architect has as his domain, but everything with the fact
for abstraction in design. Abstraction is not about ignoring
that he or she is architect on all perspectives: business, infor-
detail, it is about consciously leaving out detail. And luckily,
mation, application, data, physical, infrastructure. Enterprise
as we will see later, ArchiMate is equipped for that, as it has
Architecture is about the coherent design and modeling of
a mechanism that supports having coherent detailed and
all perspectives. For me, a Solution Architecture is also En-
non-detailed views of the same model.
terprise Architecture, because the subject is also a domain,
and thus an ‘enterprise’ in itself. There is a third division one can make in Enterprise Archi-
tecture. Basically, an organization can use architecture in
Today, these perspective are often called layers, as if the
the following three settings:
business layer sits on top of an application layer which sits
on top of a physical world. This BDAT stack has long per- The Current-State (or As-Is or IST) architecture. This is a
meated Enterprise Architecture thinking, because Enterprise descriptive model of how the current landscape of business
Architecture was born from the problem of managing the and IT is. It can be used for reporting (e.g. to regulators) and
complexity of many IT systems getting interconnected, and analysis;
at that time, the stack was real enough: people used applica-
The Future-State (or To-Be or SOLL) architecture. This is a
tions, applications used ‘hardware’. Those simple days have
(rough) prescription on how the future landscape should be.
gone.
It generally consists of both high level models and guide-
I do recognize specialization of architects from a perspec- lines or requirements for the more detailed work done in the
tive: a Business Architect is concerned with the business line of moving towards the intended state;
perspective and an Infrastructure Architect with the IT-infra-
Change architectures. These are the descriptions of what
structure perspective. Some call these layers ‘domains’ as
Change initiatives like projects will produce. A com-
well, but I find that confusing. I reserve domains for recog-
mon forms are a Project (Start) Architecture or a Solution
nizable divisions of the organization, such as departments,
Architecture (this is also true when working in an Agile
business functions or projects. So, for me, an Domain Archi-
methodology, both ‘up-front design’ and ‘agile’ require
tect is an Enterprise Architect within a certain domain.
(a good documentation of) a good architecture). Like the
If enterprise in ‘Enterprise Architect’ does not denote organi- Future-State, these are a combination of models and require-
zational level, how do we then call the chief enterprise ar- ments, but the detail should generally be comparable to the
chitect of the organization? My favorite job name for such a Current-State as the Change initiative actually results in a
function is ‘Lead Enterprise Architect’ (and he or she should very specific change of that Current-State.

Introduction Page 13
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
Enterprise Architecture is in the end about: how), or in other words: about intentions. Now, I consider
the why important, but for me — though the context of a
• Making good choices in the light of the strategic goals
design is very important — it is not part of that design, and
and positions of your enterprise;
the idea that it makes sense to model the why is question-
• Making coherent choices across your enterprise able. Modeling your strategy and intentions (in ArchiMate
• Making good choices in themselves (e.g. in sense of called motivation) may be useful, but it is also naive: the
total cost of ownership, etc.) complex, contradictory almost quantum-like nature of our
intentions cannot practically be caught in a couple of simple
In all of these, modeling your existing state and your choices models with a few boxes and arrows depicting influences.
in ArchiMate can be really helpful. That is not to say that it cannot be useful to create a couple
of visualizations that support a certain message.
2.1 Where are the principles and guidelines? Still, this book is mostly about using ArchiMate to model the
actual enterprise, not its intentions, though some attention
You might wonder, with all this talk about modeling: where
is paid to that subject and the basics are explained. As thus
are my architecture principles and guidelines that architec-
it is about using ArchiMate for Solution Architecture and
ture is all about and that guide development for instance? I
Enterprise Architecture, and the discussion about what is the
can say this about it here:
difference will be left to the audience.
There are many definitions of what Enterprise Architecture
And importantly: if at any point while reading this book
is. The widely quoted ISO/IEC/IEEE 42010 standard, for
you get the feeling “why am I looking at diagrams of arcane
instance, defines (system) architecture as
(technological) details of some sort of deployment or some
fundamental concepts or properties of a system in its sort of business?”, remember: the book is not about teach-
environment embodied in its elements, relationships, ing you those (maybe for you irrelevant) details, it is about
and in the principles of its design and evolution teaching you ArchiMate (even if in the course of that it might
There are two aspects: the design itself (elements, relation- also need to address context, such as explaining blockchain
ships) and the principles of design. This book is about the before showing diagrams about Bitcoin (Section 27.7)).
first aspect. I know many Enterprise Architects who are of
the opinion that it is all about the second aspect. I could 2.3 Disclaimer
not agree less, and hence my approach to Enterprise Archi-
tecture is above all about the actual Business-IT landscape I have to warn you: in case you did not know: you almost
decisions that have to be made and the design of the next can’t learn anything from a book (the exception being do-
step in the perpetual change. Whether the use of principles books like Bobby Fisher’s Chess Lessons). The only way to
and guidelines is a good way to come to such decisions is learn something is by doing it (which is why Bobby Fisher’s
a question that is outside the scope of this book. It is one of book is an exception as it centers around doing all the time).
the subjects of my other book: Chess and the Art of Enter- Knowledge is about ‘know how’ not about ‘know what’. It’s
prise Architecture. funny that — while being convinced of this — I have written
a book to teach ArchiMate. But anyway, you won’t really
learn ArchiMate from this book, you need to seriously use
2.2 The Why, the How and the What the language to really learn it. But if you do that, this book is
There is another issue that needs clarification, related to the meant to help you out and speed you up. Writing the book,
previous ones. As remarked above, many Enterprise Archi- by the way, is almost (but not quite) as much fun as teaching
tects are of the opinion that Enterprise Architecture is all a class (and educational in itself).
about the why of choices (strategy, translated to what and

3. Gratitude
I am very grateful for the assistance of the following people: Without that opportunity I would not have been able to
gather the experience to be able to fill this book;
• First and foremost: Jos Knoops, colleague at APG, who
has been an invaluable sparring partner from 2010 to • Peter Spiers of Adobe Forums, who helped me get start-
2014 when discussing how we would be using Archi- ed with Adobe InDesign and helped me solve serious
Mate, e.g. patterns; issues in my first attempts at the document in 2012 and
later in 2014, and without whose help, I would not have
• Former APG colleagues Joost Melsen, Floris Hack, and
had a tool to produce this book at all;
APG colleague Paul Hamers for more real world pattern
discussions between 2011 and 2014; • Marc Lankorst, the ‘father of ArchiMate’ and Jean-Bap-
tiste Sarrodie, the Vice-Chair of the ArchiMate Forum,
• Leon Joosten, former colleague at APG and my then-
for their blush-inducing forewords on page 5.
time manager, who supported me at APG when I want-
ed to introduce ArchiMate to the organization in 2009.

Page 14 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 • And of course, last, but certainly not least: my family,
who — while I was writing — have carried the burden
of the fact that I was writing and thus had less time to do
my chores and be a sunny, active part of family life.

4. License & Legal

This book is © Gerben Wierda 2017. All photographs used donated or bought a license. Please do not give this docu-
are public domain. All diagrams have been created by ment to people you did not buy a license for, and please do
Gerben Wierda unless indicated otherwise. ArchiMate® is not remove the stamping or the printing restriction. It might
a registered Trademark of X/Open Ltd. working under the feel like a victimless crime, but it isn’t, because in the end
name The Open Group. BPMN is a trademark of the Object it costs me. Statistics on Mastering ArchiMate Edition I have
Management Group. shown that when a free copy is available, less than 1 in 100
still pays. Even if 90 of those 100 would not have purchased
This book comes in four different versions:
the book anyway, a freely available copy in the end still
• A hardcover version distributed via normal channels for costs me 9 out of 10 sales, and I worked very hard to create
printed books (ISBN 978-90-819840-9-6); this book. Do you really want to reward me that way?
• A full electronic version (PDF) that is restricted (printing You can contact me at the following e-mail address:
not allowed) and stamped (ISBN 978-90-819840-8-9);
info@masteringarchimate.com
• An syntax excerpt electronic version (PDF) containing
Heerlen, The Netherlands,
only the basic introduction to the language.
Gerben Wierda
You are now reading the PDF edition.
Edition I was distributed as unprotected PDF. It was success-
ful, but only a very, very small (but appreciated) minority

5. Release Notes for Edition III.TC1

August 2017: BPMN-ArchiMate linkage that was developed in it. The
parts that could be different in ArchiMate 3 are colored
• In a few places I’ve used Donald Knuth’s
in magenta.
‘dangerous bend’ image from The TEX Book
(here shown on the left) to warn you that it gets • In several places I have left the term ‘infrastructure’ for
a bit complicated. It’s a way to show my respect the IT part of what is since ArchiMate 3 called the tech-
for Knuth’s work and to express my deep felt wish* it nology layer (and which supports physical technology
would have been feasible to do this book in TEX. next to digital technology) in place (though all elements
are named properly). This is intentional, as infrastructure
• ArchiMate 3 was released in June 2016. It has taken
is a common term for that part of IT.
more than a year to update Edition II to Edition III.TC1.
There were some personal reasons (this is done in my • Given that I have some room to spare: this book could
spare time, of which I had little); I write from actual not have been produced in the time that took without
experience, and I needed to build that experience; and the music via/of King Crimson, (early) Gentle Giant,
ArchiMate 3.0 was seriously broken (mostly the formal- Camille Saint-Saëns, Edvard Grieg, Reinhard Mey, Jethro
ly allowed relations table was broken and it was often Tull, Studio Brussel, Pjotr Ilitsch Tschaikovsky, Georg
unclear which relations were allowed and which not). I Friedrich Händel, Simeon Ten Holt, Braak, (early) Allan
wrote about that in January 2017 on my blog and I had Parsons Project, Pink Floyd, Alquin, Count Basie Or-
to wait until ArchiMate 3.0.1 (Technical Corrigendum chestra, Philip Glass, (later) The Beatles, (early) DeWolff,
1, or TC1†) was released before I was certain my book ELP, Frank Zappa, Jean-Michel Jarre, Joe Satriani, Johann
would be correct. Sebastian Bach, Mike Oldfield, Muse, Sergei Prokofiev,
The Police, Red Hot Chili Peppers, Renato Carrosone,
• The numbering of diagrams is imperfect. Often higher
Stromae, Alfred Brendel, several soul songs, and many/
numbers appear before lower ones. I have not found a
much more...
way to do this properly in InDesign.
• Section 30 “A Possible Linking of BPMN and Archi-
Mate” on page 164 is partly still based on ArchiMate
2 limitations, as my tool has stopped supporting the

* And not just because I received a TUG Award once. I truly love TEX’s output quality, stability (boy, do I miss that), and logical writing
through a macro package
† Hence “Mastering ArchiMate Edition III.TC1”
Introduction Page 15
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Basics
ArchiMate
etaMihcrA
scisaB

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005

 ArchiMate
Basics
6. An ArchiMate Map
ArchiMate has over the years become a rich environment

Motivation (of the Architecture)

Intentions
that covers many aspects of modeling in Enterprise Archi- Strategy of the
Enterprise
tecture. It started out as a simple language to model infor-
mation-heavy enterprises, focused on modeling the relation
between ‘the Business’ and ‘IT’. In version 3 it covers a lot
more. From modeling the strategy of an enterprise to the
modeling of physical processes. The old core of ArchiMate 1
is still there, and it is appropriately called the ‘core lan- The Enterprise Itself
(Core)
guage’. It is what you use to model an actual enterprise: its
processes, roles, actors, IT, physical equipment and facilities
and so forth. This part of ArchiMate is about modeling the
enterprise itself, as it is, as it should be, as it could be, what-
ever you need to express in your model.
Change of the Enterprise
As of version 3 of the language, ArchiMate now also has a (Implementation &
Migration)
part that is meant to model the strategy of the enterprise. It
contains elements such as capability and resource. The lan-
guage sees strategy as something that can be realized by ‘the View 1. The ArchiMate Map — Rough
enterprise itself’, it is thus seen as some sort of abstraction.
We will get to the finer points about thinking about abstrac-
This book focuses on the ArchiMate Core, the enterprise
tion (and recursion) later.
itself. The main reason for this is that it is there that we
As of version 2 of the language, ArchiMate has a part that is encounter the complexities that make modeling actually
about modeling the change of the enterprise. Here we find very useful. Another reason is that I have my doubts that
elements to express (project) work packages, (architectural) modeling intentions and strategy are actually very useful.
plateaus, identified gaps that need to be filled, deliverables Modeling strategy cannot be much more than illustrative
(of projects) and so forth. Though meant to model change for what in reality is a narrative that has many aspects that
of ‘the enterprise itself’, it can easily also be used to model practically can’t be modeled at all in the same way that
changes of the ‘strategy of the enterprise’, e.g. we might intelligent behavior cannot be caught in rules. Both inten-
model a deliverable that realizes a Capability. tions and strategy are domains that are far from logical in the
real world and trying to map them onto a logical structure
Finally, also as of version 2, ArchiMate has a part that is
(which is what we do when modeling in ArchiMate) will
about intentions which consists of elements such as require-
have serious limitations, limitations which turn into ‘be-
ment, goal, driver, stakeholder, et cetera. Though originally
witching ourselves’ when we ignore them. Both also tend to
meant as a part that is used to model the intentions of the
invoke with me doubts that stem from being a bit acquainted
architecture of ‘the enterprise itself’, it can as easily be used
with analytic philosophy. For the ‘change of the enterprise’
to model intentions of ‘the enterprise itself’ or the inten-
part of ArchiMate, I doubt if simply adding these to a model
tions of ‘the strategy of the enterprise’ or the intentions of
is usable and scalable and, again, their practical use might
the ‘change of the enterprise’. In fact, Mastering ArchiMate
be only illustrative. Here, in my estimate, the main problem
Edition II, the previous version of this book, only used them
is that we do not have tooling yet that is capable of actually
to model risk & security in relation to ‘the enterprise itself’.
using this in a scalable way. For all three parts, small toy-size
All of these parts are shown in View 1.

Page 17
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
examples, such as used by consultancy, tool and training attention to these parts, enough to give you a good introduc-
providers can be easily created. But having these used in a tion, but I will mainly focus on using ArchiMate to model
large-scale complex setup in a way that is actually useful ‘the enterprise itself’, using the other parts to strengthen that
(and thus meaningful) is quite something else. I will pay goal.

7. Main Core Elements and Relations

When modeling Enterprise Architecture, we need a language layering common to most enterprise architecture approach-
that knows about the concepts of ‘the enterprise itself’, and es. There are layers, from Business (processes, actors, roles
ArchiMate does a good job. To start with, you need to know and so forth) ‘down’ to Application (application compo-
that almost all of ArchiMate is built from three types of nents, application functions, etc.) and Technology (com-
elements: puting and other physical infrastructure and objects). So, a
complete map would look like this:
• elements that act: active (structural) elements
• elements that represent the behavior of those ‘elements

Behaviour

Structure

Motivation
that act’: behavioral elements Strategy

• elements that cannot act and which are acted upon by

that behavior: passive (structural) elements Business

The three element types, connected by relations, can form

sentences of sorts. A pickpocket (the application) steals (the

Core Layers
Application

Layers
application function) a wallet (the data). This is what makes

Passive Structure

Active Structure
ArchiMate a grammar, although people generally call it a

Behavior
Technology
language. The structure of the ArchiMate grammar is partly
based on the subject-verb-object pattern from natural lan- Physical
guage.
Your model is therefore a story of sorts. It tells the reader the
Implementation and Migration
basic structure of the story: who acts on what.
Going back to our rough ArchiMate Map, we might add this
internal structure as seen in View 3: Aspects

View 4. The ArchiMate Map — Complete

Behaviour

Intentions / Motivation (of the Architecture)

Structure

Strategy of the
Enterprise
The Motivation and Implementation & Migrations parts were
extensions to the Core that first appeared in ArchiMate ver-
sion 2. With respect to version 2 of ArchiMate, ArchiMate 3
has gotten an extension of the technology layer to model the
physical side of the enterprise. This is why I (and others) pre-
Passive Structure

Active Structure

fer not to show the physical side as a wholly separate layer.

Behavior

The Enterprise
Itself With all that said, we will now begin to start explaining
the elements and relations in all these parts. We will start
somewhere in the middle of ‘the enterprise itself’, specifical-
ly at the application & data perspective of classic IT-oriented
Enterprise Architecture.
Change of the
Enterprise
7.1 Application and Business
An application is fully modeled in ArchiMate as seen in
View 2.
View 3. The ArchiMate Map - With Aspects

As you see, there is a slight anomaly here. The Strategy part (Application Service) (Application Interface)

of ArchiMate doesn’t have active and passive structure, it

just has structure (and only one element in that: Resource
(but we’ll get to that later).
(Data Object) (Application Function) (Application Component)
We’re not entirely done yet with mapping ArchiMate. The
core of ArchiMate, the part about modeling ‘the enterprise
View 2. The Basic Application Pattern
itself’ has the classic (some would say ‘orthodox’) B(D)AT
Page 18 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 This is possibly the first snippet of ArchiMate you have ever might not be needed; you can imagine behavior that
encountered, and it already has five element types and four does not access a passive element. You can also imagine
relation types, so we are going to take our time to describe that you do not model Data Objects that only exist inside
it. your application. Not every variable in the application
code is modeled. But as soon as the Data Object is
Roughly, the two yellow and two blue elements in the image
visible to other parts of your landscape, or when it is
together make up the ‘application’ and the green element
persistent, it could be there. Generally, that means we
is the data the application operates on; i.e. think of it as the
generally only model (semi-)persistent Data Objects.
blue and yellow elements representing the word processing
Note: this is not the file or the database itself — those are
application and the green element representing the docu-
represented on a lower level: the Technology level. We
ment being edited*. The lower three elements represent the
are still one abstraction level up. To illustrate the differ-
internals of the application (blue & yellow) and the data
ence: an RTF file (technology) can be both an MS Word
(green). The two upper elements represent how the applica-
Data Object or an Apple TextEdit.app Data Object,
tion can be used by and is visible for (exposed to) a ‘user’,
depending on which application is used to access it.
the externals.
Two elements in the image have not been explained yet.
One of the most essential aspects of ArchiMate is that mod-
They have to do with how the application is used/seen (by
eling the behavior is separated from modeling the structure.
the business or by other applications):
The blue elements in the figure represent the active structure
(’who’) and the yellow elements represent the behavioral This is an Application Interface. It stands for
(Application Interface)
aspects of the ‘who’ elements — they are two sides of the the route via which the application offers
same coin: in a certain sense one can’t exist without the itself to the business or to other applica-
other. tions. Note: both separate concepts (used by people and
used by other applications) are supported by this one
It seems rather excessive that you need four elements to
element. One example would be a Graphical User
model a single application. We will later see that you can
Interface (GUI), but it can as well be an Application
simplify this, even to a single one of these elements, but
Programming Interface (API), a Web Service or one of the
for the moment it is very important to understand what the
many other ways an application offers itself to other
underlying structure looks like. Actually, the lack of address-
‘actors’ in your landscape. Given that difference in use
ing this in documents and courses I have seen, has been a
(and thus, as Uncle Ludwig would say, meaning), it is
major reason for writing this book. An understanding of the
unlikely that the same interface will be used by both a
foundation is required to model well in ArchiMate.
human or another application. But it can be; e.g., in the
Having said that, here is a short explanation of the 5 ele- case of a Command Line Interface (CLI) used by a
ment types in View 2: scheduler system. Application Interface is a ‘handle’ of
the ‘actor’ that is the Application Component. It is one
This is an Application Component. It stands
(Application Component) side of a coin of which Application Service is the other.
for the ‘actor’ that an application in your
Enterprise Architecture landscape actually This is an Application Service. It stands for
is. It is one side of the coin of which the Application the ‘visible’ behavior of the Application,
(Application Service)

Function (its behavior) is the other. how the Application Interface can act for a
user. It is one side of the coin of which Application
This is an Application Function. It stands
(Application Function) Interface is the other side. Here again, the service may be
for the behavior of the Application Compo-
‘technical’ in that it is offered by one application to other
nent, how the application can act. It is one
applications or it may be part of your Business-IT integra-
side of the coin of which Application Component is the
tion: services offered to business processes (behavior of
other.
humans). The same type of element is used for both. This,
Application Component and its behavior are, in a way, in- by the way is a common first hurdle for architects coming
separable. You cannot have an actor that does not act unless from the engineering side, where it is common to define
the actor is dead, and in that case it should not appear in ‘application service’ as ‘service provided by an applica-
your architecture. And without magic, you cannot have an tion and used by another application’ and define ‘busi-
act without an actor. Again, later we will see how to leave ness service’ as a ‘service provided by an application that
things out of our views and models, but for now we stick to is used by the business’. In ArchiMate, a business service
the details. is something else, which we will see below.
This is a Data Object. It is what the Appli-
cation Function acts upon. The Application
(Data Object)

Function might create, read, write, update

or delete the Data Object. Conceivably, the Data Object

* ArchiMate is color-neutral. Color has no grammatical meaning. Most tooling use a ‘layered’ default color setup. I use a matrix based
on the original ArchiMate 1 default coloring which stresses the difference between active/passive structure and behavior. See Section 14.4
“Using color” on page 60. I’ve found this choice to be easier for communication (and thus education, i.e. this book) but your mileage
may vary.
ArchiMate Basics Page 19
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
Now, apart from the elements, there are relations between layer so it is easy to understand now and it can be seen in
the elements. There are four in the initial image: View 6.
This is the Access relation. The access relation I have left out the actual human actor — the one that fulfills
always depicts a behavioral element accessing a passive the Business Role — for now to stress the equality between
element. Here it depicts the behavior of the applica- this pattern and the one about the application in View 2 on
tion (the Application Function) accessing a passive data page 18. It looks quite the same and that is not a coin-
element (the Data Object — something that in the end cidence. The relations are the same as with the application
generally resides in a file or a database). An arrowhead image above. The new element types are:
(on either side) is optional and it may depict read access
This is the Business Role. The Business Role
or write access (e.g. two for read/write).
is an ‘actor’ in ArchiMate, but it is slightly
(Business Role)

This is the Composition relation. It means that the more complicated than that, because it is
element at the end with the diamond is the parent of the an abstract sort of actor based on ‘being responsible for
element on the other end and that the child cannot exist certain behavior’. The real actors are people and depart-
independently from the parent. The relation depicts the ments and such. ArchiMate has an element type for those
composition of larger wholes out of smaller parts, but it as well, but we leave that for later. Business Roles can
does not mean the set of children modeled must be nec- perform Business Processes, just like Application Compo-
essarily complete in your model: there may be parts that nents can perform Application Functions.
are not modeled. This relation could also for instance be
This is the Business Process. It stands for a
used to show that an Application Component has various (Business Process)
set of causally-related activities that
subcomponents.
together realize services or create some-
This is the Realization relation. This has two types thing. Roles can be assigned to a Business Process, they
of use in ArchiMate. Here it means that the perform the process, just as the Application Component
element at the end without the arrowhead is the element performs the Application Function. Just as in the applica-
that ‘creates’ the element at the end with an arrowhead: tion layer, a Business Process cannot exist without a
the application’s internal functionality realizes a service, Business Role (which does not mean you must model
which is the externally usable functionality of the both, I am talking about the reality you are modeling),
application. they are two sides of the same coin. We also have
Business Function, but we leave that for later.
This is the Assignment relation. This also has more
than one meaning in ArchiMate. Here, it means This is the Business Object: the (generally)
that the side with the dot (the active element) performs abstract element that is created or used by
(Business Object)

the behavior that is the behavioral element on the side a Business Process. Think of objects like ‘a
with the arrow head. payment’ or ‘a bank account’ or ‘a bill’. Though it is
named Business Object, it is more like a Concept. It may
Important and possibly initially confusing aspects of Ar-
represent non-informational objects as well, e.g. if your
chiMate are thus that — while we have multiple elements
company produces steel beams, you may have a ‘Steel
(structural and behavioral) representing what is in the mind
Beam’ Business Object representing the beam itself and
of many a single thing (an application or an application
not information about the beam.
interface) — we also have single elements (and as we will
later see, relations) that can be used with multiple meanings. Again, just as with the application, these elements can make
When you get the hang of it, everything becomes pretty sentences of sorts. The proverbial ‘second hand car sales’
natural just like it is with natural language, but if you are role performs the ‘sell second hand car’ process, which
looking for a strictly disjunct (made of independent con-
cepts) approach to a modeling language (e.g., like a pro-
gramming language or like UML), it might be confusing in (Business Service) (Business Interface)

the beginning.
Having modeled an application, we can turn to modeling
the way this application is used by the business. And before (Business Process) (Business Role)
(Business Object)
that, we need to look at the way the business & information
layer of Enterprise Architecture is modeled in ArchiMate.
Luckily, it looks a lot like what we saw in the application

(Application Service) (Application Interface)

(Business Service) (Business Interface)

(Data Object) (Application Function) (Application Component)

(Business Object) (Business Process) (Business Role)

View 6. Basic Business Process Pattern View 5. Basic Application is used by Basic Business Pattern

Page 20 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 creates a ‘bill’. Criminal, crime and — in this case, possibly level and application level is identical, so we are going to
— proof of crime. illustrate only one.
This is the Business Interface: the way the
role interacts with others. You can think of
(Business Interface)
7.2 The double use of the Serving relation
it as a ‘channel’; e.g., phone, mail, meet-
So far, our example has only shown Serving as a relation be-
ing, etc.. The interface is the visible manifestation of a
tween levels in your architecture. But the same relation type
role. E.g. if the role is ‘help desk agent’ the interface
can also be used within a level. The business may use an
might be ‘telephone’, ‘Twitter’ or ‘web site chat’.
application, but an application can also be used by another
And this is the Business Service: more or application.
(Business Service)
less what it is always about in an organiza-
In View 7 you see the same Serving relation ( ) twice.
tion. This is the reason
Once between the ‘A’ Application Service and the Business
for the existence of the process. This (Business Process)

Process that uses the ‘A’ application, and once between the
is the service it offers to (and thus
‘B’ Application Service and the ‘A’ Application Function.
can be used by) others (either inside
This means that the ‘A’ application makes use of the ‘B’
or outside the company). A company A
(Application Service)
application. Though the relation is Serving in both cases,
might offer many services; e.g., a
it has quite a different role to play.
bank offers at the
Often, the definition of an Application
most abstract level A A B
Service that is used by the Business
a ‘savings’ service (Application Component) (Application Function) (Application Service)

is pretty business-like in its descrip-

or a ‘loan’ service.
tion, something
Having set up a couple of basic elements and relations, we B B you discuss with
can now fill in the missing links. Because on one hand we (Application Function) (Application Component)
a senior user or a
have the business that offers services to others, on the other View 7. An Application Using Another process owner. But
hand we may have IT that offers supporting services to the Application the relation between
business. Together they look like View 5 on page 20. applications is more
The application level is connected to the business level by of a technical nature and you discuss it with application
three relations. On the left we see the already familiar architects. The difference generally shows itself clearly in the
Realization relation ( ). Here it means that the Data types of names and descriptions of the service. It is hard to
Object realizes the Business Object. In a concrete example: truly imagine an Application Service that is both used by an-
the ‘bank account’ Business Object may be data (a Data other application and a Business Process. After all, both uses
Object) of an accounting application; it is the same item’s will be pretty different, unless we are talking about a fully
representation in a different architectural ‘layer’. Note: we automated business process, which we will handle later.
will get back to ‘concrete versus abstract’ modeling later. It is good to mention here that ‘serving’ (or ‘used-by’ as it
In the middle and on the right we see a new relation: was called before) is not unambiguous. If Application A
calls a service (API, web service, etc.) of Application B, but
This is the Serving relation. It means that the it does this to deliver information that Application B needs,
element at the end without the arrowhead serves the who serves who? Arguments can be made for either direc-
element at the end with the arrow head. In previous ver- tion. We’ll get back to this in Section 25.2 “Who is Serving
sions of ArchiMate this relation was called Used By and Who Anyway?” on page 128 when we will discuss the
you will still see this name in many places. The Applica- choice of pattern in some more depth. For most of our pat-
tion Service, for instance, Serves (is used by) the Business terns we will not need a deep discussion.
Process. The Application Interface (e.g. the Graphical
User Interface) is Serves the Business Role.
7.3 Function versus Process
The fact that an Application Interface can serve a Business
Role is the ‘other side of the coin’ of the same Serving So far, we have modeled business behavior as a Business
relation between Application Service and Business Process. Process and application behavior as an Application Func-
They are twins. Both illustrate the ‘service oriented’ way that tion. But ArchiMate actually has two main work horses
ArchiMate relates one layer to the next as far as actors and for behavior in all layers: process and function. In terms
their behavior goes. of the grammar, they are completely identical. They allow
for exactly the same relations with other elements. In fact,
With what has been explained so far, you can already do you could see them as ‘convenience types’ for a generic
much of the modeling you need in terms of Business-IT ‘behavior’ element in each layer. For now, as we are doing
focused ‘Current State’ or ‘Change/Project’ Enterprise Archi- the superficial introduction, it is best to use the following
tecture. There are two more things that need to be explained guidelines:
before the basic setup is complete: applications using other
applications, and business processes/roles using other busi- • You use a process if you are thinking of a causally-relat-
ness processes/roles. Here again, what happens at business ed set of behaviors (‘activities’) that in the end produce
something, normally a service or an object. Business

ArchiMate Basics Page 21

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Process is thus an outside-in way of dividing up business 7.5 Adding Technical Infrastructure to the Mix
behavior, based on what the behavior actually produc-
Just as the Business Process in our current scenario needs
es.
the Application Service to be able to be performed, the Ap-
• You use a function if you are thinking of a grouping of plication Function needs (IT) infrastructure to run. If we add
related behavior based on — for instance — same tools, the infrastructure to the application layer, we get View 9.
same skills or same role that performs it. Business Func-
There are no new types of relations here, but there are new
tion can thus be seen as an inside-out way of dividing
element types:
up business behavior, based on what it is capable of.
This is the Node. This is a slightly compli-
In section 18 “Business Function and Business Process” on (Node)
cated concept in ArchiMate and more
page 91 we will look into the difference in the business
details follow later, but for now, think of it
layer in more depth and see that there is a nice way of com-
as a generic piece of IT infrastructure: hardware combined
bining them both when modeling your business layer.
with its system software, where files are stored or applica-
Business Function looks like this: tions can run. We’ll see the details later.

(Business Function)
This is the Technology Function. Just as
(Technology Function)
with the Application Function and the
Application Component, the Technology
And Application Process, as you might expect, looks like Function stands for the behavior of the Node. They are two
this: sides of the same coin. As you might guess, there also is a
Technology Process, which is the same, just with an ‘arrow’
(Application Process)
icon in its standard visualization.
This is the Technology Service, the visible
We will get into the use of colors later, but as you can see I (Technology Service)
behavior of the Node. In many ways, this is
use colors to separate the aspects (structure, behavior) and
what the infrastructure is all about, what it
intensity to separate the layers (business, application). It
can do for the applications, its reason of existence. This is
suffices to repeat the earlier footnote on page 19 here that
what the applications need to function. Typical examples of
ArchiMate is officially colorless. I use these colors because
Technology Services are for instance a ‘file share’ or ‘appli-
in my experience they really work well.
cation execution’ or a ‘database service’. The latter may
cause confusion, because you might wonder why that is an
7.4 Business Actor Technology Service and not for instance something at the
application level. We’ll discuss that in Section 12.7 “Why
Earlier we encountered the Business Role. The Business Role
two types of software?” on page 52, but for now, it is
is an abstract sort of actor. But in a business architecture
enough to say that the Node comprises both the hardware
there are of course real actors: people, departments, or even
and the system software. A database system is generally
modeled as ‘system software’ and the database as an Artifact
(Business Process) (Business Role) (Business Actor)
(see below).
View 8. Business Actor in Context This is the Technology Interface. This is not
(Technology Interface)
that easy to explain. For Application
business units or companies or maybe regulators. ArchiMate Interface, one can easy dream up an easy
has an element for that: the Business Actor, as seen in con- example: the (graphical) user interface. But for the Technolo-
text in View 8. gy interface, ArchiMate is not very clear; it says it might be
best thought of as a kind of contract
On the left we see the already familiar Business
(Application Service) (Application Interface) that the ‘user’ (the application) has
Process to which a Business Role is Assigned.
to fulfill. An example would be a
The Business Role performs the Business Pro-
protocol, like the SMB or NFS
cess. On the right we see the
protocol for file sharing and the
new element type Business (Application Function) (Application Component)
(Data Object)
TCP/IP or UDP/IP ports where the
Actor, which is Assigned-To
service is offered. Unless you are a
the Business Role. This must
dedicated
be read as the Business
infrastructure
Actor fulfills the (responsibil-
architect, you
ities of the) Business Role. (Technology Service) (Technology Interface)
can generally do
ArchiMate was designed to
without this one.
be economical with relation
I am just men-
types, so it re-uses the rela- "Data" Bytes "Executable" Bytes
(Artifact)
(Technology Function) (Node) (Artifact) tioning it here to
tion for a slightly different
be complete and
meaning.
leaving it out
View 9. Basic Application uses Basic Infrastructure

Page 22 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 here would introduce the concept of ‘pattern’ before it is And lastly, there are the Realization relations ( )
wise to do so. between an Artifact and both Data Object and between
Artifact and Application Component. This one is also pretty
The last new element (for now) is the
simple and easiest to explain by example. Suppose your
(Artifact)
Artifact. This one is pretty simple. The best
application is Microsoft Word, then the file you are editing
example is a file. Another often-used
could be called “foo.doc”. And if the application is MS
example is the actual database where your application’s data
Word, the Artifact realizing the Application Component
resides. Another example is the actual ‘executable’ (file) also
could be “word.exe”.
known as ‘the binary’: what your application is when you
look at the ‘byte’ level. Your application. The ‘data bytes’ Note: we are still in an IT-focused scenario. The Tech-
Artifact in the model above is the one that realizes the Data nology Layer of ArchiMate’s Core has (since version 3)
Object that is accessed by the Application Function. The elements to model the physical side of an enterprise,
‘executable bytes’ Artifact forms the bytes (a file, or a set of e.g. a physical production process. We will get to that
files often called a ‘software distribution’) that the system below. For those that are already acquainted with ear-
can read and interpret as a program. On the infrastructure lier versions of ArchiMate: the name of the ‘bottom’
level, ‘a byte is a byte’ in the sense that both passive (Data) layer of ArchiMate has changed from (IT) ‘Infrastruc-
elements and active (Application) elements are in the end ture’ to the more generic name of ‘Technology’ so it
nothing but a collection of bytes. Deep down, we get to the better fits the non-IT oriented use.
basic level of zeros and ones (as we should).
I have a detailed example model for you in View 10 to see
The relations are mostly pretty straightforward. The Assign- everything in a single context. The model shows someone
ment relations ( ) between Node and Artifacts stand writing a letter to a customer that contains an answer, sup-
for the fact that the Artifacts resides on the Node. In other posedly to a question the customer has asked. Two infra-
words, it depicts where in your infrastructure you can find structural services are needed for this to work. The applica-
a file. Also pretty simple are the Serving ( ) relations tion should run and the document must be stored. In this
between Technology Service and Application Function and example, everything happens on a standalone PC.
between Technology Interface and Application Component.
If you are an ‘enterprise’ architect you may think that all this
If an Application Function needs access to a file that resides
detail is irrelevant and that the language looks like a lan-
on a file system, the file system is an Technology Service that
guage for detailed design only. Don’t worry: using Archi-
Serves the Application Function. And its mirror is the Serving
Mate does not mean you absolutely must model all these
relation from Technology Interface to Application Compo-
details, the language can handle both: a roughly sketched
nent. This mirroring is depicted by the Assignment relation
Business Operating Model down to the nitty-gritty details
( ) between Technology Interface and Technology
you have to confront when you are in a project. I am simply
Service, exactly as happens in the levels above between the
using an example everybody knows, to illustrate how it
‘interface’ and the ‘service’.
works in ArchiMate. And even in View 10, I have left some
things out, and I have combined the Technology Interfaces
into one element. I could also have combined the Technolo-
Write Answer Customer Support
gy Services into one element. I will address handling details
Answer
(Business Object) (Business Process) (Business Role)
later when I am discussing ‘modeling patterns’.
One more comment, before we go on with the rest of the
language. As you might have noticed, the initial example
[MS Word]
Document Creation
[MS Word]
GUI
with infrastructure in View 9 had no Access relation be-
(Application Service) (Application Interface)
tween the Technology Function and the ‘executable’ Artifact.
But the ‘write answer’ example of View 10 does have that
Word Document
[MS Word]
Editing
[MS Word]
Word Processing
kind of a relation (shown in red). Here an explicit Technol-
(Data Object) (Application Function) (Application Component)
ogy Function for application execution was modeled and
that function needs access to the ‘executable’ artifact. So
which one is correct? The answer is: whatever your brief
is and what you want to show. ArchiMate is a grammar,
Windows File Storage
(Technology Service)
Windows Application
Execution
Windows APIs so it is your choice what you want to put in that gram-
(Technology Interface)
(Technology Service)
mar and how you put it. You have considerable freedom
and you will certainly develop your own style. You can
certainly model incorrectly in ArchiMate, just as you can
File System Windows Binary Execution
(Technology Function) (Technology Function)
Desktop or Laptop PC
(Node) write false statements or make grammatical errors in any
language. So, yes, there are wrong models, but I will be
unable to show you a way to model ‘the right way’. The
foo.doc word.exe
syntax of the ArchiMate language does not by definition lead
(Artifact) (Artifact)
to correct statements, but there are also many ways to say
View 10. Write Answer Process, supported by MS Word and a Stand- the same thing, just as with other languages. Later, we will
alone PC

ArchiMate Basics Page 23

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
address choosing your style and patterns, the latter being software can run. So, for instance, Java on your computer
like ‘common phrases in the language’. is System Software. It can read and execute JAR files which
contain Java instructions. See also section 12.7 “Why two
types of software?” on page 52.
7.6 System Software and Device
Our first use of IT infrastructure elements was pretty limited.
We added the Technology Function, the Technology Service,
7.7 Composition and Aggregation
the Node, the Technology Interface and the Artifact. Archi- We already met the Composition relation ( ) earlier.
Mate adds two useful active structure concepts to model the The composition represents a whole-part relation. It is best
actual infrastructure level of your IT architecture: Device to look at the ArchiMate version of this common relation as
and System Software. The best way to explain them is by the relation between a tree (a real one from your garden, not
giving an example of how they can be used. the computational concept) and its branches. A branch is
branch of a single tree and cannot be a branch of multiple
In View 11 we see a model of a database server in our land-
trees. If the tree is destroyed, all of its branches are destroyed
scape. The name of the server is ‘srv001’ and that could be
as well.
the name it carries in a CMDB for instance.
Generally, you may always create a Composition relation
[srv001] [srv001] between two elements of the same type. View 12 contains
PostgreSQL RDBMS ETL NFS File Share
(Technology Service) (Technology Service) an example.
[srv001]
Linux Application
Execution [MS Office]
(Technology Service) (Application Component)

[srv001] [srv001] [srv001]

PostgreSQL Functionality "Linux Binary" Execution NFS
(Technology Function) (Technology Function) (Technology Function)

[MSOffice] [MS Office] [MS Office]

MS Word MS Excel MS PowerPoint
[srv001] [srv001] (Application Component) (Application Component) (Application Component)
PostgreSQL Red Hat Linux
(System Software) (System Software)
View 12. Composition Example

[srv001]
The Aggregation relation ( ) is a variation on the theme.
x86 server
(Device) It looks like View 13.

View 11. Device and System Software Factory Items

(Business Object)

The new element types are:

[srv001]
This is the Device, the actual hardware, the
x86 server
(Device) ‘iron’, the equipment of our infrastructure.
In this example, two elements of the type Conveyor Belt Peanut Grinder
(Business Object) (Business Object)
System Software have been deployed on it (Assigned-To
Jar of Peanut Butter
it). The little logo of the element is an image of a key- (Business Object)

board/screen. Bread Knife

(Business Object) (Business Object)
[srv001] This is the System Software element. It
Red Hat Linux
stands for software that we consider to be
(System Software)

part of our Technology layer and not our

application layer. Common uses are operating systems or
database systems, but also runtime environments are Breakfast Items
generally modeled as System Software (the name of (Business Object)

which is a bit quaint, given its wider use). In our example

View 13. Aggregation Example
both are available: the Red Hat Linux operating system
and the PostgreSQL database system. Modeled too is that
It is best to look at the Aggregation relation as a kind of
the PostgreSQL software uses the Red Hat software. (If we
grouping (note: in Section 7.13 “Grouping” on page 28
have our existing landscape modeled in such detail, we
we will see an official way to ‘group’ various elements of
could by analysis find all PostgreSQL databases that run
different types). The ‘parent’ (on the end with the diamond)
on Red Hat, handy if we are planning an update and
represents a ‘collection’ of the children. But other than with
there is something about PostgreSQL running on Red Hat
Composition, the children may be a member of multiple Ag-
that merits extra attention).
gregations as you can also see in View 13: The ‘Jar of Peanut
What really sets System Software apart from Application Butter’ is both part of the ‘Factory Items’ of the peanut butter
Component as System Software is that System Software is factory and the ‘Breakfast Items’ of a consumer’s home.
often a sort of platform. It is an environment where other It’s a like the number 4 being both part of the collection of

Page 24 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 squares of integers and the collection Math Department
(Business Actor)
same element twice. Are you going
of even numbers. Composition versus to spot that the same element occurs
Math Teacher Math Researcher
Aggregation is sometimes described (Business Role) (Business Role) twice? Probably not. So are you go-
as ‘has-a’ versus ‘part-of’, the differ- ing to see the dependencies in full?
Teaching Analysis Researching Analysis
ence being not directly clear from the (Business Function) (Business Function) Again: probably not.
terms. Also, composition is sometimes
View 17 contains another Assign-
referred to ‘strong ownership’, where- Teaching Statistics Researching Statistics ment example of Nesting, now two
as aggregation is sometimes referred (Business Function) (Business Function)
levels deep.
to as ‘weak ownership’, again some-
what problematic as the aggregation In summary: Nesting makes for nice
does not ‘own’ the child at all. View 17. Assignment Nesting,Two Levels Deep views on your model, views that
are easy on the eye. But don’t think
about them too lightly, because con-
7.8 Nesting structing your model this way comes with risks. And even
There are four relation types that may be drawn by nesting bigger risks than you think, because some tools will let you
an element inside another element: Composition, Aggrega- create nestings without actually creating a relation between
tion, Assignment and Realization. These are the so-called the nested elements (which is in conflict with the ArchiMate
structural relationships. Note: tooling often allows more standard), or they may create a default relation which was
than the language does, especially if you use tooling that is not the relation you were thinking of. I’ve seen one tool that
nothing more than a good model-drawing application such was unable to produce View 16 unless the shared object was
as Visio for Windows or OmniGraffle for Mac OS. Anyway, not shared at all, but created twice in the model; because
let’s take the ‘Factory Items’ from View 13 as an example. nesting was used to show model structure.
Nested, it looks like View 15, which looks a lot cleaner and
7.9 Using a Node to encapsulate infrastruc-
Factory Items
(Business Object) ture
Now that we have seen Composition and Nesting, we can
Conveyor Belt Peanut Grinder Jar of Peanut Butter
(Business Object) (Business Object) (Business Object) look at View 11 on page 24 that introduced System Soft-
ware and Device and show in View 14 and View 22 on page
View 15. Nested Aggregation 26 how it might be modeled.
that is why many modelers like it. But we can already see a In this example, the System Software and Device elements
disadvantage: you no longer see anymore what the relation are children (Composition) of an abstract Node element (the
is between parts and whole: Composition? Aggregation? Composition relations are not explicitly shown here, but in-
stead modeled as Nesting). This is kind of a nice grouping of
It gets worse, when you want to model both Aggregations an infrastructure element as the composition’s children have
from View 13 in Nested form in one view as in View 16. no independent existence or use. We can also go further: in
View 22 on page 26, everything has been Nested.
Factory Items
(Business Object)
In this introductory section, we only look at the element
types are and how they relate to each other. Later, we will
Conveyor Belt
(Business Object)
Peanut Grinder
(Business Object)
Jar of Peanut Butter
(Business Object)
look into finding a sweet spot for using a Node for encap-
sulation of infrastructure details when we discuss patterns.
E.g. in Section 15.2 “A Basic TI Pattern: A Database” on page
Breakfast Items
(Business Object) [srv001] [srv001]
PostgreSQL RDBMS ETL NFS File Share
(Technology Service) (Technology Service)

Bread Knife Jar of Peanut Butter

(Business Object) (Business Object) (Business Object)

[srv001]
[srv001] [srv001]
PostgreSQ
View 16. Two Nested Aggregations with Shared Object L Functionality (Technology
"Linux Binary" Execution
(Technology Function)
NFS
(Technology Function)
Function)

Not only are you unable to see the actual relations, it has
now become necessary to include the ‘Jar of Peanut Butter’ [srv001] Database Server (Node)

element twice. And though the name is the same, there is [srv001] [srv001]
PostgreSQL (Sys Red Hat Linux
nothing that will tell you if behind-the-scenes it is the same tem Software) (System Software)

element. You can have two different elements with the same
name in ArchiMate, after all, the label has no meaning
inside the language (as the language’ is in fact a grammar) [srv001]
x86 server
even if it has a meaning in the world of an architect. Be- (Device)

sides, even if your modeling guidelines force different names

for different elements, think of a very large view with the View 14. Device and System Software Nested in a Node

ArchiMate Basics Page 25

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 [srv001]
Database Server One Two Three
(Node)
(Business Function) (Business Function) (Business Function)
[srv001]
x86 server
(Device)

[srv001] [srv001]
PostgreSQL (Sys Red Hat Linux
tem Software) (System Software)
Case
[srv001]
[srv001] (Business Object)
PostgreSQL Functionality (Technology [srv001]
NFS
Function) "Linux Binary" Execution
(Technology Function)
View 20. Business Functions sharing Access to a Business Object,
(Technology Function) (Technology Function)

without Flows
[srv001] [srv001]
PostgreSQL RDBMS ETL NFS File Share
(Technology Service) (Technology Service)

One Two Three

(Business Function) (Business Function) (Business Function)

View 22. A maximally Nested Node

63, we will see that it might be handy to restrict ourselves
here, to make analysis of the model easier. You have the Case
(Business Object)
choice of course if you want to model these details (and you
can go as far and deep as you like). You can Nest or not. It View 21. Business Functions sharing Access to a Business Object, with
Flows
all depends on the use you want to make of your model (in
other words: Uncle Ludwig always wins). So, how useful is the Flow relation if you can also use the
Business Objects and the Access relation? Well, it has a few
advantages:
7.10 Event, Trigger and Flow
• You can make simpler view by leaving the Business Ob-
So far, we have handled the ‘structure’ of and dependencies
jects out and for instance label the Flow relations. The
in your architecture and all relations so far were so-called
problem, though, is that such a label generally cannot
‘structural’ and ‘dependency’ relations (explained below).
be used to analyze what goes on your landscape, I’ll say
ArchiMate is not big on the dynamics of an architecture, but
it already here: watch out for relying too much on labels
it does have two ‘dynamic relations’: Trigger and Flow.
and properties of elements, they often live outside the
In View 18 we find Trigger ( ) and Flow ( ) ‘analyzable’ structure of your model.
relations in a business layer example. We see three Business
• Technically, both Access relations do not guarantee a
Functions here from the asset management world: ‘Portfolio
Flow. After all, if two functions access a warehouse, can
Management’ is taking investment decisions, which result in
you say that what one has put in the other takes out?
orders for the ‘Trading’ function. So, ‘Trading’ starts trading
when it receives an order from ‘Portfolio Management’. • But, most importantly, your dependencies can become
Triggering means there is a causal relation between the two clearer with a Flow. Take, for instance, the example
functions. The flow between ‘Portfolio Management’ and of a ‘Case’ flowing though your business from Busi-
‘Trading’ says information flows from one to the other. In this ness Function to Business Function. Having read/write
case it is the ‘Order’. relations from these Business Functions to that single
Business Object tells you nothing about how informa-
tion flows. Take the example in View 20.
Portfolio Management Trading Risk Controlling
(Business Function) (Business Function) (Business Function)
This does not tell you how the ‘Case’ Flows through
View 18. Trigger and Flow your organization. What do you think? Look at View 21
and it becomes clear what the flow of information is.
Without the Flow relations, would you have known?
But the Trading function also regularly receives a list of
Could you have drawn the wrong conclusion? Certain-
allowed counterparties, countries and currencies from the
ly. Is that a bad thing? After all they all depend on that
‘Risk Controlling’ function. This information Flows from one
Business Object. Well, take this example: without the
to the other, but it does not Trigger a trade. A Flow relation
Flow relation, you might think that the roles behind
between two Business Functions could also be modeled as
function One, Two and Three may have to agree concur-
Business Objects written (Accessed) by one function and
rently on all the contents of the Case Business Object.
read (Accessed) by another. If we add those, it looks like
But, in reality, you might only need to set up talks
View 19.
between One and Two on the one hand and Three and
Two on the other and depending on the issues at hand,
that might be simpler.
Portfolio Management Trading Risk Controlling
(Business Function) (Business Function) (Business Function)
The above discussion of Flow is valid for ArchiMate 2 and
earlier (I have left this in to make the book not entirely use-
less for those still using ArchiMate 2 as well as for didactic
Order Rules for Transactions
(Business Object) (Business Object) reasons). ArchiMate 3 has bridged the gap between Flow
and Access, however, by allowing relations to relations,
View 19. Trigger, Flow and Access to Objects
which is specifically useful for Flow.
Page 26 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Portfolio Management Trading Risk Controlling
(evil cyborgs from the Dr. Who TV series) based on the
(Business Function) (Business Function) (Business Function)
pre-assembled parts body and brain. Several new element
types are introduced here.
Order Rules for Transactions This is a Facility. It is meant to model
(Business Object) (Business Object) Factory
(Facility) places where you can deploy technology.
Mostly, they will be used for physical
View 24. Flow with Payload
production facilities, e.g. a factory. But if, for instance,
This is shown in View 24. ArchiMate allows us to draw rela- your process is growing a specific fungus that can be
tions to relations. A main reason for this is this construction. added to raw sheep milk cheese and you need a specific
Here we have used an Association relation (simple line) be- kind of cave for that, such a cave would also be a facility.
tween a Business Object and a Flow relation, thus signifying A facility is something that in the end houses a physical
that the Business Object is the payload of the Flow. process of sorts.
Trigger and Flow relations may generally be drawn between This is Equipment. Equipment is meant as
Assembly Line
behavioral elements within a layer; e.g., from Application (Equipment) an active element that can perform a
Function to Application Function or from Business Process physical process. In this case, we have an
to Business Process. assembly line, that is housed in the facility which, we
assume, provides power, security, etc., etc..
ArchiMate also has a special element in each layer that
depicts an event, ‘something that happens’ or a ‘state’. Busi- As you can see, the behavior of the Equipment is modeled
ness Events can trigger business behavior and they can be as a (generic) Technology Process, which is an element
‘raised’ by business behavior, which is also depicted with a we already encountered before. This means that there is in
Trigger relation. An example can be seen in View 23. Appli- ArchiMate a separation between physical and computational
cation Event and Technology Event are likewise available in structural elements (subjects and objects in our ‘sentences’)
the other core layers. in the Technology layer, but the behavior (the verbs in
Market Volatility Initiate Crisis Mode our sentences) is not so separated. This and the way
ArchiMate does not fully High (Business Event) (Business Process)
these active structural elements are positioned in the
support detailed process
View 23. Business Event Triggers Business language have some interesting effects on modeling,
modeling, it only has a Process which we will see later. Note: much can be said
limited support for the
about the choices that the ArchiMate designers have
dynamics of behavior. In
made. At the end of the book I will discuss these and I will
section 30 “A Possible Linking of BPMN and ArchiMate” on
concentrate my criticism there. In this chapter I will — apart
page 164 I will present a method to use ArchiMate for EA
from a remark here and there — just report how the lan-
while using BPMN for process modeling.
guage is set up.
This is Material. Material is the physical
7.11 Modeling the Physical Computer Module
(Material)
sibling of the computational passive
As of version 3, ArchiMate has special elements to model element Artifact. It is meant to model
physical aspects of the enterprise. This is a major improve- any physical material. But other than with Artifact, which
ment as it was until this version an enterprise architecture can realize active software elements (the Artifact foo.exe
language that was rather narrowly information/IT-focused. realizes the ‘foo’ System Software for instance), it cannot
But enterprises are not just about information, even if en- Realize an physical active element, e.g. it cannot Realize
terprise architecture as a discipline was invented (and still Equipment or Facility (which I think is an oversight, but I
mostly needed) because of the complexity of the overall will keep my discussion of and critique on the language
landscape of information systems. largely to chapter “Discussing ArchiMate” on page
207)
In View 25 a small example of the use of ArchiMate’s ele-
ments for modeling the physical is shown. What we see here The Access relations from Technology Process to the Materi-
is a Factory that contains an assembly line that builds Daleks al elements show that the process takes the parts and creates
the whole. To model the fact that the assembly process ‘de-
Factory
stroys’ the parts, I’ve chosen to model those Access relations
(Facility)
as read/write. Here we encounter a bit of pure-IT-origin of
ArchiMate, because in IT of course, reading is not the same
as exhausting something, whereas in physical processes
Assembly Line
(Equipment) generally the input disappears when the output is created.
For those new to ArchiMate (including those that will get
Computer Module
(Material) exposed to your views without having learned the language),
Assemble Dalek
(Technology Process)
Dalek
(Material) seeing those Access relations pointing both ways might raise
Body
(Material)
questions.
The Assignment relations from Facility to Material represent
View 25. Modeling the Physical — Assembling Daleks that the Material is deployed at the Facility. We could of

ArchiMate Basics Page 27

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
course also have Assigned them to (deploy them Operator
payment process, or the
Factory
on) the Equipment. Here we encounter already an (Facility) (Business Role)
‘deny claim’ process, or
important modeling issue: is one approach better judgment is extended with
that the other? The grammar itself is neutral on a ‘visit claimant’ process.
the issue and while learning the grammar (and for Assembly Line Control Panel
(Equipment) One practical use of Junc-
(Technology Interface)
instance getting certified
tion is to model collab-
about it) is a good thing, it Computer Module orations. As we will see
doesn’t teach you how to (Material)
Assemble Dalek Dalek below, ArchiMate has spe-
model well, how to model (Technology Process) (Material)
cial elements for this, but
for the purpose you are Body
(Material) using a Junction is possible
modeling for. This, then, is
since ArchiMate 3 and this
of course the main subject
View 30. Assembly Line with Interface and Operator makes modeling collabo-
of the other chapters of this
ration a lot simpler. Have
book.
a look at View 26. Here
In View 30 I have added the operator and the interface he or we see modeled that Sales and Legal (both Business Roles)
she uses to operate the Equipment. I’ve modeled the opera- together perform the ‘make order’ Business Process which
tor as a Business Role and the control panel as a Technology
[Client]
Interface. Here too, we see that both the informational/ Sales
(Business Role)
Provide Offer
(Business Service)
Vendor Management
(Business Function)
computational and the physical infrastructure use the same
element for their interface: Technology Interface. So, here
too, the separation between physical and informational/ Make Offer
(Business Process)
Client
(Business Role)
computational does not exist. In section 8.5 on page 35
we will see how everything in the technology layer hangs
together. Legal
(Business Role)

One final remark: the Technology layer can Serve the Busi-
ness layer directly. No need for an intermediate application. View 26. Collaboration through the use of Junction.
Realizes the Provide Offer Business Service which is used
7.12 Junctions by the Client’s vendor management Business Function. Note
also: ArchiMate 3 allows that the end points of relations that
ArchiMate 3’s Junction (a ‘relationship connector’) has been
attach to a Junction do not show their arrow heads or such.
greatly improved with respect to previous versions of Ar-
chiMate. Up to and including ArchiMate 2, it was restricted
to connecting Flows and Triggers. Now, it can also be used 7.13 Grouping
to logically combine Assignment, Realization, Association,
Another element of ArchiMate that has been greatly im-
Influence (see page 45), Access, and Serving (all relation
proved in ArchiMate 3 is Grouping. For those already
types to a Junction must be the same type, though), and it
acquainted with earlier versions of ArchiMate: it was just a
comes standard in two forms: AND and OR. Note that in
graphical construct (misnamed as a relation), it now is a true
ArchiMate the OR must be understand as XOR, the exclu-
element that can Aggregate everything else. And it shows as
sive OR, meaning that only one of the possible connections
a grouping because you normally present it as a Nesting (see
is valid at the same time. An example is shown in View 28.
section 7.8 on page 25). An example is shown in View
Shown here is an asset management 27. Here we see two Business
organization’s rule that if a system failure Market Volatility High
(Business Event)
Processes that each use an Ap-
happens in times of market volatility, Initiate Crisis Mode
(Business Process)
plication service. BP1 and AS1
the combination of these events trigger Primary System Failure are regulated (e.g. by the gov-
(Business Event)
the initiation of the crisis mode process- ernment) and BP2 and AS2 are
es. An example of the (X)OR Junction not. What really is in the model
can be seen in View 29. Shown here is View 28. AND Junction
if we un-Nest is shown in View
an insurance firm’s rule that a claim is Regulated by Law Non-regulated 33 on page 29 Note specif-
judged, after which it either goes to the ically that not just the elements
are (can be) Aggregated by a
Pay Claim BP1 BP2
Accepted (Business Process) (Business Process) (Business Process) Grouping, relations can also be
Aggregated.
Judge Claim
Rejected
Deny Claim
(Business Process) AS2
Just to be precise (so you won’t
(Business Process) AS1
(Application Service)
(Application Service)
fail an exam on my account on
this subject): Grouping is not
Doubted
Visit Claimant
(Business Process) formally a part of the official
ArchiMate Core Framework,
View 29. (X)OR Junction View 27. A Grouping it is part of a separate domain

Page 28 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 ‘Composite Elements’ which was not shown in the overview This way, we can model an application that by itself per-
in View 4 “The ArchiMate Map — Complete” on page 18, forms a process that realizes a service*.

Automated Trucking Company Network

7.15 Distribution of data and matter (Path
and Network)
(Distribution Network) (Communication Network)

We have already seen that distribution of information

between behavioral elements can be modeled with
Warehouse
(Facility)
Warehouse Distribution
(Path)
Factory
(Facility)
Flow and/or with Access to passive elements. Archi-
Mate supports three concepts to model the infrastruc-
ture that is required for distribution to happen. One
Warehousing Message
of these is Path, a more abstract element type that can
Assembly Line
(Artifact) (Equipment) be used to logically model any sort of distribution. The
other two are Communication Network and Distribu-
Computer Module
(Material)
tion Network, Extending the
Assemble Dalek Dalek example from View 25 on
(Technology Process) (Material)
page 27 to View 32, we can
Body
(Material) show all three.
This is a Path. A Path is a kind of abstract
(Path)
View 32. Assembling Daleks — with Communication and Distribution element that stands for any form of
distribution, physical, information or
both. In the example it is used to model the distribution
or the two diagrams before it. In my defense of not showing of parts and information about the parts from the ware-
them there: neither does the standard... house to the production facility. The (logical) Path is
Realized by two networks:
7.14 Automated Processes This is a Distribution Network. A Distri-
Automated Trucking
bution Network stands for any setup to
(Distribution Network)
So far, our landscape was based on a business process handle physical transport. It could be a
performed by people (actors fulfilling a role). But what if fleet of trucks, a railway setup on the organization’s
a process is fully automated? ArchiMate has the following premises, people running around as couriers with
solution: If a process is run by people, a Business Role is packages, and so forth. In this case, the warehouse-facto-
Assigned-To the Business Process and a Business Interface is ry complex has a fleet of small autonomous trucks that
Assigned-To a Business Service. The Business Role performs automatically drive between warehouse and factory
the Business Process. If a Business Process is performed by delivering the parts from which a Dalek will be assem-
an application, ArchiMate allows us to use the Realization bled.
relation to say that the Business layer elements are abstrac-
tions of the application (or technology) layer elements. View Company Network
This is a Communication Network. A
31 shows them (in red, only application to business layer). Communication Network stands for any
(Communication Network)

setup to handle communication trans-

port. Most commonly this will be a digital data network,
According to the standard, it represents ‘the physical
(Business Service) (Business Interface)
communication
Regulated by Law
infrastructure’
(with Path being
(Business Process)
the element that
(Business Object)
represents the
‘logical’ (com- BP1
(Business Process)
AS1
(Application Service)
munication)
infrastructure.
(Application Service) (Application Interface)
There is some AS2 BP2
(Application Service) (Business Process)
vagueness here,
because what is
‘physical’? Com- Non-regulated
(Data Object) (Application Function) (Application Component)
munication
networking is in
reality a stack of
View 31. Automated Process technologies, View 33. A Grouping Expanded

* This is fundamentally different from the way it was done in previous versions of ArchiMate, which allowed direct Assignments of Appli-
cation Components to business behavior. These are not allowed anymore.
ArchiMate Basics Page 29
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Primary Database Server Fallback Database Server
‘application’ (for the business), the infrastructure people will
(Node) (Node)
rightfully disagree. The Networking element itself them be-
comes some sort of abstraction/decoupling point in a model.

Data Center 1 LAN Data Center Interconnect Data Center 2 LAN

Behind this discussion are views on the way we should prac-
(Communication Network) (Communication Network) (Communication Network)
tice enterprise architecture. Are we focused on the business
and is ‘technology/infrastructure’ an unimportant low-lev-
el aspect of it? Or does enterprise architecture
Data Center 1 Switch Interconnect Router 1 Interconnect Router 2 Data Center 2 Switch
extend all the way down into all the complexi-
(Device) (Device) (Device) (Device)
ties that make up a modern enterprise? Are we
making simple abstractions for strategic business
Internet Edge Router Teclo Switch
purposes ignoring all (possibly devastating) detail?
(Device) (Device)
Or are we using the modeling language to grapple with
all the complex dependencies in a modern enterprise? My
The Internet
personal perspective is the latter and that of course perme-
(Communication Network)
ates this book. This handling of different perspectives/uses is
something that requires attention when we model, because
View 34. Using Aggregations to Model Networking Devices modeling an enterprise from just the ‘primary business’
perspective is something that is in my view too simplistic for
with physical cabling (or the ether) as the only the goals of enterprise architecture. We will get back to this
really physical part, in network engineering terms ‘layer aspect of modeling enterprises in Section 19 “Secondary
1’. Your organization’s LAN will generally have on top of and Tertiary Architecture” on page 104.
that (switched) ethernet (layer 2), (routed) Internet I do expect, though, that — thanks to the changes in Ar-
Protocol (layer 3), and more. chiMate 3, such as the physical, the big influence of inno-
One new relation is shown, that is the Association relation, vations in IT infrastructure, and the rise of the ‘Internet of
a simple line and we will say more about it below. Here, it Things’ — the Network and Path elements might start to play
is used to associate Facilities with Paths, and Networks with a role in ArchiMate modeling, though it is a question if they
passive elements that are transported by them. Another use are actually needed to model networking at all. After all, we
(not shown) is associating Device or System Software with could model any network as a Technology Service/Interface
Communication Network. used by other elements of the physical or communications
infrastructure. This will be shown in Section 28.1 “Network-
Networking components have two types of relations with ing” on page 150.
their environment. As mentioned above, Association is used
to show which elements make use of the network. And Ag-
gregation is used to model the elements that create the net- 7.16 Who is in Charge?
work. An example is shown in View 34. Here, two database So far, ArchiMate looks like a very orthodox IT-oriented
servers in two data centers form a cluster of sorts. And only enterprise architecture modeling language. It can show how
Data Center 1 is connected to the internet. The example is the business is supported by applications which are support-
rather old-fashioned, as these days we might see multiple ed by infrastructure. Physical processes and materials have
data centers configured as one large ‘stretched fabric’ (not been added to ‘infrastructure’ which has been renamed to
routed at all, but switched). ‘technology’, but we still are in effect talking about a classic
As an aside: the example also shows something else: I’ve BAT-stack (Business–Application—Technology). From Archi-
changed the graphic shape of the ‘Internet’ Communications Mate 3 on, however, this strict layering has been loosened
Network. ArchiMate doesn’t forbid that, I can do graphically in an important way. This is an important improvement,
what I want, the visual forms are just ‘practice’ or ‘default’, it because it was always a rather difficult puzzle to model
is the model structure that counts. complex stacks, because of the strict one-way layering.
Anyway, I never saw these networking concepts used much I’ve illustrated this in View 35 on page 31. On the right
before ArchiMate 3. For the new elements, this is no sur- hand side, we see our classic BAT-stack. There is a Business
prise, obviously. A reason for the lack of use of the Path/Net- Process performed by a Business Role, the process and the
work elements that have been in ArchiMate from the start, role are supported by an Application Service and Applica-
I think, is the following: For the application people, it’s all tion Interface which are the visible parts of the application.
just ‘networking’, or ‘infrastructure’, but for the networking The application itself is supported by a Technology Service
people there are a lot of software systems involved to make and Interface (runtime environment, file shares, database,
all that transport happen. The elements are thus not very etc.). Everything as we already saw in View 5 on page 20,
usable in the reality of this part of the business. For the infra- View 9 on page 22, and View 10 on page 23. But in
structure people, the actual devices and systems that make View 35 something is added on the left hand side.
up networking (and the management of said networking) are Here, two things have been added. First, there is a Business
more useful to model. So, the language may position ‘net- Process that checks the infrastructure every day and that
working’ as ‘technology/infrastructure’ and not ‘business’ or restarts the server if certain criteria are met. The scenario

Page 30 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 here is that we do not want to restart if we can avoid it but same thing, but at different abstraction levels (which come
sometimes we have to. This is done by an infrastructure en- from data modeling).
gineer. Now, instead of modeling that the infrastructure engi-
Related to this is the abstraction that goes from Artifact to
neer also uses the infrastructure, we have modeled that the
Application Component (or System Software). The Artifact
infrastructure depends on the engineer’s process directly (to
stands for the deployment of software, the bits and bytes, the
perform well). This is shown in red. Let’s stress this: instead
Application Component (or System Software) for its role as
of a human — the infrastructure engineer — using the infra-
active element in the landscape. This was illustrated in View
structure, it has been modeled as the infrastructure using the
9 “Basic Application uses Basic Infrastructure” on page 22
engineer to remain operational. If the engineer would have
and View 10 “Write Answer Process, supported by MS Word
been some automated infrastructure (automated infrastruc-
and a Standalone PC” on page 23.
ture will return in Section 28.2 “DevOps Ready Data Center
(DRDC)” on page 151), we would have modeled the de- The third abstraction is one we encountered already in
pendency likewise. Since ArchiMate 3, we can now express section 7.14 on page 29 (View 31): modeling that our
that same sort of dependency regardless of the layers. business is (partly) automated. There might be something we
would like to call a Business Service, but in fact it is provid-
Second, I have also modeled in View 35 that the engineer
ed by automation. A good example is for instance internet
uses an application to manage the infrastructure. The engi-
banking. At the business level, the bank provides an ‘inter-
neer’s application is used by the infrastructure (in blue).
net banking’ Business Service via a ‘web’ Business Interface,
In View 36, you see the blue route from View 35, and it but in fact all this is IT: applications and infrastructure.
illustrates that the stack in ArchiMate 3 is not only BAT, but ArchiMate 3 allows us to model this by modeling both the
also TAB (it is also TBA, TA, BT, BATABAT, etc..). And it nice- application (or technology) elements (such as Application
ly shows how, via applications and technology) the primary Services or Technolo-
business process depends on the infrastructure maintenance gy Interfaces) as well (Business Service) (Business Interface)

process. While technically it all may depend in a different as the business layer
direction (the IT interface is Serving the human), logically, elements (such as Busi-
the human is Serving the IT. ArchiMate can do both, what is ness Service or Busi- (Business Process) (Business Role)

modeled is your choice depending on your needs. ness Interface) and use
Realization relations
to let the IT elements
7.17 Abstractions realize the business (Application Service) (Application Interface)

Abstraction is a favorite tool in the enterprise architect’s tool elements, thus mak-
chest. ArchiMate employs and enables abstraction in several ing the business layer
ways and for several purposes. Here we will describe some elements be abstract
(Application Function) (Application Component)
ways ArchiMate 3 supports abstraction. representations of the
IT layer elements.
The first abstraction we already encountered in the first
sections and it was shown in View 10
on page 23. It is the abstraction in the
(Business Service) (Business Interface) (Technology Service) (Technology Interface)
‘passive aspect’ of ArchiMate’s Core. A
file (Artifact, e.g. ‘answer.doc’) may Real-
ize a Data Object (MS Word data) which
Realizes a Business Object (e.g. ‘Answer (Business Process) (Business Role)
(Technology Function)
Letter’). All three elements stand for the (Node)

[Maintenance App] [Maintenance App]

(Application Service) (Application Interface)
(Application Component) (Application Function)
[Maintenance App] [Maintenance App]
(Application Service) (Application Interface)

[Maintenance App] [Maintenance App]

(Application Function) (Application Component)
(Application Interface) (Application Service)
[Maintenance App] [Maintenance App]
(Application Function) (Application Component)

Check Server Status,

Infra Engineer
maybe reset (Technology Service) (Technology Interface) Server Integrity Eyes and Fingers
(Business Role)
(Business Process) (Business Service) (Business Interface)

Check Server Status,

Eyes and Fingers Server Integrity Infra Engineer
(Technology Function) maybe reset
(Business Interface) (Business Service) (Node) (Business Role)
(Business Process)

View 35. Technology uses Application and Business View 36. Who is in Charge?

ArchiMate Basics Page 31

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
A fourth abstraction runs from the Tech- [Abstraction]
Finance System
[Abstraction]
Ledger Maintenance
[Abstraction]
Finance System
[Abstraction]
Ledger Maintenance
nology layer to the Application layer. It is (Application Component) (Application Function) (Application Component) (Application Function)

possible to create Realization relations from

Technology Function/Process to Application
[SAP]
Function/Process, from Technology Service [SAP] Finance
Finance (Application Component)
to Application Service, and from Technolo- (System Software)

gy Interface to Application Interface. Sadly, View 39. Abstraction Generic-Specific: á la

though, the standard does not really explain View 38. Abstraction Generic-Specific: Appli- TOGAF
cation abstracted from Technology
what is meant by these abstractions.
‘physical versus logical’ applications
An abstraction that is often employed in enterprise architec- (or technology). ‘Actual’ (or ‘real’) versus ‘logical’ (or
ture modeling is that of generic versus specific IT. E.g. you ‘conceptual’) would have been better, I think. Anyway,
can have a generic application, such as “the accounting an example is shown in View 39. Note true ‘physical’
system”, but in the real world of your enterprise this is a real versus logical is in ArchiMate supported by the deploy-
application, say the “MainAccount” application from the ment scenario from Artifact above.
firm “Pro-IT”. ArchiMate 3 supports several ways you could
model this*: • Using Specialization within a layer. We will describe
this below, when describing the Specialization relation.
• Using the application layer for the ‘generic’ application
while using the technology layer for the specific applica- The first one should be avoided, I think. Though the relation
tion. An example is shown in View 38. This might be the is allowed in ArchiMate you should not use it this way, as it
intended use of the fourth abstraction; means quite something different then we have in mind now.
It is an example of an ArchiMate pitfall which we will dis-
• Using a Realization relation from respectively Applica- cuss later. The latter two have advantages and disadvantages,
tion Component to Application Component or Node to which we will see later in the book when we are discussing
Node. This is actually a hidden feature of ArchiMate. It modeling patterns.
is nowhere explained in the text, but it is shown in a fig-
ure and it is part of the formal relationship table, the ta- The standard also says that an active element (e.g. Applica-
ble that holds all the ‘allowed relations’ between types. tion Component) being assigned-to behavior (e.g. Applica-
This has been put in at the behest of the TOGAF people tion Function) might be seen as an abstraction, as — in this
(ArchiMate is after all owned by TOG), but apparently example — the Application Component is ‘implementation’
The ArchiMate people don’t like it enough to fully docu- and the Application Function is ‘implementation indepen-
ment it. In TOGAF, by the way, this is confusingly called dent’. I think (again) that this is questionable, and we’ll dis-
cuss this in chapter “Discussing ArchiMate” on page 207.

8. Other Core Elements and Relations

With the elements and relations of the previous section (21 If I was a purist, I would say this element type is a ‘kludge’.
of ArchiMate Core’s 40 element types) you can probably do Still, it can be useful. The new element types are:
much of an enterprise architect’s work, if that work is fo-
This is the Contract. It represents the formal
cused on ‘Current State’ and ‘Change/Project’ Architectures. (Contract)

or informal agreement that covers the

Here is the rest of the Core:
delivery of the service provided. This might
be a specific Service Level
8.1 Product and Contract Agreement or General Terms
& Conditions. (Business Product)
If you want to model the offerings of your organization to
the outside world (anyone who uses what you produce, be it This is the
(Contract)
clients or regulators), a handy element is Product. A Product (Business Product) Product. It is
is a simple enough concept. It is an Aggregation of one or what you
more services and (optionally) a Contract. It is Associated offer to the outside world. (Business Service)
with a Value. It looks like View 37. For a department of your
organization, the Product
As you can see, the Product element type is a bit weird: it is
may be something offered (Application Service)
part of ArchiMate’s Passive Structure (elements acted upon),
‘internally’. It can be handy
but it also Aggregates Behavioral elements (the actions
to make the link between
themselves). And it is a business-layer element, but it may (Technology Service)
your Enterprise Architecture
aggregate an application-layer or Technology-layer element.
and how management looks
at the organization. View 37. Product, Contract,
Value and a Product’s Con-
stituents

* One is reminded by Andrew Tanenbaum’s remark that “the nice thing about standards is that there are so many to chose from”.
Page 32 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 8.2 (Formal) Collaboration and Interaction concept that defines multiple roles forming a (specific)
single ‘collective’ role to do something together.
Suppose you have two Business Roles in your organization
that need to work together to get some specific work done. This is the Business Interaction. It is the
Offer Creation
(Business Interaction)
For instance, the ‘sales’ and the ‘legal’ Business Roles need behavior of that Business Collaboration,
to work together to create the offer for the prospective client. the activities they do together. Note that,
Within ArchiMate there are generally two ways of modeling while the Business Collaboration Aggregates two or more
this. Business Roles, the Business Interaction does not Aggre-
gate Business Functions or Business Processes. What is
Using the elements and relations we already described, you
not clear in ArchiMate is if we want to see a Business
can put one of them in the lead and let the second provide a
Interaction as functional or process-like. Given that it
service. In our example: ‘sales’ produces the offer, but it uses
generally produces a result, it is probably best to see this
the (internal) services realized by (the processes of) ‘legal’ in
as process-like.
its processes (see [Client]
View 40). Provide Offer
(Business Service)
Vendor Management
(Business Function)
One consequence of using a Collaboration is that it is not
clear who is in charge. This might be more acceptable to the
organization in terms of sensitivities, but sometimes it is just
Provide Legal Advise
(Business Service)
Make Offer
(Business Process)
Client
(Business Role) true: nobody is really in charge. In Section 18.2 “Business
Function or Business Process?” on page 92, I will present
a ‘modeling pattern’ of the business that uses Collaboration
Write Legal Advise
(Business Process)
Sales
(Business Role) to show the loosely coupled nature of some of the organiza-
tion’s ‘end-to-end’ processes.

Legal
Both methods (using a service and using an interaction) are
(Business Role)
correct, it is a matter of style what you want to use and both
approaches have some consequences. If you think about
View 40. Collaboration: Sales Uses Legal on Order Creation it, you could even model the sales-client interaction as a
collaboration, after all the transaction requires decisions of
In this set-up, it is clear who is in charge. ‘Sales’ decides to both sides. For this introduction, it suffices that you have
send the offer out, not legal. ‘Legal’ must provide something seen this.
(and for instance withholding approval means ‘sales’ cannot
Let’s not forget we already saw collaboration in the enter-
proceed), but the service to the client is realized by the
prise modeled in View 26 on page 28. Here we used the
process of ‘Sales’.
Junction to let two Business Roles perform some behavior
ArchiMate offers a second way to model such collaborations together. That way, we also showed that the ‘Make Offer’
and their behavior explicitly as elements. You can create a process is assigned to two roles, in fact forming a ‘de facto’
Business Collaboration element that is made up (Aggregate) collaboration.
of the Business Roles that are part of that collaboration.
There is of course a still simpler way. We could just Assign
Then, you can
[Client] two Business Roles to a single Business Process or Func-
assign a Business Provide Offer
Vendor Management
(Business Service)
(Business Function) tion. This is
Interaction to that
shown in View Sales
collaboration, the (Business Role)
42. There are Make Offer
interaction being Client
(Business Process)
(Business Role)
issues, though.
the behavior of that Legal
Why is this a (Business Role)
collaboration. It
collaboration?
looks like View 41. Offer Creation
(Business Interaction) Maybe either of View 42. Informal Collaboration
the two performs
it. The standard generally (but not everywhere) says that it
Legal Contracting Sales
(Business Role) (Business Collaboration) (Business Role) is preferred to look at parallel relations to an element as
that either one is ‘enough’. But it does not demand this. In
View 41. Collaboration: Sales and Legal Collaborate on Order Creation chapter “Style & Patterns”, when we are discussing modeling
patterns, we will discuss this more thoroughly.
The whole ‘offer creation’ ‘process’ is now modeled as not
In the application layer (and in the technology layer), some-
one of the parties ‘owning’ it, but both. There are a few new
thing likewise exists in ArchiMate, as is shown in View 43
elements:
on page 34 for the application layer.
This is the Business Collaboration. It is a
Contracting
(Business Collaboration) The Application Collaboration stands for the collaboration of
special kind of Business Role that Aggre-
two Application Components. The behavior of that collab-
gates multiple other Business Roles (or
oration is the Application Interaction and such a behavior
Business Collaborations, of course, as these are also
may realize an Application Service. Here too, it is not clear
types of roles, see Section 8.5 “The Specialization
who is in charge, though as we saw in section 7.2 on page
Relation in an Actual Model” on page 35). It is the
21, the Serving-pattern is also ambiguous. This is all a
ArchiMate Basics Page 33
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
matter of patterns and style, and we’ll get back to that later • In the meta-model Application Collaboration is a Spe-
in the book. The Technology Collaboration and Technology cialization of Application Component (and in an actual
Interaction are likewise, but in the Technology layer. model Aggregates Application Components)
Certainly in the Application and Technology layers, Archi- • In the meta-model Technology Collaboration is a Spe-
Mate’s Collaboration and Interaction elements are generally cialization of Node (an in an actual model Aggregates
abstractions of what is technical reality. See Section 16.1 Nodes)
“Application Collaboration is an Anthropomorphism” on
• In the meta-model Device, System Software, Equipment,
page 84).
and Facility are all Specializations of Node (in an actual
model, this Specialization is not modeled, often Compo-
8.3 The Association Relation sition or Aggregation are used).
The weakest relation, the ‘catch-all’ relation of ArchiMate, These Specializations in the meta-model have consequences
is the Association relation which is depicted as a simple line for what can be modeled in actual models. It means that the
( ). It has a couple of formal roles in ArchiMate, but child concept in the meta-model inherits all the relations of
it also has the role of ‘relation of last resort’. If you want to its parent in the meta-model. To illustrate this, have a look at
model the relation between two elements, if you know they View 44 where the
are related somehow but you cannot model how, you can place of Contract (Business Process)
(Business Object)
use Association. It is, therefore, often a sign of lack of knowl- in the meta-model
edge or effort, so it is a matter of style if you want to use it is illustrated. The
(we’ll talk about style later). For now, know that it exists and blue relations are
that it has a few official uses, such as we saw in the relations in the meta-model. (Contract)

between Nodes and Paths or Distribution Networks and Because an Ac-

Material or between ‘payload’ and Flow. cess relation exists
between Business View 44. Specialization of Contract in the
Process and Business Meta-model
8.4 Specialization in the Meta-model Object, and because
If have to warn you up front: this part of ArchiMate Contract is a meta-model Specialization of Business Ob-
is not only complex, it is a bit of a mess. I’m going ject, there also exists an Access relation between Business
to explain this, but you should not give up if this Process and Contract. It also means, for instance, that any
part initially gets too convoluted or complex. In the Business Collaboration in an actual model can have exactly
end, the actual use becomes not that difficult and the the same relations to other types of elements that a Business
language remains of practical use. Role can, e.g. being Assigned-To a Business Process. Note
that the opposite is not true. A Contract may be Aggregated
The Specialization relation ( ) is probably the most by a Product in an actual model (as we saw above), but
complicated (some would say, ‘confused’) relation in from that we may not conclude that it is true the other way
ArchiMate, because it is used in two fundamentally different around. Actually, we may model a Business Object as part
ways that influence each other. of a Contract in an actual model, but the
Before going on, let me first clearly describe the difference reason from that is different and will be (System Software)

between an ArchiMate model and ArchiMate’s meta-model. discussed later.

A model is what you create using ArchiMate, e.g. a model One important secondary effect comes
of your organization’s current landscape, or a model that from Composition and Aggregation. As any
describes the outcome of a transformation such as a project. element type can Compose or Aggregate
(Facility)

The ArchiMate meta-model is a model of how the different itself and because any child type is also a
element types and relations together form the (grammar of) View 45. Silly
parent, the parent type can Compose or Composition
the ArchiMate language itself. This book (this chap- Aggregate each child type. We
ter above all) explains the meta-model so you can already employed this earlier when, since Device is
(Business Process)
use it to make actual models. a subtype of Node, we modeled a Device as Com-
Returning to Specialization, Specialization first posite part of a Node (as in Section 7.9 “Using a
plays a role inside the ArchiMate meta-model: Node to encapsulate infrastructure” on page 25.
A-B

• In the meta-model Contract is a Specialization

(Application Service)
But as any child type is also a parent type, any child
of Business Object (in an actual model, Con- type can Aggregate or Compose any member in the
tract plays an independent role); whole ‘family tree’, the parent type and all its chil-
A-B dren, grand-children and so forth. This leads to fun-
• In the meta-model Business Collaboration is (Application Interaction)
ny consequences such as that (non-physical) System
a Specialization of Business Role (and in an
Software may Compose
actual model Aggregates
(physical) Facility, as shown
Business Roles) A
A-B
B
(Application Component)
(Application
Collaboration)
(Application Component) in View 45. Grammatically,
you are allowed to do this in
View 43. Application Collaboration
Page 34 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 ArchiMate, there is no constraint. But it is probably unwise
(Technology Service) (Technology Interface)
to do it.
Another seemingly weird effect of this
also takes place in the Technology Passive Technology Element
(Technology Process)
Layer. In View 47 all the child types
of Node, both physical and compu-
tational/informational are
shown. I have outlined the Physical Computational/Informational (Technology
physical elements in red, (Material) (Artifact) Collaboration) (Node)

the informational/compu-
tational ones in orange and
the neutral ones in violet. Look at the right hand side first.
(Device) (System Software)
Here you see that performing behavior by active technol-
ogy elements has been made possible by the Assignment
between Node and Technology Process. The same is true for
the interface. Technology Interface is defined as a Composite (Facility) (Equipment)
child of Node. The result of the Assignment between Node
and Technology Process is that any child type of Node may
View 47. How the Node ties informational and physical together in
be modeled to perform any Technology Process. This in itself the meta-model
is not problematic, it is after all up to us not to model appar-
ently crazy things such as “System Software saws”. But if we factory robots to washing machines have become automated
take the left hand side into account, there is an additional and depend on software, regardless of internet connections.
effect. On that side I had to show a ‘hidden’ element, one
Summary: the Specialization relation in the meta-model is
from ArchiMate’s meta-meta-model, an abstract one (one
like a ‘class-relation’, which are well known from software
that never gets actually used in a real model).
engineering. The Specialization relation in the meta-model
In the meta-model, Material can reside on (Assignment) says that an element type is a kind of another element type
Equipment and Artifact can reside on (Assignment) System and an instantiation of it can do whatever an instantiation of
Software. But through Technology Process, System Software its parent can.
can Access Material. So, the language does not stop us to
model (informational) System Software or Device access-
ing (physical) Material while it does stop us from (physical)
8.5 The Specialization Relation in an Actual
Material being deployed on a computational/informational Model
system (below we will see it actually doesn’t, but for this When you use Specialization yourself, you will be
stage of the explanation it is true enough). This is not so using it in actual models. In an actual model,
weird as it may look. Suppose the sawing machine is not a Specialization can also be used with a sort of
simple hand saw, but an automated sawing machine. Is it ‘inheritance’ in mind. For instance, a ‘car insurance‘
that strange to say that its software is ‘performs’ the sawing, and a ‘travel insurance‘ are both a kind of ‘insurance’. Or a
together with the rest of the equipment? If not, then “soft- ‘stock‘ and a ‘bond‘ are both a kind of ‘liquid investment’.
ware saws a tree into planks” is also not that strange after An example is shown in View 46.
all, it is a modern day equivalent of “human saws a tree into
planks”, which also is rather impractical without the actual Here, we say that ‘Cash’ is a kind of ‘Liquid Investment’ (a
saw. The standard, by the way, says all of this is very useful liquid investment is an investment that you can easily trade)
for ‘the internet of things’, but we don’t need the ‘internet of and another kind is ‘Security’ which again can be special-
things’ at all for this to be useful: a lot of our ‘things’, from ized into ‘Stock’ (a deed to a partial ownership of a com-
pany) and ‘Bond’ (a loan to an organization or country). If
an element is a specialization of another element, whatever
relations are true for the ‘parent’ (the element at the arrow-
Liquid Investment
(Business Object) head) must be true for the child. If a Business Process han-
dles ‘Liquid Investment’ (e.g., a reporting process), it must
be able to handle both ‘Cash’ and ‘Security’. On the other
hand, if a business process handles ‘Security’, it must be
Cash Security able to handle both ‘Stock’ and ‘Bond’ but it does not need
(Business Object) (Business Object)
to be able to handle ‘Cash’. Importantly, this interpretation,
is not forced upon us by ArchiMate itself.
In Object-Oriented (OO) design, the specialization is
Stock
(Business Object)
Bond
(Business Object)
sometimes called the ‘Is-A’ relation. Its counterparts are the
‘Has-A’ relation, which in ArchiMate is Composition
View 46. Specialization Example: Investment Types ( ) and the ‘Refers-To’ relation, which in ArchiMate is
Aggregation ( ). Generally, what you can do with an
ArchiMate Basics Page 35
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
‘Is-A’ Sub-classing (which is what you do with the Special- Business Processes are shown. From a software engineering
ization relation in the meta-model), can have complex perspective this Specialization is problematic, for instance,
consequences. Take for instance ‘Cash’ from the current it does not adhere to the ‘Liskov substitution principle’ (the
example. Suppose our company says we may only use cash child type can always replace the parent type in a specific
as collateral for securities we lend (and thus not (other) situation where the parent type plays a role). In this case:
securities). We would have a new Business Object in our we cannot use an ‘Anonymized Contract’ as object for the
landscape called ‘Collateral’ and ‘Cash’ could be a kind of ‘Making a Sale’ process.
‘Collateral’. It looks like the example in View 48.
This way of modeling is possible because:
• Any element type can model-Specialize itself;
Collateral Liquid Investment
(Business Object) (Business Object)
• Hence: Business Object can model-Specialize Business
Object
• This model-Specialization is inherited by Contract
Cash Security through: Contract is a meta-model-Specialization of
(Business Object) (Business Object)
Business Object;
• Hence: Contract (is a Business Object and thus) can
Specialize a Business Object.
Stock Bond
(Business Object) (Business Object) The result of this is that ArchiMate allows
us to model more freely than it would A
View 48. Specialization Example: Multiple Inheritance if the model-Specialization relation was
(System Software)

more ‘software engineering’-like (or more

meta-model-Specialization-like). It allows
What we have here is called in OO-terms ‘multiple in- us to model things, like the almost cer-
heritance’: Cash is both a kind of collateral and a kind of tainly silly model-Specialization in View
My (physical)
Factory
security. Most OO languages do not support true multiple 49. This is allowed because any Node can
(Facility)

inheritance (C++ does, more modern Objective-C, Java model-Specialize itself and because System View 49. Silly
and C# do not) and for a reason: it tends to become messy Software and Facility are both meta-mod- Specialization
because the ‘parents’ may have conflicting rules of behavior el-Specializations of Node.
for the ‘child’ to inherit (a bit like parenting in real life, true,
but maybe not the best paradigm for software engineering or None of this is properly documented in the standard (e.g.
business architecture modeling). when the model-Specialization relation is defined), though it
can be implicitly concluded from the way ArchiMate omits a
But ArchiMate’s Specialization relation as used in actual role for any kind of Specialization in the model-‘derivation’
models is not like that. If we have a Business Process that of relations (derived relations will be explained in Section 9
Accesses ‘Liquid Investment’ we may formally not conclude “Derived Relations” on page 39). Truly, this is not Archi-
from the model that it Accesses ‘Cash’ or ‘Security’. That Mate’s most elegant and clear part.
relation we must explicitly model ourselves. Nobody does
this in practice, but technically we should. There is another aspect to the use of model-Specialization in
ArchiMate models. ArchiMate as a language is completely
That Specialization in actual models is different is driven agnostic with respect to ‘class versus instance’ modeling in
home by the fact that it is a relation that is allowed between actual models. You can make concrete models, where you
‘instances of the same type’. We already saw this. In View 46 model real elements, such as how the ‘Pro-Fin’ financial
on page 35 and View 48 we saw Business Objects Spe- application supports certain business processes and depends
cialized into Business Objects. This model-Specialization’ on certain infrastructure.
is inherited by child types via ‘meta-model-Specialization’.
This is best illustrat- But you can also make abstract models, where you use ele-
ed with a simple A Making a Sale
ments that represent a ‘type’ or ‘class’, e.g.:
(Contract) (Business Process)
example. Have a • A model valid for any finance application of which
look at View 50. there are supposed to be several in your landscape. Or
Here we see a mod- a model where you don’t model every single desktop
el-Specialization of a Anonymized Contract A Data Science in your organization, but just a generic ‘Desktop PC”
(Business Process)
Business Object that (Business Object)
or “Tablet” element. Or more specifically a “Windows
is a Specialization of Desktop” or “Apple iPad” end user device. You could of
a Contract, which is View 50. Model-Specialization (versus Me- course also use Aggregation here to connect the ‘class’
ta-model-Specialization)
the reverse of what to its ‘instances’).
the meta-model-Spe-
cialization is between both concepts. Modeled here is a • A model where your parent doesn’t necessarily rep-
Business Object that is an anonymized version of a Con- resents a collection, but where you are modeling ‘con-
tract so it can be used for analytics. To illustrate that, both ceptual’ versus ‘actual’ elements in your landscape, as
in section 7.17 “Abstractions” on page 31.
Page 36 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 An example of the [Abstraction]
Finance System
[Abstraction]
Ledger Maintenance
I’m concerned it is a strange leftover of days where the IT/
latter is shown in (Application Component) (Application Function) application-centric ArchiMate, designed with administrative
View 53. Here, the systems in mind needed an element to model informa-
same generic-spe- tion on paper. It has no relation to the physical domain in
[SAP] [SAP]
cific relation is Finance Legder ArchiMate 3 and its description has always overlapped with
(Application Component) (Application Function)
shown as in View Artifact (PDF ’file’ after all).
38 and View 39 View 53. Abstraction Generic-Specific via
on page 32. I’ve the Specialization relation
added something
8.7 Location
extra: the element The final Core ArchiMate element to explain is Location.
and relations (outlined) in red. Here is a question for you: This is new in ArchiMate 2.0 and an example is given in
would you add them or not? Some say you shouldn’t, as the View 52 (note the informal ‘collaboration’).
function itself is an abstraction of the implementation (in
This is the Location element. This element
this case the Application Component). In fact, the ArchiMate Amsterdam
stands for a geographical location where
standard’s text suggests as much. Others would argue that
something resides. You can use the Assign-
the real behavior of the real system is not an abstraction at
ment relation to link it to several other element types to
all, but more an aspect of the system. There are, after all,
model where they are located.
no two systems in the world that behave exactly the same,
and ignoring that can be perilous. We’re back in ‘modeling Again, for reasons of correctness: Location is not part of the
pattern’ territory here, and such discussions are for the rest ArchiMate Core Framework, but — together with Grouping
of the book. — part of the Composite Elements meta-meta model do-
main, the domain of elements that can Aggregate (Grouping)
any element or relation, or be Assigned to (Location) struc-
8.6 Representation ture or behavior elements.
Earlier we encountered the Business Object, the work horse
of passive structure in your business layer architecture. And
we saw how this business-level element could be Realized
8.8 The Complete Core
by an application layer Data Object. Take for instance the Without taking the rest into account, ArchiMate’s Core is
‘Answer’ Business Object that was Realized by the ‘Word already rich. There are 42 element types (including the Com-
Document’ Data Object in View 10 on page 23. Archi- posite Elements) and 10 relation types in Version 3.0.1.
Mate also has another way to Realize a Business Object, it
In View 54 on page 38 you’ll find an overall picture of a
can be realized by
selection of ArchiMate’s Core element types and their rela-
a Representation.
(Business Object) (Representation) tions. This is often referred to as the ArchiMate meta-model.
A good example
Note:
would be a print of
the answer letter you • Business Process, Business Function and Business Inter-
are sending to your (Data Object)
action take the same place and are represented by the
customer. The relation Business Process icon in this view of the meta-model;
between a Business View 51. Representation and Data Object • The red relations are those that are used to model auto-
Object and its direct Realizing a Business Object mated business layer elements. E.g. the Business Service
surroundings looks ‘web site’ that is technically in reality an Application
like View 51. Service provided by IT. See section 7.14 “Automated
The new element types are: Processes” on page 29.
This is the Representation. While the Data • The orange relations are those that are used to model
(Representation)
Object is the element in our application generic/specific abstractions, such as the generic ‘fi-
layer that represents the nance application’ versus an actually used
Business Object, the Representation is Help Desk specific system. See section 7.17 “Abstrac-
(Business Function)
another way of representing the Busi- tions” on page 31. For a third way, see
ness Object and it stands for a represen- section 8.5 “The Specialization Relation in
tation that can be shared with others, Customer Supporter an Actual Model” on page 35.
(Business Role)
e.g. a print, a PDF file you send as • The green Specializations are
attachment in a mail message, or a Help Desk Department meta-model relations. They show that the
Help Desk Department Asia
web-page. (Business Actor)
Europe
(Business Actor)
children are also parents (a Device is also
Representation was sometimes a useful a Node, just like a ball is also a toy). These
link to the physical world in pre-version-3 Hong Kong Amsterdam
are not modeled in actual enterprise archi-
ArchiMate (e.g. for the actual real Steel tecture models, they are shown because
Beam we mentioned in 7.1 “Application you need them to interpret the meta-model
View 52. Example use of Location
and Business” on page 18 ), but as far as object

ArchiMate Basics Page 37

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 correctly. See section 8.4 “Specialization in the Me- back at the meta-model to check for things. If you keep
ta-model” on page 34. your finger between that page and the one before it,the
core of the meta-model is always readily available (no
• View 54 is repeated (somewhat larger) on page 239.
such ease for the PDF users, I’m afraid).
During the rest of the book, you might want to look

(Business Interface) (Business Service) (Business Product)

(Contract)

(Business Event)
metamodel
(class)
relation
Modeling Automated BL

(Business Process /
(Business Role) (Business Object)
Business Function)

Relations:

All types can Aggregate and

Compose themselves, these

Modeling Automatied BL
relations are not shown. Note:
(Business Actor) all internal behaviours in the
same layer can do the same
(e.g. Businee Function can
Compose Business Process).

Association is always allowed

between all element types.
Only the ones explicitly
mentioned in the text (that
have a rol ein the meta-model)
(Application Interface) (Application Service) are shown.

Only direct relations, not

derived relations) are shown.

Collaborations and Interactions

Modeling Automated BL

have been excluded. They

behave like their internal active
structure and internal behavior
counterparts (e.g. Application
Component & Application
Function; Business Role &
(Application Event) Business Function, Node (and
children) & Technology
Process).

(Application Function
(Application Component) (Data Object)
/ Application Process)

E.g. TOGAF
Log./Phys.

Color codes:

- Red and violet stand for a

'higher' layer element used as
an abstract representation of a
lower layer element. When the
target is the Business Layer, it
implies automated business
behaviour (marked violet).

- Orange and Blue are used to

model 'downward' serving, e.g.
Business Layer serving the
Technology Layer.

- Green stands for class

(Technology Interface) (Technology Service) relations inside the metamodel.
Important conseqence:
relations of a parent (in the
meta-model) Specisalization
are valid for all children (in the
meta-model). This does not
happen when Specialization is
used in an actual model. There
are in fact two fully different
specializations in ArchiMate.

(Technology Event)

(Technology Function /
(Path) (Node) (Artifact)
Technology Process)

E.g. TOGAF
Log./Phys.

metamodel (class) relations

(Communication
(Device) (System Software) (Material)
Network)

Copyright (c) of this diagram 2017 Gerben Wierda. It can be

freely used, copied, printed, etc.
ArchiMate(R) is a registered trademark of The Open Group.
The ArchiMate 3.0.1 standard is (c) The Open Group

(Distribution Network) (Facility) (Equipment)

View 54. Selection of ArchiMate 3.0 Core meta-model in 9 colors, direct relations only
Page 38 Mastering ArchiMate Edition III.TC1
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 9. Derived Relations
9.1 Derived Structural and Dependency Rela- tween two elements in a model. All tools have to allow you
to model such a ‘summary’ without modeling the underlying
tions* ‘true’ route of elements and relations, but in the end each
So far we have included every concept, every element type summary relation implicitly assumes that such a route with
and all connecting relations of the Core. ArchiMate, howev- real elements and relations is there, even if you have not (or
er, offers a mechanism to create ‘shortcuts’. The researchers, need not have) created them in your model.
business users and students that created ArchiMate even of- As of ArchiMate 3, the relations are divided in the following
fered a mathematical proof that their definition of the short- categories:
cuts are ‘correct’, in the sense that there is not a runaway
one which in the end create the situation that everything can • Structural Relations (Composition, Aggregation, Assign-
be related to everything else using every kind of relation.. ment, Realization)
Adding these shortcuts to the model was originally seen as • Dependency Relations (Serving, Access, Influence —
extending ‘ArchiMate proper’ to a sort of ‘ArchiMate+’, but which we haven’t seen yet, but we will below)
these shortcuts are so handy and useful that most practi-
tioners (or teachers) do not really distinguish between the • Dynamic Relations (Trigger, Flow)
direct and shortcut relations anymore (which is a bad thing, • Other Relations (Specialization, Association).
as we will see). Add to that, tools generally do not support
• A Junction is not a relation but a relationship connector.
the actual difference (well) and it is easy to understand that
the shortcuts are probably one of the most (implicitly) used The best way to illustrate the derivation rules is by using an
but least (explicitly) understood aspects of ArchiMate. It did already familiar example, the earlier used ‘write answer’
not help that for a long time (and because the text was full example, It is shown again in View 55 for easy reference
of white spots and ambiguities), the ArchiMate people stated (ignore the redness of one relation this time).
that the real definition of the language was in the appendix
Given this example, the questions we may want to ask are:
of the standard where all possible relations are given and
that ‘all relations mentioned there were equal’. ArchiMate a. What is the relation between the ‘Desktop or Laptop PC’
3.0.1 has gone a long way in strengthening the standard Node and the ‘Write Answer’ Business Process?
on this point and is the first version to be adequate on this
b. What is the relation between the ‘word.exe’ Artifact and
point.
the ‘Document Creation’ Application Service?
Officially, ArchiMate calls these ‘shortcuts’ derived relations
c. What is the relation between the ‘Desktop or Laptop PC’
and I generally explain them by saying that the derived
Node and the ‘Answer’ Business Object?
relations are a summary of a ‘dependency route’ that lies be-
For this, ArchiMate comes with the following procedure for
Answer Write Answer Customer Support
routes that are made up from structural and dependency
(Business Object) (Business Process) (Business Role)
relations:
• Find a route from one element in the model to another
following the structural and dependency relations be-
[MS Word] [MS Word]
Document Creation
(Application Service)
GUI
(Application Interface)
tween them. There is a additional requirement: a route
is only valid if all relations followed are followed in the
[MS Word] [MS Word]
same direction. All structural and dependency relations
Word Document
(Data Object)
Editing
(Application Function)
Word Processing
(Application Component)
have a direction.
• Every structural and dependency relation has a strength.
If you have a valid route, the derived relation between
both ends of the route is the weakest relation found on
Windows Application
Windows File Storage
(Technology Service)
Execution
(Technology Service)
Windows APIs
(Technology Interface)
the route, much like the weakest link in a chain. The
strengths are (from weak to strong):
1. Influence)
File System Windows Binary Execution Desktop or Laptop PC
(Technology Function) (Technology Function) (Node) 2. Access (direction: from behavioral element to
passive structural element, independent from arrow
which depicts read or write; note very well: that the
foo.doc
(Artifact)
word.exe
(Artifact) direction may be opposite to the arrow is a pitfall
when starting with ArchiMate.)
View 55. Write Answer Process, supported by MS Word and a Stand-
alone PC 3. Serving
* Note: this section is about derivation in a model. ArchiMate sets out additional rules for the use of derivation in the meta-model. Deriva-
tion in the meta-model is used to calculate all the allowed relations from the direct relations and the rules. See appendix B of the standard
ArchiMate Basics Page 39
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 4. Realization So, all is well? It gets a little more complicated. Have a look
at the Basic Application pattern, repeated in View 56.
5. Assignment (in each layer from actor to behavior
and in the Technology layer from Node to Artifact, If you go from Application Component to Application
bidirectional in ArchiMate 1.0) Service, you can follow two routes. The first route (via the
6. Aggregation (direction: from parent to child)
(Application Service) (Application Interface)
7. Composition (direction: from parent to child)
Using this procedure, we can answer the questions above:
a. From the ‘Desktop or Laptop PC’ Node, via Assignment (Data Object) (Application Function) (Application Component)

(strength: 5) to ‘Windows Binary Execution’ Technology

Function, via Realization (strength: 4) to ‘Windows Ap-
View 56. The Basic Application Pattern
plication Execution’ Technology Service then via Serving
(strength: 3) to the ‘Editing’ Application Function then
via Realization (strength: 4) to the ‘Document Creation’ Application Interface) leads to Assigned-To as the (weakest)
Application Service then via Serving (strength: 3) to the derived ‘summary’ relation. But the one via the Applica-
‘Write Answer’ Business Process. The weakest relation tion Function leads to Realization as the (weakest) derived
encountered is Serving, which is the (derived) relation ‘summary’ relation. ArchiMate does not tell you which one
between the PC and the Business Process: the PC Serves to take if two possible routes exist. That is OK, as we saw
the Business Process, which makes good sense. in the previous example, when two routes stand for two
b. The ‘word.exe’ Artifact Realizes (4) the ‘Word Process- different aspects. But in this case, either derived relation
ing’ Application Component, which is Assigned-To (5) says something about how you view the concept of Appli-
the ‘Editing’ Application Function which Realizes (4) the cation Component. If you choose Assigned-To, you keep to
‘Document Creation’ Application Service. The weakest the separation of active component and its behavior. If you
is Realization, so the ‘word.exe’ Artifact Realizes the choose Realization, you look at the Application Component
‘Document Creation’ Application Service. Which also from a more behavioral point of view. We get back to this
makes sense. confusing issue when we discuss the language and look at
possible improvements in Chapter “Discussing ArchiMate”
c. If we take the route from (a) we need just one extra step: on page 207.
from the ‘Write Answer’ via Access (strength: 2) to the
‘Answer’ Business Object. The weakest of that route is What all of this so far implies is that derived relations are
now Access, so the PC Accesses the ‘Answer’ Business useful to make summary views or abstract representations of
Object. a complex landscape, but there are risks involved in using
them without (or mixed with) the underlying reality. The
The Open Group’s ArchiMate Forum’s decision to make risks we have seen so far are still benign. But there are some
Assignment unidirectional in ArchiMate 2.0 solved the prob- pitfalls we will see later.
lem that quite a few nonsense derivations were possible. In
ArchiMate 1.0 it would for instance enable the route from Finally, returning to View 11 on page 24 in System
the ‘foo.doc’ Artifact via the PC Node to the ‘Windows File Software and Devices, if we add a couple of Technology
Storage’ Technology Service with Realization as the resulting Interfaces to that view we get View 57.
relation, or in other words: ‘foo.doc’ Realizes Windows File
Storage. Hmm, I think not.
[srv001]
But still, sometimes, multiple shortcuts do exist. For [srv001]
PostgreSQL RDBMS
Linux Application
[srv001]
ETL NFS File Share
Execution
instance, there is an alternative answer to question (Technology Service)
(Technology Service)
(Technology Service)

(c): From the PC Node via Assignment (strength:

5) to the ‘foo.doc’ Artifact, then via Realization [srv001]
[NodeName]
[srv001]
Linux Interfaces (e.g.
(strength: 4) to the ‘Word Document’ Data Object PostgreSQL Protocol
(Technology Interface)
API, CLI)
NFS Protocol
(Technology Interface)
(Technology Interface)
and via another Realization to the ‘Answer’ Business
Object. The result is: the PC Realizes the ‘Answer’
[srv001] [srv001] [srv001]
Business Object. PostgreSQL Functionality "Linux Binary" Execution NFS
(Technology Function) (Technology Function) (Technology Function)

In other words: the PC Accesses the ‘Answer’ Busi-

ness Object and it also Realizes that same ‘Answer’ [srv001] [srv001]
Business Object. Here it is clear that we are look- PostgreSQL
(System Software)
Red Hat Linux
(System Software)
ing at two aspects of this PC, it both executes the
application and it stores the data. If the data were to
reside on another server, we would not have both [srv001]
x86 server
routes. So, the two routes are in fact a true aspect of (Device)

the situation: the PC does both and so both relations

dutifully appear. No problem. View 57. System Software and Device with Interfaces

Page 40 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 You might understand why I did not show this in View 11: 9.3 Are derived relations real relations?
very complicated for something as simple as a server that
The ArchiMate 3.0.1 standard contains a table (appendix B)
provides a file share and a database. But using derived rela-
with all allowed relations between element types. This table
tions, you can con-
is calculated from the direct relations in the meta-model and
[srv001] [srv001] clude that View 59 is
PostgreSQL RDBMS ETL NFS File Share meta-meta-model and the derivation rules. It contains all the
(Technology Service) (Technology Service) a correct representa-
possible direct and derived relations in ArchiMate and tools
tion of the same. So,
must support these to be ArchiMate compliant. All of these
if you want to keep
[srv001] are, according to ArchiMate, to be seen as valid relations.
x86 server it simple: you can
(Device) Note that the table* in version 3.0 of the standard was horri-
just model these.
bly broken and this was fixed 1,5 year later in 3.0.1.
View 59. Simplified/derived version of View Keeping it simple
57 and using abstrac- Most practitioners will use the relations in the table as if they
tions make your are all ‘independently real’ in a way, that is, not bothering
models and views easier for the reader, but there are some about a relation being indirect and what that means.
caveats. We’ll encounter several of those later in the book.
Derived relations have subtly changed over the years. The
original (seductive, but naive) idea seems to have been that
9.2 Derived Dynamic Relations it should be possible to ‘calculate’ valid summary views
from complicated models, thus providing both the designers
Since ArchiMate 2 there is also the possibility to create and the business a preferred way of looking at the landscape
derived relations from dynamic relations. The procedure has automatically, while being sure that both were just different
changed in ArchiMate 3 and now is: you may move the start views of the same model and thus coherent†. Of course,
or endpoint of a Flow relation at an element to the start of a this changed when in reality people started to model using
structural relation (Composition, Aggregation, Assignment, derived relations without bothering about the underlying
Realization) that ends at that element.. (implicit) details. As a result, the difference between derived
Take a look at the example in View 58, that uses Flow. If we and direct has all but disappeared in ArchiMate modeling
start with Flow A (red) and we circles and the main function for derivation today is to cal-
move the endpoint of that Flow culate the relationship table from the
A
to the start of Realization relation Business Service 1 Business Service 2 meta-model and meta-meta model.
2 (purple) we get Flow B (blue). B C But some derived relations can only
We can also move the start of 1 2 have a meaning if understood through
A to the element at the start of an underlying route of direct relations.
Realization 1 (violet) and get Business Process 1 Business Process 2 For instance, many business process-
Flow C (green). We can do both D
es depend on the local network (The
in either order and get Flow D LAN); if the network goes down all
(orange). And so forth to produce hell breaks loose. But no business
all the other Flows in the dia- Business Role 1 Business Role 2 process uses the network directly, they
gram. use applications and these applica-
tions use infrastructure. If you draw
For Trigger the procedure is View 58. Derived Dynamic Relations
a Serving relation from a Router to a
almost the same. There is a con-
Business Process (an approach that
straint: Instead of all ‘moving an endpoint up’ the depen-
neglects ArchiMate’s official but rather limited Networking
dency of all structural relations you may only move it up for
elements to model networking, see 28.1 “Networking” on
Assignment.
page 150), it is certainly true, but in reality it implies that
The Trigger relation is also transitive: if a Triggers b and b the intermediary elements are there, even if they have not
Triggers c, then a Triggers c. This is a conclusion that is not been modeled. The situation is even more complex because
always valid of course. The fact that the Legal Business Func- even what could be a direct relation may be derived. If Ap-
tion Triggers the Sales Business Function (e.g. when there is plication Service A Serves Application Function C, it is still
an update in the service agreement text for customers), com- possible that in between sits Application B, and potentially
bined with the fact that the Sales Business Function Triggers many others as well.
the Finance Business Function (e.g. when an invoice needs
to be sent) does not mean that the Legal Business Function
Triggers the Finance Business Function. The logical nature of
a rule-based grammar is never able to cover all the possible
meanings in real world scenarios.

* There were also many problems with the text and figures in the rest of the standard. And while not everything has been fixed, I strongly
advise against relying on ArchiMate 3.0 and not updating to ArchiMate 3.0.1.
† The name ArchiMate stems from a contraction of the words ‘Architecture’ and ‘Animate’. The original research idea was that it should be
possible to animate architecture views (probably based on that idea of derived ‘shortcuts/summaries’ and other ways of providing different
users with different viewpoints automatically).
ArchiMate Basics Page 41
Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
9.4 How useful are derived relations? more than half a century ago). The derivation mechanism, in
other words, is insufficiently reliable in the real world.
As a syntactical procedure that creates useful inferences
from a detailed model, derived relations are of limited use. I tend to use them above all as a guide during the develop-
They will not allow all meaningful conclusions and allow for ment of modeling patterns. For analysis in models, I allow
many false ones, because deriving valid inferences requires more freedom than ArchiMate’s derived relations allow. Ev-
more than what a syntactical/logical procedure can deliver ery modeled relation is fair game to draw conclusions from
(we could have known given Uncle Ludwig’s analysis of (across the entire model).

10. Non-Core ArchiMate domains

10.1 Strategy or desired). Capability in ArchiMate is a ‘behavioral’
element, which means that it needs structure that can
As mentioned in section 6 “An ArchiMate Map”, ArchiMate ‘make that behavior happen’. Those are the Resources:
sees Strategy (in part) as some sort of abstraction which is
Realized by the ‘enterprise itself’ (the Core). It is easiest to This is Resource. A Resource is an asset
Finance Skills

present a small example, first. One is shown in View 60.

(Resource)
that an organization controls/owns. These
can be tangible (facilities, equipment,
cash) or intangible (rights, skills). Resources are needed
Ledger Finance Finance Skills for a Capability to exist, which is modeled by Assigning
(Resource) (Capability) (Resource)
them to the Capability.
As mentioned before (see View 3 on page 18), the Strat-
Ledger Finance Finance Responsibility egy domain doesn’t fully reproduce ArchiMate’s standard
(Business Function) (Business Role)
(Business Object)
active-behavior-passive aspect split. It is useful to quote the
standard’s exact definition here:
View 60. Capability and Resource are abstractions of the ‘enter-
prise itself ’ “A capability represents an ability that an active
structure element, such as an organization, person, or
system, possesses. “
Here we see that the enterprise’s Finance Capability is
However, as you can see in the example, Capability is not
Realized by the Finance Business Function, which, you will
positioned as ‘possessed’ by ‘actual’ active structure, only
recall, generally is the behavior performed by a Business
indirectly: It is positioned as an abstraction of the behavior
Role, in this case the Finance Responsibility Business Role.
(of active structure). Here (as in many other places), by the
At the Strategy level, this role represents a Resource, which
way, we encounter the fact that natural language and our
I have named Finance Skills. And this Resource is Assigned
human concepts are often impossible to define strictly in
to the Capability. On the left hand side, something that looks
exact terms (Uncle Ludwig again). While active structure
like it happens: We have a Ledger Business Object that Real-
‘performs’ behavior we — as humans — often say some
izes the Ledger Resource in the Strategy domain. As you will
agent ‘has’ behavior and we mean the same thing. Along
recall, the Finance Business Function is behavior, which can
the linguistic route of ‘has’ comes the term ‘possess’, while
Access Business Objects, in this case the Ledger Business
along the term ‘performs’ comes the use of the term ‘assign-
Object. Note that there is a difference between the layers:
ment’. In the Strategy domain, Assigned-To means ‘needs’
where Business Function Accesses the Business Object, the
or requires’. It is best not to dwell on such ‘imperfections’
Resource is Assigned-To the Capability.
stemming from the essential conflict of non-logical natural
According to ArchiMate, Strategy is about ‘long-term or language and logical modeling and just accept what the
generic plans’. Strategy, thus, cannot be easily made up from standard gives you as a ‘tool’.
elements of ‘the enterprise itself’ (which, I might stress here,
To illustrate that the ArchiMate layers are not really layers (in
is a term I have coined, it does not come from the standard).
terms of being stacked in a single order), a variation on View
Being a more practical-oriented architect I tend to disagree.
60 is shown in View 61. Here, the Strategy-domain elements
All this abstraction makes the things we use less easy to use
are Realized by application-layer elements.
(and thus with a less practical meaning). In other words: I
think the capability of deploying a fighting force of such and
such size with such and such equipment, and such and such Ledger Finance Finance Skills

skills is made up of real elements of ‘the enterprise itself’ (Resource) (Capability) (Resource)

(in this case: an army). However, this section of this book is

devoted to describing ArchiMate as it is, so let’s describe the
first two new element types: Ledger Data Ledger Management
(Application Function)
Finance System
(Application Component)
(Data Object)

Finance
This is Capability. This is meant to model
(Capability)
the high-level representation of the View 61. Capability and Resource can be Realized by any ‘layer’
abilities of an organization (either existing of the ArchiMate Core

Page 42 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Now, strategy is of course about defining what you are going stacked elements

Copyright (c) of this diagram 2016 Gerben Wierda. It can be freely

(Grouping)

to do. Hence, the Strategy domain of ArchiMate comes with are not perfectly Or other composite element

ArchiMate(R) is a registered trademark of The Open Group.

(Course of Action)
an element that can be used to model this (high-level, long ArchiMate) and how

The ArchiMate 3.0 standard is (c) The Open Group

term of course). it is related to the
rest of ArchiMate
This is Course of Action. It is meant to
(Course of Action) (with the exception
model what the enterprise has decided to (Resource) (Capability)

of the Motivation
do (strategically of course). Now, as

used, copied, printed, etc.

aspect, which will
almost always, an example will explain it’s use best.
follow below). In
Core Structural Element Core Behavioral Element
In View 62, a simple example is shown. We have a dinosaur section 12.11 “The (e.g. Actor, Role, Application (e.g. Process, Function, Sevice)
company that is being eaten alive by nimble small start- Use of the Non-core Component, Node, Interface,
Artifact, Material, Object)
ups using big data analytics. To survive, the company has Domains” on page
devised the strategy 54 we will shortly View 63. Strategy domain of ArchiMate
"Resistance is Futile" Strategy (Grouping)
that it will acquire discuss the use of
Acquire Big Data
Startups
these startups and this domain in enter-
(Course of Action)
merge them with its prise architecture modeling, but I can already say here that
own operations. For the rest of the book will not pay extensive attention to this
this, it has devised domain. Not that it is needed: it’s simple enough.
Merge Startup Merge Startup
Operations
(Course of Action)
Employees
(Course of Action)
the “Resistance is
futile, you will be
assimilated” strategy. 10.2 Implementation & Migration
Burying Indoctrination The Strategy has as The Implementation & Migration domain has been part of
(Capability) (Capability)
its main Course of ArchiMate since ArchiMate 2. The domain is meant to model
Action “Acquire Big everything related to change. This means it can be used to
Data Startups” which model plateaus (enterprise architecture lingo, see below),
IT
(Resource)
HR
(Resource) consists of two parts: ‘gaps’ between plateaus, and the work needed to realize en-
merging the startup’s terprise changes (go from one plateau to another) in projects
operations with its programs. It can again best been explained at the hand of an
View 62. Simple Strategy Example: “Resis- own and merging the
tance is futile, you will be assimilated” example.
startup’s employees
In View 64 we see the Program that has come out of the
with its own. Shown
strategy of the previous section. This Program consists of a
in the view is how this plays out in the company’s actual Ca-
couple of Work Packages which Realize Deliverables. These
pabilities, which consist of indoctrinating new employees so
deliverables Realize Plateaus which. There is an initial Pla-
they’ll fit the existing company culture perfectly and burying
teau that stands for the situation at the start of the Program.
IT innovation in non-productive setups. Also shown here:
the use of Grouping to aggregate a set of arbitrary concepts,
in this case the Strategy con-
cepts and their relations.
Columbus Existing systems cannot Organization cannot
Strategy is a brand new (Gap) use new IT capabilities
(Gap)
manage new IT
capabilities
Operations Department
(Business Actor)
(Gap)
domain in ArchiMate.
That means that — as I am
writing this — there is little
New Employees
experience and — just as New IT Merged
(Plateau)
Embedded
(Plateau)
with most other changes in Current State Finalized Plan
ArchiMate with respect to (Plateau) (Plateau)

the previous version(s) — Existing System

(Application Component)
some kinks will still have
to be ironed out. To give a
simple example: suppose a PSA PID Existing Systems use new Existing Operations handle new
Course of Action requires (Deliverable) (Deliverable) Capabilities
(Deliverable)
Capabilities
(Deliverable)

us to build a new Capabil-

ity? Should not a Course of
Action be able to create one
Connect old IT to new
in some way? Acquisition Approved
(Implementation Event)
X
Create PSA
(Work Package)
capabilities
(Work Package)
Acquisition Completed
(Implementation Event)

To complete this explana- Embed new employees and train

tion, View 63 contains an Create PID
(Work Package)
existing ones
(Work Package)
CEO
overview of the Strategy (Business Role)
The Project (Work Package)
domain’s meta-model and
its relation to the rest (the View 64. Example of the Implementation and Migration domain with a bit of context

ArchiMate Basics Page 43

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
A few possible relations with Core ArchiMate Location or Grouping

elements are shown. The CEO is Assigned-To the (Grouping)

approval to signify his importance for this event. (Business

Object)
composite or aggregate
(2)
Some Plateaus Aggregate the Existing System an (Location)

the Operations Department, as these are objects of

composite or aggregate
(Gap)
the changes. They are also related to some of the (Implementation Event) (Plateau)
identified Gaps. Let’s describe the various ele- X

composite or aggraget
ments.
(Deliverable)
This is the Plateau. It generally (Work Package)
(Plateau)
stands for ‘a state the enterprise
‘landscape’ can be in’, mostly Any behavioural or structural
used to describe intermediate states in a larger composite or aggregate element from the Core or Strategy
Domains

transformation of the enterprise’s landscape), Any element from the Motivation

Copyright (c) of this diagram 2017 Gerben Wierda. It can be Aspect except Stakeholder
but — as you can see in the example — it can (Business Role)
freely used, copied, printed, etc.
ArchiMate(R) is a registered trademark of The Open Group.
(Realization only, though Influence
can be used (can be derived))
also be used to model phases in a program or The ArchiMate 3.0.1 standard is (c) The Open Group

project. In the example, the startup phase of the

View 65. Implementation and Migration domain of ArchiMate — meta-model
project delivers a Project Initiation Document overview
(from the Prince2 method) and a Project Start
Architecture (from the DYA framework). In section 12.11 “The Use of the Non-core Domains” on
(Gap) This is the Gap. It stands for a difference page 54 we’ll shortly discuss the use of this domain in
between Plateaus. It will generally be the enterprise architecture modeling, but I can already say here
product of a gap-analysis, so it is an that the rest of the book will not pay extensive attention to
assessment of sorts. It can be Associated with Plateaus or this domain.
with elements from the Core (the ‘enterprise itself’). In
the example, the Columbus Gap (Columbus Manage-
ment — as I read it originally from Jan Hoogervorst — is:
“When we left, we did not know where we were going,
when we arrived we did not know where we were, and
Business IT Run
everything was paid for by other people’s money”) is (Stakeholder) (Stakeholder)

Associated with the state at the start of the project and

the moment the plans are finished. We know where we Our IT Cost is 25% above
industry average
are, what we are going to do, and where we will end. Or (Assessment)

at least we have that illusion.

10% YoY Customer Churn
Growth

Create PSA
This is the Work Package. It stands for an (Assessment)
Increasing World-wide
Competition
(Work Package)
amount of work to be done in a proj- (Driver)

ect-like setting. So, actions intended to Major New Competitor

(Assessment)

achieve a well-defined result, within time and resource

constraints. 24/7 Operation Low IT Run Cost
(Goal) (Goal)
PSA This is the Deliverable. It stands for
(Deliverable)
anything well-defined that comes out of a ++ --
Work Package. In most project manage- Fully Automated Business

ment methods, these need to be signed-off on by for Process A

(Requirement)

instance a project executive, or by customers, end users,

and so forth.
And finally, this is the Implementation
Acquisition Approved
A
(Business Process)

Event. It plays the same role in the

(Implementation Event)

Implementation and Migration domain as

the other events do in the Core language: a marker to A System
(Application Component)
A Service
(Application Service)
signify the start, status or end of behavior.
In View 65, the full Implementation and Migration part of
High Available IT
the meta-model (including all the allowed direct relations, Infrastructure
(Requirement)
An Infrastructure Service
(Technology Service)
++
with the exception of the general rule that any type may --
Compose or Aggregate itself and Association is always
allowed) is shown, including how it connects to the rest of Standardized OS ++
(Requirement)
ArchiMate (the gray diamonds represent that these relations
can be either Composition or Aggregation).
View 66. ArchiMate Motivation aspect example

Page 44 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 10.3 Motivation (Goal) (Stakeholder) (Meaning)

As mentioned in section 6 “An ArchiMate

Map”, ArchiMate has a whole part intended (Driver)
+/-

to model the ‘why’. It contains several con-

cepts. It is easiest to illustrate (most of) them (Outcome) (Value)

in an example as can be seen in View 66 on (Assessment)

page 44.
Any Structural or Behaviorlal
The new elements and relations are: (Principle) (Requirement)
Element (except Stakeholder,
which technically is Structural in
+/- the meta-meta-model)
This is a Goal, which is an
24/7 Operation
(Goal) end state that a Stakeholder Any Motivation element,
except Stakeholder, may

wants to achieve, or a (Constraint)

influence any other Motivation
element (not shown here).
Stakholder may only Influence
direction a Stakeholder wants to move in. Stakeholder (shown here).

In the example above, the Business wants

View 67. Motivation domain of the meta-model — most Influence relations not shown
to achieve 24/7 operations and the IT Run
wants to lower IT cost. The full Motivation domain of ArchiMate is shown in View
This is a Requirement, which is a obligatory 67. It shows the allowed direct relations, excluding the
Standardized OS
(Requirement)aspect of what a system or process Realiz- always allowed Composition and Aggregation of an element
es. In the example, there is a Requirement type by itself. Also not shown in that diagram is that — ex-
to use standard operating systems only in your infrastruc- cept for Stakeholder — any Motivational element type may
ture, to have high-available infrastructure and to have a Influence any other Motivational element type. Stakeholder
certain business process fully automated. is the exception: the Stakeholder element type may only
Influence itself.
This is a Driver, which is something that
Increasing World-wide
Competition
(Driver) drives the organization to set goals and Which leaves us at explaining the remaining Motivational
implement changes. These may be external element types:
(e.g. market forces, regulation) but also internal (e.g. the This is a Constraint (a Specialization of
mission or vision of an organization). In the example, No Contractors Allowed
(Constraint)Requirement), represents is a forbidden
there is one driver: ‘Increased World-Wide Competition’. aspect. Examples are budgetary or time
This is an Assessment, which is the out-
Major New Competitor
constraints for a project (Work Package), technology
(Assessment)
come of an analysis of a Driver. E.g. if a constraints for a system (allowed technology), or legal
driver is “customer satisfaction”, a poll constraints for processes or services. We could say that
might result in an assessment. In the example, there are Constraint is a ‘convenience’ type, any role it performs in
two Assessments: a new competitor has arrived om the a model could have been fulfilled by a Requirement.
scene and we win/lose 10% of our customers each year This is a Principle, which is a sort-of Goal
All Business Interfaces are
(because they come to/from the competition) Multi-Lingual
that is a generalized Requirement, specifi-
(Principle)

Business
This is a Stakeholder, which is a role that is cally for the architecture of the enterprise.
interested in achieving a Goal. In our
(Stakeholder)
There is no Principle modeled in the example, but — like
example, there are two Stakeholder roles: Constraint — it behaves more like a Requirement than a
Business and IT Run (the responsibility for keeping the Goal, though, even if it is not a Specialization of a
systems operational). Note that Stakeholder is not related Requirement.
(or equivalent) to the Business Role element in the Core. This is Meaning. In earlier versions of
(Meaning)
There also is a new relation: ArchiMate, which lacked the Motivation
aspect, it used to be part of the business
++ This is the Influence relationship. It is used to
layer. It represents an interpretation of something by
model the way Driver, Assessment, Goal,
someone, hence its Association with Stakeholder. If used
Principle, Requirement and Constraint can influence
in Association with passive structure, it is generally used
each other. Normally, a label on the relationship is used
for the intention of that element.
to denote the type of influence. In the example, the
Requirement to use standardized operating systems in This is Value. In those earlier versions of
the infrastructure influences positively the ‘Low IT Cost’ (Value)
ArchiMate this also used to be part of the
Goal, but the ‘High Available IT Infrastructure’ influences business layer. It stands for the value of
that same Goal in a negative way. The ‘High Available IT either an element from the Core or from Outcome. But
Infrastructure’ Requirement positively influences the you can of course Associate it to anything, as Association
‘24/7 Operations’ Goal and the ‘Fully Automated Busi- is the catch-all. As far as I have seen modeling with the
ness Process A’ influences ‘24/7 Operations’ positively use of valuation, it is generally done differently, with
but ‘Low It Cost’ negatively. valuation as (financial) numbers in the properties of
elements. In other words: I’ve hardly ever seen this (or

ArchiMate Basics Page 45

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Meaning, which is evermore suspect from Uncle Lud- that the rest of the book will not pay extensive attention to
wig’s perspective) used in a useful (meaningful) way. this domain with respect to its original goal: modeling the
intentions of the architecture (principles and all).
The Motivation aspect of ArchiMate shows its origin: the de-
signers wanted to catch the intentions for the architecture of Nothing stops us from using this for other practical uses, that
the enterprise (which was modeled with the Core elements) is modeling intentions of the enterprise, however. As shown
in their modeling language. Hence, the use of the concept of in section 20 “Modeling Risk & Security with Motivation
Principle (which is a popular — though toxic (see my other Elements” on page 111, the Motivation domain offers
book Chess and the Art of Enterprise Architecture) — con- us a basic mechanism to model Risks, Control Objectives
cept in enterprise architecture circles), next to Requirement (including those from Security) and Control Measures and
and Goal. in that way link ArchiMate models to the world of Risk and
Security.
The concepts of the Motivation domain are clearly not
exactly, discretely separated. It is sometimes a matter of taste Closing Remarks on ArchiMate
if something is seen as a Goal or a Driver. Having a certain
strategic Goal as an organization may count as a Driver, it ArchiMate has improved and matured over the years, but
seems to me. And the divide between a requirement and a there are still remnants that will make you wonder. If you get
principle is not very clear too. It seems it is a Requirement the feeling that ArchiMate is not 100% clean, I cannot fault
that has been promoted to a Goal in a certain context. These you. But even with these issues (which we will visit later) I
overlaps and indistinctnesses are not really a problem (there must stress that in my experience, ArchiMate is extremely
are more issues like this in ArchiMate), it then comes down usable, and even more so in version 3 than in previous ver-
to creating your own good patterns to use them. Just don’t sions. Creating Project Start Architectures based on detailed
rely on the standard to be a good guide here. ArchiMate models has, in my experience, substantially
reduced delays and unforeseen issues — having a detailed
What this part of ArchiMate also shows is how different ‘Current-State’ model has seriously improved control over
the world of human intentions and motivations is from the and reporting on our landscape to regulators.
logical world of IT and how difficult it is to map one onto
the other (“I have one negative influence and one positive. When we started to use ArchiMate, we initially had many
Now what?”). doubts about how the ArchiMate designers had set up the
language. But, we did follow the rule that we would strictly
The relations between the elements are generally Influences stick to the meta-model and not change or adapt it in any
or Associations. The exceptions are that Realization is used way (even though our tool supported that). We did this for
to: two reasons:
• let a Requirement or Constraint (potentially via Princi- • Any future tool update might break our models or re-
ple) Realize a Goal, via Outcome; quire a lot of work;
• let any ArchiMate concept from other domains Realize a • Understanding something comes only after a lot of
Requirement. In the example, an Technology Service, an experience. Though we did sometimes dislike what we
Application Service and a Business Process all Realize a saw, we decided to distrust our (beginner) skills more
Requirement. An interesting question is if you have — as than the skills of the language designers. This was wise:
is the case in the example — a Requirement like ‘Fully when our experience grew, we learned to appreciate
automated Business Process’. Is it the Business Process most of the choices the designers had made.
that Realizes this Requirement (in red) or the Appli-
cation Service (in blue) or both? There is quite a bit of If you focus on finding faults (something that comes natural-
freedom in choosing your patterns. ly for architects as they are always for the lookout of some-
thing that may break) you will. But in my experience, that
In section 12.11 “The Use of the Non-core Domains” on does not affect the usability much. ArchiMate is very, very
page 54 we’ll shortly discuss the use of this domain in usable.
enterprise architecture modeling, but I can already say here

11. Some Beginner’s Pitfalls

11.1 Pitfalls of Derived Relations Having an Access relation from Application Service to
Artifact is not in the core
I once encountered the snippet in View 68. meta-model. Having an
Artifact A

The modeler intended to model a file that was accessed by Access relation from
an application. He used an Artifact for the file (which makes Application Service to
sense), but his tool did not allow him to draw an Access Artifact as a derived Application Service X

relation from Application Service X to the Artifact. relation was not possible
at the time (ArchiMate 2)
as it required traveling a View 68. Artifact ‘Used-By’ Applica-
tion Service?

Page 46 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 route with relations in opposite directions (Realization from and only use derived relations when they are part of pat-
Artifact to Data Object and Access from Application Service terns. We will discuss many patterns in the rest of the book.
to Data Object). In ArchiMate 3 it is possible, because the
layering has become less strictly bottom-up (see 7.16 “Who
is in Charge?” on page 30).
11.2 Don’t trust the language or the tool
His tool suggested, though, that the Serving relation was
blindly: know what you are doing
possible. At the time, that relation was still called Used-By, A tool sometimes offers you to draw a ‘default relation’
and from a human language point of view, it made sense: between two elements. If you draw a relation between an
“the file is ‘used by’ the application service’. If you say this Application Component and a Business Process, it may
to a fellow human being, he or she will know what you prefer the core relation Assigned-To over the derived relation
mean. So, he assumed that all was well and — driven by an ‘Serving’. I have seen quite a few beginner models in Archi-
understandable desire to be productive — carried on. Mate 1 & 2 that had Assigned-To relations between Appli-
cation Components and Business Processes while it was not
But in ArchiMate, this is not what it means because Archi-
an automated
Mate’s ‘Used-By’ (now Serving) relation is not equivalent to
business pro- Business Service
natural language’s ‘used by’. Since this Serving relation is Business Product
cess. (This was
not a core relation, it is some sort of a derived relation. So,
the way auto-
the question is, what route lies behind this derivate? What
mated business View 70. This was possible in ArchiMate 1.0
hidden assumptions are there that make this relation possi-
was modeled
ble? View 69 shows a possible expansion of what his derived
in previous versions of ArchiMate. You might still encounter
Serving relation means (his original relation in red).
diagrams that use this, so I keep this information in). They
Artifact A Application Component Y Application Function Y
meant to write that an Application Component was Serving
a Business Process (a derived relation and also what they
meant to model) but ended up drawing an Assignment and
thus effectively writing (in ArchiMate 1 & 2) that the applica-
Application Service X Application Function X Application Service Y
tion automatically performed the Business Process.
Another beginner modeled View 70 (in the ArchiMate 1.0
days).
Application Component X

For this one I could not find a derived route at all. Here, it
turned out, the ArchiMate 1.0 specification did allow it (it
View 69. Artifact ‘Used-By’ a Business Service: the hidden objects was in the table that has all the possible relations and de-
rived relations). This was a leftover of earlier versions before
As you can see, the Serving relation from Artifact A to ArchiMate became a standard of The Open Group. It was
Application Service X was possible, because an application never removed from the table and dutifully implemented by
can use another application (and not so much data), and the tool builder. Sadly, though, it was an error in ArchiMate
that other application is then Realized by our Artifact A. He 1.0. The error, by the way, has been fixed in ArchiMate 2.0,
thought he modeled the use of data but he did model the so decent tools in recent versions will not allow you to draw
use of another (hidden) application. this relation anymore. But there are always errors. Archi-
Mate 3.0 as released in June 2016 has errors where allowed
If the language allows the relation, it is not certain that the
relations are not in the table and thus often not implemented
relation actually means what you think. That shortcut leaves
by a tool. The tool may often have both relations that are not
intermediary structure out, and sometimes (as shown here)
allowed or not have relations that are.
that structure in ArchiMate must be something that is not
what you intended to show. Pitfall 2. Not checking/knowing if your relation makes
sense in the meta-model.
Pitfall 1. Derived relations may not mean what you think.
And finally, I once modeled an Interaction and a Collabora-
This is one reason why I generally say that it is best to keep
tion. To my surprise, the tool allowed an Aggregation from
as close as possible to the core relations in the meta-model,
Interaction to Function, but not the other way around as I
wanted. It can be seen in View 71. Now,
[AppNames] [AppNames] this is not exactly how ArchiMate de-
Interaction Name Collaboration Name
(Application Interaction) (Application Collaboration) fines the Interaction elements (Interaction
elements are not defined as an Aggregate
of functions/processes, they are just the
behavior of a Collaboration, which is
an Aggregation (of roles or application
[AppName] [AppName] [AppName] [AppName]
Function 1 Function 2 Component 1 Component 2 components, recall Section 8.2 “(Formal)
(Application Function) (Application Function) (Application Component) (Application Component)
Collaboration and Interaction” on page
33).
View 71. Not quite what ArchiMate intended,

ArchiMate Basics Page 47

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Whatever I did, I could not get the Aggregation relations on A common snag is the way the standard (Application Service)

the left the way they are on the right, the way they make meta-model shows the relation(s) be-
sense when you want to model this detail. It turned out, the tween a function/process and a service.
tool makers had forgotten to implement the allowed relation This looks like View 73.
(Application Function)
between Interaction and its constituent Functions and when
What the view illustrates is that ‘a’
you tried to create it, the tool found another relation that
function can realize ‘a’ service and that
was possible because of meta-model-Specialization: since
‘a’ service can be used by ‘a’ function. View 73. How
Interaction and Function were both implemented as Special-
But in real modeling, we model gen- Function and Service
izations of an underlying implicit behavioral element in the are displayed in the
erally not ‘a’ service or function. We
meta-model that was more or less a left over from pre-Archi- Meta-model
model specific (even if they are abstract)
Mate-1 (remember: this was still ArchiMate 2, ArchiMate 3
services and functions.
has a better foundation), and because any type of element
can Aggregate its own kind, it was possible to Aggregate an So, when a beginner models something like View 73 as
Interaction under a Function. the relations between a specific function and the service
that it provides, he actually says the function also uses the
Pitfall 3. Trusting your tool blindly.
service it provides: it uses itself. Now, as a way of modeling
Lastly, ArchiMate (and several tools) support ‘viewpoints’. In recursion, this could be OK, but that is probably not what
ArchiMate 3, Viewpoints have become optional, which is a is meant (we generally do not model this kind of technical
good thing in many ways (for one: if you want to certify, you details in Enterprise Architecture). In short: the meta-mod-
don’t need to be able to reproduce them all). Viewpoints are el pattern of View 73 should most likely not appear in our
in fact subsets of the ArchiMate meta-model (the subset may models.
include derived relations). A viewpoint may restrict which
What the above snippet illustrates is that an element of the
types of elements you may model and what relations are
type Application Function can Realize an element of the
allowed between them. They are a sort of patterns, but not
type Application
quite, as they do not so much prescribe how to model but A B
Service, and (Application Service) (Application Service)
only offer constraints in what you can show.
that an(other)
I use ‘view templates’ for modeling (see Section 31 “Con- element of the
struction & Use Views” on page 189). A tool will constrain type Application
A B
your use of elements and relations in an ArchiMate View- Function can use (Application Function) (Application Function)

point and not being able to create a relation may not be an element of the
because it is not allowed, but because it is not allowed in type Application
View 72. How the function/service relations in
the active Viewpoint. Service as illus- the meta-model are intended.
trated in View 72.
Pitfall 4. Using a viewpoint without knowing that you
are. The Realize and Serving relations are between the same
types of element, but not between the same elements. And
of course, the same is true at the Business and Technology
11.3 Misunderstanding the standard me- levels.
ta-model diagram Pitfall 5. Copying relations in the meta-model to your
I have seen beginners often just copy the relations they see model blindly.
between element types in the basic meta-model (View 54 on
page 38). This is generally fine, but there are some snags.

12. Some Noteworthy Aspects of ArchiMate

12.1 Licensing • ArchiMate is royalty-free for academia;

Though being the property of The Open Group, it is debat- • ArchiMate is royalty-free for internal use by organiza-
able if ArchiMate is an open standard. Most definitions of tions;
‘open standard’ require the standard to be royalty-free and • ArchiMate is royalty-free for internal use by organiza-
maintained by a not-for-profit organization. ArchiMate meets tions that use it to do consultancy for others, mainly as
neither requirement. There are definitions of ‘open standard’ long as you do not advertise that you sell ‘ArchiMate
that do not require these, such as industry standards in a consultancy’;
commercial domain, e.g. telecom standards (which are gen-
• Selling ArchiMate tools & training requires (in practice,
erally based on patents). These are licensed against FRAND
possibly not legally) a commercial license from TOG,
(Fair, Reasonable, And Non-Discriminatory) terms. Whatever
especially if you want to use the ArchiMate® Regis-
your interpretation of ‘open’, the short story is (Spring 2017):
tered Trademark in commercial traffic. Prices start at
• Writing about ArchiMate (blogs, books) is royalty-free;

Page 48 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 US$ 2500/year. Think twice before you start building a useless for anything but a general introduction. Now, also
tool with a plan to sell for $10 in the App Store. in ArchiMate, this can happen, if you just draw your visuals
in ArchiMate without the support of tooling that can keep
There is a more extensive treatment of the (rather toxic) legal
thousands of elements and relation in a single coherent
issues on the enterprisechess.com web site. The legal reality
model.
is much more complex than the bullets above, and there is
no warranty that the above stands up in court. You need to The fact that a single coherent model is useful is of course
read the actual licensing conditions of ArchiMate’s material clear to many. So, sometimes modeling is done in Enter-
and the use of the ArchiMate® Registered Trademark and prise Architecture tooling. These tools often have their own
consult a good IPR lawyer if you do not want to pay unnec- internal proprietary language or meta-model, a meta-model
essary fees when exploiting ArchiMate commercially (or pay that also comes with a certain philosophy on what Enterprise
up, which is probably cheaper). Besides, these may change Architecture is. These days, some of these tools will have
in the future while this book will not necessarily follow. I ArchiMate as an option, often (more or less successfully)
personally do not consider ArchiMate an open standard grafted on top of something like UML or their own propri-
(but a commercially exploited consortium standard), but as etary language. I’ll say a bit more about tooling in Chapter
I’m not religious about using only open standards. I do not “Tooling” on page 219.
mind.
Modeling in ArchiMate brings the advantage of a fixed
syntax of your models with reasonably clearly defined
12.2 ArchiMate, the modeling language element and relation types. Modeling with a tool brings you
the possibility to have those different views on what you are
ArchiMate started out as a public Dutch research institute
modeling to be actually related ‘under water’ and it brings
project, supported by a couple of large administrative or-
more possibilities to actually maintain and use your models.
ganizations, both public and private. Its initial version was
Modeling in ArchiMate also brings modeling that is inde-
finalized in 2004. In 2009 it was published as a standard by
pendent of your modeling tool: if you ever decide to move
The Open Group.
it is possible to another tool that supports ArchiMate. In the
Enterprise Architecture is not new and quite a bit of model- worst case the migration cannot be automated and migra-
ing has been done, most of it not in ArchiMate. tion is a lot of hand work, but it is possible without transla-
tion to another meta-model (which in a practical sense can
People create models for projects, often just as a set of imag-
be considered impossible, you will largely have to redo all
es in an ‘architecture’ document. Sometimes, some model-
your work).
ing for projects is done in UML, but most of the time, you
will look at some non- or semi-standardized use of boxes, In Chapter “Discussing ArchiMate” on page 207 I will
arrows, dotted lines, nesting, etc., generally some sort of discuss some of the areas where I think ArchiMate could
free-format graphical tooling will be used like Microsoft Vi- be improved. In this chapter I’ll say a few things about its
sio for Windows or OmniGraffle for Mac or worse: Microsoft strengths and some weaknesses I have no suggestions about.
PowerPoint. One of the ‘nice’ aspects of such modeling is But, though I had my criticisms in the past and still have
that it is often ambiguous enough for all stakeholders to see some, my overall conclusion remains that the language
their own preferred reality in it. A more vague and ambigu- is very practical in actual use. I would not have written a
ous approach enables this often ‘politically’ expedient mod- book about it if I were not convinced that ArchiMate can be
eling. Everybody is happy, that is, until it turns out there is a extremely useful for Enterprise Architecture work. And the
problem somewhere during a later phase of a project. In my most important argument is this: there is currently no better
experience, people do not understand detailed Visio images practical alternative.
either, but they seldom have to understand them anyway, so
In the final document of the original research project, the
everybody is happy. When ArchiMate arrives, suddenly peo-
authors write:
ple are confronted with views that they have to agree on as
a definition of sorts, and suddenly they have to understand During the initial design of the ArchiMate language
what the image says. And the result is that some of them will no explicit attention was paid to any desired formal
fight adoption of the language. They want to stick to the old properties of the metamodel itself. Emphasis was put
simpler way. Other resistance comes from people who see on the applicability of the language.
some of ArchiMate’s weaknesses (especially software archi- And this is also what resulted: a very usable language, which
tects are often in this group, as ArchiMate’s ‘looseness’ is in is not perfectly logical. As mentioned above, this sometimes
conflict with their need for solid foundations). offends architects who desire a formal, certain language
It gets even worse with the modeling of your current state. which can be used without interpretation (or so some ar-
Once every few years, the lack of insight in the existing chitects think). ArchiMate offers a ‘rational’ way of looking
landscape will cause an effort to create an overview. People at Enterprise Architecture, but it does not offer a ‘perfectly
work for months at unearthing the situation, and generally logical’ way. Later versions of ArchiMate have improved and
in the end you will have a few large posters with boxes and extended (where every aspect of the latter is not by defini-
lines (and a legend to explain what every box type, arrow tion an expression of the former) the language and some
type and color signifies. The model is never maintained and original choices leading to severe problems. The derivation
after a year, it becomes so outdated that it becomes pretty mechanism could still be improved (though, we know it

ArchiMate Basics Page 49

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
can never be perfect). But it still remains noticeable here intends the terms ‘active’ and ‘passive’. For completeness,
and there that the language never was based on a formal here quotes from ArchiMate’s official underlying core defini-
model. This remains true, even if ArchiMate 3 comes with a tions of active and passive:
meta-meta-model, giving the language (the meta-model) a
Active structure elements are the subjects that can
better foundation.
perform behavior.
A passive structure element is a structural element
12.3 Separation of ‘actor’ and ‘behavior’ that cannot perform behavior.
At the business level, separating process (behavior) from Active structure elements can perform behavior on
role (actor) is common practice in modeling. There is some passive structure elements.
confusion with respect to a business function (as will be
discussed in Section 18.2 “Business Function or Business And service and interface are defined as:
Process?” on page 92). [...] a service [...] represents an explicitly defined
Some approaches see a function as behavior embedded exposed behavior.
in some sort of actor-like element, you can recognize it in [...] an interface [..] represents a point of access where
the language used: a function is behavior (as in ArchiMate) one or more services are provided to the environ-
versus a function does something (function performs be- ment.
havior, it thus seems to be an actor of sorts). ArchiMate is a
language where the separation is more fundamental and the
separation has been replicated in all layers. This clarity in 12.4 One View Type
the meta-model really helps to make good models, but it is One of the beautiful aspects of ArchiMate is that it is a true
important to stress that at every layer, the ‘actor’ and its be- Enterprise Architecture language. ArchiMate has been de-
havior are fundamentally inseparable. You can choose not to signed to model the interrelations and dependencies across
model one (and use derived relations to pass them by), but all ‘layers’ in your Enterprise Architecture: from Business via
they are implied to exist even if they are not modeled. Applications down to Infrastructure/Technology and vice
The split often is confusing for those coming from ways of versa. Though tooling often offers you all kinds of different
thinking that do not have that split, e.g. Process Modelers view types (many of which are suggested optionally in the
who do often not use the function concept at all (for more standard), ArchiMate in effect has only one single view type:
depth, see: 18.4 “The ‘End-to-end’ Business Process” on the entire Enterprise Architecture. Those optional ArchiMate
page 95) or Software Architects where (like in mathemat- Viewpoints (which I do not use) only restrict what is in an
ics) a function is both structure and behavior in one. ArchiMate view, but it is not a fundamentally different view.
There is another misinterpretation I’ve come across. If you At the software level, UML with all its different kind of views
say ‘passive element’ to people, they sometimes interpret on the same objects and classes might be more precise. But
that as ‘not taking initiative’, as ‘reacting only’. This I en- to model the whole shebang, ArchiMate does a very good
countered for instance when a colleague first was told about job.
the interface concepts in ArchiMate. He found it illogical to
say that an interface is an active element. Because an inter-
face does nothing by itself, it needs to be used before it does
something. In his use of the words active and passive, that
[BP1] [BP2]
meant an interface is passive. But ArchiMate does not mean (Business Process) (Business Process)

‘reactive’ by the word ‘passive’ and it does not mean ‘taking

initiative’ by the word ‘active’. In ArchiMate terms:
[AS1] [AS2]
• Active means capable of performing behavior (either (Application Service) (Application Service)

acting or reacting);
• Passive means incapable of performing behavior (or
sometimes just the aspect of being incapable, e.g. an [AF1]
(Application Function)
[AF2]
(Application Function)

executable file of a program (“foo.exe”) is passive, it’s

just a file; but it can Realize an Application Compo-
nent, an abstraction that stands for the executable file
[AC1] [AC2]
being executed and becoming an active element in your (Application Component) (Application Component)

landscape).
Behavior is what links active to passive elements: Active
elements are Assigned-To behavior and behavioral elements [AC]
(Application Component)
Access passive elements. The passive ArchiMate elements
are philosophically speaking ‘objects’ and the active Archi-
Mate objects are philosophically speaking ‘subjects’. It is not View 74. Example used for discussing ‘worst case’ versus ‘happy flow’
wrong what the colleague said, it is just not how ArchiMate assumptions about dependencies

Page 50 Mastering ArchiMate Edition III.TC1

Exclusively licensed to Pavel Goncharov, pgoncharov@outlook.com, transaction: #10625005
 Another Random Document on
Scribd Without Any Related Topics
propose some more effectual mode of applying that grant: that even
if the bounties should happen to exceed the drawbacks, by eight or
ten thousand dollars, the number of seamen to be maintained would
be well worth that sum: that whenever the two Houses of Congress
and the President of the United States are of opinion that the
general welfare will be promoted by raising any sum of money, they
have undoubted right to raise it, provided that the taxes be uniform;
that although it may not at present be an object of great
consequence to America to become a maritime power, yet it is of
some importance to have constantly at hand a nursery of seamen, to
furnish our merchants with the means of transporting their
commodities across the sea; that, whatever allowance or bounty is
granted upon any particular commodity, must ever be paid by the
whole, for the advantage of a part, whether it be upon cotton to the
Southward, upon fish to the Eastward, or upon other commodities to
the Middle States; that if the people cannot have so much
confidence in their Representatives, as to trust them with the power
of granting bounties, the Government must be a very paltry one
indeed. The object of the bill was only to allow to the fishermen, in
the manner that would be most beneficial to them, the same sum
that would otherwise be allowed. If, however, from time and
experience, it should appear that this bounty proved an imposition
on Government, he would not hesitate to revoke it.
Mr. Gerry.—The State of Massachusetts asks nothing more than
equal justice. We do not come forward to request favors from the
United States, we only wish that the same system which is applied
to other parts of the Union, may be applied to us. But, in examining
this question, we wish that gentlemen would not make distinctions
which will not admit of a difference.
The proposed allowance has been called a bounty on occupation,
and is said to be very different from that encouragement, which is
the incidental result of a general commercial system; but in reality it
is no bounty: a bounty is a grant, made without any consideration
whatever, as an equivalent; and I have no idea of a bounty, which
admits of receiving from the person, on whom it is conferred, the
amount of what is granted. We have imposed a duty on salt, and
thereby draw a certain sum of money from the fishermen; the
drawback is, in all instances, the amount of the money received; this
is all we ask; and we ask it for a set of men who are as well entitled
to the regard of Government as any other class of citizens.
It has been supposed, that the allowance made to the fishermen,
will amount to a greater sum than the drawback on the exportation
of the fish; but I think it has been clearly shown that this will not be
the case: on the contrary, it is presumable, that the drawback on the
fish would on the whole exceed the sum which is proposed to be
allowed to the fishermen; sometimes it might be more, sometimes
less. The calculation is made on general principles; and it is
impossible to calculate to a single cent: the quantity of salt to be
expended on the fish, cannot be minutely ascertained; but this was
not heretofore considered as a sufficient reason why Congress
should refuse to allow the drawback; they allowed it, though in a
different shape. It is now proposed to make a further commutation:
gentlemen call this a bounty on occupation; but is there any
proposition made for paying to the fishermen, or other persons
concerned in the fishery, any sums which we have not previously
received from them? If this were the case, it would indeed be a
bounty; but if we beforehand receive from them as much as the
allowance amounts to, there is no bounty granted at all.
If, however, it really was a bounty on occupation, it would after all
be only an indulgence similar to what has been granted to the
landed and agricultural interest. We have laid on hemp a duty of
fifty-four cents per hundredweight; and on beer, ale, and porter, five
cents per gallon. Now, I ask gentlemen, whether the professed
design of those duties was to raise a revenue, or to prevent the
importation of those articles? They were laid for no other purpose,
than to prevent foreigners from importing them, and thereby to
encourage our own manufactures; and was not that encouragement
a bounty to the persons concerned in producing such articles in this
country? If the duties had not been laid, the importer could sell
much cheaper than he now can; and the landed interest would be
under a necessity of selling cheaper in proportion. If those
prohibitory duties operate as a bounty in favor of raising hemp, and
of brewing beer, ale, and porter, I ask, whether, if a bounty were
proposed on every quintal of fish, it might not, with the same
propriety, be granted? If we have not a right to grant a bounty in the
one case, we have as little right to grant it in the other.
A calculation has been offered to show that the proposed allowance
will exceed the amount of the present drawbacks, by ten thousand
dollars a year; but that calculation has been proved to be erroneous.
Suppose, however, that this was the fact, what comparison is there
between such a tax on the citizens of the United States, and the tax
borne by the citizens of Massachusetts, for the defence of the
Western frontier? A commercial war is waged against the American
fisheries, by foreign nations, who lay heavy duties on the American
fish, and apply the produce of those duties in bounties to their own
fishermen; and their fisheries being less extensive than ours, the
duty thus imposed on our fish, and bestowed in bounties to their
vessels, operate in a twofold proportion to the discouragement of
our fishermen, and the encouragement of theirs.
I wish to know on what principle gentlemen can expect, that the
citizens of Massachusetts should contribute two hundred thousand
dollars, or perhaps a greater sum, for the protection of the Western
frontier against the Indians, when no contribution is made to
support the commerce of Massachusetts, which, without this
support, will be as effectually ruined, as if their vessels were
captured by an enemy. The principle is carried farther with respect
to the protection of the frontier: we have voted large sums as
presents to the savages, to keep them friends to the frontier
settlers; there is, however, no clause in the constitution that will
authorize a measure of this kind: it is true, indeed, we have a power
to regulate trade and commerce with the Indian tribes; but does that
give us a power to render the United States tributary to the
savages? and if we make them such grants every year, do we not in
fact become tributary to them?
The gentleman from Virginia (Mr. Giles) says that although this plan
of encouraging the fisheries may be wise policy in Britain, as being
on all sides surrounded by the sea, yet the United States will not
equally find their account in pursuing the same plan. The State of
Virginia is, in point of exposure from the sea, very differently
circumstanced from the State of Massachusetts: we have a vast
extent of country four hundred and fifty miles of sea-coast, exposed;
the citizens of all the towns along the coast are obliged to pursue
marine occupations and I hope the gentleman does not wish that
the country should be depopulated, and the inhabitants driven off to
settle the Western territory.
The State of Virginia is very happily circumstanced with respect to a
marine war: should such an event take place, that State is pretty
secure from depredations; but when we consider how much the
inhabitants of Massachusetts are exposed in a case of that kind, we
ought to look forward, and make some provision for their defence:
they have as good a right to expect that Government will make
some arrangements for their protection, as that they shall be obliged
to contribute for the defence of the Western frontier.
But their commerce, it seems, must not be supported! Taxes
however must be laid; and those taxes applied to encourage the
former, and to bribe the Indians into peace! Is this fair? Is this
pursuing a liberal system of politics? Will this reconcile the minds of
our people to the General Government? If so reasonable a
proposition be neglected by the House, it will convince the citizens of
that State, that it is the object of Government to destroy their
commerce, and to make them entirely dependent on the agricultural
interest.
Here Mr. Gerry read a statement, to show the diminution of the
revenue in consequence of the failure of the fisheries; and added,
To support the fisheries, is to support the revenue: by that staple,
the citizens of Massachusetts are enabled to pay the revenue that is
expected from them; and, by an attempt to save ten thousand
dollars, Government will probably sacrifice a hundred thousand; and
besides, lose the confidence of the citizens of that State.
The only question now is, whether this be a direct bounty, or simply
a commutation of the allowance already granted by Congress? If the
latter be the case, I can see no reason why we should refuse our
assent to a proposition, which is only calculated to do justice to the
people concerned, and to give encouragement to a very important
branch in the United States; especially as the proposition will even
have a tendency to increase the revenue.
Mr. Williamson.—It has been urged with great propriety, in favor of
the bill now submitted to our consideration, that the operation of our
laws should in all cases tend to encourage useful industry; that while
we are giving back the duties on all other foreign goods which are
exported, it would be unjust and cruel to refuse a full drawback of
the duties on salt which may be exported, especially when the
circumstances of its exportation are attended with an increase of
riches and strength to the nation. Impressed as I am with the force
of these arguments, and desirous as I am to protect and encourage
the native seamen of America, by all prudent, practicable, and
constitutional means, I shall nevertheless find it my duty to vote for
striking out the first section of the bill, because it proposes to give a
bounty for the encouragement of the vessels employed in the
fisheries.
We have been told that the name is improper; that it is simply a
drawback of the duty upon salt; and gentlemen have produced a
very ingenious calculation, by which they attempt to prove, that in
some years it may happen that the whole duty on the salt will not be
repaid; but they admit that in some years the drawback or bounty
will exceed the duty. It is certainly their opinion—and in this we are
perfectly agreed—that the money to be paid will be more than that
received, else there had been no use for so large an appropriation.
We shall not trouble the committee with calculations on this subject.
It is conceded, that the encouragement to be given, probably will
exceed the full drawback of the duty on salt. In other words, a
douceur or a proper bounty is to be given: let us call it one thousand
dollars per annum. Is it within the powers of this Congress to grant
bounties? I think not; and on this single position I would rest the
argument.
In the constitution of this Government there are two or three
remarkable provisions, which seem to be in point. It is provided, that
direct taxes shall be apportioned among the several States according
to their respective numbers. It is also provided, that all duties,
imposts, and excises, shall be uniform throughout the United States;
and it is provided, that no preference shall be given, by any
regulation of commerce or revenue, to the ports of one State over
those of another. The clear and obvious intention of the articles
mentioned was, that Congress might not have the power of
imposing unequal burdens; that it might not be in their power to
gratify one part of the Union by oppressing another. It appeared
possible, and not very improbable, that the time might come, when,
by greater cohesion, by more unanimity, by more address, the
Representatives of one part of the Union might attempt to impose
unequal taxes, or to relieve their constituents at the expense of
other people. To prevent the possibility of such a combination, the
articles that I have mentioned were inserted in the constitution.
Suppose a poll-tax should be attempted; suppose it should be
enacted that every poll in the Eastern States shall pay a tax of half a
dollar, and every poll in the Southern States should pay a tax of one
dollar. Do you think we should pay the tax? No certainly. We should
plead the constitution, and tell you that the law was impotent and
void.
But we have been told, that Congress may give bounties for useful
purposes; that is to say, they may give bounties for all imaginable
purposes; because the same majority that votes the bounty will not
fail to call the purpose a good one. Establish the doctrine of
bounties, and let us see what may follow. Uniform taxes are laid to
raise money, and that money is distributed—not uniformly; the
whole of it may be given to the people in one end of the Union.
Could we say, in such a case, that the tax had been uniform? I think
not. There is certainly a majority in this House who think that the
nation would be stronger and more independent, if all our labor was
performed by free men. This object might be promoted by a bounty.
Let a poll-tax be laid, according to the constitution, of one dollar per
poll: in this case, sixty cents must be paid for each slave; and the
number of slaves being 680,186, their tax would amount to
$334,911. To encourage the labor of citizens, let Congress then give
an annual bounty of one dollar to every free man who is a mechanic,
or who labors in the field. We might be told that the bounty was
small, and the object was good; but the measure would be most
oppressive, for it would be a clear tax of rather more than three
hundred thousand dollars on the Southern States.
Perhaps the case I have put is too strong—Congress can never do a
thing that is so palpably unjust—but this, sir, is the very mark at
which the theory of bounties seems to point. The certain operation
of that measure is the oppression of the Southern States, by
superior numbers in the Northern interest. This was to be feared at
the formation of this Government, and you find many articles in the
constitution, besides those I have quoted, which were certainly
intended to guard us against the dangerous bias of interest, and the
power of numbers. Wherefore was it provided that no duty should
be laid on exports? Was it not to defend the great staples of the
Southern States—tobacco, rice, and indigo—from the operation of
unequal regulations of commerce, or unequal indirect taxes, as
another article had defended us from unequal direct taxes?
I do not hazard much in saying, that the present constitution had
never been adopted without those preliminary guards in it. Establish
the general doctrine of bounties, and all the provisions I have
mentioned become useless. They vanish into air, and like the
baseless fabric of a vision, leave not a trace behind. The common
defence and general welfare, in the hands of a good politician, may
supersede every part of our constitution, and leave us in the hands
of time and chance. Manufactures, in general, are useful to the
nation; they promote the public good and general welfare. How
many of them are springing up in the Northern States? Let them be
properly supported by bounties, and you will find no occasion for
unequal taxes. The tax may be equal in the beginning—it will be
sufficiently unequal in the end.
We are told, that a nursery of seamen may be of great use to the
nation, and the bounty proposed is a very small one. These, sir, are
the reasons why I have marked this as a dangerous bill; the most
dangerous innovations are made under these circumstances. To
begin with a great bounty would be imprudent, and to give a small
bounty for a doubtful purpose, might deserve a worse epithet. Half a
million of dollars per annum would have been too much for a
beginning, and perhaps a bounty on the use of sleighs, though they
are convenient for travelling in winter; or a bounty on stone fences,
though they are durable, would not at this time be prudent. The
object of the bounty, and the amount of it, are equally to be
disregarded in the present case; we are simply to consider whether
bounties may safely be given under the present constitution. For
myself, I would rather begin with a bounty of one million per annum
than one thousand. I wish that my constituents may know whether
they are to put any confidence in that paper called the constitution.
You will suffer me to say, that the Southern States have much to
fear from the progress of this Government, unless your strength is
governed by prudence. The operation of the funding system has
translated at least two millions of dollars from the Southern States,
that is to say, from Georgia, the Carolinas, and Virginia, to the
Northern States. The interest of that sum, when it shall be six per
cent., will be $120,000; but the quota of those States is at least one-
third of the whole; whence it follows, that they must pay forty
thousand dollars every year, in the form of interest to the Northern
States. This, it seems, is not sufficient, and other measures are to be
adopted for draining the Southern States. Bounties to promote the
general welfare are already brought forward. We shall not hear of a
bounty for raising rice, or preparing naval stores. If that was the
question, the general welfare would not have such prominent
features. Unless the Southern States are protected by the
constitution, their valuable staples, and their visionary wealth, must
occasion their destruction. Three short years has this Government
existed—it is not three years—but we have already given serious
alarms to many of our fellow-citizens. Establish the doctrine of
bounties, set aside that part of the constitution which requires equal
taxes and demands similar distributions, destroy this barrier, and it is
not a few fishermen that will enter, claiming ten or twelve thousand
dollars, but all manner of persons—people of every trade and
occupation—may enter at the breach, until they have eaten up the
bread of our children.
Perhaps I have viewed this project in too serious a light; but if I am
particularly solicitous on the subject of finance, that we do not even
seem to depart from the spirit of the constitution, it is because I
wish that the Union may be perpetual. The several States are now
pretty well relieved from their debts, and our fellow-citizens in the
Southern States have very little interest in the national funds; press
them a little with unequal taxes, and the remedy is plain.
While I would shun bounties, as leading to dangerous measures, I
am not inattentive to every argument that has been advanced by the
honorable member who first rose in defence of the bill. That
gentleman tells us, that more than a bushel of salt is used in curing
a quintal of fish. If this fact be established, the former act should be
amended, by giving a greater drawback. He says the drawback, as it
is now paid to the merchant, does not operate so as to encourage
the seamen, who have most need of such assistance. This is very
probable, and the parties may be relieved by dividing the drawback
in the very manner that is proposed by the bill. If it is true that the
proposed bounties will not exceed the average of the drawback that
should be paid on salt, why do they contend about names, unless
they are solicitous about the precedent? If our object is to
encourage industry, and to increase our commerce, by sending fish
to a foreign market, we must adhere to the drawback; for, according
to the terms of the bill, the bounty is to be paid, though every fish
that is caught should be consumed in the country; in which case we
should be paying a visionary drawback, when nothing was exported.
According to the terms of the bill, there is no proportion between the
labor and the reward, so far as the bank fishery is concerned; the
bounty in all cases being the same.
Having exercised your patience in objecting to this new system of
bounties, and having hinted on some objections to the general
operations of the bill, so far as industry and enterprise may be
desired, I shall, in a few words, submit the outline of a plan that
seems to comprehend all the useful parts of the bill, without any
speculation upon bounties.
If the drawback on dried fish exported, is not equal to the duty on
the salt used in curing such fish, let the drawback be increased to
eleven cents or twelve cents, as the case may be. Let us suppose
that the drawback for the next year will be equal to the drawback on
the last year; and let that sum of money, being the expected
drawback, be divided between the seamen and owners, according to
the terms of the bill. The accounts must be made up annually. If the
drawback exceeds the allowance that had been made, the difference
will be considered as advanced to the fishery, and the allowance for
the next year must be somewhat reduced, according to the actual
amount of the drawback. If the fishermen are more fortunate or
more active, and the exports are increased, the allowance for the
next year must be raised. The rule being fixed by law, all that
remains, being pure calculation, may be done from year to year by
the Executive. Every important object of this bill, that has been
presented to our view, may be obtained by safe and constitutional
steps. Why should a man take a dangerous and a doubtful path,
when a safe one presents itself? If nothing more is desired than to
regulate and protect the fishery, the bill may be altered and
accommodated to that purpose. If the theory of bounties is to be
established, by which the Southern States must suffer while others
gain, the bill informs us what we are to expect.
The committee now rose, without taking any question.

Monday, February 6.
A member from Maryland, to wit, John Francis Mercer, returned to
serve in the room of William Pinkney, resigned, appeared, and took
his seat in the House.
A petition of the tanners of the town of Newark, in the State of New
Jersey, was presented to the House and read, stating the
inconveniences they suffer from the erection of mills for the purpose
of grinding tanners' bark for exportation, and praying that Congress
will adopt such measures for their relief as may appear just and
right. Ordered to lie on the table.

The Cod Fisheries.

The House again resolved itself into a Committee of the whole
House on the bill sent from the Senate, entitled "An act for the
encouragement of the Bank and other Cod Fisheries, and for the
regulation and government of the fishermen employed therein."
Mr. Goodhue.—The gentleman last up (Mr. Williamson) says, that an
appropriation of money being made by the bill now before us, and
the Treasury standing pledged for the payment, therefore a direct
bounty is granted. At present, we pay in drawbacks about $45,000;
but we cannot say that this sum will be adequate to the payment of
the drawbacks next year; for, if a greater quantity of fish be taken, a
greater sum, of course, must be allowed; and, as the sum depends
entirely on the quantity of fish, it is impossible to ascertain
beforehand the precise amount. There is not, however, in the whole
bill, any thing of a bounty except the bare name. The gentleman
allows that we may commute the present drawbacks, and give them
to the fisherman instead of the merchant; but it is impossible to do
this with safety in any other mode than that pointed out in the bill.
Shall we leave it to the fisherman, to be determined by his oath?
This would not be advisable.
The plan proposed is a much less exceptionable one. It is founded
on a calculation that a certain quantity of tonnage is employed in
taking a certain quantity of fish. On this calculation the allowance is
apportioned to the tonnage. If gentlemen think the allowance too
high, let the sum be reduced; but let it not be stigmatized as a
bounty. It is no such thing. The word "bounty" is an unfortunate
expression, and I wish it were entirely out of the bill.
Mr. Livermore.—The bill now under consideration has two important
objects in view. The one is, to give encouragement to our fishermen,
and, by that encouragement, to increase their numbers; the other is
to govern those fishermen by certain laws, by which they will be
kept under due restraint. Both these objects are of great importance
to such persons as choose to employ their capitals in the fishery
business. And I believe it will not be disputed that the business itself
is of considerable importance to the United States, insomuch as it
affords a certain proportion of remittance or exportation to foreign
countries, and does not impoverish the country, but enriches it by
the addition of so much wealth drawn from the sea.
It is the object of those gentlemen who favor the bill that the
fishermen should have some encouragement, not given to them at
the expense of the United States, but directed to them out of what
was in the former law called a drawback of the duty on salt. The
calculation, as I understand it, has been made as nearly as possible
to give that drawback, not to the merchants who export the fish, but
to the fishermen who take it, in order to increase that description of
men, without whose assistance it is vain to expect any benefit from
the fisheries; for, if the merchants at present engaged in that branch
possessed the whole capital of the United States, yet, if they cannot
get fishermen, they cannot carry on the fishery. This is done by a
particular class of men, who must be not only expert seamen, but
also accustomed to taking the fish and curing it. If these men cannot
be had, the capital cannot be employed, and those who undertake
the business cannot carry it on, or reap any profit from it.
Whilst the drawback is payable only to the merchant who exports
the fish, it is impossible to convince the fishermen that they reap
from it any advantage whatever; or, if the more discerning among
them do perceive any advantage in it, the others who are not so
clear-sighted cannot discern it, and are therefore not disposed to
undertake the business. It is, however, of considerable importance to
the merchants that the fisherman should receive a proper
encouragement, even if they were obliged to allow him a bounty out
of their own pocket.
The government of the fishermen, after their engagement in this
business, is also necessary to be provided for; otherwise, frequent
instances may occur among that class of men of quitting one vessel
to embark on board another, or of shipping themselves for a foreign
voyage, before the expiration of the fishing season. In the latter
case, the vessel lies useless on the owner's hands, and he, together
with the whole expense of the outfit, loses all his prospects of future
gain.
The two objects here mentioned are fully provided for in the bill.
Still, however, it is objected to. But what is the objection? It is, that
the word "bounty" is twice used in this clause. Let us now see what
advantage will result from striking out this obnoxious "bounty." None
at all. The bill says it shall cease; and have gentlemen any objection
to the bounty's ceasing? Since the bounty is to cease by this bill,
what advantage in striking it out? The sense would still remain the
same; and I do not know why we should make a law expressly to
strike out the word "bounty," but to strike out the bounty itself.
It is strange to me that any gentleman, whether he is for giving a
great bounty or no bounty at all, should quarrel with this
unfortunate word. There is, indeed, one part of the section which I
will readily consent to strike out, and I believe every other
gentleman who is in favor of the bill will consent to it likewise; and
that is the clause which provides that the bounty to be allowed and
paid on every vessel for one season, shall not exceed one hundred
and seventy dollars. If, when the vote is taken on the section, there
does not appear a majority of the House in favor of striking out the
whole, we may then move for striking out the proviso, if it be
offensive to any gentleman. If it be not offensive, it may remain.
If gentlemen are disputing only because the word "bounty" is in the
bill, they may be perfectly relieved from their uneasiness on that
score; for the bill expressly says, "that the bounty now allowed upon
the exportation of dried fish of the fisheries of the United States
shall cease, and in lieu thereof," a different kind of encouragement is
to be given. Here is no reason to dispute about a word. If gentlemen
are disposed to consent to the principle of the bill, that the drawback
of the duties on salt shall be commuted for a certain sum, to
encourage the fishermen, they will vote in favor of the bill; if not,
they will vote against it. But it is impossible for me to conceive why
any gentleman under heaven should be against it. It is only fixing,
for the merchants engaged in this branch, a clear and equitable ratio
for distributing among the fishermen that encouragement which they
think necessary in order to attach those people to the business, and
to prevent them from going to other occupations on land. The bill is
an important one, and will increase that branch of business, which is
very useful to the community. It does not lay a farthing of bounty or
duty on any other persons than those who are immediately
concerned in it. It will serve them, and will not injure any body.
Mr. Laurance said, from examining the section, he conceived it
contemplated no more than what the merchant is entitled to by
existing laws. The merchant is now entitled to the drawback; but it is
found by experience that the effect has not been to produce that
encouragement to the fishermen which was expected; and he
presumed the way was perfectly clear to give a new direction to the
drawback, and this is all that is aimed at in the bill. He supposed
that the clause had no necessary connection with the question which
had been started respecting the right of the Government to grant
bounties; but, since the question has been brought forward, it may
be proper to consider it. In discussing the question, he inquired,
What has Congress already done? Have we not laid extra duties on
various articles, expressly for the purpose of encouraging various
branches of our own manufactures? These duties are bounties to all
intents and purposes, and are founded on the idea only of their
conducing to the general interest. Similar objections to those now
advanced were not made to these duties. They were advocated,
some of them, by gentlemen from the Southward. He traced the
effects of these duties, and showed that they operated fully as
indirect bounties.
Mr. L. then adverted particularly to the constitution, and observed
that it contains general principles and powers only. These powers
depend on particular laws for their operation; and on this idea, he
contended that the powers of the Government must, in various
circumstances, extend to the granting bounties. He instanced, in
case of a war with a foreign power, will any gentleman say that the
General Government has not a power to grant a bounty on arms,
ammunition, &c., should the general welfare require it? The general
welfare is inseparably connected with any object or pursuit which in
its effects adds to the riches of the country. He conceived that the
argument was given up by gentlemen in opposition to the bill, when
they admit of encouragement to the fishermen in any possible
modification of it. He then adverted particularly to the fisheries,
stated the number of men employed, the tons of shipping necessary
to export the fish taken, and inferred the sound policy of
encouraging so important a branch of business.
Gentlemen say that we do not want a navy. Grant it; but can they
say that we shall never have a war with any European power? May
not the time arrive when the protection to the commerce of this
country, derived from this source, may be of the utmost necessity to
its existence? Adverting to Mr. Williamson's objection from the
unequal operation of bounties, and who had referred to the article of
the constitution which says that taxes shall be equal in all the States,
Mr. L. observed, that this article in the constitution could only respect
the rates of the duties, and that the same duties should be paid in
Virginia that are paid in New York—at the Northward as at the
Southward. It surely could not mean that every individual should pay
exactly the same sum in every part of the Union. This was a
provision that no law could possible contemplate.
He concluded by a summary recapitulation of his arguments, and
saying he hoped the section would be retained.
Mr. Madison.—In the conflict I feel between my disposition on one
hand to afford every constitutional encouragement to the fisheries,
and my dislike, on the other, of the consequences apprehended from
some clauses of the bill, I should have forborne to enter into this
discussion, if I had not found, that over and above such arguments
as appear to be natural and pertinent to the subject, others have
been introduced which are, in my judgment, contrary to the true
meaning, and even strike at the characteristic principles of the
existing constitution. Let me premise, however, to the remarks which
I shall briefly offer, on the doctrine maintained by these gentlemen,
that I make a material distinction, in the present case, between an
allowance as a mere commutation and modification of a drawback,
and an allowance in the nature of a real and positive bounty. I make
a distinction also, as a subject of fair consideration at least, between
a bounty granted under the particular terms in the constitution, "a
power to regulate trade," and one granted under the indefinite terms
which have been cited as authority on this occasion. I think,
however, that the term "bounty," is in every point of view improper
as it is here applied, not only because it may be offensive to some,
and in the opinion of others carries a dangerous implication, but also
because it does not express the true intention of the bill, as avowed
and advocated by its patrons themselves. For if, in the allowance,
nothing more is proposed than a mere reimbursement of the sum
advanced, it is only paying a debt; and when we pay a debt, we
ought not to claim the merit of granting a bounty.
It is supposed by some gentlemen, that Congress have authority not
only to grant bounties in the sense here used, merely as a
commutation for drawbacks, but even to grant them under a power
by virtue of which they may do any thing which they may think
conducive to the "general welfare." This, sir, in my mind, raises the
important and fundamental question, whether the general terms
which had been cited, are to be considered as a sort of caption or
general description of the specified powers, and as having no further
meaning, and giving no further power than what is found in that
specification; or as an abstract and indefinite delegation of power
extending to all cases whatever; to all such, at least, as will admit
the application of money, which is giving as much latitude as any
government could well desire.
I, sir, have always conceived—I believe those who proposed the
constitution conceived, and it is still more fully known, and more
material to observe that those who ratified the constitution
conceived—that this is not an indefinite Government, deriving its
powers from the general terms prefixed to the specified powers, but
a limited Government, tied down to the specified powers which
explain and define the general terms. The gentlemen who contend
for a contrary doctrine are surely not aware of the consequences
which flow from it, and which they must either admit or give up their
doctrine.
It will follow, in the first place, that if the terms be taken in the
broad sense they maintain, the particular powers afterwards so
carefully and distinctly enumerated would be without any meaning,
and must go for nothing. It would be absurd to say, first, that
Congress may do what they please, and then that they may do this
or that particular thing; after giving Congress power to raise money,
and apply it to all purposes which they may pronounce necessary to
the general welfare, it would be absurd, to say the least, to
superadd a power to raise armies, to provide fleets, &c. In fact, the
meaning of the general terms in question must either be sought in
the subsequent enumeration which limits and details them, or they
convert the Government from one limited, as hitherto supposed, to
the enumerated powers, into a Government without any limits at all.
It is to be recollected, that the terms "common defence and general
welfare," as here used, are not novel terms, first introduced into this
constitution. They are terms familiar in their construction, and well
known to the people of America. They are repeatedly found in the
old Articles of Confederation, where, although they are susceptible
of as great latitude as can be given them by the context here, it was
never supposed or pretended that they conveyed any such power as
is now assigned to them. On the contrary, it was always considered
as clear and certain, that the old Congress was limited to the
enumerated powers, and that the enumeration limited and explained
the general terms. I ask the gentlemen themselves, whether it ever
was supposed or suspected that the old Congress could give away
the moneys of the States in bounties, to encourage agriculture, or
for any other purpose they pleased? If such a power had been
possessed by that body, it would have been much less impotent, or
have borne a very different character from that universally ascribed
to it.
The novel idea now annexed to these terms, and never before
entertained by the friends or enemies of the Government, will have a
further consequence, which cannot have been taken into the view of
the gentlemen. Their construction would not only give Congress the
complete Legislative power I have stated—it would do more—it
would supersede all the restrictions understood at present to lie on
their power with respect to the Judiciary. It would put it in the power
of Congress to establish courts throughout the United States, with
cognizance of suits between citizen and citizen, and in all cases
whatsoever. This, sir, seems to be demonstrable; for if the clause in
question really authorizes Congress to do whatever they think fit,
provided it be for the general welfare, of which they are to judge,
and money can be applied to it, Congress must have power to create
and support a Judiciary Establishment, with a jurisdiction extending
to all cases favorable, in their opinion, to the general welfare, in the
same manner as they have power to pass laws and apply money,
providing in any other way for the general welfare. I shall be
reminded, perhaps, that according to the terms of the constitution,
the Judicial Power is to extend to certain cases only, not to all cases.
But this circumstance can have no effect in the argument, it being
presupposed by the gentlemen that the specification of certain
objects does not limit the import of general terms. Taking these
terms as an abstract and indefinite grant of power, they comprise all
the objects of Legislative regulation, as well such as fall under the
Judiciary article in the constitution, as those falling immediately
under the Legislative article; and if the partial enumeration of
objects in the Legislative article does not, as these gentlemen
contend, limit the general power, neither will it be limited by the
partial enumeration of objects in the Judiciary article.
There are consequences, sir, still more extensive, which, as they
follow clearly from the doctrine combated, must either be admitted,
or the doctrine must be given up. If Congress can apply money
indefinitely to the general welfare, and are the sole and supreme
judges of the general welfare, they may take the care of religion into
their own hands; they may establish teachers in every State, county,
and parish, and pay them out of the public Treasury; they may take
into their own hands the education of children, establishing in like
manner schools throughout the Union; they may undertake the
regulation of all roads, other than post roads. In short, every thing,
from the highest object of State legislation, down to the most
minute object of police, would be thrown under the power of
Congress; for every object I have mentioned would admit the
application of money, and might be called, if Congress pleased,
provisions for the general welfare.
The language held in various discussions of this House, is a proof
that the doctrine in question was never entertained by this body.
Arguments, wherever the subject would permit, have constantly
been drawn from the peculiar nature of this Government, as limited
to certain enumerated powers, instead of extending, like other
Governments, to all cases not particularly excepted. In a very late
instance—I mean the debate on the Representation bill—it must be
remembered, that an argument much urged, particularly by a
gentleman from Massachusetts, against the ratio of one for thirty
thousand, was, that this Government was unlike the State
Governments, which had an indefinite variety of objects within their
power; that it had a small number of objects only to attend to, and
therefore that a smaller number of Representatives would be
sufficient to administer it.
Several arguments have been advanced to show, that because, in
the regulation of trade, indirect and eventual encouragement is
given to manufactures, therefore Congress have power to give
money in direct bounties, or to grant it in any other way that would
answer the same purpose. But surely, sir, there is a great and
obvious difference, which it cannot be necessary to enlarge upon. A
duty laid on imported implements of husbandry, would, in its
operation, be an indirect tax on exported produce; but will any one
say, that by virtue of a mere power to lay duties on imports,
Congress might go directly to the produce or implements of
agriculture, or to the articles exported? It is true, duties on exports
are expressly prohibited; but if there were no article forbidding
them, a power directly to tax exports could never be deduced from a
power to tax imports, although such a power might directly and
incidentally affect exports.
In short, sir, without going further into the subject, which I should
not have here touched on at all but for the reasons already
mentioned, I venture to declare it as my opinion, that were the
power of Congress to be established in the latitude contended for, it
would subvert the very foundation, and transmute the very nature of
the limited Government established by the people of America; and
what inferences might be drawn, or what consequences ensue from
such a step, it is incumbent on us all well to consider.
With respect to the question before the House, for striking out the
clause, it is immaterial whether it be struck out, or so amended as to
rest on the avowed principle of a commutation for the drawback; but
as a clause has been drawn up by my colleague, in order to be
substituted, I shall concur in a vote for striking out, reserving to
myself a freedom to be governed in my final vote by the
modification which may prevail.
Mr. Bourne, of Massachusetts—
Mr. Chairman: I think little can be added after so full a discussion of
the subject before you. The object of the first section in this bill is
intended for the relief of the fishermen and their owners. They
complain that the law now in force was meant for their benefit, by
granting a drawback on the fish exported; this they find by
experience is not the case, for they say, that neither the fishermen
who catch the fish, nor the importer of the salt, receive the
drawback; and I rather suppose, sir, it is the case. The owners of the
greater part of the fishing vessels are not merchants, neither do they
import the salt they consume; but when the fish they take are cured
for market, they are sold at the market price; and it frequently
happens that those persons who purchase the fish are not the
exporters of them, or the importers of the salt, but a third person,
who purchases with a prospect of selling them at a profit, is the
exporter; and when it so happens, neither the fisherman who
catches the fish, nor the importer of the salt, receives any benefit
from the drawback, unless the purchaser (the third person) give a
greater price in contemplation of the drawback, which I think is not
to be supposed.
Is it worthy the attention of Government that the cod fishery should
be preserved? It appears to me that it is. When we consider the
labor and assiduity bestowed on this object by our Ministers, at the
settlement of peace between us and Great Britain, and the care then
taken to secure this privilege, as appears by the treaty—[here Mr. B.
read that part of the treaty which secures to us the fishery, he then
proceeded]—and consider the struggle made to deprive us of this
inestimable branch of commerce, I cannot suppose that any one
would, at this day, voluntarily relinquish it, and suffer Great Britain to
monopolize this branch, and supply the Mediterranean, French, and
other markets. Great Britain, at present, enjoys a sufficient portion
of this commerce, while France is confined to the narrow limits of St.
Peters and Miquelon. If we relinquish this branch of the cod fishery,
what is left us? Our whale fishery is nearly at an end, and unless
Government speedily interpose, by granting relief, we shall totally
lose it. Does not the British Government wish to deprive us of this
branch also? Have not letters of agents been sent to the island of
Nantucket, as well as New Bedford, where this branch of business is
principally prosecuted, inviting the whale fishermen to remove, and
offering them permanent settlements at Milford-Haven, at the
expense of their Government? This must be viewed as a great
encouragement, in addition to their bounties on oil, to a class of
poor men employed in that business. If the cod fishery is
relinquished, the fishermen have only to remove to the opposite
shore of Nova Scotia, where they will find encouragement fully
adequate to their services—of all which they are not unapprised. By
encouraging this class of men, your revenue will be increased; for in
return for the fish exported, you will receive sugar, coffee, cocoa,
indigo, molasses, pimento, cotton, dye-woods, rum, wine, salt, fruit,
and other articles subject to duty, and consumed in the country. And
again, your Treasury will receive an excess by the provision in this
bill; for I presume the greater proportion of vessels employed in this
business are from twenty to forty tons; the town of Marblehead,
perhaps, has principally large ones. Suppose, then, a vessel of thirty
tons obtains, in a season, six hundred quintals of fish? (a very
moderate voyage indeed,) her tonnage is seventy-five dollars; the
drawback on exportation would be seventy-eight dollars; so that
your Treasury retains three dollars gain by this bill, which would be a
loss on the drawback.
Mr. Chairman, I think, upon the whole, that granting the
encouragement to the fishermen and their owners, held out in the
bill, would prove very beneficial to the United States; I hope,
therefore, the section before you will not be struck out.
At this point, the committee rose, and had leave to sit again.

Tuesday, February 7.
Ordered, That the petitions of the tanners of the town of Newark, in
the State of New Jersey, which was presented yesterday, be referred
to Mr. Boudinot, Mr. White, Mr. Thatcher, Mr. Bourne, of Rhode Island,
and Mr. Niles; that they do examine the matter thereof, and report
the same, with their opinion thereupon, to the House.
Mr. Benson, from the committee appointed, presented a bill for an
apportionment of Representatives among the several States,
according to the first enumeration, and making provision for another
enumeration, and apportionment of Representatives thereon, to
compose the House of Representatives after the third day of March,
1797; which was received and read the first time.
The Speaker laid before the House a letter from the Secretary of the
Treasury, accompanying his report stating the amount of the
subscriptions to the loans proposed by the act making provision for
the public debt, as well in the debts of the respective States as in
the domestic debt of the United States, and of the parts which
remain unsubscribed, together with such measures as are, in his
opinion, expedient to be taken on the subject, pursuant to an order
of this House of the 1st of November last; which were read, and
ordered to be committed to a Committee of the whole House on
Monday next.

The Fishery Bill

The House again resolved itself into a Committee of the whole
House on the bill sent from the Senate, entitled "An act for the
encouragement of the Bank and other Cod Fisheries, and for the
regulation and government of the fishermen employed therein."
Mr. Page said no man in this House was more heartily disposed to
encourage the fisheries of the United States than he was; nor could
any one more sincerely wish to encourage the bold, active, and
enterprising adventurers in that branch of our commerce to
persevere in it, than he did; being sensible of the importance of their
traffic in peace, and of their defence of their country and annoyance
of their enemies in war. But, sir, (said Mr. P.,) I much doubt whether
Congress can give that encouragement to the fisheries to which they
are entitled, and which policy would lead the General Government to
give, were it not restricted by the constitution. I consider, sir, the
constitution as intended to remedy the defects of the Confederation
to a certain degree; so far only as would secure the independence
and general welfare of the Confederated States, without
endangering the sovereignty and independence of the individual
States. Congress, therefore, was authorized to pay the debts of the
Union, and to regulate commerce, partly for that purpose, and partly
to prevent improper and dangerous commercial combinations,
jealousies, and altercations between the States. But Congress was
not intrusted with any regulation of exports which could admit of an
interposition which might be dictated by partiality; nor was Congress
permitted to lay any tax which could by any possibility operate
unequally on the States in general. It is said, indeed, that, if a
drawback be not allowed on the salt used in salting fish, there will
be, in fact, a duty on the exportation of the fish. But to this I think it
may be replied, that the constitution guards the exports of each
State against the possibility of a partial restriction by Congress, or
even by the States themselves; that Congress cannot lay a duty on
the exportation of rice, indigo, tobacco, &c., or any other article
exported from any State, because this might be done to the injury of
the State where such duty would operate, and to the advantage and
aggrandizement of some particular States, its competitors more
favored by the General Government, or possessing more influence in
the debates of Congress; and that the States are also individually
restrained from laying such duties without the consent of Congress,
to prevent acts which might produce jealousies, commercial
combinations, and, perhaps, at length, civil dissensions. That this
restriction, if it be intended to prevent partiality, therefore, cannot
extend to authorize drawbacks, which may be productive of partial
preferences and their consequent jealousies; that if drawbacks be
granted at all, they ought to be universally extended to every article
which is or can be exported from any of the States, having in its
composition a dutiable ingredient; that hence, ships and other
vessels, &c., should have drawbacks on the sails, cordage, iron, &c.;
but it may also be said that, as to the duty on salt, that is amply
repaid to the merchant by the price annexed to his fish; the sums
laid out in salt and fish together form a capital on which he takes
care to have a sufficient profit. Those merchants employed in this
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com