Sparx EA: Extend properties

[hfrmobile]

Current fields:

• Author: Name of the person who created the object
• Created: Date/Time of creation
• Modified: DateTime of last change

A missing a "

Changed by" ....

It is common having fields like:

• Created by: Name of the person who created the object
• Created at: Date/Time of creation
• Modified by: Name of the person who changed the object
• Modified at: DateTime of last change

--hfrmobile
[/list]

[qwerty]

It may be common, but you won't see that in the near future. You can check the audit facility which can give you information about changes made to elements.

q.

[Glassboy]

Once when we were trying to evaluate the performance of a couple of architects we ran a SQL query to look at how many elements had been created in the repository.  I obviously won, but there was an unexpected result in third place.  It took me a couple of hours but what I worked out is that person had been exporting packages and importing them into different root nodes and making minor cosmetic changes to the diagrams.

I think if EA is going to get extended auditing details as standard then it needs to try and tackle element lineage as well.

[qwerty]

People seem to have a need to run auditing in "accusation mode". And that's probably the one need for auditing. However, once a murder is committed, shooting the murder does not resurrect the victim. And for historical reason, no one will look into yesterdays model. If goals change we don't start with old models but try to adapt the current one since everybody knows (should know) the recent state, but not a historical one.

I guess this is just human habit. Also nobody has ever really learnt from history. Unfortunately.

q.

[Paolo F Cantoni]

Once when we were trying to evaluate the performance of a couple of architects we ran a SQL query to look at how many elements had been created in the repository.  I obviously won, but there was an unexpected result in third place.  It took me a couple of hours but what I worked out is that person had been exporting packages and importing them into different root nodes and making minor cosmetic changes to the diagrams.

I think if EA is going to get extended auditing details as standard then it needs to try and tackle element lineage as well.

The modelling equivalent of "Lines of Code"?   

Surely architecture is NOT a production line activity?

Since it's my assertion that "the job of the architect is not to do stuff, but to stop others doing stupid stuff", perhaps numbers of stupid ideas "nipped in the bud" might be a better method of assessing performance. 

Paolo

[Paolo F Cantoni]

People seem to have a need to run auditing in "accusation mode". And that's probably the one need for auditing. However, once a murder is committed, shooting the murder does not resurrect the victim. And for historical reason, no one will look into yesterdays model. If goals change we don't start with old models but try to adapt the current one since everybody knows (should know) the recent state, but not a historical one.

I guess this is just human habit. Also nobody has ever really learnt from history. Unfortunately.

q.

The case for tracking the last modifier is not an auditing issue, it is an authorship issue.  As I've mentioned before, in a corporate environment no one knows the current state, it's just too diffuse.  In the corporate environment, we're more interested in who last changed the element rather than who initially created it (who may have long gone over a decade ago).  The have the latest knowledge on what is happening around that element.  Similarly, relationships should have the same authorship properties.  Not knowing that a relationship has changed (and who by) is proving quite problematic for us.

Paolo

[Eve]

Auditing is effectively a black box recorder.

It can be used to assign blame, or it can be used to find out exactly what happened, and hopefully lead to preventing a situation happening again.

Personally, I've found myself referring to auditing much more frequently lately. In a few circumstances I've had to talk to the people who made a change, but only to find out information that isn't captured by auditing. They are usually the victims of process shortcomings.

[Glassboy]

Since it's my assertion that "the job of the architect is not to do stuff, but to stop others doing stupid stuff", perhaps numbers of stupid ideas "nipped in the bud" might be a better method of assessing performance. 

After a while that becomes the main reason for leaving a job :-)