Blue Heron design
 
Page updated: 2014 02 17

Implemention Frameworks and Guidelines

1.     Community governance and definition

Community governance needs to capture the culture and objectives of a peer-to-peer community including: its basic architecture, process and service ambitions; the terms and conditions of membership; roles; standards and infrastructure; how it will be developed and evolve; its day-to-day operations; together with applicable integrity, privacy and performance criteria. 

Collectively, this guidance describes a potentially complex mix. It is advocated that, wherever possible the governance and definition of a peer-to-peer community should be based on available and tested reference models. Where a community needs to build new models, these should be made available to other follow-on communities wherever possible to accelerate their establishment.

In traditional organizational settings, independent platforms typically exist for each aspect of design, governance, development, operations, and performance measurement.  Each platform is selected because it is judged by the appropriate specialists and practitioners to be the best available for the task at hand.  These platforms will separately evolve over time, but will generally be based on independent assessments of the needs of each applicable discipline.

In traditional organizational settings, management exercises accountability and measures progress against plans by each of the applicable disciplines, making adjustments to plans as appropriate, and rewarding progress made.  Because the management of traditional organizations has a unified perspective, this is a relatively practical arrangement.  As an organization grows to resemble a conglomerate, some of these responsibilities may be delegated, but the highest level of the organization maintains a comprehensive perspective.




In peer-to-peer partnerships and collaborations, there is always a multiplicity of entities, each with their own separate purpose and management functions. A collective commitment is only ever achieved the common aspects of interactivity or interoperability judged to critical to community interoperability, be that a design framework, a set of models, standards, or hosting platforms, or the availability of shared tools for use by members. But there is never a single governance arrangement for the totality.

Without the unity of a management purview, the continued use of separate and unrelated platforms for each discipline increases the prospect of community failure.  For peer-to-peer relationships to be viable, the ability to connect or integrate applicable platforms has to be a factor in their selection and use.  Without solid connectivity, there is a high risk that information about essential relationships and features will be lost in translation between the governance of planning, provisioning, service delivery and feedback.  This risk of loss is applicable to both the integrity of process lifecycles and the evolution of a community.

Under these circumstances, it is essential that the entire lifecycle of a community and its approach to evolution be architected as a unified whole.  Architecting the operational state alone will not be sufficient.

2.      Community member needs, preferences and obligations

Each requestor and provider in a partnership or collaboration has varying needs, preferences, motivation and capacity to engage in program- or service-relationships and these must be both respected and capable of evolution.

Communities in general must have communications frameworks which enable participants with a range of capacities and competencies to co-exist.  Participants must also have access to education strategies that enable their migration to higher levels of sophistication and competency when desired.

Each individual community governance framework must also make clear the member’s specific obligations and options as they relate to:

  • The currency and availability of member provided services and associated integrity, privacy and performance standards;
  • Processes for resolving community deficiencies, problems and challenges; and
  • Processes for upgrading the community vision and associated services and infrastructure.

General and specific community frameworks that guide communications and purpose should be derived from available reference models wherever possible.  Because these frameworks exist at a relatively high level of abstraction, they are generally viable as reference models that can be refined and extended for local use, thereby enabling cost-effective and accelerated deployment of frameworks that remain relatively agile.

3.      Community relationships and processes must be defined

The execution and evolution of services must respond to best practice guidelines and to the currently expressed needs of both requestors and providers if a community is to support an appropriate array of high integrity information, transactions and dialogues in a cost effective and timely way.

The best practice principles and guidelines need to address the following.

  • All community languages, vocabularies, models, business and technical standards, information and transaction systems, and publishing, discovery, transaction and performance management tools are to be acquired from the highest available sources and refined and extended to suit local needs;
  • All member relationships with a community are to be established and populated by members using community approved or provided tools: membership should not require intermediated set-up processes undertaken by community ‘experts’ (the role of experts being to establish viable frameworks and platforms);
  • All processes and transactions between a requestor and a provider that carry specific information are to take place directly between the requestor and the provider.  An agent may act for a requestor or a provider only after clearly defined agent roles and responsibilities have been established.  No agent can act for both a requestor and a provider.  The community host should not be considered for an agency role;
  • Third parties that provide community methodologies, platforms and tools are not to have access to, or be associated with, the processing or manipulation of user specific information, nor the definition or processing of user requests; and
  • The evolution of a community, through fragmentation or consolidation, is to be undertaken directly by community participants on an incremental basis, not by third parties acting on change requests.

The implementation of the currently expressed needs of members requires the following:

  • The unification of designer and provider roles through applicable platforms, methodologies and tools;
  • Platforms to enable comprehensive community communications and management of member status and roles, available methodologies and tools, and member transactions;
  • Governance methodologies to review and agree proposed changes to membership, programs, services and their content;
  • Quality assurance and performance measurement methodologies to assure continuing compliance with agreed frameworks;
  • Tools that enable providers to;
    • describe the scope of their programs and services;
    • populate each program or service described.
  • Tools to assure community availability.

4.      The governance of communities must include all aspects of the agreed frameworks and platforms

Prospective and accredited members of a community must establish their relationship with the community, its infrastructure and its platforms, and progressively describe and populate their program and service offerings in the context of that framework. 

The community framework, including its infrastructure and platforms, need to address the following.

  • An end-to-end community design that has viable connections between its various planning, procurement and service delivery modules such that there is no loss of information or process integrity;
  • A declaration of community vision and purpose and all community languages, vocabularies, models, business and technical standards, information and transaction systems, and publishing, discovery, transaction and performance management tools and standards that must be respected;
  • All community requirements that must be addressed by prospective members;
  • The ability to capture and review all prospective member proposals and to provide access to tools and methodologies for accepted members;
  • The ability of members to describe and update each program or service offering and its privacy, security and performance parameters;
  • The ability of the community to support the discovery, presentation, and population of offerings described by members; to enable service delivery, provide necessary confirmations and to ensure that integrity and performance are within agreed ranges; to take the necessary action to ensure compliance with agreed parameters; and
  • The ability to update and evolve community vision, infrastructure and platforms based on community member needs.

5.      Members of communities must be able to share and grow

Members of a community are also likely to be members of other communities, and will want to be able to interoperate between them and to evolve their relationships as suits their own mandate and purpose.

At a basic level, a member of a community may see themselves as a “passive client” of the community, working through an agent who utilizes agent- or community-tools and platforms while retaining very little of the inputs and outcomes in their own environment. Over time, a community member may want to deepen their relationship with one or more communities, initially retaining a record of the inputs and outcomes, but potentially using the same or similar tools across a number of communities and developing interactive and interoperable relationships in place of the initial agent interface and presentation layer.

The extent that new communities can be built on and develop through common reference models enhances their ability to achieve a fast and cost effective launch, and be part of a growing ecosystem. The larger that ecosystem, the more likely that common tools will become available to participants, thereby further accelerating the trend to peer-to-peer, or horizontal relationships.

Over time, a service innovation agenda will increase both the viability and attractiveness of ever larger peer-to-peer assemblies. While the natural inclination is to start small, the underlying reference models must be well formed and substantially complete. Also, in the absence of mature standards, the prospective community must be comprehensive enough to support both a micro formats agenda and an implementation to ensure payback from the investment being made.

This raises the age old problem: who goes first? Follow-on peer-to-peer implementations will certainly benefit from early efforts. A supplementary attraction of reference modelling is that, even if initial models are incomplete, through refinement and extension they can evolve, reducing the need to start over that is so common with a change management orientation.