Representing product + configuration = application

[Rick Walsh]

Hello everybody.

I have a product which when configured, at runtime, hosts and executes secured RESTful APIs.

So, product + config equals a new API which we deliver to the customer.

I want to represent in our model (using Enterprise Architect) a customers application built using this product and some config.

I've modelled our product already.

It is important to me that the view point representing the customers application shows the APIs that are produced so I can show how they are used in the wider landscape.

It is also important to me that this application is represented as a configured form of the product and shows the produced APIs.

 

This will enable me to interrogate the model and answer questions such as, which customers use this particular product and at which version etc.

 

So, in the diagram below I have the product a configuration artifact and the Customers Application (simple form).

I want a view point that can we show that product + config = customers application and meet my model interrogation requirements?

It feels like the configuration + the product "realises" the application.

Thanks!

[Mastering ArchiMate]

On 30 Nov 2017, at 12:53, Rick Walsh <rick....@gmail.com> wrote:

Hello everybody.

I have a product which when configured, at runtime, hosts and executes secured RESTful APIs.

So, product + config equals a new API which we deliver to the customer.

I want to represent in our model (using Enterprise Architect) a customers application built using this product and some config.

Just so that it is clear (as you do use the word ‘customer’ twice), you do not want the Customer Application to use the API but you want it to 

I've modelled our product already.

It is important to me that the view point representing the customers application shows the APIs that are produced so I can show how they are used in the wider landscape.

It is also important to me that this application is represented as a configured form of the product and shows the produced APIs.

 

This will enable me to interrogate the model and answer questions such as, which customers use this particular product and at which version etc.

 

So, in the diagram below I have the product a configuration artifact and the Customers Application (simple form).

I want a view point that can we show that product + config = customers application and meet my model interrogation requirements?

It feels like the configuration + the product "realises" the application.

It seems to me that the “Customer Application” is indeed Realized by the Customer Application configuration Artefact. 

The Product might be modeled as either System Software or Application Component and you can let it Realize a ‘runtime’ service that Serves the Customer Application. If you let the Product be System Software, the Artefact can be Assigned to it (deployed on it).

So,

configuration realises customer application

product realises or is assigned to ‘runtime’ service (or composes ‘runtime’ interface’ if you do not want to use behaviour)

runtime service (or runtime interface) Serves customer application

And if Product is System Software (which I prefer for a platform)

Product Assigned-To Artefacf

G

Thanks!

--
You received this message because you are subscribed to the Google Groups "ArchiMate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/a7f0373c-734d-438d-9e34-21bed5569a45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rick Walsh]

Something like this?

[Jean-Baptiste Sarrodie]

Hi,

Gerben's suggestion is to have your product as System Software, not in addition to a System Software:

Regards,

JB

[Mastering ArchiMate]

(Sorry JB, accidentally pressed send on a wrong message)

On 1 Dec 2017, at 20:15, Jean-Baptiste Sarrodie <jean-b...@sarrodie.org> wrote:

Hi,

Gerben's suggestion is to have your product as System Software, not in addition to a System Software:

Indeed, because that enables you to deploy the application configuration Artefact on it (and you cannot do that with an application-level element).

For your Admin API you could still use application-level elements as your Product is probably a "complex application stack" (see my book :-) ) combining platform (system software) and maintenance app (application component) in a set.

I also notice you’re still using ArchiMate 2 (or 1 even). ArchiMate 3 has more (and better) options than ArchiMate 2 (in general).

G

Regards,

JB

--
You received this message because you are subscribed to the Google Groups "ArchiMate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/777ad9a8-09b7-41f1-bd92-e0d6911ccdb7%40googlegroups.com.

[Rick Walsh]

Thanks for the help and I do have your book (although helpfully, its on my shelf at home rather than at work today!).

I'm using Archimate 2.0 - unfortunately the version choice is out of my hands!

Regarding your suggestion, please could you give an example of :

"your Admin API you could still use application-level elements as your Product is probably a "complex application stack" (see my book :-) ) combining platform (system software) and maintenance app (application component) in a set."

Specifically how do we relate application level elements and the system software. 

I hoping that this will allow me to understand how the 'product' is used when I using sparx tooling!

Thanks!

On Saturday, 2 December 2017 13:45:01 UTC, masteringarchimate wrote:

(Sorry JB, accidentally pressed send on a wrong message)

On 1 Dec 2017, at 20:15, Jean-Baptiste Sarrodie <jean-b...@sarrodie.org> wrote:

Hi,

Gerben's suggestion is to have your product as System Software, not in addition to a System Software:

Indeed, because that enables you to deploy the application configuration Artefact on it (and you cannot do that with an application-level element).

For your Admin API you could still use application-level elements as your Product is probably a "complex application stack" (see my book :-) ) combining platform (system software) and maintenance app (application component) in a set.

I also notice you’re still using ArchiMate 2 (or 1 even). ArchiMate 3 has more (and better) options than ArchiMate 2 (in general).

G

Regards,

JB

--
You received this message because you are subscribed to the Google Groups "ArchiMate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-forum+unsub...@googlegroups.com.

[Mastering ArchiMate]

I have little experience with Sparx other than that I have noticed that with Sparx you can connect anything with anything using any relation, so you can effectively already use ArchiMate 3 like constructs even if you use a ArchiMate 2 configuration.

I’m sorry, I have no time to write an extensive explanation today. Have a look at the book tonight on ‘platform’ and ‘complex application stack'

G

To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/b5146196-b456-41fd-a8cd-f55565d5a7c4%40googlegroups.com.

[Rick Walsh]

So, based upon your suggestions, I've got to this point.

Next :)

From an infrastructure perspective the platform actually is usually deployed over 2 nodes. These two nodes are configured very differently from a security perspective and the functional responsibility. Note however there is only one distribution - its assigned to 2 nodes!

Node 1 is a gateway - this hosts your applications APIs

Node 2 is a runtime - this executes the code behind your API.

How would you communicate the differences between each node? They both together realize the Platform Hosting Service?

G

[Rick Walsh]

Hey,

Ive recently revisited this area and I have a question about your excellent book. 

In the section 18.3 "A Completely alternative approach", in view 189 the application component C A&P Generic is assigned to the "Running Specific Modules". There is also an infrastructure service called "Execute C A&P". Im confused as to why both are needed? I was under the impression the application component was responsible for execution. Is the infrastructure service redundant?

Thanks 

On Monday, 4 December 2017 10:16:15 UTC, masteringarchimate wrote:

I have little experience with Sparx other than that I have noticed that with Sparx you can connect anything with anything using any relation, so you can effectively already use ArchiMate 3 like constructs even if you use a ArchiMate 2 configuration.

I’m sorry, I have no time to write an extensive explanation today. Have a look at the book tonight on ‘platform’ and ‘complex application stack'

G

[Mastering ArchiMate]

On 6 Apr 2020, at 13:17, Rick Walsh <rick....@gmail.com> wrote:

Hey,

Ive recently revisited this area and I have a question about your excellent book. 

In the section 18.3 "A Completely alternative approach", in view 189 the application component C A&P Generic is assigned to the "Running Specific Modules". There is also an infrastructure service called "Execute C A&P". Im confused as to why both are needed? I was under the impression the application component was responsible for execution. Is the infrastructure service redundant?

I notice you are still using Edition II (ArchiMate 2). For others: this is about Section 27.4 View 255 in the current ArchiMate 3.0.1 edition.

There still is infrastructure and that requires a service for the application layer elements to use. It might have been clearer if I had renamed that infra service to signal it does less than in the previous pattern.

Anyway, the application component is now indeed servicing the modules while before the infrastructure service was doing that. But that too requires some infrastructure services. One could say that the [server1] C A&P Execution (Infrastructure Service) of view 188 (254) has been split into [server1] C A&P Execution (Infrastructure Service) and [C A&P] Run Modules (Application Service) of view 189 (255). This is the consequence of [server1] C A&P Platform Part (System Software) having been remodeled as being now implicitly part of [C A&P] Generic (Application Component). You can conclude this from the fact that in the second pattern only one element is Realised by the single ‘distribution' Artifact. 

So, you are creating a different choice in the divide between what is infra and what is application. The text of the section explains that both are possible. You will always have both (depending of course on how fully you want to model it). So

1. ‘Rich' Infra service services behaviour of your module

2. ‘Poor' Infra service services an application service (the ‘richness' of the previous infra service) that services your module

Yours,

G

To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/d6e5d59d-a378-4854-8fb1-e556b2bd0b65%40googlegroups.com.

[Rick Walsh]

Thanks for the rapid and clear answer!

In my case my application (C A&P) Generic is doing all the heavy lifting and sits on top of IIS. From what you've said, am I right in thinking  the service (Execute C A&P) in my case is IIS's hosting capability?

Thanks!

On Monday, 6 April 2020 15:11:44 UTC+1, masteringarchimate wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/d6e5d59d-a378-4854-8fb1-e556b2bd0b65%40googlegroups.com.

[Mastering ArchiMate]

On 7 Apr 2020, at 10:08, Rick Walsh <rick....@gmail.com> wrote:

Thanks for the rapid and clear answer!

In my case my application (C A&P) Generic is doing all the heavy lifting and sits on top of IIS. From what you've said, am I right in thinking  the service (Execute C A&P) in my case is IIS's hosting capability?

Yep.

G

To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/7b371a8d-9778-40c6-ae34-f84805736af5%40googlegroups.com.

[Rick Walsh]

Quick question about your two diagrams (mentioned previously). In one diagram system software realises a service (Im assuming a derived relationship? In your other a node is assigned to a service. Why the difference?

Thanks again!

On Tuesday, 7 April 2020 10:13:18 UTC+1, masteringarchimate wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/7b371a8d-9778-40c6-ae34-f84805736af5%40googlegroups.com.

[Mastering ArchiMate]

They are both derived. 

Node/Device/SystemSoftware Assigned-To Infrastructure/Technology Function Realises Infrastructure/Technology Service results in a Realisation

Node/Device/SystemSoftware Composes Infrastructure/Technology Interface Assigned-To Infrastructure/Technology Service results in an Assignment

It’s somewhere else discussed in the book (don’t have time to look that up for you now)

Those both are technically OK, I think I should have kept them the same in both. I think the assignment is a mistake because it comes from the Device. If anything it should have come from the System Software. I need to fix this in a next release.

G

To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/77d8b57a-2f0e-4808-a2a2-fbce00d66e94%40googlegroups.com.