Pattern Languages The idea of Pattern Languages, as a process for analyzing recurrent problems and a mechanism for capturing problems and archetypal solutions, was first outlined by architect Christopher Alexander [Alexander 1964] and [Alexander 1979]: “The value of a Pattern Language is that remains readable and engaging whilst providing basic hooks for further machine processing… [it] is not an ‘out-of-the-box’ solution but rather some ‘familiar’ patterns with which a team can work” [Brown 2011]. The exact configuration varies from one pattern language to another, and the pattern adopted in the TGF is structured as follows: the name of the pattern and a reference number; an introduction that sets the context and, optionally, indicates how the pattern contributes to a larger pattern; a headline statement that captures the essence of the need addressed; the body of the need being addressed; the recommended solution – what needs to be done; some notes on linkages, showing how each pattern links to related and more detailed patterns that further implement or extend the current pattern. In some cases this also includes references to external resources that are not part of the TGF. These patterns together make up an initial set of “Core Patterns” of what is expected to be an evolving set of TGF patterns. These form the core of the TGF standard, and it is against these that conformance criteria are set out in Section 9. Where closely related patterns have been grouped together in one section of this document – for example, on Business Management, Service Management and Technology and Digital Asset Management – the relevant section also includes some additional introductory text to help readers understand linkages more easily. This text, however, does not form part of the TGF Core Pattern Language. Guiding Principles There is one TGF Core Pattern on Guiding Principles. This is set out below. [GP1] Guiding Principles Context Development and delivery of a successful TGF program requires collaboration and change across a wide range of individuals, communities and organizations over a sustained period of time. An approach that is rooted in a set of clearly stated principles can help ensure that business decisions across those organizations align. In the TGF, we use the term “principle” to mean an enduring statement of values can used on a consistent basis to steer business decision by multiple stakeholders making over the long term, and which are: used to inform and underpin strategy; understood, agreed and owned by stakeholders.
Supplier partnerships should set out a formalized and robust way of managing, monitoring and developing supplier and commissioning party performance whilst at the same time minimizing risks to the business. ‘Partnerships’ focus on the overall relationship over time rather than the specific relationship around an individual, time-limited, contract. Yet traditional public sector procurement and supplier management practices can represent a significant obstacle to transformational government. From both the public and private sector sides of the market, there is strong evidence that such practices can stifle innovation and inhibit the ability of governments and industry jointly to undertake real life R&D and to pool intellectual property for mutual benefit. Equally, there is increasing consensus on new, “smarter” approaches to supplier partnership, which are already starting to develop and should be more widely adopted. Figure 9 summarizes some of the key elements of this shift. Traditional public procurement and supplier management Transformational Supplier Partnership Silo-based procurement, with requirements set by individual agencies within the government… An integrated strategic approach to the commissioning of services, across the government and in partnership with other public service delivery organizations …and with little ability to fund solutions that benefit multiple organizations Budget alignment mechanisms enable effective provision of common good platforms and services The government defines the technology and other inputs it wants to buy, and the immediate outputs it wants these to deliver The government defines the outcomes and service levels it wants to achieve Requirements are developed internally by the government Requirements are developed iteratively, in partnership between customer, commissioner and supplier The government brings its requirements to the market in a piecemeal manner Published pipelines of future requirements help to stimulate the market and enable suppliers to propose new cross-cutting solutions to deliver multiple requirements Government agencies define requirements in isolation from each other Joint procurement initiatives, facilitated by shared pipelines, enable shared services across more than one agency and also stimulate the market for standardized and replicable public sector solutions (including via Cloud Computing) Procurement and contracting is based around purchaser–provider, client–agent relationships A range of more innovative delivery models are deployed, including joint ventures and partnerships between government, industry and academia that promote collaborative solutions while safeguarding the intellectual property of each