I am trying to understand best way to model a typical scenario for our solution architects in our enterprise.
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.
Which HOPEX diagram is most appropriate to show the project overviw diagram?
Desicion process (the way I understand it):
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
Solved! Go to Solution.
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.
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:
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.
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.
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.
@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:
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.
Here are some tips and principles to help you :
I hope it helps.
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 ???
@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 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.
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.