Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - YogaMatt

Pages: 1 2 3 [4] 5 6 7
Uml Process / Re: TOGAF and Model Structure
« on: May 04, 2016, 07:11:16 pm »
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.

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).

Uml Process / Re: Visualising Classifier Relationships
« on: May 03, 2016, 06:08:07 pm »
Well.... Fixed-ish. ;)

But the instance/classifier relationship is not defined as a connector in UML so there's no way to show it with a diagram link. And since relationship matrices show connectors you can't get it that way either.

You can always write a search for it. That will at least give you a table view.

So why not create one?  Ours («InstanceOf») is an extension of the metatype «Abstraction».


This view has my support.

Uml Process / Re: TOGAF and Model Structure
« on: May 03, 2016, 06:05:50 pm »
Any prior art / experiences, please?

My advice is have a read of this

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.

Suggestions and Requests / Re: Locate Classifier from Instance
« on: May 03, 2016, 05:46:14 pm »
Yes, that would be consistent with the behavior of a selected object in the diagram and a valuable addition.  ;D

I'll submit a feature request, referencing this thread.

Anyone wants to add support, give Karma ;-)

Feature request submitted and Sparx considering for future release. In the meantime, remember to use Geert's valuable workaround.  :)

Suggestions and Requests / Re: Locate Classifier from Instance
« on: April 29, 2016, 08:10:18 pm »
Yes, that would be consistent with the behavior of a selected object in the diagram and a valuable addition.  ;D

I'll submit a feature request, referencing this thread.

Anyone wants to add support, give Karma ;-)

Suggestions and Requests / Re: Locate Classifier from Instance
« on: April 29, 2016, 07:29:49 pm »
Thanks again Geert - helpful as always.
Though valuable, I want to be able to just navigate whether I have the traceability view open or not. Ctrl-Alt-G from instance in browser surely should navigate the classifier?

Suggestions and Requests / Locate Classifier from Instance
« on: April 29, 2016, 07:04:38 pm »
Instances of a classifier are in a different location to the classifier in the project structure.
From an instance on the diagram, can locate the classifier (either right click and find classifier, or shortcut Ctrl-Alt-G).

When viewing the instance in the browser, Ctrl-Alt-G does not locate the classifier, nor is there a context menu.

Am I missing the trick, or is a feature request in order?



Uml Process / Re: TOGAF and Model Structure
« on: April 29, 2016, 05:41:40 pm »
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,


Peter, again very helpful, thank you.

The use of EPF in describing work in EA part is what we're currently considering, though you raise the additional point which is to model the EPF in EA. I'd be really interested in your EPF domain model (EA xmi file) - would that be possible?

On the matter of an explicit connection between EPF to EA: I'm not sure I completely understand this:
To avoid that process description in one thing and reality is something completely different, we have created a EA MDG technologies that supports the users in their work and in complying to our process requirements.

Please could you describe further?

Good karma!


Hello Peter, and thank you very much for your thoughts.

It is good to learn of this possibility, and it would be interesting to see an example model of an EPF spec. Basis for an MDG?

But I need to refine my question: I was thinking that if the EPF implementation is about things you do in EA, that the EPF could direct you into the right place in your EA model - and therefore act as a computer-based coach / guide into EA. Back to the floor?



Uml Process / 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?

Anybody done any integration between EA and EPF?

General Board / Re: As Is- To Be modelling
« on: April 27, 2016, 10:39:29 pm »
Thank you both

There is no conflict in the propositions here:

Hi there, you're not the first to ask this question here.  The thing that you and your organisation need to properly understand before you embark on this journey is that the target state is never the future state.  Any "to be" modelling you do needs to be completely disposable without leaving any ghosts on your "as is" model.
Instantiation means there are no ghosts - merely that the AS-IS and TO-BEs each have a heritage in the building blocks in the common architectural repository (such as described in TOGAF (OK, I've just been on the course  ;D )).
You could dispose entirely of your TO-BE (or your AS-IS for that matter). Hence my statement that things are entirely separate in each temporal model.

People also assume that you can move an element from your "to be" into your "as is" and your "as is" will be up to date, but your model will never totally reflect reality.  If you want an accurate "as is" model you have to model what was implemented not the planning for implementation.

I'm not amongst said people. Instead, the idea is that the TO-BE becomes the AS-IS (when indeed it is).

So what does this mean?  My advise is never reuse elements from your as-is model.  Clone the element and use a trace relationship back to it.

Classifiers and instances does this, but having a common library allows for re-usable components that are not part of the AS-IS but could be part of a number of candidate TO-BEs.

General Board / Re: As Is- To Be modelling
« on: April 20, 2016, 11:12:37 pm »
Consider this approach:
Use a common library area in your model containing master definitions (classifiers) of all elements (instances) found in in each of your AS-IS and your TO-BE state(s).
To work with library elements in the different temporal model(s):
  • For each of your temporal model(s), instantiate only the master elements needed i.e. if an AS-IS application "WIDGET" isn't going to feature in your TO-BE, do not instantiate the WIDGET. Obvious really, but worth saying.
  • You can always navigate back to the classifier, and from the classifier you can always see where it is in use in each temporal model.
  • Relationships between things in each temporal model are separate, as they should be.
  • This enables Gap Analysis and Impact analysis between temporal states using EA's matrix tools.

Now we need to consider "churn".

One type of churn is where the AS-IS keeps evolving whilst you model your future state - where not all change goes through the same control procedures (there's nothing more constant than change). For this situation, if the changes have happened or are certain, you could simply update your AS-IS model. Where the changes aren't certain or haven't happened yet, you can create another branched TO-BE from your AS-IS. And then you move into the territory of multiple impact analysis. All possible. You need to work out the appropriate balance between increased effort and risk mitigation in your situation, in order to decide whether you need to add a branched TO-BE.

Another type of churn is when the designed TO-BE actually becomes the AS-IS. At this time, what was the AS-IS needs to be retired (as it will have been in real life), and the next TO-BE may arise. Taking each in logical order:
  • Retiring the AS-IS: up to you what you do. You could leave it in your model, read only. You could baseline it and then move everything from your "was TO-BE now AS-IS" over the top. Either way, you'll have previously sweated the gap/impact analysis assets getting to this point therefore so long as they are documented sufficiently for audit or reviewing your decision making processes, you don't really have to angst about looking back and doing a model compare (that, I agree with forerunners, would be onerous).
  • Making the "was TO-BE the now AS-IS": baseline it first then either rename or move it. The event has occurred - it is now your AS-IS. Why do more? It is sufficient for modellers to know this is the current baseline and needs to be maintained for measuring change in your next transition state. There is no ultimate substitute for skill and experience, after all.
  • Your next TO-BE. Either you have one already (your project has multiple transition states), or you simply go about creating one. Take a holiday first.

Finally - how to branch one temporal model to create another? Export to XMI and reimport into a new location by stripping GUIDS.

General Board / Re: Gap Analysis Matrix
« on: April 07, 2016, 09:06:32 pm »
Thanks Geert
t_document holds the definition of the GAP matrix (and other types). I think the Gap Notes have to be in the BinContent, having searched extensively in many tables.
So, stuck in terms of getting the Gap Note information out. I'll try support and come back with anything that's of any value.
Namaste, YM

Pages: 1 2 3 [4] 5 6 7