Chris,
Happy to go along with keeping “enabler” as a distinct term.
As much for my education as anything else, one question of clarification:
Something like a piece of legislation (say, a law such that lays the foundation for what is acceptable in the domain of electronic signatures), would this be
an enabler or a business change? For me, instinctively, it seems to be an Enabler – the business change comes about when that legislation is used by someone to actually effect some specific, tangible change. But in the document, artifacts such as policy documents
are listed as examples of business changes.
Cheers,
Peter
From: Chris Parker [mailto:]
Sent: Wednesday, 11 December, 2013 00:41
To: Peter F Brown; John Borras; TGF TC List
Subject: RE: [tgf] TGF v2
John
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.
Regards,
Chris Parker
Managing Partner
CS Transform Limited
www.cstransform.com
T: +44 7951 754060
F: +44 207 681 3908
Citizen Service Transformation
From:
[mailto:]
On Behalf Of Peter F Brown
Sent: 11 December 2013 00:09
To: John Borras; TGF TC List
Subject: RE: [tgf] TGF v2
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.”
regards,
Peter
From:
[mailto:]
On Behalf Of John Borras
Sent: Tuesday, 10 December, 2013 02:52
To: TGF TC List
Subject: [tgf] TGF v2
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.
Regards
John
