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
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
- 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)
- 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).
- 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).
- 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.
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.
- 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)
- 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)
- 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).
- 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.
- 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.