Stop Building It From Scratch!
How to Build a Reusable eLearning Framework
Chad Udell (twitter.com/visualrinse) & Mark Tovey (twitter.com/em_tee)
Overview: APIs are prevalent in RIA and web design and development, but are relatively unheard of in
eLearning development. Using APIs has a quantifiable return on investment and is a standard way to build
robust functionality in application development. How can we start to move towards this sort of development
process in eLearning?
Why This Is important: There are significant cost and time savings possible in standardizing around an API
for use in your learning development organization. Shorter development cycles, improved quality and more
reliable testing results will be immediately noticeable. Protection of intellectual property and improved risk
management for your company are also areas that will see benefits in implementing an API.
Things to Consider: Creating an API is a worthwhile activity, but one that requires planning and collaboration
between the API developers and the API users. Once you create an API and deploy it, it’s difficult to come
back and wipe the slate clean if you need to start over. An API is a contract between two mechanisms. An
API should consist of concise, intuitively named methods, properties and events. Any codebase utilizing the
API can then be written to a simple interface, able to ignore the implementation details of that interface.
How You Can Get Started: The first steps in creating an API are completely analog! Take stock in what you
have to develop repeatedly in your courses. Survey your developers and determine what are some of the
more difficult things they have to create. Review your existing code library for the “greatest hits.” Research
publicly available APIs and note what you like and don’t like about them.
For further reading:
How To Design a Good API and Why It Matters: http://www.scribd.com/doc/33655/How-to-Design-a-Good-API-and-
How do you know you when an API is right for you?
If five or more of these situations apply to you, you’ve probably outgrown
using a code library. You should consider moving to an API.
1. Your development team is three or more people.
2. You have junior level developers that need to produce “senior level products.”
3. You have to ask questions like, “Where is the latest version of the LMS connection script?” more than
once a month.
4. You have projects with external developers with whom you need to collaborate.
5. You want everyone on your team to use the company’s “Best Practices” in creating their code.
6. Your code will have a multi-project shelf life. Some modules will be reused many, many times.
7. Your investment in your intellectual property is worth the effort required to create an API the right way.
8. You are standardized on a toolset, and need to standardize on an implementation path.
9. You have been burned by quality issues that could have been remedied by a standardized approach.
10. You are looking for new ways to enhance productivity in your development team.
11. You are deploying your code as a software product (SaaS or otherwise).
If the following situations apply to you, proceed with caution.
1. You work alone.
2. You don’t have a standard toolset.
3. Your technology decisions are often ruled by forces outside of your department.
4. Spending dozens or hundreds of hours to get your toolset in order is not an option.
5. You have no need for reusable code as assets across multiple projects.
6. Code as intellectual property is a foreign concept to your organization and you won’t be able to change
that anytime soon.