WICSA 2011 Tutorial T2: Architectural Knowledge Management with Semantic Wikis

1,113 views

Published on

Architectural knowledge is increasingly regarded as an organizational asset that should be managed. Consequently, the architecture community has been researching and developing tools and techniques to support architectural knowledge management. Ideally, such tools and techniques support management of formal, structured architectural knowledge (e.g., architectural decision graphs); documented, unstructured architectural knowledge (e.g., text) and even tacit architectural knowledge (e.g., community building). Semantic wikis are capable of delivering this type of support for managing architectural knowledge.
In this tutorial, the participants will learn how semantic wikis can be used to manage architectural knowledge. We will address the nature of architectural knowledge, and draw a distinction between tacit and explicit and between generic and organization-specific architectural knowledge. We will then look at what a semantic wiki is, and what its main differences and advantages are as compared to a regular wikis. This is followed by real life examples of different forms of architectural knowledge in Semantic MediaWiki, including models, principles, design decisions and their interrelations. We discuss the underlying knowledge model, how it can be registered in the wiki, and what types of inference can and cannot be performed from within the wiki. We finish the tutorial with an investigation of how a semantic architecture wiki can be linked to other repositories, such as modelling environments and even other semantic architecture wikis, thereby providing an effective means of reusing existing architectural knowledge.

Published in: Business, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,113
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hier al: leer het publiekkennenvertel over persoonlijkeachtergrondvertel over ‘persoonlijke’ probleem (AK in documenten, 1-dimensionaal. Maarerzittenverschillendedwarsdoorsnedes en dwarsverbandenverstopt in een document. Cf. NORA)vraagnaarachtergrondpubliek: naam? academia en/of practice? verwachting van vandaag? ervaring met semantische wiki?
  • Let’s have a brief look at my background. I am an IT-architect at ArchiXL, an independent IT architecture consultancy in the Netherlands founded in 2008. We have a particular focus on the financial and the public sector. So we have several clients in the Dutch government area, and as a matter of fact during this presentation I will draw from our experience with some of our government clients to illustrate some of the ideas I want to convey today. We have several knowledge areas, one of which is knowledge management – especially architecture knowledge management – and this is also the background from which I am standing here today. So we are talking about knowledge management for enterprise architecture, specifically using semantic wikis.
  • In essence, architects are knowledge workers. We gather pre-existing knowledge - about the enterprise’s strategic goals, about processes and information needs, about reference architectures and so forth – and process that knowledge to determine for instance the IST and SOLL architecture, to perform a gap analysis and to construct a transition road map. It is only when we make this newly created knowledge explicit that it becomes visible for others. This may happen in various ways: in modeling tools, via e-mails, in presentations, at the coffee machine, et cetera. Eventually, we will aim to aggregate this knowledge in one or more architectural documents. This means that there is a lot of knowledge out there that we as architects need to take into account, and also a lot of knowledge we ourselves produce, which is usually shared in the form of documents.
  • So what are the types of knowledge architects have to deal with? We can distinguish between different types of architectural knowledge along two orthogonal axes: tacit vs. explicit and generic vs. specific. [Tacit =, explicit =, generic =, specific = ...] It is the architect’s task to make as much knowledge explicit as possible. Obviously, there is a trade-off there between the time invested in codification and the organizational gain in terms of reuse, understanding, and preventing ‘architectural erosion’. In principle, enough architectural knowledge should be made explicit such that the important decisions and components are traceable all the way up to the organization’s strategic goals.An area where explicit architectural knowledge plays an especially important role is in reuse of reference architectures.NB. Dissemination is not always about explicit knowledge (socialization!), but documented AK is!NB2. Explicit AK can be further divided in documented (unstructured) and formal (structured) AK.
  • NB. lijstje requirements van Rik (p.129):Stakeholder-specific content (wiki: semantische queries/verschillendedwarsdoorsneden)Easy manipulation of content (wiki: evident)Descriptive in nature (tool should not prescribe how it should be used) (wiki:’alles is mogelijk’)Support for codification (semantisch model)Support for personalization (wiki = community; historie van pagina-auteurs)Support for collaboration (wiki: evident)Sticky in nature ( widgets)
  • Eerste release 2005>200 publieke sites bron: SMW community wiki
  • An example of a domain in which reference architectures play a role is e-government. There, the goals as well as the means have been made very explicit. Obviously, these goals and means are still at a very high level of abstraction. Therefore, further refinement into concrete enterprise architectures is necessary.
  • For the Dutch e-government, a whole family of reference architectures has been created. The Dutch Government Reference Architecture – the NORA – consists of principles that, when adhered to, establish processes and systems that ensure interoperability. These are further refined in more domain-specific reference architectures. Each of these reference architectures falls under the authority of – and is maintained by – a particular governmental body. The reference architectures in turn form the basis for organization-specific enterprise architectures, e.g., for a particular municipality or educational institution.We have been working with several government agencies to make their reference architectures available as a cloud-based service. This all started from our own needs; among our customers are several Dutch municipalities, and at the time we were trying to find easier ways to use the information from the Municipality Reference Architecture GEMMA. The way we did this is that we analyzed the documents (GEMMA is published as a series of documents) and transferred their contents to a semantic wiki.
  • Geen van deze principes heeft direct betrekking op IT. Dat er significante effecten op de informatievoorziening zijn (die in meer technische architectuurmodellen verder uitgewerkt moeten worden), is niettemin evident.
  • ZaakgerichtwerkenuitleggenadhvdezeplaatOokvertellen over basisregistraties
  • // TBD: rewrite this text: explain what we see on this screen (esp. Motivation, Implications / inferred links)What you see here is an example page of our GEMMA architecture wiki. There are several advantages of a wiki over a traditional, linear document. Instead of a linear document, this wiki makes it possible to browse through the reference architecture knowledge in a much more associative way. One user of the wiki may be interested in a broad overview of the reference architecture, while another may be interested only in a part of it, but wants to delve into much more detail. Since the wiki presents the architecture knowledge as interlinked pages, both types of information needs are simultaneously supported. Documents, on the other hand, present the architecture in a much more linear fashion.Of course, putting architecture knowledge in a wiki does not equal putting the architecture in the cloud. What makes this wiki especially interesting, though, is the fact that it has been extended with a semantic engine. This means that the information in the wiki can be semantically annotated, such that the knowledge on a wiki page becomes comprehensible for both man and machine. In this semantic wiki, we have dedicated pages for principles and architecture components. These pages can be linked to other pages in the same wiki, but they can also be linked to other semantic architecture wikis, maintained by other organizations. Semantic interwikilinks: architectural knowledge in the cloud
  • Whole tree: 541 principles/statements
  • Last slide before the lunch break? (~halfway)
  • Demo:ROSA feiten en relaties: implicatie via factbox (Plaat -> Portaal -> Eigenschappen -> i-Principe)Overzichten: Principe-overzichtArchiXLitrefarch feiten en relaties:ArchiMate pagina’s overzichten: hoofdservicesGEMMAfeiten en relaties: principesoverzichten: themapagina (Zaak- en procesgericht werken)Interactieve selecties: - Dyndrilldown: GEMMA Speciaal:GegevensBekijken principesITRefArch: Architectuurprincipes (kwaliteitseigenschap), Applicatie-infrastructuur (ArchiMate concept)De gebruiker moet toegevoegde waarde van de wiki ondervinden. Bijvoorbeeld door (automatisch) betekenisvolle views te genereren op basis van de opgeslagen gegevens (met hun relaties). Hierbij zou je bijvoorbeeld wat voorbeelden kunnen laten zien uit de gemeentewereld. Jullie hebben bij ons hier al wat van laten zien, onder andere met relatieschema's. 
  • // TBD: rewrite this text: explain what we see on this screen (esp. Motivation, Implications / inferred links)What you see here is an example page of our GEMMA architecture wiki. There are several advantages of a wiki over a traditional, linear document. Instead of a linear document, this wiki makes it possible to browse through the reference architecture knowledge in a much more associative way. One user of the wiki may be interested in a broad overview of the reference architecture, while another may be interested only in a part of it, but wants to delve into much more detail. Since the wiki presents the architecture knowledge as interlinked pages, both types of information needs are simultaneously supported. Documents, on the other hand, present the architecture in a much more linear fashion.Of course, putting architecture knowledge in a wiki does not equal putting the architecture in the cloud. What makes this wiki especially interesting, though, is the fact that it has been extended with a semantic engine. This means that the information in the wiki can be semantically annotated, such that the knowledge on a wiki page becomes comprehensible for both man and machine. In this semantic wiki, we have dedicated pages for principles and architecture components. These pages can be linked to other pages in the same wiki, but they can also be linked to other semantic architecture wikis, maintained by other organizations. Semantic interwikilinks: architectural knowledge in the cloud
  • We komen later
  • We komen later weerterug op architectuurprincipes en e-overheid
  • Most functionality is standard (through published open source extensions), some of it has been custom written (special forms, tool-integration)
  • Live demo!?
  • Principles are just one form of architectural statements
  • The datatypetemperature is for temperature values. Unlike other physical quantities, temperature has to be a built-in type in SMW, because conversions between temperature scales can't be expressed as simple conversion factors in user-defined Custom unitsThe datatypetelephone number is used for international telephone numbers that are to be stored in a standardized format. The datatype will try to interpret the phone number according to RFC 3966 so that it can be exported in a machine-readable format using tel: URIs. Equivalent URI is a special property in Semantic MediaWiki with a built-in meaning: it marks a page in the wiki as having a well-known meaning beyond this wiki, in an external URI. For example an extension to the Semantic MediaWiki extension might introduce its own property, and all wikis should use the same equivalent URI for it. In RDF Export the "Equivalent URI" special property exports as owl:sameAs. This OWL property indicates that the article in the wiki and the external URI actually refer to the same "identity". If a property in the wiki corresponds to a URI in an existing ontology, you can use SMW's special vocabulary import feature to directly identify it with a property from that ontology. Then RDF Export will simply use that ontology's URI when exporting the property. Imported from is a special property in Semantic MediaWiki with a built-in meaning. It allows users to reuse elements of external vocabularies directly within the wiki. For more details, see the documentation at Help:Import vocabulary. For example, ontoworld.org uses this to reuse FOAF vocabulary, such as foaf:homepage in ow:Property:homepage.
  • Klasseaanmaken (demo)
  • toonkennismodelITRefarch, ROSA + eenaantal queries omvaliditeittecheckenVoorafafdwingennietmogelijk
  • Hiereventueel de code latenzien van de PSA generator.
  • Hiereventueel de code latenzien van de PSA generator.
  • Generic wikis provided in the cloud, organisation-specific wikis may be in the cloud (preferable), but could also be hosted on-premises.
  • Twee varianten:ontsluiting en verrijking van organisatiespecifieke AKhergebruik van generieke AK
  • WICSA 2011 Tutorial T2: Architectural Knowledge Management with Semantic Wikis

    1. 1. Tutorial T2Architectural Knowledge Management with Semantic Wikis Remco de Boer (ArchiXL) WICSA 2011 Monday 20 June 2011 Boulder, Colorado 1
    2. 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. 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. 4. Architectural Knowledge 4
    5. 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. 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. 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. 8. Architectural knowledge transformations Tacit Socialisation Externalisation Internalisation Combination Explicit 8
    9. 9. Architectural knowledge transformations Abstraction Generic Maturation Refinement Specific Use 9
    10. 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. 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. 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. 13. Semantic MediaWiki 13
    14. 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• “Were looking for that common knowledge thats 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 wont necessarily contain the usual parts of a WrittenPattern. Were just labeling ideas so we can study how they flow.” 14
    15. 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. 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. 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. 18. Wikipedia: a wiki encyclopedia 18
    19. 19. Wikipedia: a wiki encyclopedia How large are the largest cities in the US? What is Boulder‟s Rank? 19
    20. 20. Wikipedia page“List of United States cities by population” 20
    21. 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. 22. Back to Boulder... 22
    23. 23. What the regular wiki engine knows Boulder County, ColoradoBoulder, Colorado United States Rocky Mountains 23
    24. 24. What a semantic wiki engine knows Population: Population: County seat of 282,304 94,268 Elevation: 5,430 feet Located in Boulder County, ColoradoBoulder, Colorado Borders Population: 308,745,538 Located in United States Located in Rocky Mountains 24
    25. 25. Semantic AnnotationsRegular wiki Semantic wikiBoulder is the [[county seat]] and most Boulder is the [[county seat]] and mostpopulous city of [[Boulder County, populous city of [[County seat of::BoulderColorado|Boulder County]] and the 11th most County, Colorado|Boulder County]] and thepopulous 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 thefoothills 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 estimatesthat in 2008 the population of the city of that in 2008 the population of the city ofBoulder was 94,268. Boulder was [[Population::94,268]]. 25
    26. 26. Semantic properties of “Boulder, Colorado” 26
    27. 27. Examples of knowledge that may be derived fromwithin 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. 28. Semantic Wiki forArchitectural Knowledge 28
    29. 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. 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. 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. 32. Renovating your house, before Oct. 2010 Building permit Tree felling permit Demolition permit 32
    33. 33. Renovating your house, since Oct. 2010 Environmental permit 33
    34. 34. Interacting with the e-government 34
    35. 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. 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. 37. Example architecture model:GEMMA Information architecture source: GEMMA 37
    38. 38. Principle (Wiki page) 38
    39. 39. Example query answered by the wiki:Case management motivation and implications 39
    40. 40. ArchiMate model element (Wiki page) 40
    41. 41. ArchiMate: Overview Represen - Business BusinessBusiness tation service collaboration Business Event interaction Business Business Business Business object process role actor ApplicationApplication Application service interface Data Application Application object function component Infrastructure InfrastructureTechnology service interface System Artifact Device Network software Passive structure Behaviour Active structure 41
    42. 42. An ArchiMate modelsource: Lankhorst et al., ArchiMate Language Primer 42
    43. 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. 44. Facts and relationships in GEMMA:Principles, motivation and implication 44
    45. 45. Facts and relationships in ROSA:Education Chain Processes as ArchiMate Wiki Pages 45
    46. 46. Textual information(combined with structured semantics) 46
    47. 47. Image: ArchiXL IT Reference architecture 47
    48. 48. Dynamic overviews 48
    49. 49. Dynamic overview: table 49
    50. 50. Dynamic overview: relation table 50
    51. 51. Dynamic overview: graph 51
    52. 52. Interactive selections 52
    53. 53. Semantic search 53
    54. 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. 55. Input forms 55
    56. 56. Special forms 56
    57. 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. 58. Approved Revisions 58
    59. 59. Per-page Revisions with Approved Revisionsextension 59
    60. 60. Approved Revisions 60
    61. 61. Comparison of approved and latest version 61
    62. 62. Setting up and maintaining the wiki‟sarchitectural knowledge model 62
    63. 63. Step 1: Knowledge model - Determine what to register 63
    64. 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. 65. Principles (TOGAF) 65
    66. 66. Principles as a form of (architectural) statements in thesemantic 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. 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. 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. 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. 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. 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. 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. 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. 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 pagePage “Case handling” Template:ArchiMate_concept 75
    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. 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_conceptPage “Case handling” 77
    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_conceptPage “Case handling” 78
    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. 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. 80. SMW Query: Table{{#ask: [[Specializes::User interaction]] |mainlabel=Service |?Description |format=table}} 82
    81. 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. 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. 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. 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. 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. 86. Dedicated Inference: ROSA PSA (Project Start Architecture) Generator SectorChain process Architecture Layer(s) 88
    87. 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. 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. 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. 90. Reusing Architectural Knowledge: A System of Wikis 92
    91. 91. Architectural knowledge in a system of Semantic Wikis Generic Semantic Wiki InterWiki linksSemantic Wiki Semantic Wiki Semantic Wiki Organisation Organisation Organisation X Y Z Export Export Export 93
    92. 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. 93. Import final implications of “Case management” from GEMMA Municipality Wiki (organisation- “Case specific)management” 95
    94. 94. Implications of „case management‟ Municipality Wiki “Casemanagement” (organisation- specific) Case management? GEMMA Wiki (generic) 96
    95. 95. MunicipalityImplications of Wiki “Case (organisation-Management” specific) 97
    96. 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. 97. Local decisions about generic GEMMA principles 99
    98. 98. Reusing Architectural Knowledge (II) An Architectural Knowledge Portal 100
    99. 99. Disseminate and enrich existing models Architecture diagrams (HTML) Semantic Architecture Modeling CMDB Wiki tool XLS Architecture models (CSV) 101
    100. 100. Enrich existing models in the architecture wiki 102
    101. 101. Reusing architecture diagrams from other tools MarkupPage as for theshown in page the wiki 103
    102. 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

    ×