In June the e-Framework Partnership begins a major review of its work on service-oriented approaches to software design. Ian Dolphin provides the background to this development:

The e-Framework grew from early attempts to explore the promise of service oriented approaches to software design in the context of learning and teaching. Whilst this promise seemed considerable - offering significantly greater flexibility in the development and delivery of services to support learning and teaching, together with the potential to re-use smaller software components and thus reduce initial and maintenance costs - it became rapidly obvious that efforts could not be confined to learning and teaching if the maximum benefits were to be obtained. The e-Framework therefore set out to map a coherent approach to the design of service oriented systems to support not just learning and teaching, but the additional, intertwined areas of systems to support research and administration.

Rather than basing the e-Framework approach around what has become known as ’capital letters SOA‘, the full realisation of a Service Oriented Architecture, the e-Framework consciously took a service oriented approach, mindful that institutional and other systems would take time to transition to such a state.

The design of service oriented systems, however, requires a degree of up-front analysis which is both time consuming and expensive. Early efforts in service orientation in education were likely to take place in silos - teaching and learning, research, administration, and libraries (an area which clearly crosses the first three, but remains, in many senses, distinct) - which in general often had a poor record of communicating with one another in a meaningful manner. The approach developed by the e-Framework therefore had the objective of being as neutral as possible; capable of being applied or mapped to by development efforts in any of these distinct areas of development, across national boundaries, and at differing scales of deployment. The intention was, and remains, to capture the early efforts of education's transition to service oriented systems in a way which would facilitate sharing.

Alongside the development of the technical approach, then, was the development of an international knowledgebase. This knowledgebase contains design artefacts, based on the e-Framework technical approach, which captures experience from a variety of innovative software development projects and activities in differing contexts across the partnership.

The early experience of both the approach and the experience of its application has resulted in the articulation of an e-Framework Technical Model. This model aims to make the approach more comprehensive and more comprehendible; to show how the different e-Framework documentary design artefacts relate to inform the design of systems.

This work has taken time and effort to realise. It has been intimately intertwined with the experience of the education sectors in the United Kingdom, Australia, The Netherlands and New Zealand. With the production of the overarching technical model, a knowledgebase with over fifty documentary artefacts, and a further fifty in review, and widespread experience of use of the technical approach, it's time to pause and take stock.

From June 2009, the e-Framework Partnership will be conducting a review of its work to date, and seeking to validate (or otherwise) the service oriented approach it has developed. We will be seeking feedback from those engaged in innovation activity, software development, and service delivery across the partnership from a variety of contexts. Key issues the Partnership will seek to address as part of this process include:

Is the central objective of the e-Framework - the creation of a meta-approach which provides a neutral means to articulate the design of software services - a valid, feasible and useful objective?

Does the technical model the e-Framework has developed provide a coherent overview of the e-Framework approach? How might it be improved, and what other factors should be taken into account?

Are the documentary design artefacts in the e-Framework service knowledgebase useful for those developing or re-factoring software services? Are there specific areas of work or contexts where they are of greater value than others? How could they be improved? What do they not capture which would be useful to capture in a standardised format?

The progress of the review will be reported in future newsletters.