Finding the one application that will do everything is the “holy grail” of most learning technologists. That’s where companies like SAP and Saba position themselves – as a one-stop-shop to support all your formal and informal learning needs. These systems are very fully featured and configurable, so, as well as a large license cost, they also require a significant investment in implementation to make sure you’re getting full value from them.
Don’t get me wrong. There’s a place for these massive, multi-purpose, integrated application suites. Particularly in larger organisations, where processes and practices change relatively slowly, and software can have a lifespan of many years, if not decades.
But, often, you’ll be looking for best of breed applications, each supporting a specific purpose, such as video-sharing, social networking, shared documents, course booking, elearning delivery and content management.
The problem with this is that these applications don’t usually talk to each other out of the box, so there’s no data sharing, which means you miss getting the full benefit of the applications as a whole. Each one becomes its own silo of information.
There are four ways that you might want to consider joining these best of breed systems together. Each one can be considered separately, but, implemented together, would help you to build a powerful integrated system. Obviously the more complex your application landscape, the more complex (and expensive) this integration process can become – which may then tend you towards looking at one of the all-in-one systems, with best of breed tacked on where necessary.
In the outside world, many applications are using Twitter, LinkedIn, Google and Facebook for authentication. This makes it easier for end-users, who don’t have to worry about creating yet another username and password. It also allows those applications to have a shared set of user identities from which they can start sharing data.
The same is true for for organisations running multiple applications. By putting in place an identity management system (like LDAP) alongside a standardised authentication mechanism (such as SAML or Shibboleth), you immediately make those systems more usable, and therefore more likely to be used. It will mean that personal details only have to be entered once, and then can be used across all the software tied in to the ID management system.
ID management can get pretty complex, so, in many cases it’s better to work with an expert in the field when you’re setting out, or when you’re adding in new applications. This is particularly the case when working in a mixed economy of Microsoft and other platforms…
There are two reasons why it’s important to have consistent design across all your applications:
Visual design is important to achieve this consistency, but so also is a common navigation structure. A great example of this is the BBC website, where the common top menu is always present, with just its colour changing to reflect the service below.
Reports that contain useful and accurate information are vital tools for any manager. Most applications will provide reporting capabilities for their specific functional area. But sometimes you’ll want to try to correlate data from across multiple applications – for example, to see if the people accessing a particular page in your content management system are the people who go on to enrol on a course in your learning management system.
You could use tools like Google Analytics, which track page views and provide sophisticated reports on user behaviour. Or, for more complex reporting, you’ll need to implement some sort of analytics tool that will take the data from the disparate systems, join them together and produce the reports. Something like Activ8, Cognos, or Microsoft Reporting Services would all be good places to start.
Using data from one application inside another is often the best compromise between multiple, separate applications and one, monolithic application.
This can be achieved by building custom integrations between the software. But this is usually bespoke and therefore not easily replicable. It’s also difficult if the software is operating on different foundations, eg. PHP or .NET
A better approach is for the software providers to build a route into their systems that can be used by other applications. These routes are known as Application Programming Interfaces (APIs).
An API provides a standard way for other applications to read data from, and write data to a third-party application. Usually they work as web service, which means that the underlying platform is irrelevant, as long as the service has a web address.
I’ll look at APIs in more detail later this month, when I’ll examine:
Posted: 03 June 2013