[Feature request?] External database + sectorization

[Nicolas]

Hi,

I'm currently testing Archi for my company and setting up a workflow to map and maintain our organizational structure.

In brief:
Is there a way to refer to or use an external database instead of importing CSV files? Additionally, is there a way to create "contexts" for specific views, links, and properties?

In detail:
Let's say my company uses three software applications (S1, S2, S3) and operates in two countries (CountryA and CountryB).

In CountryA, S1 and S2 are used, and these two software applications communicate via API. In CountryB, S1 and S3 are used, and they communicate via CSV.

In reality, we have more countries, software applications, and communication methods.

I want to avoid the complexity of mapping software communications while still maintaining a global view and local views. Additionally, I need to manage multiple areas where people can modify the Archi file.

My idea is to define certain "constants" that rarely change, such as the definitions of software applications, countries, and main types of communication. Each country could then have its own "part/context" of the software where they can implement and extend these definitions.

Thanks in advance.

[Phil Beauvoir]

Is there a way to refer to or use an external database instead of importing CSV files? Additionally, is there a way to create "contexts" for specific views, links, and properties?

Archi doesn't ship with a database connector (although Herve Jouin has developed a third-party database plug-in). As for your idea of "contexts" I don't know exactly what you mean, but the short answer is no if that involves setting up some kind of multi-user rules and permissions. If this type of feature is part of your company's requirements you might want to look at a different (paid) solution.

[Nicolas]

Thank you for the plugin.

Regarding the "context," I'm not specifically referring to permissions. Instead, I mean the ability to define a context (such as a specific geographic area or a particular team) where a process might differ from the theoretical ideal workflow.

For example:
In theory, when you visit a restaurant, you are greeted by a waiter who shows you to your table. However, in one of our company's restaurants, there is an automatic table assignment process. The overall workflow remains similar (a customer enters the restaurant, is assigned a table, and begins ordering), but this particular restaurant's approach differs slightly from the standard procedure.

When modeling the workflows of our restaurants, I would like to focus on a specific restaurant and study it within its unique context. Any changes made to this restaurant's workflow should not affect how other restaurants are modeled.

Additionally, if I add a new feature to this restaurant, such as a click-and-collect interface, which other restaurants do not have, I still want it to be recognized as a restaurant. However, in the context of this specific location, the restaurant operates differently.

[Jean-Baptiste Sarrodie]

Hi,

I think there are some complementary approaches to solve this:
- You can define a generic process/application, and (when needed) create local processes/applications that specializes (that's a relation in ArchiMate) the generic ones. Using your restaurant example, "Assign table to customer" would be the generic process, and "Automatic table assignment" would be a local one which specializes "Assign table to customer".
- To keep track of the context in which a specialization makes sense, you can use a property (for example named "Context"). This makes it possible to filter specialization relationships based on your criteria.
- If your context is geographical, you can create a location per context and have it aggregates all related processes/applications. If your context is not geographical, you can use groupings.

Regards,

JB

[Nicolas]

Thanks for the answer, its basically all I needed to know !

Do you think we could have some automation for context ? Like when working on a view, we would be able to define the view as having a global set of properties that will applies to all element added to this view. It would make easier creating some context and preventing people forgetting to add this property.

[Phil Beauvoir]

Do you think we could have some automation for context ? Like when working on a view, we would be able to define the view as having a global set of properties that will applies to all element added to this view. It would make easier creating some context and preventing people forgetting to add this property.

Feature requests can be opened on GitHub but it's unlikely that I'll find time to assess this one right now. As Archi is open source you (or your company) could provide, if you wish, an implementation either by a pull request, or extending via a plug-in, or perhaps using jArchi, the scripting plug-in.

[Jean-Baptiste Sarrodie]

Hi,

Do you think we could have some automation for context ? Like when working on a view, we would be able to define the view as having a global set of properties that will applies to all element added to this view. It would make easier creating some context and preventing people forgetting to add this property.

There won't be such feature built into Archi anytime soon (read: never), unless you contribute some code ;-)

But that's something you can do with some jArchi script. The real question for you is: What's your end goal? If you only need to be able to export some information based on these contexts, then a script is enough. But if your need people to be able to see these properties as real properties in Archi, you'll have to make sure people run a script to update them each time they do some changes, but people often tend to forget to run such scripts.

As an example:

I use a single model containing both my current-state and future-state architectures. This model also contains project architecture which has not been validated yet (so neither current-state nor future-state). Based on this, I sometime have to extract some catalogs containing the list of applications, data or flows. When creating such extracts, I have to be able to filter based on either current or future state.

To do this, I've set some properties (I tend to call them "Plateau") on folders (the ones containing views). If a folder (and its sub-folders) contains views related to current-state, then the folder has a property "Plateau" set to "current-state". If a folder (and its sub-folders) contains views related to future-state, then the folder has a property "Plateau" set to "future-state". (and its sub-folders) contains views related to some projects, then the folder has a property "Plateau" set to "project".

Thanks to these properties, I can easily create jArchi script to export my catalogs and filter objects:
- all elements and relationships appearing in views contained (directly or though some sub-folders) in a folder having "Plateau=current-state" are concepts that exist today.
- elements and relationships appearing ONLY in views contained (directly or though some sub-folders) in a folder having "Plateau=future-state" are concepts that don't exist today but will in the future.
- ...

Regards,

JB

[Nicolas]

Thank you for the responses.

The primary goal is to model complex and large architectures without creating overly complicated views, while also being able to automatically generate and update these views.

For context, I am trying to develop a workflow to map (or create a cartography of) software applications, workflows, interfaces, and more within my company. Initially, this would involve regularly importing CSV files exported from a large Excel spreadsheet that lists all software applications and interfaces. The idea is to generate new views or update existing ones to illustrate how different software applications are connected.

However, I need to consider various "dimensions" for these connections. The first dimension is geographic location, allowing each location's manager to see the complexity of their software system. Another dimension would show where a specific software application is used and what it is connected to in each location. This way, if there is an issue with a software application, we can easily identify similar situations across all locations and assess the current state of any given location. (I have intentionally simplified this explanation, but it is already quite complex.)

In a second phase, I would like to eliminate the Excel import part and use only Archi, making it easier to maintain. I understand that the collaboration feature is not currently viable for large instances, but it could be an option in the future.

In short, the basic idea is to automate the workflows for mapping various elements within the company and maintain this information in a database. This would make it easier to find information, generate views, and perform similar tasks. When you only have drawings without any underlying data, it becomes difficult to maintain them.