TOGAF and Model Structure

[YogaMatt]

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]

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

[YogaMatt]

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]

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.

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.

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.

So many thanks,

YM

HTH,
Paolo

[Glassboy]

Any prior art / experiences, please?

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

[YogaMatt]

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]

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]

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]

[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! ^TM_{Uffe - 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