I remember when working for a software house specialising in NHS data systems in the mid 1990s that one of the services they offered was the transfer of data from legacy systems to their own system. This was done through various rather unorthodox means, the most popular being running 'screen reports' from the old system, and scanning each screen for ascii text which was captured and then input into the new system. Was that interoperability?
Of course, of a sort, it was. In those cases, interoperability existed as a requirement to have a solution to a problem. Whilst there was a demand to upgrade a system, there was a threat that in the upgrade process, data might be lost. This was a headache for managers: a moment of breakdown in the contract between the supplier of the new system and the demands of the operation which required an upgrade. For users of the existing system, the assumption was that whatever was decided in response to this breakdown would work and everything would be ok. For end-users, the means by which a solution might be found didn't matter, so long as it worked.
The case for interoperability standards arose from cases like this, where enough variety of jiggery-pokery was being done in different areas for people to think how it was that some agreements could be made as to how data could be moved from one system to another. However, the case for interoperability standards arose in different places in the organisation, depending on where the problems or breakdowns that the interoperability standards addressed arose. For example, interoperability of learning content arose from concerns of learning managers who didn't wish their learning content to disappear if they changed system. As with the NHS data systems, end-users on the whole didn't care how the problem was solved so long as the solution worked.
However, it is interesting to compare these managerial interoperability concerns with the interoperability concerns of individual consumers, which have similarly led to standards. MIDI, for example, is much closer to individual practice. The problem of "how do I get my electronic musical devices to talk to each other" is a breakdown at the individual musician level (but importantly not at the 'listener' level). By being a breakdown at the individual level, it produced a marketing opportunity for musical instrument suppliers and the standard emerged. Similar individually-based (and even more universal) breakdown situations can be identified in the 3-pin electric plug. Other standards present breakdown situations for users who whilst being consumers, provide services for others who may not care on the adherence to standards by their service providers. Standardised construction materials and tools for example, present builders with solutions to potential breakdowns, which may well be of little interest to the customers who they serve.
What is particularly interesting is that a standards-based solution to a problem at one level of practice may present a barrier at other levels. Examples of this can be found amongst the plethora unpopular EU-directives which irritate the Daily Mail. But the point there is that from the perspective of high-level bureaucratic processes, particular standards address specifically-identified points of breakdown in the regulatory system of the European economy. However, the intervention of a standard has impacts on practice of individuals for whom the breakdown which the standard addresses isn't a problem at all, and instead presents ordinary individuals with their own new problem: a solution at one level is a problem at another.
When this occurs in e-learning, what tends to happen is that the standard simply doesn't get adopted. Whilst at a high-level, the standard is deemed necessary, at the personal level it is deemed irrelevant. It is worse if at the high level, the standard is paired with some sort of 'desired change in practice': that will never fly! The trick with technology standards is to find those which address individual breakdowns, but the solution to which creates a transformed organisational framework around which the different layers of regulation can organise themselves. TCP/IP, HTTP, HTML and (maybe) W3C Widgets are like this: each address a specific end-user need, but in doing so scale-up to address higher-level needs too.
In education, however, we have a tendency to look on problems from a high-level, formulating grand designs as to how things ought to be done "in order to meet the challenges of the future". However, if this is done by ignoring the challenges of the individual at the present, then the high-minded standardisation efforts are likely to be ignored. In the graph above, column B shows an identified high-level breakdown, which is significant at a global international level, but insignificant at an individual level. Conversely, column A shows an individual high-breakdown moment (say, "my whiteboard doesn't work"), which is significant for the individual teacher, but as it approaches the global level is insignificant. Column C is the most interesting. It is some sort of interoperability solution which addresses the institutional and end-user need. But by doing this, creates the transformed organisational context which can address problems or cause reorganisations further up the system (for example, a Widget might address an individual need, but create the context for an AppStore, which might then provide new ways of thinking about the international coordination of education)
It may be that increasing real-timeness in the technology will make a difference both to the process of standards identification and needs, and to the processes of responding to end-user feedback. The issues over high-level breakdowns producing out-of-touch standards with end-users is really a problem of communication where transparency and timeliness of communication is the major factor. The real-time web might start to close the gap between individual practice and high-level management, where individual breakdowns become more transparent and available for inspection at a strategic level. In such an environment, the way we approach standardisation may have to change...
Of course, of a sort, it was. In those cases, interoperability existed as a requirement to have a solution to a problem. Whilst there was a demand to upgrade a system, there was a threat that in the upgrade process, data might be lost. This was a headache for managers: a moment of breakdown in the contract between the supplier of the new system and the demands of the operation which required an upgrade. For users of the existing system, the assumption was that whatever was decided in response to this breakdown would work and everything would be ok. For end-users, the means by which a solution might be found didn't matter, so long as it worked.
The case for interoperability standards arose from cases like this, where enough variety of jiggery-pokery was being done in different areas for people to think how it was that some agreements could be made as to how data could be moved from one system to another. However, the case for interoperability standards arose in different places in the organisation, depending on where the problems or breakdowns that the interoperability standards addressed arose. For example, interoperability of learning content arose from concerns of learning managers who didn't wish their learning content to disappear if they changed system. As with the NHS data systems, end-users on the whole didn't care how the problem was solved so long as the solution worked.
However, it is interesting to compare these managerial interoperability concerns with the interoperability concerns of individual consumers, which have similarly led to standards. MIDI, for example, is much closer to individual practice. The problem of "how do I get my electronic musical devices to talk to each other" is a breakdown at the individual musician level (but importantly not at the 'listener' level). By being a breakdown at the individual level, it produced a marketing opportunity for musical instrument suppliers and the standard emerged. Similar individually-based (and even more universal) breakdown situations can be identified in the 3-pin electric plug. Other standards present breakdown situations for users who whilst being consumers, provide services for others who may not care on the adherence to standards by their service providers. Standardised construction materials and tools for example, present builders with solutions to potential breakdowns, which may well be of little interest to the customers who they serve.
What is particularly interesting is that a standards-based solution to a problem at one level of practice may present a barrier at other levels. Examples of this can be found amongst the plethora unpopular EU-directives which irritate the Daily Mail. But the point there is that from the perspective of high-level bureaucratic processes, particular standards address specifically-identified points of breakdown in the regulatory system of the European economy. However, the intervention of a standard has impacts on practice of individuals for whom the breakdown which the standard addresses isn't a problem at all, and instead presents ordinary individuals with their own new problem: a solution at one level is a problem at another.
When this occurs in e-learning, what tends to happen is that the standard simply doesn't get adopted. Whilst at a high-level, the standard is deemed necessary, at the personal level it is deemed irrelevant. It is worse if at the high level, the standard is paired with some sort of 'desired change in practice': that will never fly! The trick with technology standards is to find those which address individual breakdowns, but the solution to which creates a transformed organisational framework around which the different layers of regulation can organise themselves. TCP/IP, HTTP, HTML and (maybe) W3C Widgets are like this: each address a specific end-user need, but in doing so scale-up to address higher-level needs too.
It may be that increasing real-timeness in the technology will make a difference both to the process of standards identification and needs, and to the processes of responding to end-user feedback. The issues over high-level breakdowns producing out-of-touch standards with end-users is really a problem of communication where transparency and timeliness of communication is the major factor. The real-time web might start to close the gap between individual practice and high-level management, where individual breakdowns become more transparent and available for inspection at a strategic level. In such an environment, the way we approach standardisation may have to change...
No comments:
Post a Comment