Are your staff and students happy about remembering multiple usernames and passwords? Is your technology team enjoying creating separate username and password combinations for each system/software in your school district (not to mention that each system has it’s own password restrictions)? I highly doubt it.

For the past 8 years of my career, I have continually been astonished by the amount of time and energy school districts spend on creating user accounts for staff and students. The “active” directory becomes so fragmented that managing user accounts literally becomes unmanageable. This causes each department to spend massive amounts of time managing user account data that is never in sync with any other system. As a result, users (staff and students) are frustrated with remembering how to login.

This is NOT a good model for any school district.

The World of Single Sign On

For years, Single Sign On (SSO) has been the solution for this problem. Unfortunately, many have fostered the bad habit of adopting a software solution before investigating if it provides an SSO solution. I argue that if a piece of software does not provide SSO, the software should not be adopted.  Yes, I said it and I know it’s extreme but the cost to build it is low and upside benefit is high.

The reality is that building SSO into your software is not some monumental task.  As an example, Google Apps for Education (GAFE) provides schools with FREE tools to allow their staff and students to have a seamless login experience. The process goes like this:

  1. Create an account in an Active Directory (1 username, 1 password)
  2. Allow staff and students to sign into all systems with their GAFE account.

Note: I did not say create 1 account for Google, 1 account for Windows, 1 account for a gradebook, 1 account for company XYZ.  If a piece of software does not provide SSO, districts should seriously question purchasing the software.

Why Would a Software Vendor Not Provide It

You really have to ask yourself why a software vendor would not provide something that is so valuable to a user.  And this goes to the heart of the issue – the lack of openness in Education Software.  Some vendors actually charge fees to districts that want to integrate their own data via an API! This is insane.  Is it insecurity in their own product?  Why do they feel the need to lock down their customers and not provide them value?  Many hide behind a veil of security issues.  This is either ignorance or laziness or just an excuse.

Of course, security is important. We want to protect student privacy and have that obligation. But through standards like Open Authentication we can achieve the goal of security with the simplicity of single sign on.

Edtech Software needs to be more open.  Whether that is something simple like enabling SSO or providing a public API for interoperability between apps.  The mentality of building closed software is dated and ending.  Edtech vendors will need to open up their software because schools and teachers are increasingly demanding it and adding it as a criterion for adoption.

The World After Single Sign On

But we need to take things one step at a time.  So once an SSO solution has been adopted it’s now time to unlock your data. Logging in with 1 username and 1 password is only the first step in the process. In my next post I will discuss the power of API (Application Program Interfaces).  SSO combined with API’s not only provides the best user experience but allows different systems to communicate with each other. Teachers, Students, Admins, and Parents can see a complete data picture in a single glance.  This idea of efficiency and openness is the criteria by which all software decisions should be made.