Today we’re excited to announce support for a new specification in SCORM Cloud- cmi5, which is something that doesn’t happen all that often in its history. Along with making cmi5 support readily available in SCORM Cloud, we’ve also added support for cmi5 to some of our other products including SCORM Engine and SCORM Driver.
Obviously, supporting a variety of specifications is a huge part of what we do well at Rustici Software. More than anything, though, I think it’s important for us to be conscious of, and to explain well to all of you, when and why we add support for a particular specification.
So, what is cmi5?
cmi5 is technically a profile of xAPI which means it piggy backs on top of things already well defined in xAPI, but adds specificity in others. For cmi5, this means that certain xAPI statements are required, and launch is handled in a very specific way.
For me, it’s the launch piece that’s so important. From xAPI’s advent years ago, there have been issues with launching content. In the earliest days, we at Rustici Software defined a very simple launch specification that several content vendors picked up on. It was good enough for the time being, but it wasn’t really good enough in practice.
So, over the last couple of years, many people including Bill McDonald (as Chair of the working group) and Art Werkenthin and others at RISC have put a lot of energy into considering how their AICC work could be applied to launch in the xAPI world. The result is that we have a good solution for launching content via xAPI.
Why it matters
Years ago, as we at Rustici Software and others around us started evangelizing xAPI, we made some mistakes. We talked about all of the things that could be enabled by xAPI, the things for which it was necessary but not sufficient. Over the last year or two, we’ve really started to fill in the gaps to make it sufficient as well. And while launch isn’t the dreamiest of capabilities for which xAPI is a solution, it is absolutely fundamental.
If content launch is ultimately going to transition from SCORM to xAPI, cmi5’s support for launch will be a requirement. And further, so many other activities actually benefit from having a well defined, implemented, and adopted specification for launch. So for now, we’re excited to share that Cloud now offers vendors and others a great place to test cmi5 based launchable activities. We hope this helps spur the development of many xAPI/cmi5 adopters.
Here at Rustici Software, we’ve been spending a lot of time lately hosting SCORM Engine and Content Controller installations on behalf of our clients. And we have learned a lot of interesting lessons from the experience. I’ll be talking about hosting SCORM Engine here, but all of this stuff applies directly to Content Controller as well.
We started hosting things for folks because we realized several things all at once:
Our clients are having to spend way too much time and money to host our products themselves. We kept seeing integrations falter because of delays in provisioning infrastructure and cost issues. Finding dev/ops folks that can deploy and manage web applications is really difficult and really expensive, and so a lot of our clients were settling for inadequate deployments that didn’t scale and didn’t hold up well under pressure
Hosting web applications well is really hard. It’s not too hard to stand up a server and run Engine on it. It’s a lot harder to build a secure, highly available Engine environment that can hold up under heavy traffic spikes, scale to meet demand, and not cost a fortune.
We are really good at hosting web applications. Our experience building SCORM Cloud taught us that we’re actually really, really good at hosting web applications at scale, and it felt like we were in a great position to provide a useful service that saved our clients time, money, and hassle.
What’s a user? How many can we support?
When folks are integrating with SCORM Engine, two questions always come up: “how do I build a system that can serve X number of users?” and “I’m not really sure how many users I have, how do I spec a system based on a wild guess?”
We thought about this a great length, and decided that there are two numbers that really matter:
Concurrent Users – The number of users that the system can serve at once.
System Population – The system’s ability to serve a given annual user base.
System Population, in particular, is a number that we thought about a lot. Engine installations very rarely have every registered user of the system engaged at once. But sometimes (like right before a deadline) they all pile on at once, so we designed our Managed environments to be able to grow and shrink so that they can meet peak demand without costing the Earth.
Once we figured that out, we went and locked ourselves in a dungeon laboratory* for a few weeks and ran load tests against every kind of setup we could think of. We came out of that with a set of system specs that we could look at and say, “yup, this will do the job for X Concurrent Users and Y System Population, and here’s what it will cost to make it go.”
When we looked at the economics of our clients hosting a robust, production-quality web application, it was clear that the cost of the computer hardware wasn’t the problem. Nor was datacenter space, bandwidth, storage, or any technical bits. It was the human beings and human intelligence needed to build and maintain that were our client’ greatest cost and most scarce resource.
When you add it all up, the annual costs for hosting a production-quality web application that is going to serve a population of 50,000 users quickly goes north of $150,000. That’s too much. Way too much.
Fortunately, we’ve got a lot of people here at Rustici that do this kind of thing all day long and are really good at it, which lets us provide Galaxy-class Managed Hosting of our products at a fraction of what it would cost our clients to host themselves. We can provide a production quality, geographically redundant, highly secure, zero-touch Managed environment for under $35k annually. That’s a huge savings in time, money, and effort. To get an idea of what it might cost using our services to host your instance of Engine or Content Controller, check out our fee schedule.
So, when considering Engine or Content Controller, remember that you have options when it comes to who handles the deployment. We’re here to help. Just ask.
*Well, it was more like a nice sunny office with hot coffee, snacks, and ping-pong, but a dungeon sounds way cooler.
Just having a great product is not enough. Many people forget that exceptional customer support is one of the most important parts of an organization’s ongoing success.
Why? It’s most often the only contact a customer has with your company. Receiving the help they need (while interacting with awesome people) encourages customers to stick around. Further, it reinforces the lifetime value of your products and increases customer loyalty.
Well, not really, but it’s the closest thing that the e-learning industry has to offer in the area of “prestigious awards for doing awesome things”.
It’s a lot of fun working with both hosted and locally installed platforms. Yes, technically the deployments vary a lot (and I’m thankful for our super talented developers who manage both worlds), but it gives us the chance to work with many types of companies and products.
Some folks gravitate towards the flexibility of SCORM Cloud as a hosted solution that scales with them as their business grows. Other folks require a more controlled, locally installed solution and need our Engine player for those very reasons.
Recently we’ve noticed another benefit of offering both deployment options— migrating from one deployment method to the other as business models change.
Case in point? Atomic Learning.
Older Posts »