Author Topic: EA Repository Structure  (Read 2422 times)

martinjsharp

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
EA Repository Structure
« on: August 15, 2024, 01:06:29 am »
I am sure there are as many ways to organise an Enterprise Architecture repository in Sparx as there are Sparx customers, but I would be keen to see some examples that organisations have found helpful and why.

We started with the TOGAF 10 Repository Structure but I am not sure this is really that practical with most elements and drawings end up in sub packages in the Architecture Landscape.

We were thinking of adding a top level Projects package in which all elements, be they proposed changes to current state, or an interim state or a final state would be created. Once deployed, they would be moved into the Architecture Landscape and the earlier states removed.

Just wondering what is considered best practice in Sparx

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: EA Repository Structure
« Reply #1 on: August 15, 2024, 02:55:42 am »
Honestly you can't have a general answer. Each application is different as each EA usage domain is different. It's a main part of an EA consultant to figure out the most appropritw configuration. A task that can easily take many weeks and probably having a need to change configuration during operation more than once.

q.

Modesto Vega

  • EA Practitioner
  • ***
  • Posts: 1088
  • Karma: +28/-8
    • View Profile
Re: EA Repository Structure
« Reply #2 on: August 16, 2024, 03:44:56 am »
The issue with most EA consultants is that they are not engaged and embedded into the organisation long enough to work around the nuances of specific organisations.

Our repository is more or less structured as follows:
1) we have only one root node
2) we have a view -i.e., package with root node as its parent for the following,
2.1) Each framework definition,
2.2) Each architecture development method,
2.3) Each enterprise architecture domain - e.g. data, application, and business
2.4) Each live system of interest, but not all
2.5) A generic programmes and projects view
3) At least one architecture domain, data, is further split into aspects, with each aspect being a proper package
4) Each live system is also split into aspects
5) Each in flight programme or project has a dedicated package under the package described in point 4, how these packages are split is another matter


Martin you can direct message me or email me about this is you wish.

martinjsharp

  • EA Novice
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
Re: EA Repository Structure
« Reply #3 on: August 20, 2024, 09:30:14 pm »
Thank you Modesto Vega,
I have messaged you but this is an interesting and helpful suggestion.