UK (London) Enterprise Architect User Group Conference

[YogaMatt]

I'd like to thank very much, everyone involved in making the conference the gem it was: the organisers, the sponsors, the presenters, the delegates and the venue. I had a brilliant time and had plenty of very useful take-home messages.

[johnks]

Seconded!

[philchudley]

As of the organisers and also one of the presenters, I really appreciate your comments.

Many thanks for posting your feedback
 

All the best

Phil

[Ian Mitchell]

The results of the 'Wish List' workshop can now be found at http://www.eausergroup.com/blog
Interesting reading....

[YogaMatt]

Great!

Most are self-explanatory, although I'd like to expand on the "Roadmap as a process (As an artifact)" piece: I think the idea here is that we'd not only like to have clear visibility of the roadmap, but also have the user group feed into the process of determining the roadmap in a more formal way. I-Logix for Rhapsody used to have an Executive User Group that were trusted to feed into the roadmap. Could Sparx do something similar.

Also, come somebody expand on the "Security of Views" piece?

Cheers

Matthew

[johnks]

Hi YogaMatt

IIRC "Security of Views" was a consolidation of a few people's views on a similar topic. Namely being able to have more fine grain control over what people could see/do when they have access to a shared repository.

In my particular case I wanted to control which users can see what content. We are using a single sql server database to host a shared model of the IT estate (applications/interfaces/operations). Individual Projects get their own package and create their own project deliverables (integration models using sequence diagrams) re-using the shared model elements (as instances) and calling out the changes they want to make to them in order to deliver their project solutions. We have over 40 projects running concurrently in the same repository - it generally works well. However, in some cases the project is subject to some kind of non-disclosure agreement and we therefore don't want the content visible to users outside the project team, not until deployment anyway (although we do want the project team to see the rest of the repository). In other cases, the user may only be allowed to see their own project contents (e.g. we sometimes enrol 3rd party suppliers onto a project and we don't want them to see all our other work). There are other scenarios.

So my high level requirement was to be able to restrict visibility of the repository content in some way to certain users/groups of users. In this way I can really go for a single shared model repository supporting multiple IT projects. I don't want to solve it by creating multiple .eaps or databases etc. That's not our favoured approach to model management.

Does that make sense?

[YogaMatt]

Thanks John. Yes it makes sense and a set of requirements can be conceived. I'm on-board!