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

General Board / Re: Gap Analysis Matrix
« on: April 07, 2016, 08:28:33 pm »
Hi Phil, and all

Update: using EA 12.1.1225 things haven't progressed.

It gets worse: you can only create new gap elements from the "Missing/Eliminated" right-hand column and from the "New" bottom row. We have a legitimate reason to want to do it within the grid too: we're considering an AS-IS baseline architecture and a TO-BE target architecture, and looking at how the roles of <<ApplicationComponent>>s may be enhanced or reduced role in the target operating model. Someone in the team has painstakingly added Gap Notes within the grid, now we want to report on them so we want to turn them into model elements to overcome the limitation of the Gap Matrix. Can't.

Does anyone where the Gap Notes are stored in the backend database (we're on MS-SQL).

Agree - thanks Geert.

Good Karma for giving the confidence to apply time to this.  8)
I'll update with what we finally arrive at as a solution: another aspect we're looking to achieve is producing the output as a spreadsheet artefact, with data filter, embedded in a master document, and automate the process completely.

Pages: 1 2 3 [4] 5 6 7