RE: [tgf] TGF Pattern Language work

To offer up comments on this thread will take some serious deep reading of Peter's WD02!

But a couple of observations to bear in mind that are arising out of this great exercise are:

1) the 'layers' of GP/Delivery Areas/CSF..and then the retrospective lens of conformance..are becoming more delineated, which I think clarifies the framework for the audience

2) the rationale of PL for machine readability as a means to conform is a great litmus test. The computer logic of 1s and 0s is a neat way to ensure us humans (with more circuituous logic) are in step, when we write this.

Cheers

Colin

From: Peter F Brown [mailto:peter@peterfbrown.com]
Sent: Wednesday, 8 June 2011 4:49 a.m.
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 “conformed”

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 duplication.

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 Value

[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 Services

[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,

Peter

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

Peter

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?

All

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 please.

Regards

John Borras

Chair OASIS TGF Technical Committee

m. +(0)44 7976 157745

Skype: gov3john

www.oasis-open.org/committees/tc_home.php?wg_abbrev=tgf

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

Peter

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!

Regards,

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

Hi,

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 document.

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 12^th and Monday 13^th.

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 16^th:

- 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 draft;

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

Best regards,

Peter

Peter F Brown

Independent Consultant

Transforming our Relationships with Information Technologies

www.peterfbrown.com

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

Tel: +1.310.694.2278

Member of:

Follow me:

tgf message