Open Badges at CIPD

As CIPD increasingly experiments with free and low cost digital learning (see the forthcoming Future of Learning course – developed with Home Learning College, and our first MOOC: Working Digitally: Social Media and HR),  we’ve been thinking about how we incentivise and accredit those courses. Hence this week’s musings on Open Badges.

Analogue badges

I don’t know about you, but when I was a kid I loved badges. In fact one of the (few!) things I liked about being a brownie was all those badges sewn on to my uniform. (Although I never did get the Needleworker or the Hostess badges!) We children of the late 70s/early 80s were spoiled for badges: my Adidas tracksuit fairly bristled with various BAGA gymnastics badges and International STA swimming badges.

brownie badges

Digital badges

That analogue yearning to earn, collect and display badges for participation and achievement is no less acute in our digital lives. Particularly in the spheres of learning (for example Kahn Academy) and collaboration, and especially in order to ‘gamify’ online activities: the pre-eminent example being Microsoft Xbox’s 360 Gamescorer system. But digital badges appear all over the internet, two great examples are TripAdvisor (contributions) and FourSquare (check ins).

Khan Academy's digital badges

What’s wrong with digital badges?

Kahn Academy, Xbox’s Gamescorer, FourSquare and TripAdvisor are all examples of closed badging systems, meaning you can’t display badges you’ve earned within a particular platform elsewhere on the web. Digital badges just aren’t interoperable, they’re not transferable between systems.

Another issue with digital badges is their validity and credibility: how can an pixel-generated icon represent a ‘trusted credential’?

Open badges to the rescue

Open badges are similar to, but not to be confused with digital badges. In 2011 Mozilla (the chaps behind the FireFox internet browser) started work on an open source framework that supports web-based badges to solve the issues of validity and interoperability.


Valid and credible badges

Open badges aren’t just icons. Embedded within each badge image is a set of metadata that describes (amongst other things) how, where and when it was earned, who earned it, and who issued it.

What’s metadata you might ask?

Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. Metadata is often called data about data or information about information. (Niso)

This wonderful illustration by Kyle Bowen neatly strips back the metadata that sits behind an open badge.

Image illustrating the metadata baked in to an open badge

The metadata can then be viewed by anyone wishing to check up on a person’s credentials, or just to find out more about the badge.

badge metadata displayed

Image courtesy of Open Badges 101 course

Interoperable badges

Mozilla’s open badge infrastructure is an open standard. Essentially this means open badges are:

  • Free and open: Mozilla Open Badges is not proprietary. It’s free software and an open technical standard any organization can use to create, issue and verify digital badges.
  • Transferable: Collect badges from multiple sources, online and off, into a single backpack. Then display your skills and achievements on social networking profiles, job sites, websites and more.
  • Stackable: Whether they’re issued by one organization or many, badges can build upon each other and be stacked to tell the full story of your skills and achievements.
    From Mozilla’s Open Badge Wiki.

On the issuer side of things Mozilla’s BadgeKit includes all the tools an organisation or an individual needs to create, design, assess and issue badges.

For the earners, their badges are can be stored anywhere, even your own computer, but it’s most practical to collect them up in a ‘backpack’. (Why not an adidas tracksuit I couldn’t say.)

Mozilla’s backpack is a repository for the collection, management and display of your badges. (And because it’s a federated, open ecosystem, Mozilla have made the source code for both BadgeKit and Backpack publicly available, so other providers can develop their own versions.)

From your backpack badges can be embedded and displayed across numerous platforms (including Moodle, Mahara and WordPress) and social media sites. (A little like videos can be embedded across different sites, but are hosted on YouTube.)

Badge thinking at CIPD

We’ve a way to go yet before we work out our (open) badge strategy at CIPD. Although we’ll be starting out by issuing badges for various activities on the Future of Learning course, for example for curating great content and writing insightful blogs and posts.

But some of the things we might issue badges for are:

  • Participation in CIPD’s community platform
  • Completion of a MOOC
  • Participation in a webinar
  • Speaking at a CIPD conference or event
  • Completion of CPD

We’re going to need to think carefully about our badge taxonomy and learning pathways, and things like how we might reward and integrate offline activities such as participation in programmes such as Steps Ahead Mentoring or volunteering at Branch events.

So this is all work in progress, and I’ll be blogging more about the Open Badges initiative at CIPD in the coming months.

And finally, a confession

I’m part way through the Think Out Loud club‘s excellent Open Badges 101 course. Highly recommended for anyone wanting to find out more about open badges.

With this blog, I’m hoping to earn my first digital badge with the 101 Course, to put it in my backpack, and display it on my LinkedIn page. Whaddyathink: should I get my badge?


Open standards and open platforms: ‘play nicely children’

Thanks to Matt Goral who contributed to this post.

My colleague – the incredibly talented Matt Goral – and I have recently been noodling on the challenges of connecting up CIPD’s various content technology platforms. In particular the Learning Management System (LMS) and CPD (Continuing Professional Development) tools to the CCMS, the new website and CRM system we hope to implement in the next couple of years.

We’re nothing if not ambitious at CIPD. We have a veritable smorgasbord of digital aspirations, which can never be satisfied by a single platform. Instead, we will need to build an ecosystem of tools, working in concert, in harmony together.

It is of course easy to be seduced by the lure of slick, off the shelf solutions to complex and strategically pressing digital requirements. But when those platforms are proprietary tools, you soon run into trouble trying to connect them all up, to feed data – and content – between systems, and to provide customers with a seamless digital experience.

To build a harmonious content technology ecosystem tools must play nicely together In order to build that harmonious content technology ecosystem the individual tools must be able to connect to and easily communicate with other tools – to play nicely together. If a tool cannot do that, it will not fulfil our aspirations regardless of the individual functionality it offers.

Data is what connects system together

A tool must understand data generated by another toolWhen we talk about connecting systems together we specifically mean enabling a tool to understand data generated by another tool. The simplest, most desirable situation is when one tool outputs a data format that the other tool already accepts; in this case we can simply pass the data directly from one to the other.

Maintenance of ‘glue’ programs is the hidden cost of implementing proprietary systemsIf the systems cannot do this, a third tool is necessary, which translates the data from one format to another and acts as the ‘glue’. Data formats of proprietary systems are not usually publicly available, making this data translation either not possible, or losing information (structure and metadata) during the process. Maintenance of such ‘glue’ programs is the hidden cost of implementing proprietary systems.

It is undesirable to choose a system, only to find out later that you have to pay out considerable costs to make it work with other systems; this is the concern that IT departments raise the world over, and the reason they must be involved from the outset in any digital project.

Open standards and open source

Open source tools are designed with interoperability in mindSo, wherever possible, it is recommended that you use open standards and open source, over closed, proprietary software. Open source tools are designed with interoperability in mind – that is they use open standards to communicate with other programs.

But it’s not just Matt and I who are advocates for open source! Over the past few years increasing numbers of high profile voices have come out in support of open standards.

The UK Government heavily advocates open standards in its own Information and Communications Technology [ICT] Strategy, aiming to provide better public services for less cost.

[The] Cabinet Office … mandates that when purchasing software, ICT infrastructure and other ICT goods and services Government departments should wherever possible deploy open standards in their procurement specifications. This is because Government assets should be interoperable and open for re-use in order to maximise return on investment, avoid technological or supplier lock-in, reduce operational risk in ICT projects and provide responsive services for citizens and business.

Typical benefits of open source software include lower procurement prices, no license costs, interoperability, easier integration and customisation, fewer barriers to reuse, conformance to open technology and data standards giving autonomy over your own information, and freedom from vendor lock in.

Funnily enough, a couple of weeks ago a group of us at CIPD were lucky enough to talk to Andy Beale, Director of Common Technical Services at the Government Digital Services agency. Andy said his two guiding principles for IT were to make sure that every service is accessible through the web browser (‘the browser is the window into what we do’ he said) and to use open standards wherever possible. So, direct from the horse’s mouth, so to speak!

Similarly the charity Jisc, champions of the use of digital technologies in education and research, make a strong case for systems interoperability using open standards.

Building our Virtual Learning and CPD capability on top of COPE

Central to content strategy at CIPD is our COPE (Create Once Publish Everywhere) solution. Hopefully, if we get the go ahead 😉 the first year’s work will involve the implementation of a Component Content Management System (CCMS). We’ll also take that time to scope requirements for a dynamic delivery server. The CCMS will hold the ‘raw’ DITA XML – the building blocks from which we will build products; the dynamic delivery server will hold the ‘published’ products and distribute them to onward channels and platforms.

It is with these two systems that we will provide the backend functionality that will enable CIPD to the build world-class Virtual Learning and CPD solutions our customers deserve. If our COPE solution seamlessly integrates with open platform LMS and CPD systems, we can exploit incipient and unforeseen innovations in the Virtual Learning space.

The COPE solution is preeminent

The management of ‘intelligent’ source content must always be the preeminent considerationTo deliver on our digital aspirations it is imperative that individual systems work together, but the COPE framework should be considered the preeminent solution. That is, other content delivery platforms, be they website or Virtual Learning, should build on the central foundational technology of the CCMS and dynamic delivery server. Otherwise we will make compromises in terms of the content structure and metadata – fitting them for a particular delivery channel. We have a diverse publishing portfolio (training content, research reports, web content, online products, textbooks, professional books, etc.). This coupled with the inevitable, exponential growth of digital channels, mean that the management of ‘intelligent’ source content must always be the preeminent consideration in our content technology solution.

Our digital aspirations as seen from the customer perspective


The customer wants a seamless digital experience: they do not want to have to use multiple logins for different tools. Customers also want to reconnect with previous experiences on another platform/device. For example, they might want to send comments and reflections made in the CPD tool through to the Virtual Learning platform, or vice versa.

This is achieved by establishing an ecosystem of tools that work well together, and ensuring the data transfer between them is ‘lossless’, that is content structure and metadata are preserved.

Linking and Search

The customer wants to see suggested content that is relevant to them. Moreover, they would like that content to be personalised specifically to them, rather than simply to their customer group, and that suggestions get ‘smarter’ as the customer interacts more with the system. They also want to be able to search for specific topics and content.

This can be achieved by applying CIPD taxonomy terms at content source (i.e. at authoring stage in the XML) and the Virtual Learning and CPD platforms using data from the proposed CRM system. The use of taxonomy and a Content Server’s faceted search functionality can generate such content and recommendations automatically, without hard-coding the links (like Amazon’s ‘you might also be interested in’). This implies that the delivery platform needs to be connected to and make use of the data provided by the CRM and the Content Server. It will also need to be able to send its own data back to those systems.

Portability and Rewards

Rita Gunther McGrath talks of people’s ‘entrepreneurial careers’. No longer are jobs for life, instead we move from job to job, employer to employer. Therefore our customers will want to take their CPD data with them and use it with each employer’s system and/or a public CPD platform. This is particularly true of the feedback and acknowledgement they received for their effort, but also any comments and reflections they might have made.

We need to give customers their CPD data in an open standard formatWe cannot predict the ways in which the customer would like to use their data, how they might like to present it, or what systems they might want to use it with. So to make this portability as easy, and as flexible as possible, we need to be able to give them their data in an open standard format (e.g. XML, LEAP2A, Open Badges, etc.). After all, it’s their data. (See NHS Hackney and the ePortfolio Data Liberation Front.)

It’s a philosophical argument. It’s my data. About me. I want it liberated.

Agility and future ‘readiness’

Finally, the customer wants functionality that they and we cannot even begin to predict right now. The only way to keep up and respond is to be able to experiment with and customise the platform. With proprietary platforms we are at the mercy of the vendor as to which new functionality is implemented, when and how.

Architecture of agility

By investing in open source tools using open standards – interoperable platforms that ‘play nicely together’ and can be customised and adapted – we can build an architecture of agility, giving CIPD the best chance of delivering on our digital aspirations, now and in the future.