OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tgf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [tgf] TGF Pattern Language work

I'll take a look at the attachment asap
On your last comment - bang on the nail: we shouldn't let the Primer structure blind us to creating a coherent patter set

Peter F Brown
Independent Consultant
Twitter @pensivepeter

Sent from my Phone - Apologies for typos and brevity - it's hard to type on a moving planet

-----Original Message-----
From: John Borras
Sent: Wednesday, 08 June, 2011 8:54
To: 'TGF TC List '
Subject: RE: [tgf] TGF Pattern Language work



Thanks for the explanation.  As you say perhaps if you had started in the
middle then we might not have raised these concerns!


I've made comments on your suggested re-organization in the attached
together with a proposed consolidated list  but I guess this might take a
few iterations to get it right.  I have not attempted to produce the
definitive name for each of the combined patterns, that should fall out of
the merging of material.


One other thought occurs to me.  Part of the problem seems to be that we are
trying to keep to the schematic map in the Primer which as you suggest is
somewhat irrelevant for the patterns.  Perhaps we should therefore dispense
with the separate Section headings in the WD eg 3 Guiding Principles, 4
CSFs, 5 Delivery Processes, and just have one Section listing all the
patterns?  This might help the understanding of how Patterns differ from the
text based Primer?  Just a thought.




From: Peter F Brown [mailto:peter@peterfbrown.com] 
Sent: 07 June 2011 17:49
To: ''Chris Parker''; John Borras 
Cc: 'TGF TC List '
Subject: RE: [tgf] TGF Pattern Language work


Chris, John, thanks for the constructive comments.


Firstly, I agree that, as an objective, we should ensure that the collection
of patterns avoids duplication.

Secondly, each pattern should address a distinct problem and for which there
should be a distinct sense of what is needed in order to be deemed to have


Part of the "problem" in the drafting is possibly down to the grouping and
implicit classification. Each of the items currently bagged as a guiding
principles or as a CSF is in fact a distinct issue (Customer Insight,
Leadership, Future Proofing, etc) and "just happen" to also be guiding
principles or CSFs. The essence of pattern languages writing is to get to
the core of each distinct issue and - as you rightly point out - eliminate


Maybe it was unfortunate that I started the exercise with the Guiding
Principles and Critical Success Factors rather than in the delivery
sections. As you rightly point out, the substance is in these four delivery
areas and if we had started there, we would probably identify many of the
current patterns under the first two sections as redundant. If we strip out
the labels and categories of Guiding Principles and Critical Success
Factors, we nonetheless still address core issues that may be either
duplicated elsewhere or treated in more detail in another pattern. Wherever
we bag them, they are distinct problems.


I understand where you see the problems with the current formulation. I do
agree that there is probably a single pattern for Guiding Principles and
CSFs but we need to distinguish between;

-          Patterns that state some higher-level or general principle such
as "make sure you have guiding principles and use them" or "manage and
measure CSFs"; and

-          Patterns that state a distinct problem (such as "Leadership") and
which happen also to be considered as being guiding principles or CFSs -
that is the source of the ambiguity.


To clarify the point, take an example: the principle of stakeholder
engagement is central to many aspects of the TGF. On one level it is a
pattern; at another level, it is too vague and is better formulated as a
series of more specific patterns; at yet another level, it is a critical
success factor.


In summary, I think the litmus test is to determine whether a single pattern
deals with a distinct issue or not, wherever it might be currently placed.


Below is a first attempt to regroup along those lines - the main criterion
used is: how discrete is the material currently available?


It's an iterative process - happy that you carry that further. I do think
identifying the main patterns is the priority - once the meat is on the
bones of key patterns, we will be able to identify further redundancy or
need for further distinct patterns.


Possible re-organisation:


[1] Guiding Principles - combine with [17] Roadmap for Transformation

[2] Customer Insight - combine with [9] User Focus

[3] Customer Centered Services - combine with [36] Personal Data under
Citizen Control

[4] Transformation with the Citizen - combine with [38] Citizens Add Public

[6] Manage Critical Success Factors - combine with [24] Risk Management

[8] Leadership - combine with [7] Strategic Clarity, [19] Sustained Support,
and [23] Policy Management

[10] Stakeholder Engagement -combine with [18] Collaborative Governance and
[33] Map All Stakeholders

[11] Skills

[13] Future Proofing - combine with [34] SOA Principles, and [35] Shared

[14] Achievable Delivery - combine with [15] Benefit Realization

[16] Independent Review of Performance

[21] Transformational Business Model

[22] Franchise Marketplace - combine with [5] Grow the Market and [12]
Supplier Partnership

[25] Brand-Led Service Delivery - combine with [37] Product Management ?

[26] Citizen Empowerment - combine with [27] Citizen Identity Management

[28] Multiple Channel Delivery

[29] Channel Management

[30] System Realization and Governance

[31] Interoperability using Open Standards

[32] Information Resource Management - combine with [20] Common Terminology

[39] Open Government Data to Re-Use



Hope that helps!


Best regards,



From: John Borras [mailto:johnaborras@yahoo.co.uk] 
Sent: Tuesday, 07 June, 2011 06:39
To: 'TGF TC List '
Subject: RE: [tgf] TGF Pattern Language work



Now that we can see the PLs in black and white I must say I have some
sympathy with Chris's comments.  As I was reading through your draft WD02
two things struck me.  First the amount of duplication ie having read the
Guiding Principles much of that re-appeared or was referenced in  the
delivery processes' patterns, and second the lack of any real conformance
requirement in each of the individual Guiding Principles and CSFs.  That
made me wonder whether we had cut the cake correctly and also ask the basic
question of what exactly the TGF Standard should constitute in terms of
things implementers have to do to be compliant.  And basically the things
that need to be done are in the delivery processes whilst the GPs and CSFs
are supportive and supplementary to those elements.  So Chris' suggestion of
a single pattern for the GPs and CSFs feels right to me on reflection, each
saying "you must have a set of GPs or CSFs and by the way here is our
recommended set which you can vary and add to but you must not contradict".


I know we've had a good deal of discussion in the working sessions on this
point before but I think nobody was really too sure which way to jump on it
until they had seen something.  Now that we have something to look at and
understand I think we can see which is the better approach.  As Chris says
It's not about throwing away all your hard work to date, and many thanks for
that effort, it's more a case of recasting it.


I'm ready to help either with any re-casting of what you've produced so far
or writing new patterns.   Perhaps before we get stuck into the new patterns
we need to resolve this issue and do any re-casting work?  



If necessary we can defer a decision on this point until the next TC call
but it would be good if we can reach early agreement and hence make further
progress before that call.  So can I ask for views in the next few days



John Borras


Chair OASIS TGF Technical Committee


m. +(0)44 7976 157745

Skype:  gov3john




From: Chris Parker [mailto:chris.parker@cstransform.com] 
Sent: 07 June 2011 13:36
To: peter@peterfbrown.com; TGF TC List 
Subject: RE: [tgf] TGF Pattern Language work




Thanks for all the hard work you've been doing on this.  For me, it has
helped make real what the pattern language approach means in practice.  Up
until now I've always struggled a little with the concept, but all the work
you've done makes both the approach and the value it will bring much clearer
for me.


I started working through the document this morning, annotating comments and
questions on each of the patterns.  But as I did this, it occurred to me
that there was a common driver behind most of my comments.  So I thought I
should raise a general question before carrying on with the detail.  I
wasn't able to attend your working group session on this two weeks ago, so
apologies if this is an issue which the group has already thought about and
reached a decision on.


In short, my thought is that the document would be stronger and clearer if
we only did one pattern each on "Guiding Principles" and "Critical Success
Factors", rather than articulating separate patterns for the individual
principles and CSFs. 


I have three reasons for suggesting this:


1)     As it stands, there is a strong sense of duplication - for example
between the guiding principle on Customer Insight, the CSF on User Focus and
the elements of the Customer Management framework.

2)     The patterns for the individual principles and CSFs feel to me like
they fall somewhat between two stools.   The three-part pattern structure of
"context/problem to be solved/solution" means that that they have been
expanded significantly from the 1 or  2  sentence description in the Primer
- but not to the extent that they yet feel they map out a complete delivery
solution.  And yet on the other hand I think that they lose some of the
clarity of communication that the original short versions tried to achieve.

3)     Finally, it feels to me that every pattern should have within it some
clarity about the conformance criteria: ie how do we know if the pattern is
being used effectively?  Your present version largely doesn't do that -
reflecting the fact that we didn't set conformance criteria at the level of
individual principles and CSFs in the original Primer.  (Instead we set  the
conformance criteria at the higher level, ie requiring that a conformant
implementation of the TGF must use the Guiding Principles and must measure
and manage the CSFs.)


So my preference would be for the patterns mostly to be confined to the four
delivery areas of Business Management/Customer Management/Channel
Management/Technology Management (where I thought that the number and level
of patterns seemed just right) , with a single pattern for Principles and a
single one for CSFs.   I don't see this as ducking a task, but simply
recognising the overlaps that exist between these parts of the TGF.  In
fact, one of the things that your work on the patterns has brought out more
clearly for me is the extent to which these three elements of the Primer
(Principles/Delivery Areas/CSFs) address the same issues, but in different
ways for different audiences:


.         The Guiding Principles try to distil the core essence of the TGF
approach, in a set of business principles which can be intuitively
understood and which can form the basis of top leadership commitment across
the government to a new sort of approach

.         The four delivery Frameworks then set out the meat of the TGF,
articulating in detail what needs to be done in order to put  the principles
into practice

.         The CSFs then cover the same scope of issues, but through the lens
of quality assurance and for the benefit largely of those involved in
periodic health-checking.of the TGF program.


What do you and others think?  If the alternative approach I'm suggesting
sounds worth trying, I'd be happy to do a first cut at what the top-level
single pattern for Principles and for CSFs might look like.  Much of the
content in your individual patterns we would then want to move to relevant
parts of the  Business Management/Customer Management/Channel
Management/Technology Management patterns.


But like I say, apologies if I'm reopening an old issue!  




Chris Parker

Managing Partner, CS Transform Ltd, +44 7951 754 060

From: Peter F Brown [mailto:peter@peterfbrown.com] 
Sent: 07 June 2011 01:58
To: TGF TC List 
Subject: [tgf] TGF Pattern Language work



Somewhat belatedly, I can give an update on work being done of the drat
Pattern Language


Attached is an interim, incomplete draft (WD02) of the TGF-PL deliverable.

Following the working group meeting held two weeks ago, I proceeded with the
first steps in a methodology:

-          Identify each and every conformance criterion in the TGF Primer

-          From the criteria, identify possible "candidate" patterns;

-          Add patterns that contribute to the whole;

-          Remove patterns that are redundant or can be better expressed as
part of a larger pattern;

I then started the work of transposing text from the TGF Primer to the
Pattern Language document:

-          Identify the core "imperative" statement for each pattern, based
on the conformance statement in the Primer;

-          Add text that relates a particular pattern to others;

-          Add text that serves as the prose body of the pattern, taken from
the Primer and other contributions;

-          Add references back to the Primer where appropriate in the
"completion" statement of each pattern;

As a result of a couple of cycles, the number of proposed patterns has gone
up and down and has now stabilised at under 40.


The interim result attached reflects this process applied systematically.

As a result,

-          the first 15 patterns are finished;

-          another half dozen are nearly finished;

-          the skeleton of the remaining patterns is in place


As I am "in the zone", I'm happy to continue this tomorrow and should be
able to complete another dozen or so of the patterns but after that I will
be travelling for the remainder of the week.


Can I ask all members of the TC to:

-          take a look and give any comments about whether the draft is
going in the right direction;

-          indicate whether the completed patterns satisfy the conformance
criteria that we have nominally indicated in the Primer;

-          submit any comments or queries on the nature and content of the


Can you also indicate whether you will be able to lend a hand at writing a
few patterns, now that the structure and practice is clearer. As an
indication, you should allow 30-45 minutes per pattern to go through the
steps outlined above. I will continue tomorrow in any case, proceeding
sequentially through the text. I will then only be able to return to this
after tomorrow on Sunday 12th and Monday 13th.


If you are willing to write some patterns, please let me know, and I will
send you the .docx file to work with.


For reference, we are due to decide at our TC meeting on Thursday 16th:

-          whether to proceed with moving this working draft to a full
"Committee Specification Draft" - which involves shifting the content to the
new formal template and completing the set of patterns, at least as a first

-          agreeing a timetable to finish a first formal draft for adoption
by the Committee and releasing it for public review


Best regards,



Peter F Brown

Independent Consultant

Description: Description: Description: Description: Description:
Description: cid:image002.png@01CB9639.DBFD6470

Transforming our Relationships with Information Technologies


P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.3
[The entire original message is not included.]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]