You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The platform will be managed at the application entity level, we do not create a dedicated entity. (The platform is a subtype of an application because it is itself an application)
A platform is identified by the fact that it hosts other applications (we will call them components). We were not far off with our components 😊
Architecture type is created with the values: Platform host / Platform application / Micro Service
An application has only one and only one architecture type value.
A platform like T24 or Salesforce or Outsystem hosts platform applications.
These platforms (T24) will have the Architecture Type field set to: Platform host.
Applications hosted on platforms (T24) will be application components with the Architecture type field with a value: platform application
So no Architecture type = platform application value possible on anything other than a component.
Category loses its meaning for me and we reuse it to put the BIL nomenclature: Business platform / Technology platform etc.
The text was updated successfully, but these errors were encountered:
I could have designed the applications and components as in ArchiMate: there are no applications, just components nested within each other.
This gives complete freedom.
However, I chose an opinionated model to enforce governance in the tool:
There are indeed applications
and components that are not applications, but pieces of an application.
This is why, for example, a capability cannot be mapped to a component but only to an application.
This is also why, in a landscape, you can choose not to display the components, only applications
This means that if nothing is changed in the application, and your proposed solution is applied, you will be able to map capabilities to a platform but not to a component of that platform....
So, no capabilities on an "application" (or "component") developed in a low-code platform or in Salesforce.
I feel like this is not okay @Laetkipull your opinion ?
Ok understood.
I focused on application and forgot all the entities linked to it.
so what about changing application and like capabilities having applications linked to applications. We don’t change components. If this is possible tell me and I will deep dive to get back with restriction and lifecycle management
The platform will be managed at the application entity level, we do not create a dedicated entity. (The platform is a subtype of an application because it is itself an application)
A platform is identified by the fact that it hosts other applications (we will call them components). We were not far off with our components 😊
Architecture type is created with the values: Platform host / Platform application / Micro Service
An application has only one and only one architecture type value.
A platform like T24 or Salesforce or Outsystem hosts platform applications.
These platforms (T24) will have the Architecture Type field set to: Platform host.
Applications hosted on platforms (T24) will be application components with the Architecture type field with a value: platform application
So no Architecture type = platform application value possible on anything other than a component.
Category loses its meaning for me and we reuse it to put the BIL nomenclature: Business platform / Technology platform etc.
The text was updated successfully, but these errors were encountered: