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.
We see two distinct ways to innovate learning standards. One is to push the community forward by developing and evangelizing emerging standards. We do this all the time. The other is to create and deploy new approaches around existing standards.
Our SCORM Engine powers content launch for the vast majority of LMSs in the world. Our SCORM Driver is used by all but one of the largest rapid authoring tools and countless content creators.
Today we’re announcing Content Controller. We believe that content providers have been underserved. Limitations imposed by SCORM have discouraged innovation that can help them realize the value of their compelling content.
Many industries have transitioned to “as a Service” models. Software as a Service is quite familiar, and Infrastructure as a Service and Platforms as a Service are well on their way too. In each case, customers are able to leave more of the problems to their providers, and providers are able to iterate much more quickly and proficiently than their customers. Providers are also able to generate long term recurring revenue by this model.
In the elearning world, content has long been deployed physically, as digital assets, from content provider to customer. While this has long been required by SCORM’s architecture, it also created real issues.
LMSs are prone to have duplicate and out of date content.
Customers are liable to use content well beyond its licensed period and/or licensed number of learners.
Content providers are blind not only to the utilization of their content, but to the value of it.
Content Controller addresses all of these issues by allowing the content provider to host their content centrally while deploying it for use by their customers. Built on top of our existing SCORM Dispatch product (meaning this is well vetted), Content Controller circumvents SCORM’s limitations to allow both provider and customer to have what they need. This allows Content Controller customers to offer Content as a Service (CaaS).
Content Controller provides version management, license management, content analytics, and sophisticated equivalencies that allow content owners and their customers to do things they haven’t previously.
I’m really excited about this product personally because I think some of the best creative work in our industry is being done by content providers. This will allow those companies to take proper advantage of their unique abilities. We’ve developed this initial version of Content Controller in conjunction with four customers, and the first of the deployments are live and have already delivered tens of thousands of launches. This is just the beginning.
You might have heard that we like to take care of our employees by offering them things that most employers wouldn’t ever consider providing, and most employees wouldn’t dream of receiving.
I believe that we create such great products because we have an amazing company, not the other way around.
We talk a lot about SCORM, the Tin Can API, and the products that we make. We know these things well, and we enjoy talking to the world about them.
Older Posts »