Re: [tgf] TGF v2

[John Borras <johnaborras@yahoo.co.uk>]

Mark, and everyone.

 

Apologies that you couldn't open the .wiz file.  That was the template I was given by TC Admin.  Hope you can open the attached version.

 

John

From: Mark Woodward <mark@millbeckconsulting.co.uk>
To: Chris Parker <chris.parker@cstransform.com>
Cc: Peter F Brown <peter@peterfbrown.com>; John Borras <johnaborras@yahoo.co.uk>; TGF TC List <tgf@lists.oasis-open.org>
Sent: Thursday, 12 December 2013, 16:52
Subject: Re: [tgf] TGF v2

John - I am OK with Peter's wording for page 14.

On the Business Change/Enabler issue, I think we have a slightly tricky issue.  In BRM parlance, an Enabler is usually something acquired from outside the environment - IT systems, buildings, other plant or equipment; Business Changes are things like organisational structure, processes, company policies which a programme has to address for the value of the Enable to be realised.  The problem is that this language developed in the arena of organisational change programmes, whereas TGF has a much wider world to deal with, and in particular where the word "policy" carries different connotations.

Taking Peter's example of legislation for electronic signatures, I would handle that as an "external Enabler", assuming that the legislation was not itself part of the TGF Programme.  To take advantage of it, private and public sector bodies would have to adjust/create an internal policy addressing, for example, where they were prepared to accept the use of electronic signatures, and where not; this would be an associated Business Change.  However, Policy in governmental terms could be a driver, an Enabler or a Business Change, depending on the Policy and the context.

I think Chris' suggestion on the wording is probably the best solution; I'd suggest some changes, but I can't open the document that John sent out.  I don't think .wiz can be opened on a Mac.

Mark

On 11 Dec 2013, at 19:03, Chris Parker <chris.parker@cstransform.com> wrote:

Peter

I agree: I'd also say that legislation was an enabler not actually a business change - it's not hard to think of ineffective laws that have no real impact on organizational or individual behaviour.  If others agree (Mark?), that suggests we need to change the bits of text referred to in your final sentence.

Chris Parker
Managing Partner, CS Transform 
+44 7951 754060

From: Peter F Brown
Sent: ‎11/‎12/‎2013 18:33
To: Chris Parker; John Borras; TGF TC List
Subject: RE: [tgf] TGF v2

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:chris.parker@cstransform.com] 
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: tgf@lists.oasis-open.org [mailto:tgf@lists.oasis-open.org] 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: tgf@lists.oasis-open.org [mailto:tgf@lists.oasis-open.org] 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

Attachment: TGF-v2.0-csd01.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document