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

Hi Geert

I'd noticed the SQL fragments, but wasn't sure it would work as the query in our model view creates derived columns e.g.

COALESCE(dest.Name,destCls.Name) + '_AND_' + COALESCE(src.Name,srcCls.Name) [InterfaceName]

When you say "maybe" - do you know that this will work?



Hi All

There are two very different types of ModelView in EA. One is a model element, accessible from the toolbar on most diagram types, under Artifacts. The other is the Ctrl-Shift-5 "Model Views" window.
I'm asking about is the model element type, which we're currently using to display interface catalogues (see the TOGAF model template for an example).

They work nicely. But the document generation capability in EA disregards it. I can create a template to output the interface connectors, so that's not a major problem. But stakeholders want an output which looks very much like the one you can see in the model. We could do that by running the SQL script directly on the database and export the results to Excel. But that's not joined up when it comes to managing complete documents from place.

Any ideas?



Hi Gayle
That sounds like a neat trick, and of general use. Have you thought about posting it somewhere?
Does the diagram auto-refresh or can you place an "update" button on it to run the script?

Hi Gayle
I recommend you download a trial of eaDocX - I'm sure you'll be pleased with the results.
It'll give you HTML tabulated (and hyperlinked) model content.
With the collaboration edition, you can even get non-model stakeholders to provide feedback in one place for all to see.
You can then take that feedback and push it through into the model from the document.
Hope that helps!

Let me playback what I think you want:
Produce output which combines model output with externally "generated" stuff.
A very good option would be to use eaDocX (I have no commercial interest - just a happy user).
You can place various sections in an external document that are interlaced with the existing content in that document.
One use case is to use an external document template with header, TOC, disclaimer, etc and ensure model output goes into the appropriate sections.
eaDocX document generation will not trample all over the existing content, just squirt in what you want, where you want.
What's more, in one of the editions, you can manage the documents within the model.
I don't think it let's you generate HTML in this way (i.e. interlacing model content and other content), but having produced a Word document you could save as HTML.

Then you won't have to script.

Hopefully I've understood your problem and this is a viable solution for you.

Pages: 1 2 3 [4] 5 6 7