4 Collaboration Architecture

This Paper purports to be about Collaboration Architecture but, so far, has limited itself to collaboration models and community development: the processes we might use to develop aspects of collaboration, or a

comprehensive set of collaborative structures. We have also made passing references to the underpinnings that have the potential to truly populate a collaboration, to Service Oriented Architectures (SOAs) and to Government Interoperability Frameworks (eGIFs). We need to put these various components and perspectives into context if we are to have a Collaboration Architecture.

 

A Collaboration Architecture is a means of describing and placing the various elements that support business activity within a framework that enables any number of loosely coupled peer-to-peer relationships to release

substantial value for participants in a way that does not limit or compromise other relationships. Such a Collaboration Architecture will identify the necessary governance, business, standards and technology components and approaches and how they need to be configured to enable members to be accredited, and information, services and knowledge to be defined and delivered, independent of organizational affiliation. It will clarify the roles each participating entity will play in relation to each component of the architecture and enable the application of appropriate SOA and eGIF concepts.

 

The most critical need is for a conscious shift in focus from partners to the collaboration as a whole. There remains an ever-present risk that the collaboration focus will bio-degrade back to a series of cluster or partner relationships, however the prospect of such regression is limited by public sector commitment to comprehensive policy definition and broadly based application. Provided our horizontal collaborations are reflective of a public sector policy orientation then we can protect the integrity of our collaborations but, if our horizontal collaborations become selective or focused (listen for the 80:20 rule), then we risk a reversion to a partner focus.

 

Figure 4 below shows the Collaboration Architecture, which is expected to have multiple layers (or slices). SOAs and eGIFs would enable the definition, population and execution of each layer or slice. The critical value of the Collaboration Architecture is to map the entity/role relationships between these layers. Within a business level articulation of the Collaboration Architecture there are two zones: a Development Zone, and a Deployment Zone. The Deployment Zone will have an external interface with the Development Zone and an internal interface with the existing Legacy environment. Over time it is expected that the Deployment Zone will expand and the Legacy component of that zone will be of diminishing significance. This is because, as the required functionality for a given legacy system evolves, new business rules and services can be developed in the middle tier (interface) and registered as common components that can be reused by other applications.

 

“The Objective of the Collaboration Architecture is to position all of the elements

that support Business Activity”

 

Figure 4: Positioning the Collaboration Architecture and SOAs/eGIFs

 

 

In Figure 5 below, we show for any layer (or slice) of the architecture, the ‘external’ interface between the Development and Deployment Zones and the ‘internal’ interface within the Deployment Zone that reaches out

to the Legacy System(s).

Figure 5: Collaboration and Service Oriented Architecture