This document discusses using a semantic wiki for architectural knowledge management. It begins with an introduction to architectural knowledge and knowledge management strategies. It then provides an overview of semantic wikis and MediaWiki, describing how semantic annotations allow the wiki to understand relationships between concepts. The rest of the document discusses setting up a semantic architecture wiki, including deciding on a knowledge model, using forms and properties to capture information, and maintaining the wiki through approaches like revision control.

1. Tutorial T2
Architectural Knowledge Management
with Semantic Wikis
Remco de Boer (ArchiXL)
WICSA 2011
Monday 20 June 2011
Boulder, Colorado
1

2. ArchiXL
• IT architecture consultancy
• Founded in January 2008
• Located in Amersfoort (NL)
• Focus on financial and public sector
• Independent
• Knowledge areas:
– IT architecture
(BPM, EAI/SOA, ECM, IDM, BI, Porta
ls)
– Enterprise architecture
methods, techniques and tools
(TOGAF, ArchiMate)
– Knowledge management (semantic
wikis)
– Domain knowledge
(insurance, pension funds, local
government, education)
30-4-2012 2

3. Today‟s agenda
• Introduction to architectural knowledge and architectural knowledge management
– The architect as knowledge worker
– Different types of architectural knowledge
– Architectural knowledge transformations and AK management strategies
• Introduction to Semantic Wiki
• Semantic wiki for architectural knowledge
– Real life cases from Dutch e-government and ArchiXL‟s architecture practice
– What does the end user (the reader) see?
– What does the contributing architect see?
• Setting up and maintaining the architecture knowledge model
– Deciding on the knowledge model
– Important building blocks
– Inference: Possibilities and limitations
– Conformance: Validating the wiki‟s contents against the knowledge model
• Reusing Architectural Knowledge through a System of Wikis
– Organisation-specific extensions of generic reference architecture knowledge
– Linking different semantic architecture wikis
– Remote querying
• Semantic Architecture Wiki as an Architectural Knowledge Portal
– Reusing architectural knowledge from other tools/environments
3

4. Architectural Knowledge
4

5. The architect as knowledge worker
• Knowledge work entails gathering, processing, creating, sharing and
disseminating knowledge
• 3 phases:
1. Information:
• gathering relevant knowledge and data
2. Use:
• processing the gathered knowledge
• creating new knowledge
3. Result:
• sharing and disseminating the result
(Mackenzie Owen, 2001)
5

6. Architectural knowledge is an asset
“The major problem with intellectual capital is that it has
legs and walks home every day.”
Rus & Lindvall
6

7. Dimensions of architectural knowledge
Tacit
goals, constraints
experience, expe
, assumptions, co
rtise
ncerns
Generic Specific
standards, requirements,
reference principles, design
architectures, decisions,
architectural models
styles
Explicit
7

8. Architectural knowledge transformations
Tacit
Socialisation
Externalisation
Internalisation
Combination
Explicit
8

9. Architectural knowledge transformations
Abstraction
Generic Maturation Refinement Specific
Use
9

10. Architectural Knowledge:
Decisions are key
Tacit
goals, constraints
Motivation
experience, expe
, assumptions, co
rtise
ncerns
Generic Specific
standards, refere requirements, pri
nce nciples, design
architectures, arc decisions, model
Reuse
hitectural styles s
Implications
Explicit
10

11. Strategies for architectural knowledge management
• Codification
– Emphasizes explicit, often formalized knowledge
– Knowledge base
– „Push‟-mechanism
• Personalisation
– Emphasizes tacit, implicit knowledge
– Expert network
– „Pull‟-mechanism
• Hybrid
– Combination of codification and personalisation
– Collaborative environment
– Push/Pull (active contributions, „who knows what?‟)
11

12. Advantages of using a semantic wiki
• Open invitation for knowledge sharing
– Everyone may contribute
– “Who knows what”?
• Single entry point for architectural knowledge
– Open platform
– Integration with other tools possible
• Architecture in context
– No a-priori constraints on the type of knowledge that can be captured
• Semi-structured
– Supports structure and text
• Dynamic overviews / queries
– Stakeholder-specific content
12

13. Semantic MediaWiki
13

14. A brief history of wiki (1)
• First wiki: WikiWikiWeb
– 25 March 1995
– Ward Cunningham
– Portland Pattern Repository
– http://c2.com/cgi/wiki
• People, projects and patterns
• “We're looking for that common
knowledge that's so uncommon. For
example, CommandObject makes
undo and redo easy while
WindowPerTask addresses updating
issues in early ModelViewController
(MVC). ModelRendererView
describes a variation on the theme.
These pages won't necessarily
contain the usual parts of a
WrittenPattern. We're just labeling
ideas so we can study how they flow.”
14

15. A brief history of wiki (2)
• The essence of wiki:
– A wiki invites all users to edit any page or to create new pages within
the wiki Web site, using only plain-vanilla a Web browser without any
extra add-ons.
– Wiki promotes meaningful topic associations between different pages by
making page link creation almost intuitively easy and showing whether
an intended target page exists or not.
– A wiki is not a carefully crafted site for casual visitors. Instead, it seeks
to involve the visitor in an ongoing process of creation and collaboration
that constantly changes the Web site landscape.
Ward Cunningham, Bo Leuf, “The Wiki Way: Quick Collaboration on the Web” (2001)
15

16. A brief history of wiki (3)
• Examples of Wiki Engines:
– MoinMoin (2000)
• Public wikis: Ubuntu, Apache, Debian, FreeBSD, ...
– MediaWiki (2002)
• Wikipedia
– Confluence (2004)
• Enterprise wiki (commercial)
– XWiki (2004)
• Enterprise wiki (FOSS)
16

17. MediaWiki
• Most popular wiki engine worldwide
• Developed by WikiMedia foundation
– Open source,
– xAMP (Apache/MySQL/PHP)
• Optimized for scalability and performance
• The wiki engine for Wikipedia.org...
– >18M articles, 279 languages
– >3.6M articles in English
– >14M registered users source: Wikipedia
– >50M unique daily visitors (april 2011) source: Google Trends
• ... en for many more wikis
– >50K public wikis source: s23.org/wikistats
17

18. Wikipedia: a wiki encyclopedia
18

19. Wikipedia: a wiki encyclopedia
How large are the largest cities in
the US?
What is Boulder‟s Rank?
19

20. Wikipedia page
“List of United States cities by population”
20

21. Semantic MediaWiki
• First release: 2005
• Initially a EU FP6 project (SEKT, Semantically Enabled Knowledge
Technology, 2004-2006)
• Extension to MediaWiki
– A „regular‟ wiki with an underlying knowledge model
– The knowledge model makes facts and relations meaningful, both for
humans and machines
– From this meaning (or „semantics‟), new relations and facts can be
derived
– It becomes possible to directly pose questions to the wiki (queries)
– Queries may be used to dynamically generate and visualize reports
• >200 registered public SMW wikis
21

22. Back to Boulder...
22

23. What the regular wiki engine knows
Boulder County, Colorado
Boulder, Colorado
United States
Rocky Mountains
23

24. What a semantic wiki engine knows
Population:
Population: County seat of 282,304
94,268
Elevation:
5,430 feet
Located in Boulder County, Colorado
Boulder, Colorado
Borders
Population:
308,745,538
Located in
United States
Located in
Rocky Mountains
24

25. Semantic Annotations
Regular wiki Semantic wiki
'''Boulder''' is the [[county seat]] and most '''Boulder''' is the [[county seat]] and most
populous city of [[Boulder County, populous city of [[County seat of::Boulder
Colorado|Boulder County]] and the 11th most County, Colorado|Boulder County]] and the
populous city in the U.S. state of 11th most populous city in the U.S. state of
[[Colorado]]. [[Located in::Colorado]].
Boulder is located at the base of the Boulder is located at the base of the
foothills of the [[Rocky Mountains]] at an foothills of the [[Borders::Rocky Mountains]]
elevation of 5430 feet. at an elevation of [[Elevation::5430 feet]].
The United States Census Bureau estimates The United States Census Bureau estimates
that in 2008 the population of the city of that in 2008 the population of the city of
Boulder was 94,268. Boulder was [[Population::94,268]].
25

26. Semantic properties of “Boulder, Colorado”
26

27. Examples of knowledge that may be derived from
within the wiki
• Answers to direct questions:
– How big is Boulder (area)?
– What is its population?
– In which country is it located?
– ...
• Answers to indirect questions:
– Population density (population / area)
– What is the largest city (in terms of population) of the country in which
Boulder is located?
– ...
• These answers can be presented in dynamic overviews
– List of all cities in Boulder County
– Table of all county seats in the US ordered by population
27

28. Semantic Wiki for
Architectural Knowledge
28

29. Semantic (Architecture) Wikis
• E-government
– Reference architectures
– Organisation-specific (enterprise) architectures
• IT
– ArchiXL IT reference architecture
– Information model (water control)
• Viewpoints
– 42010 Viewpoint Repository
• But also
– issue management
– project management
– contract management
– service management
29

30. Background: „e-government‟
• Goals (for citizens and businesses):
– Reduce administrative burdens
– Better service provision
• Means (for government agencies):
– Work together
– Align business processes
– Use each other‟s information
• This has huge impact on the enterprise architecture of government
agencies!
– business processes
– information landscape
– technology
30

31. Example: the environmental permit
• Suppose you want to renovate
and extend your house
• It‟s a big operation, so you
need to fell some trees that are
in the way
• You also need to demolish part
of the existing building
31

32. Renovating your house, before Oct. 2010
Building permit
Tree felling permit
Demolition permit
32

33. Renovating your house, since Oct. 2010
Environmental
permit
33

34. Interacting with the e-government
34

35. The NORA architecture family
• Establish processes and systems
that ensure interoperability
• Increasing level of specificity
(government  domain 
organization)
• Main constituents:
– Architecture principles
– Architecture models
• Architecture is the fundamental organization of a
system embodied in its components, their
relationships to each other, and to the
environment, and the principles guiding its
design and evolution (ISO-IEC 42010)
• “Principles are general rules and guidelines,
intended to be enduring and seldom amended,
that inform and support the way in which an
organization sets about fulfilling its mission.”
(TOGAF)
35

36. Example architecture principles
• No wrong door:
– Citizens and businesses can direct their questions to „the government‟;
government offices (re)direct to the appropriate service
• Single request, multiple use of data:
– Once the government has obtained certain data from a citizen or
business, no government agency may ask for the same data again.
• Transparent services:
– Citizens and businesses are informed about the state of the requested
service.
36

37. Example architecture model:
GEMMA Information architecture
source: GEMMA
37

38. Principle (Wiki page)
38

39. Example query answered by the wiki:
Case management motivation and implications
39

40. ArchiMate model element (Wiki page)
40

41. ArchiMate: Overview
Represen - Business Business
Business
tation service collaboration
Business
Event interaction
Business
Business Business Business
object
process role actor
Application
Application
Application
service interface
Data
Application Application
object
function component
Infrastructure Infrastructure
Technology
service interface
System
Artifact Device Network
software
Passive structure Behaviour Active structure
41

42. An ArchiMate model
source: Lankhorst et al., ArchiMate Language Primer 42

43. Semantic architecture wiki:
The end user‟s perspective (the „reader‟)
• Facts and relationships, such as
– Model elements: ArchiMate attributes and relations
– Architectural statements: motivation and implications; traceability
• Combined structured and unstructured information
• Dynamic overviews
– Tables
– Lists
– Diagrams
– Relation tables
– Categories
• Interactive selections
– Faceted search; dynamic drill-down
– Semantic search (advanced)
43

44. Facts and relationships in GEMMA:
Principles, motivation and implication
44

45. Facts and relationships in ROSA:
Education Chain Processes as ArchiMate Wiki Pages
45

46. Textual information
(combined with structured semantics)
46

47. Image: ArchiXL IT Reference architecture
47

48. Dynamic overviews
48

49. Dynamic overview: table
49

50. Dynamic overview: relation table
50

51. Dynamic overview: graph
51

52. Interactive selections
52

53. Semantic search
53

54. Semantic architecture wiki:
The architect‟s perspective (the „contributor‟)
• Input forms
– Forms for meaningful codification of e.g. ArchiMate concepts and
architecture principles
– Automatic form assignment for „red links‟ based on relations
• Standard wiki markup for free text
• ImageMap editor
– Annotate images with links to wiki pages
• Special forms, such as
– Import reference architecture knowledge
– Project Start Architecture generator
• Integration with other tools
– show and link model images from other tools in the wiki
– batch import model definitions from other tools
54

55. Input forms
55

56. Special forms
56

57. A brief note on the editing process
• How open should your architecture wiki be?
• Options to consider:
– Self registration vs. registration through administrator
– Publically readable?
– Contributions from everyone, or only a selected few?
• There is a tension between control and openness
– Traditionally, (reference) architectures are tightly controlled by an
architecture board and/or editorial board.
• Possible solution: revision control („approved revisions‟)
– Everyone may contribute
– Only the approved revision is shown and used in semantic queries
– Approval rights are selectively distributed
57

58. Approved Revisions
58

59. Per-page Revisions with Approved Revisions
extension
59

60. Approved Revisions
60

61. Comparison of approved and latest version
61

62. Setting up and maintaining
the wiki‟s
architectural knowledge model
62

63. Step 1: Knowledge model - Determine what to register
63

64. Most important components of the knowledge model
• Templates
– „Classes‟
• Properties
– Attributes and relationships
• Forms
– For data entry and changes
• Categories
– „Object types‟
64

65. Principles (TOGAF)
65

66. Principles as a form of (architectural) statements in the
semantic knowledge model
Wiki page
(Statement)
Template: Category:
Statement Statements
Attributes -Goals
-Statement -Principles
-Type -Core principles
-Architecture layer -Process architecture
Form: -Architecture domain principles
-Quality Attribute -Information architecture
Statement -Source principles
-ID -...
-Requirements
Relations -Design decisions
-Motivation -...
-Implication
-Association (ArchiMate)
66

67. Statements: core attributes
• Page name: a condensed form of the statement that uniquely
identifies it (e.g. “No wrong door”).
• Type: the type of statement
– e.g., „Strategic goal‟, „Architecture principle‟, „Core principle‟, „Process
principle‟, „Design decision‟
• Statement: The full statement, in the form of a sentence
• Motivation: The reason behind the statement
– Textual: free text
– Reference: references to other statements in the wiki
• Implications: The implications of the statement
– Textual: free text
– Reference: references to other statements in the wiki
• Related to (association): Other pages, such as model elements
67

68. ArchiMate in the semantic knowledge model
Wiki page
(ArchiMate concept)
Template: Category:
ArchiMate Concept ArchiMate Concepts
Attributes -Active concepts
-Name -Interfaces
-Type -Structural elements
-Description -Behavior concepts
Form: -... -Behavioral elementen
ArchiMate -Services
Relations -Passive concepts
Concept - All ArchiMate relations -Objects
69

69. ArchiMate concepts (1)
• Page Name: A unique (!) name
• Core properties
– Type: the type of ArchiMate concept (e.g., Infrastructure service,
Application component, etc.)
– Description: a description or definition of the concept
– External information: a link (URL) to further information about this
– Owner: the owner of the concept
– Maintainer: the maintainer of the concept
• Metadata
– Name: optional (alternative to pagename)
– Version: number that should be increased upon significant changes
– Active: whether or not the concept is still active (may become inactive
due to, e.g., aging or replacement)
– Category: list of categories the concept belongs to
70

70. ArchiMate concepts (2)
• Additional information (type-dependent)
– Supplier
– Level of abstraction [logical/physical]
– Open source [yes/no]
• Relations
– Related to (association).
– Accesses
– Uses
– Realizes
– Assigned to
– Groups
– Consists of
– Flows to
– Triggers
– Specializes
71

71. Properties (Attributes and Relationships)
• Every property has its own Property: page in de wiki
• Each property has a type
– Page – Text – URL
– String – Code – Email
– Number – Temperature – Geographic
– Boolean – Telephone number coordinate
– Date – Record
• Some special (pre-defined) properties:
Properties of properties: External services
– Allows value – Provides service
– Has type Inferred:
– Has fields – Modification date
– Subproperty of – Has improper value for
Custom units: OWL / RDF:
– Corresponds to – Imported from
– Display units – Equivalent URI
72

72. Templates
• Predefined, parameterized part of a wiki page
– Presentation + visualization
• Layout
• Standard queries (e.g., graphs, inverse relations)
– Semantic annotations
– Control flow
• Can be included on regular wiki pages:
{{Template|parameter1=x|parameter2=y}}
• Example: ArchiMate concept “Case handling”
{{ArchiMate concept
{{ArchiMate concept
|Name=Case handling
|Name=Case handling
|Type=Infrastructure service
|Description=Provide case-oriented support for
|Description=Provide case-oriented support for
processes, which means the case is central
rather than whichdetailed process is central
processes, the means the case design
|Version=1 the detailed process design
rather than
|Version=1
|IT reference architecture=Application
infrastructure architecture=Application
|IT reference
|Specializes=Process control
infrastructure
}}
|Specializes=Process control
}}
Page “Case handling”
73

73. Templates: Layout
• Predefined, parameterized part of a wiki page <table> Shows ArchiMate symbol based on type
– Presentation + visualization <tr>
• Layout <td>[[File:{{{Type|}}}.png]]</td>
• Standard queries (e.g., graphs, inverse relations) </tr>
– Semantic annotations <tr>
Show Parameter values in table
– Control flow <th>Name</th>
<td>{{{Name|}}}</td>
• Can be included on regular wiki pages: </tr>
{{Template|parameter1=x|parameter2=y}} <tr>
<th>Description</th>
• Example: ArchiMate concept “Case handling” <td>{{{Description|}}}</td>
</tr>
{{ArchiMate concept
{{ArchiMate concept <tr>
|Name=Case handling
|Name=Case handling
<th>Specializes</th>
|Type=Infrastructure service
|Description=Provide case-oriented support for <td>{{{Specializes|}}}</td>
|Description=Provide case-oriented support for
processes, which means the case is central </tr>
rather than whichdetailed process is central
processes, the means the case design
<tr>
|Version=1 the detailed process design
rather than
|Version=1
|IT reference architecture=Application <th>Generalizes</th>
infrastructure architecture=Application
|IT reference <td>???</td>
|Specializes=Process control
infrastructure |}}
}}
|Specializes=Process control This value is not provided, should be
...
inferred
}} </table>
Page “Case handling” Template:ArchiMate_concept
74

74. Templates: Standard queries
• Predefined, parameterized part of a wiki page <table>
– Presentation + visualization <tr>
• Layout <td>[[File:{{{Type|}}}.png]]</td>
• Standard queries (e.g., graphs, inverse relations) </tr>
– Semantic annotations <tr>
– Control flow <th>Name</th>
<td>{{{Name|}}}</td>
• Can be included on regular wiki pages: </tr>
{{Template|parameter1=x|parameter2=y}} <tr>
<th>Description</th>
• Example: ArchiMate concept “Case handling” <td>{{{Description|}}}</td>
</tr>
{{ArchiMate concept
{{ArchiMate concept <tr>
|Name=Case handling
|Name=Case handling
<th>Specializes</th>
|Type=Infrastructure service
|Description=Provide case-oriented support for <td>{{{Specializes|}}}</td>
|Description=Provide case-oriented support for
processes, which means the case is central </tr>
rather than whichdetailed process is central
processes, the means the case design
<tr>
|Version=1 the detailed process design
rather than
|Version=1
|IT reference architecture=Application <th>Generalizes</th>
infrastructure architecture=Application
|IT reference <td>{{#ask:
|Specializes=Process control
infrastructure [[Specializes::{{PAGENAME}}]]</td>
}}
|Specializes=Process control |}}
}} ... Query to find pages that specialize
</table> this page
Page “Case handling”
Template:ArchiMate_concept
75

75. Templates: Semantic annotations
Silently assign some semantic property values
• Predefined, parameterized part of a wiki page
– Presentation + visualization {{#set:ArchiMate Type={{{Type|}}}}}
• Layout {{#set:Version={{{Version|}}} }}
• Standard queries (e.g., graphs, inverse relations) <table>
– Semantic annotations <tr>
– Control flow Assign parameter values to semantic
<td>[[File:{{{Type|}}}.png]]</td>
properties
</tr>
• Can be included on regular wiki pages: <tr>
{{Template|parameter1=x|parameter2=y}} <th>Name</th>
<td>[[name::{{{Name|}}}]]</td>
• Example: ArchiMate concept “Case handling” </tr>
<tr>
{{ArchiMate concept
{{ArchiMate concept <th>Description</th>
|Name=Case handling
|Name=Case handling
<td>[[description::{{{Description|}
|Type=Infrastructure service
}}]]</td>
|Description=Provide case-oriented support for
|Description=Provide case-oriented support for
processes, which means the case is central </tr>
rather than whichdetailed process is central
processes, the means the case design
<tr>
|Version=1 the detailed process design
rather than
|Version=1 <th>Specializes</th>
|IT reference architecture=Application
infrastructure architecture=Application
|IT reference <td>[[specializes::{{{Specializes|}
|Specializes=Process control
infrastructure }}]]</td>
}}
|Specializes=Process control </tr>
}} ...
Page “Case handling” Template:ArchiMate_concept
76

76. Templates: Control flow
• Predefined, parameterized part of a wiki page
– Presentation + visualization {{#set:ArchiMate Type={{{Type|}}}}}
• Layout {{#set:Version={{{Version|}}} }}
• Standard queries (e.g., graphs, inverse relations) ...
– Semantic annotations <table>
– Control flow <tr>
Semantic annotation of property
„Name‟: use page name when no
<td>[[File:{{{Type|}}}.png]]</td>
other name provided
• Can be included on regular wiki pages: </tr>
{{Template|parameter1=x|parameter2=y}} <tr>
<th>Name</th>
• Example: ArchiMate concept “Case handling” <td>[[name::{{#if: {{{Name|}}} |
{{{Name|}}} | {{PAGENAME}}
{{ArchiMate concept
{{ArchiMate concept }}]]</td>
|Name=Case handling
|Name=Case handling </tr>
|Type=Infrastructure service <tr {{#ifeq: {{{Description|}}} |
|Description=Provide case-oriented support for
|Description=Provide case-oriented support for |class=“hidden”}}>
processes, which means the case is central
rather than whichdetailed process is central
processes, the means the case design <th>Description</th>
|Version=1 the detailed process design
rather than
<td>[[description::{{{Description|}
|Version=1
|IT reference architecture=Application }}]]</td>Semantic annotation of Description:
infrastructure architecture=Application
|IT reference only shown when a description is
</tr>
|Specializes=Process control
infrastructure provided
}} |}}
|Specializes=Process control
...
}}
Template:ArchiMate_concept
Page “Case handling”
77

77. Templates
• Predefined, parameterized part of a wiki page
– Presentation + visualization {{#set:ArchiMate Type={{{Type|}}}}}
• Layout {{#set:Version={{{Version|}}} }}
• Standard queries (e.g., graphs, inverse relations) ...
– Semantic annotations <table>
– Control flow <tr>
<td>[[File:{{{Type|}}}.png]]</td>
• Can be included on regular wiki pages: </tr>
{{Template|parameter1=x|parameter2=y}} <tr>
<th>Name</th>
• Example: ArchiMate concept “Case handling” <td>[[name::{{#if: {{{Name|}}} |
{{{Name|}}} | {{PAGENAME}}
{{ArchiMate concept
{{ArchiMate concept }}]]</td>
|Name=Case handling
|Name=Case handling </tr>
|Type=Infrastructure service <tr {{#ifeq: {{{Description|}}} |
|Description=Provide case-oriented support for
|Description=Provide case-oriented support for |class=“hidden”}}>
processes, which means the case is central
rather than whichdetailed process is central
processes, the means the case design <th>Description</th>
|Version=1 the detailed process design
rather than
<td>[[description::{{{Description|}
|Version=1
|IT reference architecture=Application }}]]</td>
infrastructure architecture=Application
|IT reference </tr>
|Specializes=Process control
infrastructure
}} |}}
|Specializes=Process control
...
}}
Template:ArchiMate_concept
Page “Case handling”
78

78. Forms
• Usage: Create and edit pages {{{for template|ArchiMate concept}}}
{| class="formtable"
! Type:
• Forms are linked to templates | {{{field|Type|property=ArchiMate
Type|mandatory|show on
– form fields are converted to template select=Application_component=>reali
zes;Application_component=>speciali
parameter zes;Infrastructure_service=>special
izes;...}}}
! Name:
• Various tools for workflow and user | {{{field|Name}}}
...
support: |}
<div id=“realizes”>
– Default values {| class="formtable"
– Show fields depending on values of ! Realizes:
| {{{field|realizes|autocomplete on
other fields (show on select) category=ArchiMate concepts}}}
}}
– Automatically retrieve relevant input </div>
values (autocomplete) ...
Form:ArchiMate_concept
80

79. SMW Query language
• Comparable to SQL “SELECT x WHERE y”
{{#ask: y | ?x }}
• Examples:
– all application components
{{#ask: [[Category:Application components]] }}
– names and descriptions for all application components at the logical level of
abstraction
{{#ask: [[Category:Application components]] [[Level of abstraction::Logical]]
|?Name |?Description}}
– all application components that realize Document management
{{#ask: [[Category:Application components]] [[Realizes::Document management]]
}}
– all application components that realize any application service (via a subquery)
{{#ask: [[Category:Application components]] [[realizes::<q>[[Application
services]]</q>]] }}
– all application components that realize a specialization of Content management
{{#ask: [[Categorie:Application components]] [[realizes.specializes::Content
management]] }}
81

80. SMW Query: Table
{{#ask: [[Specializes::User
interaction]]
|mainlabel=Service
|?Description
|format=table
}}
82

81. SMW Query: Graph
{{#ask: [[User interaction]] OR
[[specializes::User interaction]]
OR [[realizes.specializes::User
interaction]]
| ? | ?specializes | ?realizes
| format=graph
| graphcolor=Yes
| graphlink=Yes
| graphname=User interaction
| graphlegend=No
| graphlabel=Yes
| graphsize=8,8
| rankdir=RL
}}
83

82. Validating model conformance:
A priori
• Forms may provide guidance
– autocomplete
– show on select
• Properties may be limited to certain values
– allows value::
• However, there is no true enforcement of model conformance
– Autocompletion is not limitative
– Semantic annotations may be set through wiki text, without using any
form
– In true wiki style, one can always make (semantic) references to as-of-
yet inexisting pages („red links‟)
84

83. Validating model conformance:
A posteriori
• We cannot (and probably should not) fully control the knowledge that
will be registered in the wiki beforehand
• We can, however, verify the contents of the wiki with respect to the
knowledge model after the fact
• To do so, we use inline queries that have been written as a strict
interpretation of the knowledge model
• Violations found by such queries signify one of the following options:
1. There is some knowledge in the wiki that is „incorrect‟ (model-wise)
2. The knowledge model was incomplete, and we found an exception
3. The query was incorrectly specified
• It‟s almost a „unit test‟ for architectural knowledge
85

84. Validating model conformance:
A posteriori
Concepts that should not have a 'realizes' Drivers motivated by an architectural
relation: principle:
{{#ask: [[Category:ArchiMate concepts]] {{#ask: [[Category:Drivers]]
[[ArchiMate Type::!Application component]] [[motivation::<q>[[Category:Architectural
[[ArchiMate Type::!Node]] [[realizes::+]]| principles]]</q>]] OR [[Categorie:Drivers]]
default=none}} [[-implication::<q>[[Category:Architecture
principles]]</q>]]|default=none}}
Application components that realize
something else than application services: Architecture principles without a
{{#ask: [[Categorie:Application components]] motivation:
[[realizes.ArchiMate Type::!Application {{NotFilledOut|Category=Architecture
service]]| default=none}} principles|Field=Motivation,-Implication}}
...
86

85. Inference
• Limitations:
– Open world assumption (cannot ask directly for properties that have not
been set)
– No transitivity
• Sometimes dedicated inference is necessary, e.g.
– Template:NotFilledOut
• Computes (from within the wiki) which properties have not been filled out, by
retrieving and comparing all pages from within a category and all pages from
that category for which the property has been set
– ROSA Project Start Architecture Generator, GEMMA Import module
• Wiki extensions (PHP) that exploit knowledge about the (transitive)
knowledge model to answer very specific information needs
• Make use of the SMW API
• Dedicated inference engines
87

86. Dedicated Inference:
ROSA PSA (Project Start Architecture) Generator
Sector
Chain process
Architecture
Layer(s)
88

87. Dedicated inference:
ROSA PSA Generator Inferred Output
• Principles
– All leading architecture principles
– All basic principles (from ROSA and NORA)
– All derived principles related to a building block that can be reached through the
following (sector-specific) sequence of relations
• Chain process – consists of  Chain process
• Chain process – leads to  Process
• Process – consists of  Process
• Process – uses  IT Service
• IT Service – is realized by  Building block
• Business architecture
– Selected chain process + subprocesses
– Sector-specific business processes
• Information architecture
– Supporting IT Services
– Building blocks
– Applicable standards
• Roadmap
– Projects that realize any of the building blocks
89

88. Dedicated Inference:
ROSA PSA (partial result)
Selected chain
processes (+
subprocesses)
Sector-specific
business
processes
Supporting IT
services
Technical
building blocks
Applicable
standards
90

89. Dedicated Inference:
ROSA PSA (partial result)
• Chain process: Register HO
– Business processes:
• Register participant at institution
• Maintain participant data at
institution
• Maintain central participant data
• Business process: Maintain
participant data at institution
– IT Services:
• Collect registrations at institutions
• ...
• IT Service: Collect registrations at
institution
– Bulding Blocks:
• Student administration system
– Applicable standards:
• Education Service Bus
91

90. Reusing Architectural Knowledge:
A System of Wikis
92

91. Architectural knowledge in a system of Semantic Wikis
Generic
Semantic Wiki
InterWiki links
Semantic Wiki Semantic Wiki Semantic Wiki
Organisation Organisation Organisation
X Y Z
Export Export Export
93

92. Linking specific and generic architectural knowledge
• The „tree‟ of principles in a reference architecture represents a
decision space, often with an increasing level of detail
e.g., Core principle  Information principle Design principle
• A reference architecture is open ended
– we need to work out generic reference architecture in organisation-
specific context
• Basis:
– Final implications of principles
– Specializations of architectural concepts
• Example: GEMMA Case management
– Municipality opts to work “Case-oriented” according to GEMMA (Dutch
Municipality Model Architecture)
94

93. Import final implications of “Case management” from
GEMMA Municipality
Wiki
(organisation-
“Case specific)
management”
95

94. Implications of „case management‟
Municipality
Wiki
“Case
management” (organisation-
specific)
Case management?
GEMMA Wiki
(generic)
96

95. Municipality
Implications of Wiki
“Case (organisation-
Management” specific)
97

96. Organisation-specific refinement of
„Case management‟
ArchiXL GEMMA Wiki Organisation-specific (municipality) EA wiki
GEMMA Information
function
Case management GEMMA Decision
(final)
Within our municipality:
implications Every case is recorded
in a case warehouse
... GEMMA Principle motivation implication
Every case is recorded Design decision
... in a case warehouse
Our municipality uses
... case management
system X
...
...
98

97. Local decisions about generic GEMMA principles
99

98. Reusing Architectural Knowledge (II)
An Architectural Knowledge Portal
100

99. Disseminate and enrich existing models
Architecture diagrams (HTML)
Semantic Architecture Modeling
CMDB
Wiki tool
XLS
Architecture models (CSV)
101

100. Enrich existing models in the architecture wiki
102

101. Reusing architecture diagrams from other tools
Markup
Page as for the
shown in page
the wiki
103

102. Wrap up
• What we‟ve seen today • Questions? Remarks?
– Introduction to architectural Want to share your
knowledge management thoughts?
– Introduction to Semantic wikis • Right here, right now...
– Semantic wiki for architectural • ... or contact me:
knowledge
– Setting up and maintaining the
architecture knowledge model
– Reusing Architectural Knowledge
through a System of Wikis
– Semantic Architecture Wiki as an
Architectural Knowledge Portal
104