Some features not visible in V5 anymore

[hsoegaard]

We have noticed that some features are not available anymore, in a standard installation, due to the change from private workspace to public workspace.

1. Collaborative workspaces are not visible anymore, which means that working on changes over longer period is not possible. If changes are to be done in a public workspace always, thid can be problematic if we are publishing web sites during this period.
2. Design Tasks are not visible anymore. In environments where we have requirements for traceability on changes this is not possible anymore.

I know we can change the meta-model where we change the WET back to private but, is that the recommended approach if a customer has the needs to manage their changes in collaborative workspaces, design tasks etc.?

[cnisparnorddk]

This thread is still very relavant

[hsoegaard]

Yes, its very easy to change. It is just a check mark that needs to be changed.

[Valentino]

BTW, where in the metamodel can you change it back to private? 

Very useful for a dev environment if you're testing automation/import or other macro stuff to be able to discard the changes.

[TDucher]

Having used in the past Mega/Hopex implementations with several repositories and transfer of objects from one to another, I confirm that it is a robust solution but also add a certain level of administration additional workload and complexity mainly due to the difficulty to transfer complex "High level" objects with multiple children's and links like application for example.

[hsoegaard]

Hi, Yes this is also an approach, and an approach that was used in the past. But in my experience, it creates an enormeous task of maintaining the artifacts that needs to be transferred. Even with with the ability to move content from one repository to another automatically using Transfers, you still must validate artifacts, make sure they are locked (including all sub-components) - and keep them locked untill the transfer, otherwise the transfer from the design repository to the publishing repository will fail. This means you will now also have to run the Validation workflow on objects to get them locked, or at least build in the locking mechanism in the workflows you use for the different artififacts (which is the methid we prefer). Checking artifacts out in a collaborative workspace simplies this task and is much easier for the users to understand. Keeping everything in one repository makes life so much easier 😀

[BenAvdicevic]

Hello @hsoegaard , @oguimard 
Our organization is new to Hopex and we're finding this change "interesting" and are discussing how to adapt.  Our pre-sales discussions were done with version 4.

Regarding moving from Scenario 2 to a more governed architecture model  - maybe a best practice with HOPEX is to create a "Published" repository along side the "work-in-progress" repository.   Then, only those building blocks (artifacts) which have passed governance are moved from the "working copy" repository to the "Published" repository. I realize this probably adds a layer of complexity to a HOPEX deployment and management of the platform.

Just a thought.  We seem to be leaning to that model.  Important note - we are just starting to adopt HOPEX V5 - so we don't have architects who are used to workspace features in previous versions.

[hsoegaard]

Hi,

Even if you are in scenario 2, that dosnt mean you can completely abondon Governance. Scenario 1 is also vey much about being in control of your work.Therefore you would still need the Request For Changes with the Design Tasks to track what you have changed.

We also see users starting out with scenario 2 when they start using HOPEX (it is a more simple approach). However, later when their models needs to come under a Governance regime, they need to be able to switch to scenario 1.

As of V5, this can only be accomplished with a change of the meta-model (although it is avery simple change with check mark that needs to be changed).

[oguimard]

Hello,

There are 2 approach to modeling.

1. You want to work for a while before you share your work
2. You want to share immediately your work with anyone.

The trend that we see is that more and more users prefers to share immediately the work.

• The point (1) correspond to private workspace (or also called long term transaction)
• The point (2) correspond to public workspace (or also called short term transaction)

Having a "collaborative workspace" make sense in scenario one (1). In that scenario you may want to be several to work on a long time on element before to share them.

In the second scenario (2) ,  you share everything immediately; so everyone can work with you, there is no need to create a "collaborative workspace".

Because of this new trend, the default behavior in V5 is to promote public workspace. Therefore this feature of collaborative workspace is not available as it doesn't make sense.

You seems to be in the situation were your customer is in scenario one (1). You then don't have a choice than to edit the default configuration.

The same thinking apply for design task.

[png]

Hi,

Do you have the answers that you needed for the missing features in V5 or still waiting for someone to reply?

Feel free to submit separate Support cases for all your questions. Someone in Support Team will be able to assist you.

Thanks,

Philip