I was asked to look into the CPD-Eng project by the JISC programme managers, specifically in conjunction with the JISC “Benefits Realisation” work, because this project in particular has a lot to do with portfolio technology and interoperability, and then with skills and competences in professional development.

CPD-Eng is a JISC-funded project, to quote from the JISC project page, “to integrate systems that support personalised IPD/CPD, applicable to professional frameworks.” The lead institution is the University of Hull, and much of the documentation can be found through their own project page.

The project start date was April 2009. At that date, the tender documentation spelled out the aspirations for the project. The main image that emerges from the tender documentation is not of a new e-portfolio system as such, but of an approach to integrating evidence that may reside on different systems, all of which has relevance to an individual’s CPD. “CPD-Eng will provide the innovative, personalised infrastructure that will support the work-based learner through a new suite of flexible pathways…”

The original plan was to deploy Sun’s Identity Management software, perhaps aiming towards Shibboleth in the longer term. These were overtaken by various events. Consultations with various people related to JISC lowered the perceived value of Shibboleth, and in any case there needed to be a more open approach to accommodate the wider potential usage of the tools.

One of the shaping factors was the requirement to integrate the Hull institutional VLE (“eBridge”), based on the SAKAI framework. Right from the outset there was explicit mention also of integrating e-portfolio systems that have adopted Leap2A. Clearly, one of the main areas of future evidence of the success of a project that claims to be about integrating systems will be the actual extent of integration carried out. In the project plan, WP7 states that the most important integration is between eBridge and other partners’ VLEs. The nature of the integration, however, was not specified at the outset, but remained to be filled in through earlier work in the project itself. A theme that does continue throughout the tender is about the ability of learners to control access to information that may be stored in different places.

The baseline report (version 0.9 of August 2009) spells out more graphically where the project started from. Perhaps the core point at the centre of the vision is the statement: “A portal system has been established alongside an Identity Management (IDM) system that allows self-service management of the learner’s identity. CPD-Eng will develop a robust and scalable approach to interoperability, access and identity management that is both easy to use and seamless, allowing the learner to control their personal e-portfolio-type technologies and share the content within them with whom they choose.” Compared to this, the rest of the baseline report is interesting background.

After the baseline report the project took stock of the situation. Some other portfolio products were “not very engineering”. TAS3 was not seen as very user-friendly. Academics still wanted the software to sit in SAKAI. Unfortunately, the lead programmer resigned to take up employment elsewhere, and the project was left without a developer. After looking into advertising for a replacement, and consulting with the JISC Programme Manager, it was decided to put the software development out to tender. MyKnowledgeMap (MKM: a York-based company with a track record of producing software in the area of skills and portfolios, for users in education and various professions) was judged as the most suitable partner, though they lacked experience of SAKAI. The project leads arranged for MKM employees to be trained by the University’s consultant, Unicon.

This was the situation for the following progress report of 2010-03. Three software modules were being developed within SAKAI:

• Aggregator
• Mapper / Tagger
• Showcaser

The Aggregator module “provides a mechanism for users to gather their artefacts and items of evidence from across multiple sources.” While it is relatively easy simply to copy information from other sources into a system like this, the point here is explicitly “not” (emphasis original) to copy, where it is possible to establish access from the original location.

Tagging is conceived of similarly to elsewhere, in terms of adding free text tags to aid categorisation by individuals. Mapping, in contrast, is designed to allow users to connect artefacts to elements of established “skills, competency and assessment frameworks”. This function is vital within CPD practice, so that users can present evidence of meeting required standards. Such frameworks are stored externally. JISC is now funding some “Competence structures for e-portfolio tools interoperability” work finishing July 2011, and CPD-Eng can play a useful role in determining the standard form in which competence structures should be communicated. MKM does have existing techniques for this, but they will be critiqued and adapted as necessary before being adopted as a consensus.

Showcasing is conceived of similarly as in many portfolio tools. Official review is supported by routine copying of showcases to uneditable areas. This works for e.g. health professionals, because they want a carefully controlled system, though others like engineers need that less, and prefer to do without the extra burden of storage. It is planned to support review without necessarily copying showcases in a later release. Access to showcases was originally only via SAKAI, but it was later recognised that limiting to SAKAI access was not ideal, particularly as many professional bodies have their own e-portfolio systems.

Working with health professionals, archeologists and others (there is also interest from schools, and a pilot with BT), it became clear that a useful system should not be tightly bound to other institutional software or to SAKAI, so what was needed was an independent identity management system.

In the Benefits Realisation plan from the summer of 2010 came a clear restatement of the core aim of the work. “At its centre is a scalable, interoperable and robust access and identity management system that integrates and control access to personal e-portfolio technologies.” But what is the relationship between the CPD-Eng work and other identity management systems? Sun’s Identity Management software had been abandoned. The European funded TAS3 work (in which the University of Nottingham is a partner) was seen as too complex for professional end users. A question which remains outstanding is to clarify the relationship of the system devised with the trials funded by JISC under the PIOP 3 programme, involving PebblePad, the University of Nottingham and Newcastle University. It would be good to see a clear exposition of these and any other relationships. All that can be said at this stage is that in the perception of the CPD-Eng project, none of the other identity management systems really worked for them.

The next piece of documentation is the progress report from September 2010. This is where the questions really start to become clearer. Included in this massive report is the complete text of the final report from “Personalised systems to support CPD within Health Care”, a mini project extending CPD-Eng concepts to health care professions. In this very interesting inner report, there is a large body of evidence about CPD practice in the health professions. This leads to a second major question. What about the whole process side of portfolio practice? CPD-Eng has very clearly focused on the rather technical side of facilitating the access management for artefacts. This is certainly useful at the stage when all the evidence has been generated, when it remains to gather together appropriate items from different places.

Much portfolio practice centrally involves reflection on evidence as well as its collection and showcasing. The phrase “collect, select, reflect…” is often used in portfolio circles. (Helen Barrett adds direction/projection and connection.) Reflection is often vital in portfolio practice, because the mere presentation of a selection of artefacts is no guarantee of a clear and coherent understanding of how and why they fit together. Because unprompted reflection is hard, institutions often support the process. It is useful to be able to build in some aspect of process into the same tools which hold the information and resources to be reflected on, and it is useful to hold the reflections themselves in a place that they can be easily connected with the things on which they are reflecting.

Increasingly, it is recognised that the peer group is another vital aspect of this reflection process. In a situation where staff time is short, or the staff seem uninvolved, possibly the best stimulus for reflection and re-evaluation of ideas is the peer group. Portfolio systems designers themselves have recognised this, by integrating social tools into the portfolio software.

It is clear that MyShowcase is not primarily designed to support reflection. (More information about MyShowcase can be found at www.my-showcase.org which has a demo and links, and through www.mkmlabs.com.) However, one of the consequences of implementing a stand-alone version is that users found an immediate need for some of the functionality that is normally provided within full-feature e-portfolio systems. In particular, users want to collect evidence together and send a link to a tutor for feedback. The link is sent to the reviewer by e-mail, who can then access the system for the purpose of leaving feedback comments. Indeed, some users feel that fully-featured e-portfolio systems are just too complex for their users’ needs, and value a simple tool because it does less, and does not explicitly support reflection by users. So this is the only extra feature implemented in MyShowcase that comes from the fuller set normal in portfolio software.

If one has a hybrid system including MyShowcase and some other portfolio tool, the portfolio functionality will therefore mainly be fulfilled in the portfolio tool, not MyShowcase. But what of the feedback that has been designed into MyShowcase for standalone use? To be useful, it would have to seen within the portfolio system. And generally, any information used in MyShowcase needs to be presented to the associated e-portfolio system for use within whatever (e.g. reflective) processes the portfolio software is used for. We don’t want the flow of information to be only one-way, or there to be solely unidirectional two-stage processes. What is needed is an effective two-way integration, so that the chosen portfolio tool can access all the information gathered through MyShowcase, the user / learner can gather further feedback and reflect, and present the outcomes of that further reflection back into the MyShowcase pool, for onward presentation.

Recent discussion has confirmed that MyShowcase is not primarily conceived of as a replacement for a full e-portfolio system, though it does act as what we might call an “evidence resource management” tool. Perhaps we can now discern an ideal answer to where this might lead, and where things ought to be heading, and the questions that still need to be answered.

If a service such as MyShowcase is to work effectively alongside e-portfolio tools, there needs to be transfer of information all ways round. In addition to this, and because it can be implemented stand-alone, there needs to be Leap2A export and import directly between MyShowcase and a user’s personal storage.

Looking at things from a user’s perspective, a portfolio tool user should be able to make use of MyShowcase functionality transparently. It should be able to be used as invisible “middleware”, allowing the front end e-portfolio system to focus on an appropriate user interface, and portfolio and PDP processes (including reflection and feedback), with MyShowcase providing the funcationality that allow the user to link to evidential resources held in a variety of places, including VLEs, HR systems, other portfolio tools, social networking services, blogs, etc., possibly including sites with sensitive information that will only be displayed to authorised users.

The MyShowcase architecture in principle could provide resource management for “thin portfolio” services, where the storage is not in the portfolio system. Is it, or could it be, adapted for this?

As part of the PIOP 3 projects, Leap2A connection between different systems was been investigated by PebblePad, Nottingham and Newcastle, and this work needs to be carefully compared with the MyShowcase architecture. What exactly are the similarities and the differences? Are they alternatives? Can they be integrated, combining any strong points from both?

In order to facilitate this two-way interaction, there really needs to be substantial compatibility between the information models in all the connected systems, so that there can be meaningful communication between the systems. This does not necessarily mean a full implementation of Leap2A in each participating system, but it does mean at least a reasonable mapping between the information managed and corresponding Leap2A structures, because Leap2A is the only well-implemented and tested model we have at this time that covers all the relevant information. If there are requirements that are not covered by Leap2A, this is a good time to raise them so that they can be incorporated into discussion with other parties interested in Leap2A, and our common future thinking.

I hope I’ve made the issues clearer here. Here are collected recommendations for taking this work forward, whether within the current CPD-Eng and Benefits Realisation work or beyond it.

• What the portfolio community really needs is multi-way integration of portfolio information, artefacts and permissions, based around Leap2A concepts.
• Leap2A export and import by users should be provided for standalone implementations of MyShowcase, just as with other portfolio systems that have adopted Leap2A.
• Showcases in MyShowcase need to be exportable as Leap2A (as with PebblePad WebFolios and Mahara Views).
• For transparent integration between different sources of information in a portfolio architecture, identity management approaches need consolidating around good workable models such as OAuth
• The PIOP 3 work by PebblePad Nottingham and Newcastle, as well as TAS3, need to be carefully considered, to extract any lessons relevant to CPD-Eng, even if their appearance is only in the final report.
• The opportunity provided by any planned project meeting should be fully exploited in these directions.
• Another meeting should be planned around the wider questions of e-portfolio interoperability architecture, covering not only the technical aspects, but the requirements of practice as well, such as reflection, feedback and comments on non-public items stored elsewhere.