@SergeThorn great question!
There are several ways to think about this. First, there is a "modeling perspective". How would Solution Architects prefer to model HOPEX Platform? Which objects would be helpful in their diagrams? From this perspective, I find most architects would prefer to model HOPEX as an Application System - composed of many individual Applications. The Applications would represent different Product modules, such as APM, ITBM, ITA, BCM, ERLM etc.. This way, in the diagrams, they can show flows going directly to the "HOPEX Product" - rather, then showing flows into "HOPEX".
However, there is another perspective - Application Portfolio Management perspective. In general, HOPEX Platform is a managed as a single record in your Application Portfolio Catalog (TOGAF). For example, if you setup your Application Portfolios in HOPEX, then generally there should be only 1 record there for HOPEX platform and not multiple records for each HOPEX product. This makes sense because an Application in HOPEX is more like a Conceptual object, rather than Physical. Hence, it makes sense to map servcienow "Business Application" to HOPEX Application object. There is a single budget, single data classification, lifecycle, and risk profiles.
This way, internal "components" of HOPEX should be modeled as IT Services. For Solution Architects, this means they have to draw additional diagrams to show flows into these components.
To me - because HOPEX Application is more of a Conceptual object with a single budget, lifecycle, risk and data profiles - I think it makes more sense to model with an Application object - rather than Application System.
