This content has been marked as final. Show 1 reply
Thanks for the reference, found it interesting reading. Especially the final design question:
2.12 How do we expect users to understand and use Guvnor?
In my view, the problems described above are self-inflicted. Guvnor is sort of an SCM. 'Sort of' solutions do not result in consistent user models, users become confused, and all the unhappy consequences of having confused users appear (adoption of alternative choices, increased tech support/forum activity, bad publicity, etc.).
I think the fact that there are so many questions related to how Guvnor would work along side an SCM does raise doubts in my mind whether this approach is appropriate.
I agree with the view that governance will only be used effectively by an organisation if it does not add any burden on its developers - otherwise they will either find ways to circumvent it thus losing the benefits that it provides an organisation, or it will increase development cost - which organisations will also not appreciate.
From my perspective, a developer creating or modifying SOA artefacts (e.g. in an Eclipse environment), should only have to deal with a SCM.
At an appropriate point in a projects development cycle, it could be 'registered' with the repository - and from that point onwards, the repository could take responsibility for governing the SOA artefacts in the SCM project - but this should be based on referencing the artefacts. Any errors detected could then be presented back to the developer.
The repository should only have readonly access to the resources, and be responsible for moving tagged/snapshot versions of the project in the SCM through the relevant lifecycle.
I had thought that Guvnor would be implemented on top of DNA, so that the enrichment of information in a SCM through notification of changes, applying 'sequencers' to analyse the information, apply policies etc, would all operate on the artefacts residing within the SCM?