[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
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…
 Guiding Principles – combine with  Roadmap for Transformation
 Customer Insight – combine with  User Focus
 Customer Centered Services – combine with  Personal Data under Citizen Control
 Transformation with the Citizen – combine with  Citizens Add Public Value
 Manage Critical Success Factors – combine with  Risk Management
 Leadership – combine with  Strategic Clarity,  Sustained Support, and  Policy Management
 Stakeholder Engagement –combine with  Collaborative Governance and  Map All Stakeholders
 Future Proofing – combine with  SOA Principles, and  Shared Services
 Achievable Delivery – combine with  Benefit Realization
 Independent Review of Performance
 Transformational Business Model
 Franchise Marketplace – combine with  Grow the Market and  Supplier Partnership
 Brand-Led Service Delivery – combine with  Product Management ?
 Citizen Empowerment – combine with  Citizen Identity Management
 Multiple Channel Delivery
 Channel Management
 System Realization and Governance
 Interoperability using Open Standards
 Information Resource Management – combine with  Common Terminology
 Open Government Data to Re-Use
Hope that helps!
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 please.
Chair OASIS TGF Technical Committee
m. +(0)44 7976 157745
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!
Managing Partner, CS Transform Ltd, +44 7951 754 060
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 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 draft;
- agreeing a timetable to finish a first formal draft for adoption by the Committee and releasing it for public review
Peter F Brown
Transforming our Relationships with Information Technologies
P.O. Box 49719, Los Angeles, CA 90049, USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]