Author Topic: TOGAF and Model Structure  (Read 4124 times)

YogaMatt

  • EA User
  • **
  • Posts: 101
  • Karma: +8/-0
    • View Profile
TOGAF and Model Structure
« on: April 28, 2016, 02:01:18 am »
Our team are debating. Faced with the template "TOGAF-ADM" package structure generated from the TOGAF MDG, where do we put stuff? The differing views:

  • Model elements (ABBs/SBBs) all to exist within the appropriate ADM phase folder.
  • Model elements (ABBs/SBBs) all to exist outside the phase folders in a central repository, but artefacts which draw together those elements published in their appropriate ADM phase's folder.

Other considerations are:
  • elements are re-used (and embellished) throughout the phases;
  • so are some artefacts;
  • both baseline and target architecture(s) to be managed in the same model.

Any prior art / experiences, please?

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6148
  • Karma: +83/-85
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: TOGAF and Model Structure
« Reply #1 on: April 28, 2016, 09:42:10 am »
STRONG Advice for an Enterprise level repository is to separate item storage from diagram storage.

By all means place all the viewpoint diagrams in the TOGAF structure, but put ALL items in a separate branch - whose structure is NOT related to any methodology.  There is NO methodologically based structure that will handle item storage to the satisfaction of all concerned.

In our case, because we use ArchiMate, as the basis (but vastly enhanced/modified)of our methodology/modelling, our items are in the Items branch, then separated by items aspect (Business/Application/Technology/Motivation/Implementation etc.)  Then by type (for example: Business Objects, Business Processes, Business Functions etc.).
We have so many items that within each folder, we have a set of alphabetical folders (A,B,C etc.).  Indeed for some types, we now have so many that we have gone to a second level of alpha: AA,AB, AC etc.

Our overnight processing harvests the items from wherever they have been placed (by the user or by EA) and puts them into the correct folder.

We also have separate branches for Enterprise level and Project level models.  Each project gets its own Items folder and there is one Enterprise level folder.

YMMVWFU
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

YogaMatt

  • EA User
  • **
  • Posts: 101
  • Karma: +8/-0
    • View Profile
Re: TOGAF and Model Structure
« Reply #2 on: April 29, 2016, 05:41:40 pm »
Fabulous!
STRONG Advice for an Enterprise level repository is to separate item storage from diagram storage.
By all means place all the viewpoint diagrams in the TOGAF structure, but put ALL items in a separate branch - whose structure is NOT related to any methodology.  There is NO methodologically based structure that will handle item storage to the satisfaction of all concerned.
... this resonates. It's built on the fundamental separation between the things that are and the ways of looking at them, or more simply the diagrams and the things on the diagrams --- because the things on the diagrams "live" independently of any one diagram, and can inhabit more than one diagram.

We have so many items that within each folder, we have a set of alphabetical folders (A,B,C etc.).  Indeed for some types, we now have so many that we have gone to a second level of alpha: AA,AB, AC etc.
Our overnight processing harvests the items from wherever they have been placed (by the user or by EA) and puts them into the correct folder.
Did you foresee this scale? When did you get to the point of needing the automation?

We also have separate branches for Enterprise level and Project level models.  Each project gets its own Items folder and there is one Enterprise level folder.
When you say branches, do you mean in the version control sense, or in the folder structure sense?

So many thanks,

YM

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6148
  • Karma: +83/-85
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: TOGAF and Model Structure
« Reply #3 on: April 29, 2016, 06:44:42 pm »
Fabulous!
STRONG Advice for an Enterprise level repository is to separate item storage from diagram storage.
By all means place all the viewpoint diagrams in the TOGAF structure, but put ALL items in a separate branch - whose structure is NOT related to any methodology.  There is NO methodologically based structure that will handle item storage to the satisfaction of all concerned.
... this resonates. It's built on the fundamental separation between the things that are and the ways of looking at them, or more simply the diagrams and the things on the diagrams --- because the things on the diagrams "live" independently of any one diagram, and can inhabit more than one diagram.
If you come from Visio, for example, you don't make the distinction between the diagram (the viewpoint) and the model.
Quote
We have so many items that within each folder, we have a set of alphabetical folders (A,B,C etc.).  Indeed for some types, we now have so many that we have gone to a second level of alpha: AA,AB, AC etc.
Our overnight processing harvests the items from wherever they have been placed (by the user or by EA) and puts them into the correct folder.
Did you foresee this scale? When did you get to the point of needing the automation?
We've always had automation of various kinds.  One of my theses - which I place on my resumes - is that it is IMPOSSIBLE to create and maintain an enterprise level repository WITHOUT significant automation.  So when, organically, things grew to this size, it was relatively easy to add the structure.
Quote
We also have separate branches for Enterprise level and Project level models.  Each project gets its own Items folder and there is one Enterprise level folder.
When you say branches, do you mean in the version control sense, or in the folder structure sense?
Folder structure.  Another of my theses is that source-type version control for repositories is a chimera - you're asking for trouble.  That's not to say we don't use XMI, we do, but not for version control.  We maintain snapshots of the repository and when we need to recover, we "compare and contrast" the current with the snapshot and perform appropriate updates.
Quote
So many thanks,

YM
HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Glassboy

  • EA Practitioner
  • ***
  • Posts: 1038
  • Karma: +58/-71
    • View Profile
Re: TOGAF and Model Structure
« Reply #4 on: May 02, 2016, 12:00:42 pm »

YogaMatt

  • EA User
  • **
  • Posts: 101
  • Karma: +8/-0
    • View Profile
Re: TOGAF and Model Structure
« Reply #5 on: May 03, 2016, 06:05:50 pm »
Any prior art / experiences, please?

My advice is have a read of this http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html

Thanks GB. Fresh from the course, so am familiar with the material. It hasn't answered my question: whether the architecture repository should or shouldn't be structured along the lines of ADM i.e. have the hierarchical structure of phases. I've come up with a view, supported by Paolo, that we can make use of the ADM phases to structure the model for a project, but not to make this the core of the architecture repository for reusable assets across projects. I'm meeting with the team today to review a (large and real) sample project that takes this approach, and will post the range of opinions garnered from sharing this.

Glassboy

  • EA Practitioner
  • ***
  • Posts: 1038
  • Karma: +58/-71
    • View Profile
Re: TOGAF and Model Structure
« Reply #6 on: May 04, 2016, 08:41:34 am »
The M in ADM is the method.  The content metamodel describes how you structure your content.  The ADM may have something to say about what views you generate but shouldn't dictate the way you structure your elements.

I should also point out, I have never seen anyone do TOGAF well.  No one has ever been happy to have me look at thier repository as and indicative example.

YogaMatt

  • EA User
  • **
  • Posts: 101
  • Karma: +8/-0
    • View Profile
Re: TOGAF and Model Structure
« Reply #7 on: May 04, 2016, 07:11:16 pm »
Update:
We've reached a team consensus - and decided upon a root node for an Architecture Repository of reusable building blocks, alongside other root node (one for each project). The folder structure for the project root node mirrors the TOGAF ADM phases, with baseline and target architectures clearly demarked within each phase. The artefacts within the phases (will) abide by the ACM meta-model.
We use classifiers in the Architecture Repository node and instantiate them in the project node. That way, relationships in a baseline or target architecture do not pollute one another, but the common ancestry is retained.

Outcome:
A team that is happy to proceed. We're mindful that there is no perfect solution, but we're clear amongst ourselves. We're also happy that we will probably need to develop some automations to maintain things, and if push comes to shove we'll restructure (the difficulty of which is often overplayed).

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6148
  • Karma: +83/-85
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: TOGAF and Model Structure
« Reply #8 on: May 04, 2016, 08:24:46 pm »
[SNIP]
Outcome:
A team that is happy to proceed. We're mindful that there is no perfect solution, but we're clear amongst ourselves. We're also happy that we will probably need to develop some automations to maintain things, and if push comes to shove we'll restructure (the difficulty of which is often overplayed).
Well done!

As Uffe and I say:
Concistency, konsistency, consistensy! TMUffe - after Paolo


So long as you're consistent, you'll be able to restructure more easily.

As I've said for decades, "It's better to consistently wrong, than inconsistently wrong!"

Paolo

Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!