Roadmap for Archi 2.8

Update (2014/10/08):

• Archi moved from 2.7.1 to 3.0 (justified by the migration to eclipse 4)
• Most features included in Archi 3 (main exception "Viewpoint based filter", still in development)

---

Code name: First ArchiMate journey

This page aims at describing Archi 2.8 features and enhancements. In an attempt to provide clear guidance for development, a "story" has been defined to help focus on features or use cases in a coordinated manner.

The story

The choosen story is the first ArchiMate journey of an EA practitioner. Thus we will try to focus on typical use cases followed when one starts building models using ArchiMate:

• Collect material from several sources (CMDB, misc. referentials...).
• Import this material in Archi -> this leads us to the import/export request (what format...).
• Explore the model through the visualizer.
• Create a few first "high level" views: when starting, there's much chances that ArchiMate is not well known -> this leads us to the teaching/learning part of Archi (included ArchiMate specs, feature request around magic connector...).
• Export these views to share them with stakeholders -> This leads us to the reporting features.

You'll note that repository features are not (yet) needed at this stage because a "beginner" will not be at the maturity level which requires this kind of features. When climbing the ladder of maturity level, some more specific workflows or use-cases will appear (collaborative work, scripting engine...) but that's for another release.

The requirements

Starting with these use cases, we can then try to figure how to improve Archi to best cover these needs. Here is a feature list comming in mind:

• Simple, text based (CSV), export import capability.
• Viewpoint based filter.
• Documentation enhancements.
• Enhance the magic connector to show all possible relations based on 2 elements independently of which one is the source and which one is the target.
• Reporting feature: to be honest I think it should be fully rewritten, but at least we could better document how to customize a report, how to build one from scratch... We could also add more report templates to cover matrices and catalogs (which are both popular requests). Last, the jasperreport lib included is really old and should be updated (today one has to use the old 4.5.1 version of iReport to work with Archi).

CSV export / import

See this issue for even more details

After reflection, it has been decided that this feature plugin should create/read 3 files to cover all needs:

• Elements with following attributes
  • Element ID
  • Name
  • Type (Actor, Application Component...)
  • Documentation (newline have to be managed in a way or another)
• Relations with following attributes
  • Relation ID
  • Name
  • Type (assignment, used by...)
  • Source element ID
  • Target element ID
  • Documentation (newline have to be managed in a way or another)
• Properties with following attributes
  • Element or relation ID
  • Property Name
  • Property Value

Remarks:

• Of course, one assumption here is that we export/import only model, not views.
• We should follow some standard like this one
• Files should include headers
• IDs should be kept in model file so we have to define some basic rules to follow (e.g. accepts letters and numbers only without spaces). It should be easy to create them in tools like spreadsheets using formula (e.g. append Type to Name and remove spaces)
• Fields have to be delimited with double-quote and potential double-quotes in field content have to replaced by a pair of double-quotes. This should be enough to protect newlines in Description fields, but I suppose we should include and option to remove or convert them so tools not accepting newlines even if double-quoted should work.
• There's a known issue with some software which always remove leading zeros. An option should allow to use known the workaround.
• The model itself should be seen as an element whose Type is ArchimateModel, so that we can export/import its description and properties.
• Even if this makes it no more real CSV, being able to define another field separator should be great (e.g. in French localized Excel, CSV uses semicolon)

Export should create 3 files in a folder with an option to add a suffix in order to easily group multiple export of different model in the same folder. Import should either ask explicitly for each file or ask for one of them (e.g. "elements") and assume filenames to be (eg.) elements.csv, relations.csv, properties.csv

We should also have an option to import into an already existing model so that elements that exist are updated and new ones added. Here is a typical workflow:

• Open an already existing model
• Export it to CSV files
• Edit some files with a spreadsheet to add elements, properties...
• Import the CSV into the model and choose to ignore warnings about already existing elements/properties
• New elements/properties are added to the model.

This raise some questions about properties update as there are no id associated and multiple keys are allowed. The best solution/workaround is to create a new property only if it does not exist, and update the first match in all other cases. That's the best we can do and is more aligned with what a user expect from an update feature.

Enhanced Visualizer with viewpoint based filter

See this issue for even more details

On big models, the Visualizer output quickly gets clutter. Been able to apply dynamic viewpoint would allow to focus on context dependent needs. ArchiMate viewpoints are the obvious choice, but we should add an option to navigate through incoming or outgoing relationships only. This would turn visualizer in a potential impact analysis tool.