Describing an IT Service with HOPEX IT Architecture

[SergeThorn]

Dear all,

the standard definition is:

An IT service is a software component of an application, that can't be deployed alone and that realizes a sub-set of the functionalities of this application either for end users of this application or inside the application (or another application). This includes batch programs.

If I get right, the component should not be linked to several Applications, however nothing prevents me from adding the same IT Service to several applications.

Either the definition is wrong or there should be a control when adding an IT Service already attached to an Application! Something like “ IT Service can’t be added as already deployed with another application.”

Have I misunderstood?

Thanks for your comments.

Kind regards

[TDucher]

Thanks @BenAvdicevic for the clarifications.

Coherent with what we are doing so because the IT service is not owned by 2 different applications in fact but by 2 different versions of the same application (technically specking only it is owned by 2 Apps).

Have a nice day !

[PBessodes]

Yes. Exactly.

[BenAvdicevic · Accepted solution]

@TDucher The way I understood this  -  Same IT Service can be owned by multiple Application objects to support modelling that a duplicate of an Application (representing a new version) can be linked to the same IT Service.

Image this Example scenario.

1. Create Application called App-ABC
2. Create IT Service "Service-1"
   Now, Service-1 is component of App-ABC
   
   
3. Duplicate Application ABC to create a "Future State" Application object "App-ABC-1"
   During Duplication wizard - you have a choice to "Keep" or "Create New"  Service-1
   If you choose "Keep" - it will literally make the original IT Service object "Service-1" be a component of the duplicated application object
   
   
4. After duplication - you have 2 Application objects "App-ABC" and the duplicate "App-ABC-1", and each has the same IT Service "Service-1" as a component".
   
   

This is what I understood as the reason why MEGA's metamodel allows same IT service to be a component of more than one Application objects.

@PBessodes did I get that right?

[TDucher]

Sorry but not clear ?

[PBessodes · Accepted solution]

Hello,

This mechanism (allowing to link an IT Service to multiple applications) is there only to allow describing versions of application components (I agree it is a very ambitious objective). So you can link a single IT service to several applications (as versions) if this component doesn't change.

[TDucher]

Hello @BenAvdicevic 

Which links in the metamodel are you using to link applications to IT services.

For us it is working as expected but we are using the an old Method and Metamodel to manage Application architecture design.

We have 1 link which identify the owner application of the service and one another to model which applications are using the service (for services shared/exposed by an application and used by multiple other applications).

That is how we are modeling the "shared web services" for a while.

I image that you are using the latest version of the l don't know how you link the IT services to the Applications. 

[BenAvdicevic]

@PBessodes What is Mega's position on IT Service object?  

If it is a "component" of an Application object - why is it OK to link one IT service as a component of multiple Applications?  

[SergeThorn]

Thanks @BenAvdicevic for your thoughtful reply. For your understanding...that discussion has been a hot topic in my team for a while...😁. We created a type of applications named "Technical Applications" which are Applications being used by several Business Applications. For example an ETL application or an application with various web services/microservices accessing other Business Applications. People were challenging the fact of creating an intermediary application with let's say a series of shared IT Services. Some started to link the same IT Services to several Business Applications, which I believe is not correct.

I hope MEGA will fix this in the nearest future.

Kind regards

[BenAvdicevic · Accepted solution]

@SergeThorn 

You are 100% correct to raise this.

I think the definition of an IT Service is correct.  An IT Service is a "child" of an Application.   It is not something reusable, that can be a child of many applications.   

For example,  imagine an Application A has a "Log Extraction" IT Service.       Now imagine an architect for Application B wans to model a logical component for "Log Extraction"  for that Application.

I would think the model would be wrong if the architect "reuses" the existing Log Extraction IT service created for Application A.   Instead, I think they should create a new IT Service for Application B and also call it "Log Extraction".

There are other example where HOPEX doesn't enforce rules which follow from its documentation and training materials.

For example, based on documentation and training materials, an Application Environment should have only 1 Subject Application.   But HOPEX doesn't enforce this in any way, and architects are free to create an App. Env. diagram where every object is a "Subject" application.