LISS Ethos

What is the LISS Ethos?

Data should be free to flow both securely and easily between any connected system. Integration should not be a competitive space, and should be equally accessible to even the smallest start-up, who may want to embark on innovation. LISS Vendors should actively encourage and assist others in integration. Education departments and other larger entities should promote this ethos.

Standards should be clear, accessible and easily implemented. Use of bespoke or 'vendor specific' protocols (including flat-files) should be discouraged, in favour of LISS, or similar generic and global protocols like SIF, and perhaps with data aggregators like (UK) Wonde, Assembly, Groupcall, (USA) Clever.

What is the cost of LISS?

There is no cost for LISS. The LISS alliance specifically promotes an open (yet secure) flow of educational data between systems, with no prohibitive barriers, either technical, or financial. The LISS ethos is that schools own their data, and it should be free to transfer as best suits. Competition between vendors should be on features and service and marketing, but NOT on walled gardens that lock data into proprietary formats, have fees for schools, or fees for other vendors to connect.

Some providers in global education markets levy high fees to vendors who want to integrate with them, or require purchase of full and expensive licenses to their platform, which may not be otherwise needed. Some vendors charge a per-school fee to vendors for 'integration'. Some charge schools themselves such a fee. LISS does not, and strongly discourages this ethos. It is viewed by the LISS alliance as anti-competitive and restrictive, stifling innovation, blocking smaller start-ups while favouring large incumbents, and not in the best interests of the education technology space.

With LISS, data should always be secure, but always be free.

Barriers to Integration

There are many onerous barriers to efficient integration, understanding these below, helps overcome them. For market regulators, or educational departments, it would provide benefit to schools and vendors alike, if these barriers were well understood, and ideally legislated away. Barriers provide friction. Policy and tender requirements could stipulate clearly that e.g. the schools data is not a commercial commodity, and access to this should be freely provided at all times via integration to any vendor who seeks it. The flexibility and transparency and active encouragement of integration should be viewed by authorities as awarding higher points when considering various technologies which will be used by their schools.

Technical barriers to Integration

Standards that require many months to understand and implement, and significant cost and effort to maintain. The high level of complexity can be a huge barrier for vendors, and thus a lack of opportunity for schools to have access to innovative systems that help them improve further. Standards do not need complexity to be 'secure', and often complexity itself can be counter-productive, leading to more possible attack vectors that are harder to spot, or lethargy in humans who may take shortcuts to workaround complexity.

In a number of cases, vendors use outdated or poorly documented API's, and this is a barrier. It could be argued that this is just them being slow to update or adopt a more modern protocol like LISS, but this can also be used as a means of control. Without commercial incentive to improve their integration, vendors can advertise that they DO provide integration, yet it's so onerous that it provides a natural barrier. Only well funded and technically competent players can navigate these old API's and obscure support responses. Merely having an API for access still doesn't mean the data is freely accessible.

Time Barriers

Integration requires communication with other vendors to diagnose issues, obtain access credentials or seek vendor's product integration related support. This gives rise to a barrier where there may be significant delays in responding. It's difficult to point to 'delay' as a hostile means of discouraging integration innovation, but it is certainly a barrier. If it takes too long, customers may give up, and the controlling vendor may benefit from long wait times and slightly obscure support resources. Similar to legal cases where you need funds and time to get justice, some big players can wear you down. For any writing standards and expectations from an Edtech marketplace, there should be minimum expected standards for support responses, so that time barriers are not able to be used as a subtle means of control and market dominance.

Financial barriers to Integration

Some integration protocols require high fees for certification or membership. Some vendors charge high fees to other vendors for 'access' to the data they use, despite it being owned by the school. In a sense, they are selling access to data they do not own, under the guise of it being a fee to 'facilitate' the access. This may be high annual fees, but also a fee 'per school'. The cost to support integration should be minimal, and not related to the number of schools. Once an integration gateway is established, it really doesn't matter how many schools are using it. But if in a position of competitive dominance, vendors can and do leverage this for commercial returns.

Some systems require the purchase of a license to operate their technology, as in a copy of their software or annual license, purely for integration purposes. There may be some vague reason this could be seen as needed, yet it's not needed by the vast majority of players. Many vendors use client instances to assist integration, and have no need to purchase or 'use' a potential competitor software in the way it's intended. Purchasing an entire copy and annually licensing an expensive school administration software is a big barrier to a vendor who has no need to use this. The LISS alliance encourages vendors to provide free test server instances, where integration can be tested without having to pay onerous site licenses - for technology where the use isn't to operate a real school.

Some vendors charge other vendors a proportion of their revenue from the school, in order to provide access to the schools own data. A commercially enforced and onerous revenue share, for which the school gets no benefit, and the vendor wanting integration is paying significant fees, such as 10% of their product licence fee may be paid as 'Integration fees' to the dominant vendor.

Some vendors charge for access to training datasets - databases or files, including annual updates. The provision of dummy data and test servers with anonymised dummy data should be free, and is free for the vast number of global providers. The exception from some larger players with market control means innovative start ups incur significant and ongoing costs paying for essentially worthless data.

Membership and Compliance barriers

There may be reasons to support paid membership (often tied to revenue) and paid compliance, but the ideal is a completely free protocol in all aspects. LISS currently imposes no fees of this nature, but if there were, they would be low. Fees introduce friction where free promotes innovation. An analogy is blockchain and it's main use case crypto-currency, which has removed many barriers in the cost of transactions, and the regional barriers that exist in a traditional monetary system. Protocols are openly published and collaboratively agreed, without a single point of oversight, or costs to entry. This has led to significant innovation, and yet much higher security and privacy in financial transactions.

The ideal is that LISS protocol is sufficiently robust and transparent, that there need be no need for formal compliance. Any system that asks for data in the right format, and with the right credentials can be provided this data. The LISS alliance doesn't need to 'certify' that systems support integration correctly, and while still a bit complex, it's still relatively easy to diagnose if there are issues. A gold stamp certification process may provide false security, especially as standards and data evolve over time. What matters more is that if it is broken, it can be fixed fast and transparently - rather than there being an authoritarian body that 'controls' the use of and certification of the protocol. It should also be pointed out that LISS itself isn't a security protocol, but uses others. So security should not be used as a reason to require any formal compliance. LISS defines how data is transferred, but this is done using standard SSL communication protocols, of which LISS itself doesn't dictate any standards around.

Competitive barriers

Vendors who control school data have a competitive incentive to construct walled gardens. This is where they deny or discourage access to this data, from other vendors who need it. This is to discourage other vendors from providing overlapping / competing services to schools, and reducing their own revenue or goodwill as a result. The walled garden may be through the various barriers above, or be simply a case of a vendor stating to another that they 'do not wish' to integrate. This has been used in the past, and drawn the attention of the industry regulators, such as the UK's Competitions and Market authority.

Legislative barriers

Data privacy policy and legislation may provide an onerous barrier. GDPR allows processing of personal data outside the EU for example, but this is often debated by data and IT managers. They may openly deny, or actively discourage systems which operate with data outside the EU. This may be foreign servers, or foreign support staff. Innovative startups almost always operate globally. It's a given. Remote workers and cloud systems do not follow traditional geographic borders. So data privacy can be a big barrier to data integration. There exists for example ISO standards for quality. Should educational entities and more specifically key individuals want to cover themselves, they may try to enforce compliance with these standards as a way to reduce perceived risk. The result is that big incumbents who have the financial resources will be able to comply, where the innovative startups run by that one smart individual - have no hope of compliance with such high barriers. As such they risk being cut out of the market, and more unfortunately, the schools risk not having opportunity to benefit from such innovation. There is certainly a case for data privacy, but it must be viewed with balance and opportunity cost.

By way of example, car companies may be allowed to legally drive some test vehicles on the road, which do not currently meet the normal recognised standards. Provided there are few of these, there is value in allowing such real world testing, to ensure and support innovation. Allowing some products which have very low market share but do not yet cover some of the bigger barriers may be acceptable to permit, where stronger / tighter regulation should be applied to those with larger market share. Dynamically adjusting the balance between legislative barriers and innovation is helpful. It's easy to see it as 'acceptable' to enforce ever increasing standards of privacy and security, without proper visibility in the often much larger cost in what innovation is being blocked by this. Barbed wire and armed guards around your private home may be seen as a way to increase security, but what loss in amenity - probably far more than the value of items that could be stolen.

Education Department Support for Healthy Integration

For an efficient marketplace that encourages healthy innovation, and allows schools to access the very best technologies, regardless of the size, or length of time a vendor has been in the marketplace (may be a red flag), the following may be helpful to consider:

• Require all vendors to support generic integration protocols, like LSS. For those who don't, consider allowing this 'with penalties' vendors may be slow to change, but without blocking them onerously - additional fees for them to operate in the marketplace may provide the much needed incentive to get on board with integration. For example, a say, £300 pa fee per site paid to an authority, for a vendor that doesn't support one of the accepted protocols for connectivity may be helpful to both. The vendor will work to align with integration, and the authority is paid funds which can go towards assisting vendors to understand obligations, and otherwise incentivise. Other means to discourage may also be applied, such as listing these vendors in the 'second class' vendor integration list

• Penalise or prohibit vendors from charging a fee to other vendors, to purchase their system, or a license to their system, or significant fees that are beyond what is reasonable to charge for integration support

• Penalise or prohibit vendors from charging a per-site license, or a proportion of revenue gained from the school. Require fees for integration support to be zero, or at most what would be fair and reasonable, within stated guidelines.

• Penalise or prohibit vendors from charging vendors a proportion of their own revenue, as a commercial requirement to providing access to school data. Integration costs should be zero, or at most very minimal, and solely covering costs, not as a revenue stream able to be commercially exploited (on school data they don't own themselves) due to market dominance. We note equivalent protections applying in some financial markets. Previously, vendors charged customers onerous fees for credit card payments, well beyond the actual fees charged. Meanwhile banks were charging onerous interchange fees. Financial authorities introduced legislation to restrict maximum fees for these to be solely the reasonable fees incurred, and not as a hidden additional and lucrative revenue stream.

• Penalise or prohibit vendors from charging schools any form of integration fee. Such fees must only be incorporated into the normal pricing, and not be listed in a way that indicates it is a problem, or levied only on those schools who use integration - as this provides a natural barrier.

• Penalise or prohibit vendors from bundling, such that high fees and forced revenue sharing are required to be a 'partner', where there are other benefits tied in with this, such as marketing the applying vendors products to the dominant vendors customers. This at outsent appears fair, where there are a range of benefits, and a cost. However, it is then forcing the marketing spend as a requirement to access integration. In essence, integration alone should ideally be free, and if vendors want to additionally pay to access the 'marketplace' of a larger vendor, they have this as an option - and not as a dependency.

• Penalise, prohibit or strongly discourage vendors from charging for dummy sample data, or access to test databases. This is an example of gouging, using the need to work with the dominant vendor's system 'with data' as a means to derive additional revenue. Here it's not charging for access to the school's data, but regardless, this is another hidden cost unrelated to the actual fees, and onerous, and charged by the use of unfair competitor dominance.

• Require vendors to actively and enthusiastically support others in integration, and respond to support requests on integration in a timely manner.

• Consider the dominance of the vendor in policy. Vendors who operate as the main school admin system may be in a more dominant position to (potentially) stifle innovation and commercially benefit from restrictive trade practices relating to innovation by smaller players. Similarly, a vendor who has significant market share in a market may be viewed as needing to be judged by a higher bar. Also, a vendor who has a particularly critical product may be in a dominant position to control access to the data, such as a new tool to profile student academic performance or timetable in ways others can't compete. Should such vendors abuse their position of control by integration, this should come under more scrutiny.

• Publish guidelines for data privacy such as GDPR in context of education policy. Much confusion still surrounds this area. Having clear policy from the department will lower the barriers in control. School IT managers may stipulate incorrectly that all school data must be held only in UK based servers for example, or van't be viewed by foreign vendor staff when conducting support. This is not uncommon, and is difficult to counter, as sadly security seems to take dominant precedence to effective use of the data for it's intended purpose. GDPR (for example) supports data being held, viewed and processed outside the EU - but without being able to reference educational authority acknowledgement of this, it becomes yet another barrier. Simply stating an authority permits and accepts as GDPR compliant, systems which use school data outside the EU, provided it follows the required guidelines, would be very helpful in allaying fear and misunderstanding.

• Provide a means for vendors to appeal to authorities, if they feel there are barriers being applied unfairly, such as being blocked from integration on grounds of unreasonable costs, or delays in integration support responses. If upheld, authorities should be able to fine vendors, or restrict their ability to operate in the market, such as preventing them selling new licences.

• Publish information to schools so they understand the value of healthy integration. Often vendors state there is no business driver to integrate properly, yet schools have no idea of the value the miss. An authority encouraging schools to push themselves (as customers) for this will incentivise vendors to get on board and support integration.

• Review integration protocols and establish a reasonable test for difficulty to implement. Favour protocols that are not an onerous barrier to integration. For reference, vendors have fully supported the basic LISS integration within one developer week, where some other protocols may require over six months of developer time - and far more time ongoing to maintain support for. The disparity in this is stark, and should be considered by authorities when promoting or valuing integration methodologies.

• Provide small grant funding to vendors to implement effective integration protocols. The grant should specifically exclude big players who have resources to fund themselves. Smaller players (e.g. Revenue < £2m?) should be incentivised and funded (e.g. matched or partial funding) to add this. This allows vendors to focus their resources more directly on innovation in EdTech, and less on the administration of their business, or the Integration efforts which don't add core value, and are not paid for directly by customers.

• Make it clear to vendors that the authority values frictionless, secure data integration, via globally recognised protocols with wide support. This may be seen by

  • • The authority openly publicly listing vendors who do and do not comply - Not quite meant as a wall of shame, but certainly to provide transparent visibility on which systems can talk with which. This information isn't readily available from any other source at present.

• • The authority publicly listing integration protocols that are authorised and encouraged. Not being listed here doesn't mean the protocol or vendor can't be used (e.g. an old bespoke vendor standard), but it is discouraged if not listed as approved.

  • Indicate to vendors that they will be judged in tenders, and favoured more if they can demonstrate active and enthusiastic compliance with the protocols listed, and enthusiastic support for integration, including in their effective and current technical documentation, and in their vendor support communication.