Baseline compare utility - elements without diagrams

[Paolo F Cantoni]

The irony is you've chosen an English word that means different things depending whether it's a verb or an adjective.   

I used to work with a German woman who would often become infuriated with multiple meanings in English.  One day she arrived at my desk furious from some discussion that was happening in the Communications department and asked me "Why can't English have rules?".  I handed her my copy of Usage and Abusage (http://www.amazon.co.uk/Usage-Abusage-English-Penguin-Reference/dp/0140514422).  After I moment or two of perusing it, she declared loudly she was correct and marched off with my book to claim victory.

These days, it should be called "Abusage and Usage".  There's a recent excellent podcast by Steven Pinker (Harvard psychology professor): "Steven Pinker explains how to write clear and coherent prose with a sense of style"  I commend it to everyone - whether native English speaker or not.
Fowler would be pleased...

Paolo

[Helmut Ortmann]

Hi,

if you have a special use cases to solve Diff/Merge it should be possible.

If you want a general purpose solution I doubt that it's easy and valuable.

If you have a DSL like solution like:

• Class Diagram
• Logical Data Model

you should be able to get a valuable solution.

Helmut

[minastaros2]

Oh, I understand your point, just not the idiom.  But I learnt a long time ago that German idiomatic phrases and Dutch swear words make no sense when translated into English.

That is universal. Translating "raining cats and dogs" or "cute as a button" don't make sense in other languages either (in Germany, it's raining pack-threads instead).

On the other hand, the more interesting fact is that even when a word-by-word translation does not work, there is very often a sematic equivalent in the other language. For instance, the English  sit on "cloud number nine", the Germans on "Wolke sieben" (cloud seven) for the same purpose. Even more interesting: which one was first? Once upon a time some guy must have travelled a long way and brought the word, but has obviously confused the numbers.

Or: "Jemanden ins kalte Wasser schmeißen" (throw somebody into the cold water) - in English: "throw somebody in at the deep end".


Back to the topic:

I think there is a tendency to think that tools will solve what is basically an editorial problem.  Same thing happens with CMDBs.

Not exactly, I do not try to abuse a tool for purposes it is not designed for.
It was just the starting point from things I already know: following the V model, design follows requirements (i.e. new features), and implementation follows design. So my first naïve guess was to see the design model on the same level as the code.

And since I am quite new with EA, I now try to figure out what EA can actually do well and what would not work. And because they state that they can do versioning, baselining, ex- and import, even kind of a comparison and merging, I was wondering what was the closest possible (and practicable) workflow to the code's versioning strategy.
Obviously, they differ, that means that one has to think freshly - not a bad thing at all.

Since the requirements are managed in a database tool which does not know branches but only baselining, orientating the EA database more to the requirements and get inspired by that workflow would probably be the more reasonable way to go.

[qwerty]

Definitely that's reasonable. Setting it on its feet  is the best approach. Of course, trouble is right ahead. Each domain has different ideas about what the impact of requirements to a system is. And that's where you have to start. It's setting up a reasonable workflow which not only meets the interests of the customer giving the direction, but also that of architects and developers making the way. There is no king's way to anywhere. It's always a steep, stony way one has to go. And each mountain is different.

q.

[Glassboy]

And since I am quite new with EA, I now try to figure out what EA can actually do well and what would not work. And because they state that they can do versioning, baselining, ex- and import, even kind of a comparison and merging, I was wondering what was the closest possible (and practicable) workflow to the code's versioning strategy.
Obviously, they differ, that means that one has to think freshly - not a bad thing at all.

What the tool allows one person to do, and how it slots into the dynamics of a team are two different things.  In the end, a model is just a representation of knowledge and history shows us that any successful implementation of a knowledge tool has a real person operating in an editorial role.

[Paolo F Cantoni]

[SNIP]
What the tool allows one person to do, and how it slots into the dynamics of a team are two different things.  In the end, a model is just a representation of knowledge and history shows us that any successful implementation of a knowledge tool has a real person operating in an editorial role.

This is indeed true; especially as the size of the audience grows.  We are developing an enterprise-wide repository.  Many maintainers, potentially thousands of readers.  We are developing rules, guidelines and conventions to improve the consistency of the model.  We are also developing automata to assist, but their role is to handle the "known knowns", leaving more time for the human editors to handle the more difficult stuff.
Ultimately, if we can't use terms consistently outside the model, how can we expect to create a consistent representation of knowledge?  See my tag line.

Paolo

[minastaros2]

We are developing an enterprise-wide repository.  Many maintainers, potentially thousands of readers.  We are developing rules, guidelines and conventions

See, and we are just a handful of people in different projects, starting to switch over to EA at the same time, and asking exactly these questions: HOW to begin with those guidelines and conventions, where exactly are the pitfalls - and chances - that come with the new tool? O yes, we have a QA system which requires "detailed design", but people used to do that quite differently with other - not so powerful - tools. We desperately see that letting every user tampering with the database would do no good, so that "editorial" part is now really important.

You guys helped me heaps, thank you again!

[Glassboy]

I highly recommend you start simply by creating some "style guide" diagrams within the repository that show how to create diagrams in models in the way that your external governance processes need them.  And have a champion that the team can go to for advice.

As you progress, you can use things like the MDG capability to create model templates that users can deploy via the Add Model via Wizard functionality etc.

[qwerty]

A good start, yes. I recommend creating a meta model where the whole setup is documented (config mgmt, rules to document the system - use cases, classes, etc.). You will need a super-champion to do that (hopefully you) and of course the champions that know this meta model and can transport what it really means. Alternatively you can write all that as plain text documents. But hey, UML is exactly about this stuff. So it's ideal for this purpose.

q.

[Paolo F Cantoni]

Separate location in the repository of the elements from the diagrams.  We separated our elements by metatype (and because we mainly use ArchiMate, by metatype within aspect).
Each project should have their "private" element area.
You will probably find you need a shared element area - you can "promote" project specific elements to shared elements by dragging.

Paolo