I wasn’t planning on writing this post, but I’ve become aware of several recent conversations that have led me to the conclusion that it would be useful to get this out.
For people who adopt software, trying to judge the value of so-called “standards support” in a product can be an incredibly frustrating experience. Standards implementations often fail to live up to their promises and, worse, it can be very hard to tell in advance of installing and running the software whether or not the “standards support” it supposedly provides is actually going to meet your needs. There are several reasons for this. First, creating a standard is hard. You have to think of all the different ways people might want to use the technology in all kinds of different environments, and then find some overlay that can meet all of those needs while still being able to work with existing software packages that are very different from each other. For example, Peoplesoft Campus Solutions and SunGard Banner are both SISs, but their architectures and data models are substantially different from each other. The same is true among the various LMSs. If you have a standard that is supposed to represent data from any SIS to any LMS (like, for example, the IMS Learning Information Services standard does), then you have to come up with a representation of that data that maps to the different data models and works with the different architectures. This is always hard, and it’s harder on some software developers than on others. For example, if your system doesn’t already have some pretty robust generic ways to interact with web services, then it will be more work for you to support a standard that is built on web services.
Further complicating the picture is that, while it is almost always in vendors’ interest to say that they support a standard, it often isn’t in their interest to do the hard work of actually supporting the standard, especially in the short term. Standards tend to reduce the total amount of money that customers spend on integration, which generally means that somebody is going to make less money. This hits companies that depend on service revenues harder than it hits companies that mostly sell product because at least with the product you can build the cost of the standards implementation into your license fees. But the truth of the matter is that, most of the time, everybody makes less money after a standard has been implemented, at least in the long run. This is because a standard, by definition, commodifies the function it is standardizing. A capability cannot be a differentiator if everybody does it. Therefore, while you might be able to continue to charge for the capability, particularly if you implement it very well and early, customers will, over time, increasingly expect it to be an affordable part of the package rather than a major expense (including the ongoing expense of maintenance that comes with a consulting-based custom integration).
The net result is a situation where it is both technically easy and financially convenient for the outcome of standards implementation to be nothing more than one more meaningless bullet point that vendors can add to their glossy product brochures. But it doesn’t have to be that way. You can hold your vendors accountable for delivering the actual value that the standards promise, if you know the right questions to ask.
Second, find out if the vendor has added extensions to the standard that are required for integration. Extension isn’t always a bad thing, which is why many standards explicitly provide extension mechanisms. However, extensions that break the minimal interoperability that the standard promises are always a bad thing. Oracle has not extended LIS in SAIP and has committed to supporting the finalized version of the plain vanilla LIS application profile with no extensions required to achieve interoperability shortly after that finalized version comes out.
Third, find out if there are any official conformance tests and, if so, whether the software you’re evaluating has passed them. LIS doesn’t have an official conformance test yet, although one is planned. Basic Learning Tool Interoperability (BLT), another IMS standard, does have a conformance test. If a software package supposedly BLTI but hasn’t passed the test, that would be a red flag.
Finally, find out of the software has been tested against multiple implementations. As much as a standard can lower the barriers for interoperability, there is no better test either for the standard itself or for its implementation than seeing whether integration works as advertised with different products. If a supposedly standards-compliant product has only been tested to integrate with one other product, then you can’t have confidence that it has achieved the true interoperability that the standard promises. Oracle has completed LIS integration testing with Sakai, Moodle, and Schools on Facebook, is testing integration with another product now, and has testing plans with more in the near future.
Great post as ever, but I disagree that standards implementation results in a net loss of revenue for suppliers & service providers. When a standard is trusted (and that’s the key) it generates business for everyone. Look at any standard – SQL, HTTP, your electric plug & socket – haven’t these increased revenues over what was there before? Standards are good for everyone, and we need never make apologies for pushing the good ones.
Of course you’re correct that it is often in the vendors’ enlightened self-interest to promote standards—with two big caveats. First, the gains are often long-term while the losses are often short-term. That’s not always an easy trade-off for a company to take. And second, standards can shift around the distribution of who ends up getting the money that is spent. There can be winners and losers. From a macro perspective, standards can open up innovation, which is good for everyone. But that’s not the only perspective that businesses look at when deciding if, when, and how to implement.
Good points, from an interesting perspective. It made me think that in the technology commodification process (cf http://blogs.cetis.ac.uk/wilbert/2008/07/14/how-users-can-get-a-grip-on-technological-innovation/), closed source vendors probably also need a production level open source implementation of an open standard: to take the risk and establish the market in addition to the traditional reference implementation role.
I like the comment by Wilbert of production level code in some open source commons that implements portions of the standard. Blackboard has done some work on this with our support of the BasicLTI standard.
I think this is a thoughtful perspective and kudos to Michael, Linda and the Oracle team for work on LIS. I’ve written a more detailed response here with my personal views on some of these criteria and a plea for edutech commons http://bit.ly/cyxiAY