Author Topic: Sparx Best Practices doc ?  (Read 380 times)

SJ

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Sparx Best Practices doc ?
« on: May 17, 2019, 01:11:42 am »
Dear All ,
For a user that had all the EA diagrams stored in MS Power Point and Spreadsheets and is moving to standardize on Sparx, is there a 'best practices' manual or document that I can refer to ? Mainly the first phase is to move all the diagrams to Sparx and draw a Sparx roadmap between Target and Baseline architecture. The objective is that we should be using Sparx for lifecycle, after moving on Sparx and not rely on Powerpoint and Excel Spreadsheets from now on.

Thanks in Advance
SJ

bknoth2

  • EA User
  • **
  • Posts: 99
  • Karma: +2/-0
    • View Profile
Re: Sparx Best Practices doc ?
« Reply #1 on: May 17, 2019, 02:03:05 am »
I've developed internal conventions for using EA to try to maintain some consistency in the model, mostly based on experience.

Be aware, which you may well be, that it's not so much "moving diagrams" from Viso to EA. In EA, you are developing a model and diagrams reflect the relationships in the model. If you have three Visio diagrams and each has a block representing a car, for example, and you simply redraw those three diagrams in EA you will end up with three "car" elements in the model. You want probably just want one "car" element and three diagrams that show different views of the relationships of the "car" element and other elements.

SJ

  • EA User
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: Sparx Best Practices doc ?
« Reply #2 on: May 17, 2019, 02:24:01 am »
Hi ,
Thanks for the response. Yes,  I understand what you mean. I have basically used one element that is being used across different Sparx representations (for example Baseline, Target and Roadmaps). This single element is linked to these 3 diagrams so that one change in element is reflected across 3 diagrams (in my example). Anything else that I should be worried about ? My end goal is to trash these Microsoft PPT and spreadsheet once and for all.

Thanks again
SJ

qwerty

  • EA Guru
  • *****
  • Posts: 10882
  • Karma: +248/-232
  • I'm no guru at all
    • View Profile
Re: Sparx Best Practices doc ?
« Reply #3 on: May 17, 2019, 07:32:57 am »
As bknoth2 said it's a matter of experience. It's a good idea to hire an experienced trainer/consultant to get you going at least the first steps. It's not an easy road and Sparx is doing their best to make it even harder with each version they release :-/

q.

Glassboy

  • EA Practitioner
  • ***
  • Posts: 1358
  • Karma: +109/-75
    • View Profile
Re: Sparx Best Practices doc ?
« Reply #4 on: May 17, 2019, 08:08:13 am »
Be aware, which you may well be, that it's not so much "moving diagrams" from Viso to EA. In EA, you are developing a model and diagrams reflect the relationships in the model. If you have three Visio diagrams and each has a block representing a car, for example, and you simply redraw those three diagrams in EA you will end up with three "car" elements in the model. You want probably just want one "car" element and three diagrams that show different views of the relationships of the "car" element and other elements.

The car you have now, and the car you imagine you'll have in the future are two different cars.  Or maybe three or four.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9833
  • Karma: +300/-30
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Sparx Best Practices doc ?
« Reply #5 on: May 17, 2019, 01:44:56 pm »
The thing is that modelling different "versions" of the same thing in a single repository is not a simple task.

For architectural model (in ArchiMate) we used plateaus, and tagged values with auto color legends to indicate which elements are new/changed/deleted in a certain plateau.
It is still a workaround, but it sort of did the job.

Trying to do so for a whole (functional and technical) model is madness.

A single EA repository can only keep a single version of the system. Usually this is a combined AS-IS/TO-BE model.
Keeping track of previous versions can be done with (a combination of)

- backups
- html exports
- generated documents

All these "freeze" the state of the model at a certain point in time.

Geert