[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tgf] TGF v2
Just to say I agree with all Peter’s points. On the “enabler” question, I’d say keep the definition, because enabler is a clearly distinct term in the causal flow of benefits described in the benefit mapping section.
CS Transform Limited
T: +44 7951 754060
F: +44 207 681 3908
Citizen Service Transformation
Thanks for this John.
As I mentioned offline to you, there are a few formatting and layout issues in the Terminology section (Pattern B9) that we should and can fix before committing the document to the doc repository. They do not affect the content at all.
A couple of outstanding comments that you had asked me to respond to:
- p14: I favour the simplest wording here: “d) can be measured”;
- p23: I support Mark’s proposed rewording here, “Franchises provide a pragmatic and low-risk operational structure…”
- p32: there are two issues here. Firstly, this is not phrased as a problem statement; second the phrase “act as enablers rather than blockers…” is a bit clumsy. A further suggestion would be: “Transformational Government programs require effective, partnership-based relationships with suppliers but the relationships themselves can obscure or prevent the vision of more citizen-centric and integrated service delivery.”
- p37: At top of page I had dropped “Linkages” but, for consistency, it should be there: “Linkages <newline> Introduction to Terminology”
- p37: the term “Enabler”: I’m not convinced that this needs to be defined as a formal term. The concept – that various artifacts are created and serve to provide some value, and thus enable things to be done – is clear but ‘enabler’ can also be non-tangible, such as a piece of legislation or policy – although later on in the document we call these “business changes”. The distinction that is made between Enabler and Business Change is useful and parallels discussions in SOA standards work: A ‘Capability’ is a set of functions organized in such a way to deliver some value (it is the ‘potential’). However, it is only by leveraging that capability and using it as a service, that actual benefits result. The key question for us is: if we don’t formally define “enabler” would this be a problem or a hole in the document? The problem is that it is used and sort-of defined in several parts of the document.
- p38: the term “Function” – I would be in favour of dropping it. The definition as proposed is a very narrowly IT-related definition and is likely to cause confusion rather than enlighten the document.
- p38: agree to drop ‘Measure’ as a defined term
- p63: possible rewording “’Digital assets’ can be either data or the technologies that process them. These two asset classes represent distinct value chains (depending on whether the technology itself; the data; or both; are of value to a particular stakeholder) but are often treated as an indistinguishable whole, if they are treated as assets at all. The prevalence of digital assets presents growing challenges and opportunities will be limited if those assets are not understood and managed on a government-wide basis.”
Attached is the draft Committee Specification of TGF v2. This contains all the changes approved so far by the TC plus some outstanding issues and Peter's proposals following his review of the core terminology. I would hope that we can agree all outstanding matters on our TC call next week and then move to approve it for Public Review. To that end it would be good if we could clear as many of the issues as possible before the call so early views on the Comments, particularly from those who have raised the Comment, and Peter's proposals in Pattern 9 Core Terminology would be appreciated.
I will send out the agenda and call details for the TC call early next week. If anybody has any items for inclusion in the agenda please let me know asap.