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

[PBessodes]

Hello,

The best/recommended solution to manage application version depends on the added value/cost ratio. You may define a method for strategic/complex applications and a more simple approach for minor applications.

The complete/consistent way to do this is to manage every piece of software as a building block (BB) that can be used to create another building block of higher level.
For example, an application is composed of internal modules (IT Services) or external/shared services (microservices).

Each BB version is a BB itself, allowing to manage catalog of available components to build more complex artefact (designing a new version of BB doesn't mean it replaces older one eveywhere, everytime etc. ).
For example, an IT service can evolve to be integrated in a new application although current version still exists in some other remaining applications.

This way of managing version/evolution of BB apply to each level. You design an application system (As-Is or To Be) by selecting version of applications or microservices to assemble and data flows/API call that are needed/planned to make them cooperate (in this assembly) and work properly. Same thing at application level where you select versions of internal module or microservice to design a new version.

The simplest way to manage As-Is/To Be (for simple or non strategic applications for example) is to maintain architecture description of As-Is only. You can prepare description switch  (when new version go live) by identifying and defining new version as new BB and replace old BB by new one wherever it is required.
Note : this process is manual today but will be assisted with automation in future Hopex version.

[BenAvdicevic]

@PBessodes 

Can you expand on this:

Keep in mind that using environment to model As Is/To Be situations of an application is only a shortcut. It is relevant only if you don't want to handle version of application in your repository because you want to handle only As Is view of your architecture ("what is running") but wants to prepare evolutions in a light way.

What is the proper/recommended way to describe application version or (future state) in HOPEX? 

[PBessodes]

Hello,

You're right : if you use "Application Environment Graph", you won't be able to distinguish between environment contents.

But you can use "Graph of Interactions of an agent", which allows to filter report content by selecting environments (or upper application systems if you use them).

Keep in mind that using environment to model As Is/To Be situations of an application is only a shortcut. It is relevant only if you don't want to handle version of application in your repository because you want to handle only As Is view of your architecture ("what is running") but wants to prepare evolutions in a light way.

[BenAvdicevic]

@PBessodes 

Thanks again for this reply. It is quite helpful to see someone else's perspective.

I have a question on your recommendation of using a new environment ("future one") to design future state.

But - if you create new environment - and add future-state connections to the application, wouldn't that mess up your reporting ?

For example,  if you:

1. Open properties of an Application
2. Open the Reporting Tab
3. Create an Application Environment Graph

Hopex would create a graph which includes all known connections to that objects - including the connections from the "future-state environment",    

Which is not what we want for this report;  it should only show existing connection in current state.

To avoid this, we are learning to model future-state with "duplicate objects" which represent future state of an object we're interested in.  

Versioning would probably work for this purpose also - but for now, we're focused on showing future states with duplicate objects.

Regards,

Ben

[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.

[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.

[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  ???

[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.

[engeh]

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

[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