Welcome to the Archimate Risk Extension

Welcome to the ARE project

Welcome to the webapplication of the project ARE. ARE is an abbreviation for Archimate Risk Extension. This application supports a model for doing Risk Analysis for various ICT governance subjects.

Modules

This application consists of the following modules:

• Architecture repository
• Registration module
• Checklist module
• Modelling environment
• Data exchange portal

Status

At the moment only the repository and registration module are implemented in the following technologies.
The architecture repository is a SQL server 2008 database.
The registration module is available as a Lightswitch application and as an ASP.Net Dynamic Data Module.

Introduction

Below you will find a number of walkthroughs describing how to use this webapplication

• Creating and modifying elements and their relationships
• Registration of stakeholders and their concerns
• Storing and retrieving architectural documents
• Creating checklists and assigning checklists to stakeholders
• Diagrams and other visual representations of the architecture
  • Risk evaluations
  • Matrices
  • Diagrams

Also available are the following webcasts and tutorials

• 
• Overview (in Dutch)

Creating and modifying elements and their relationships

Creating and modifying elements are the steps you have to take te create and maintain the architectural model. This model displays how the various elements are related to eacht other. Of course it is possible to make different diagrams of this architecture, for example a baseline and a target solution. Below you will find a description of these steps, hhen possible a direct link to the relevant pages is included

1. Create and modify architectural elements, give a logical name and description of the various elements. Extend this with the element type in archimate types and define the architectural location with the component description. All these actions can be done in the element form (Menu->Overview-Elements-Elements)
2. Create and modify architectural relationships, you can relate various architectural elements to each other describing the archimate relation type. These actions are done in the relationships form (Menu->Overview->Elements->Relationships).
3. Define architectural models, often an architectural description becomes complex. Furthermore you want to create different views on the architecture. With models and diagrams it is possible to create these views (Menu->Overview->Elements-Models).
4. For elements you can use a number of visual presentation techniques, for example the Element Risk diagram and the Element Element matrix. Diagrams are based on the Archimate notation and the ARE extension. Matrices are a tabular representation of the associations between architectural elements.

Registration of stakeholders and their concerns

In describing an ICT or enterprise architecture, the concerns and requirements of stakeholders are an important aspect of the target solution. Therefore these entities have to be registered and maintained in the architectural repository.

• Registration of stakeholders, you can describe the relevant stakeholders with this form (Menu->Overview->Stakeholders->Stakeholders)
• Describing concerns and requirements, these requirements highly influence the target architectural solution, for example the cost aspect or the non functional requirements of a technical implementation. Concerns and requirements are implemented in an extended form (Menu->Overview->Stakeholders->Concerns)
• Wizards for concerns and stakeholders, these elements have various relations with a number of architectural entities in the repository. Creating these relationships can be difficult and errorprone. Therefore a number of wizards are available like the Stakeholder wizard and the Concern wizard each guiding you through the relationship creation process with the other entities.
• For concerns and requirements you can use a number of visual presentation techniques, for example the Stakeholder Concern matrix, the Concern Document matrix and the Stakeholder Document matrix. Matrices are a tabular representation of the associations between architectural elements.

Storing and retrieving architectural documents

When you are describing the enterprise architecture of an organisation documents are a good source of information. Mostly there are already a lot of books, reports, overviews and other documents relevant for your architecture. During the architectural process this collection of documents will grow more and more. Keeping track of the relevant documents for the architecture can become cumbersome when a structure is lacking. In the ARE repository you can store some metadata of documents, associate them with other entities and offer your collegues a solution for retrieval of documents.

• Registration of documents, you can describe the relevant documents with this form (Menu->Overview->Stakeholders->Documents)
• Registration of diagrams, a distinction is made between diagrams and documents for retrieval reasons. You can describe the relevant diagrams with this form (Menu->Overview->Stakeholders->Diagrams)
• Wizards for documents, Uploading a document to the repository and create the associations with other entities in the repository is done by the Document upload wizard.
• Visual representation of documents is done with the Concern Document matrix

Creating checklists and assigning checklists to stakeholders

A new aspect in architectural repositories is the usage of checklists. Checklists give the architect the tools to quantify the concerns and requirements of stakeholders and interrelate these. In every organisation there are different concerns and requirements so it is necessary to create different checklists. In the ARE application it is possible to create or modify your own checklists.

1. Create and modify architectural checklists,  give a description of the checklist elements. This action can be done in the element form (Menu->Overview-Checklists-Checklists)
2. Create and modify questions, checklists are constructed from a number of questions. These questions quantify gthe concern or requirement of the stakeholder. This action can be done in the element form (Menu->Overview-Checklists-Questions)
3. Modifying responses and evaluations, checklists and questions are the templates for evaluations and responses. A checklist will be assigned to a stakeholder (via a concern). When the stakeholder fills in the checklist these elements are created. You have access to the data of these entities via (Menu->Overview->Checklists->Evaluations) and (Menu->Overview->Checklists->Responses).
4. Assistants and Wizards for checklists, the checklist assignment process is quite complex. Therefore a number of assistants and wizards are available.
   • The Checklist test and email wizard gives you the opportunity to test the checklist forms, furthermore it has a dialog for sending invitation emails to the stakeholders relevant for the selected checklist.
   • The evaluation assistant gives you direct access to the checklist questions, this is for indirect checklists
   • The checklist evaluation wizard creates relationships between checklists, stakeholders, concerns and elements.
5. For checklists and evaluations you can use a visual presentation techniques, for example the Element Risk diagram. Diagrams are based on the Archimate notation and the ARE extension.

Introduction

Welcome to the prototype of the ARE webaaplication. The abbreviation ARE stands for Archimate Risk Extension. It is a project where a prototype is introduced to manage risks in ICT architecture. Implemented as an extension of the ArchiMate modeling language. The final product consists of the following:

• a prototype of an architecture repository with a risk assessment module.
• ArchiMate modelling environment
• Stakeholder and concern registration
• a number of articles and white papers on this extension in ArchiMate
• some sample checklists 

Webapplication

Part of the project is implementation of a webaplication. This application prototype makes the proposed architecture development process transparent. The implementation is based on a proototype as final product. This means that we compromise on the layout and presentation, but not on the functionality. In the figure below an idea of ​​the application design.

Idea is to model an architecture, a repository and to develop an application that the above inventory can be done. Below an overview of the components:

• Architecture element Module
• Checklist registration
• Archimate modelling environment
• Exchange portal
• Architecture repository

Stakeholder involvement

Involving stakeholders in the architecture development process is not new, especially prospective users and management are in the spotlight. You often see, however, that the system operators of the current applications and infrastructure are involved at a late stage in the development process. That's a shame often system operators know very well what the problems are in an organization because they are the first to receive questions and comments about the ICT landscape. On the other hand, they are also well aware of the IT management problems that exist. An important source of information when you search for a different (and optimal) design.

Evaluating risks

Finding an adequate way to evaluate in terms of system operation and implementation risks is the identification of governance risks in consultation of the system operators. The ARE webapplication will provide the opportunity to register architecture design, checklists, and evaluating these checklists by system operators. In addition, the repository is extensible for new checklists and questionnaires.