Question on using Application System object for modelling project architecture

[BenAvdicevic]

Hello,

I am trying to understand best way to model a typical scenario for our solution architects in our enterprise.

Issue description

==============

Imagine a solution architect representing the Personal Banking segment (yellow color) below.   They have a new project and need to setup 4 new data flows for a busines app Application ABC.

This is a HOPEX scetch showing the overview of the project's target state application arhictecture.

NOTE: all objects show are the Application object in HOPEX.

Modelling question

===============

Which HOPEX diagram is most appropriate to show the project overviw diagram?

Desicion process (the way I understand it):

• Application  - Scenario of Application flows OR Structure diagrams 
  • Not appropriate because the flows are external to the Applicaiton ABC
• Application Environment  - Scenario of Environment Flows or Environment Structure diagrams
  • Not appropriate because environment diagram are only supposed to show flows/interactions between subject application and the parter application/system.
    • Application BBB flow to Application ZZZ doesn't belong on applicaiton environment diagram
• Application System Scenario of flows or even Applicaiton System Structure?
  • Could work
  • Application system scenario of flows or strcuture could show a landscape of applications
  • But - then I have to ask the question - what is my application system??
    • According to HOPEX documenation, Applicaiton Systems are supposed to group applications fulfill a simlar function.
    • But, in below example, creating an applicaiton system for this grouping of applicaitons doesn't make sense.

Hence, my issue.  I know I can create such landscape of applicaitons viewpoint by using HOPEX Applicaiton System as a starting object.  But, creating an applicaiton system for this group of applications doesn't make sense).   

I suppose, I could create an application system for sole purpose of this project and which would not be reused anywhere else. But that approach seems wrong.

Appreciate any advice on how to think about this in terms of HOPEX

Ben

[BenAvdicevic]

Any thoughts or suggestions on the above question?

[DaveM]

You could in theory use the Exploded Diagram report to show one diagram inside the other? not sure if that still works..

[TDucher]

Hello Ben,

If what you need is to have a "temporary" Diagram describing a landscape showing the scope of a project in terms of applications & applications interactions impacts, that's what we needed some years ago with a previous version of HOPEX and we did not find how to manage that with standard behaviors so we created a new type of Diagram named something like "Project scope" and we use this Diagram to show project's applications landscape and sometimes more by adding also processes,  Master data ... to give a big picture of the scope/impact of the project on our processes, applications, data ....

The Diagram has the project object as entry point which make it by essence a temporary Diagram.

Thierry.

[BenAvdicevic]

@TDucher Thanks for that idea.  That is very interesting.   Is that a regular "Project" object you used - or the "EA Project" object?    

Seems like an opportonity for MEGA to give us a more flexible diagram choice.  Similar to "Layered viewpoint" when modelling with Archimate.   Just to give us a full flexibility to create the view we need for a project.

In fact - I am debating if using Archimate is part of the answer for diagraming project architectures.   Drawing connections between applications in Archimate, lets me create the right "interactions" or "flows" in the EA repository (which is ultimately what I need ) - and I'm not constrained by needing a "starting object" for the diagram.

In any case. thanks for the suggestion - much appreciated.

Ben

[engeh]

how about application landscape diagram? There you don't have to start from a "starting object".

[BenAvdicevic]

@engeh Yes. a generic "Applicaiton Landscape" diagram would work.  

But, hopex doesn't have that type of diagram out-of-box.  That is the issue we're facing.

[TDucher · Accepted solution]

Hi @BenAvdicevic

We are using the EA project Object. We are in version V2 of HOPEX. Will migrate to the V5 this year.

There are also "Overviews" Diagrams capability in HOPEX.

Not sure if it is a full standard & recommended capability but maybe it could respond to your needs  ???

[PBessodes]

Hello,

Here are some tips and principles to help you :

• Environment object defines an integration context for an application and a scenario of flows represents all data flows involved for a specific event/use case/...
  So, a scenario of flows for an application environment is application centric but nothing prevents you from presenting flows between partners as long as they make sense for the scenario.
• Designing future state of architecture : depending on your method, you can create a new version of your application or keep current version and create a new environment ("future one"). Then you can create a new scenario of flows.
• All new building blocks related to future state should be owned by en "EA project" (yes, it can be a container also, for this purpose) until they go live or project is aborted.

I hope it helps.

Patrick.

[BenAvdicevic · Accepted solution]

Thanks everyone for feedbacks.

This question  of "how to model project overviews (i.e. application landscapes)" is becoming more and more relevant for us as we plan to onboard our solution architects.

Given the lack of a generic "application landscape" diagram type out-of-box in HOPEX, we are going with the approach to re-use the Application System object for projects.

For example,

• For each new project - create a new Application System and give it a name "Project XYZ Application Landscape (AS-IS State)"
  • Add all the business applications which are impacted by the project into this landscape
  • Create either scenario of flows or Structure diagram (whichever the architect preferrs). 
  • Reuse (existing repository) connections betwen applications in the diagram (i.e. flows, or interactions).  If needed, create new connections to capture current-state
  • Once current state diagram(s) are created for the project landscape, duplicate the project application system object
    • For example, name the duplicate object "Project XYZ Application Landscape (TO-BE) (duplicate)"
  • Create the project-end state diagrams in the duplicated object by adding (or removing) new connecitons or components to the landscape

To distinguisih between the real Application Systems and project related systems - we might create a library called "Project Landscapes" and put these typs of objects in that library.

Lastly,

@TDucher  did mention using the "overview" type diagrams for the EA project object.  Initially, this seemed like a great solution.

After reviewing the documentation for the HOPEX V5, I was only able to find this page - which looked promising:

https://doc.mega.com/hopex-v5-en/#page/ARC/Premiers_pas.Creating_an__22Overview_of_Applications_22_D...

However, this seems outdated informaiton - as I can not create such diagrams in our SaaS deployment of V5.  Maybe it is a metamodel configuration thing - but that is not clear from documentation.  

So, we will proceed with re-using the "Applicaiton System" object for purpose of creating the architecture project related diagrams.