Episode 11.
Music
IT folks are familiar with frameworks or models that use layers in order to organize information about whatever their systems are.
Generations of IT professionals have been taught the Open Systems Interconnection, or OSI model, to understand network protocols in seven layers.
That's largely then replaced by the Transmission Control Protocol, slash IP, TCIP, and its four layers.
Those are very important for network professionals to understand, aren't they?
Well, sure, yeah, well, maybe. You know, they are important if you want to understand the principles of how networks operate,
but most network managers can keep a well-designed network up and running without referring to it.
But we're getting further away from the intended focus of this episode.
Okay, back on task. Can we understand technology in schools using layers?
I think we can, and I think it does help us to have a more complete understanding of what exactly it is that we're managing when we're managing school IT.
The layers that I talk about are a little different from those that you encounter with the OSI or the TCIP models, however.
Those focus on technology, you know, hardware and software, the protocols and rules that are programmed into the operating system and applications that allow them to communicate with each other.
My layers focus on technology, along with how it's used and by whom it's used.
Do we really need another model with layers?
One of the things I'm trying to develop in this podcast is there is a difference between the IT we need in business and the IT we need in schools.
These differences mean that we need to include both IT professionals and educators in decisions that we make about the systems we deploy and how we change them once they have been installed.
So, tell me about your model.
My model comprises five layers. I'll name them in a moment and you can find a visual on my website, hack science.education.
But in general, it starts with the IT infrastructure, that same stuff that you encounter when you talk about the OSI and TCIP models, although of course I include end user devices.
But anyways, at this level, the technology and the decisions are very predictable. They're very manageable.
They're tame problems. And if you listen back to episode seven, you'll learn exactly what I mean by tame problems.
This is technology that we can control and we can test the systems that we build before we deploy them.
My model ends with IT being used in classrooms with teachers and students.
What happens at this level can be very unpredictable and we can't control it in the same way that we can control the design of IT systems.
This is a typical wicked problem. Again, have listened to episode seven to see exactly what I mean by that.
I think I have it.
Five layers as we move from one to another, things are less controllable.
Yeah, eventually we get to things being less controlled, but each layer it's necessary that we include more factors in our decisions.
That makes sense. Tell me about first layer.
The first layer of my model includes the information technology systems themselves. That's the infrastructure.
This would include of course end user devices, computers and laptops and tablets, peripherals, including hardware and software.
In addition, we would include all the networking infrastructure, the ethernet cables, routers and switches and access points and gateways and firewalls.
All those devices that we use to control how our computers talk with each other internally and also externally with the internet,
those are all systems that we include in this first layer.
Interestingly, the operation and the management of devices at this level are really not as similar from how you would manage this stuff if you're working in a business.
The fact of the matter is if you want to restrict network access using a firewall, it doesn't matter if you're working in a manufacturer or a school,
you're going to go and access the firewall in the same way. You're going to configure the rules in the same way.
When we think about building systems at this layer of my model, the networks and the systems that we plan and install can always be very clearly defined.
We have to have some kind of system requirements that are going to be used by the network architects or by the purchasing department to figure out exactly what it is that we need to build and or buy in order to meet the needs of,
or at least meet our perceived needs.
This is an engineering process. Known procedures can be used to configure the devices.
Engineers can test the operations before they're deployed.
You can tell the IT systems are up and functioning if you can put an adequate device in front of every user who needs one.
And if you can ping devices internally or externally and you can get a connection back to confirm connectivity, then really the folks who are responsible for this layer of my model have done their job.
So this is the domain of IT folks?
It sure is. They have expertise to make sure everything is reliable and secure.
Of course, if no one ever uses systems or if no data were stored on them, then keeping them reliable and secure would be quite easy, wouldn't it?
I sense the next layer has to do with how systems are used.
In the real world, no IT system is designed without a task in mind.
Those tasks inform the system requirements that the architects and the buyers use in order to make decisions.
The tasks are very specific and the system is designed for a single task.
The computing capacity that's built into the Internet of Things is an example of this.
Your Internet-connected door velled. It functions to show you who's outside at your door, but it's not useful for calculating your budget, for example.
The IT systems created in schools tend to be general purpose computing devices.
We use them for many purposes, some of which are known prior to the system requirements being defined, and some of those are unknown.
So we try to, in many cases, future-proof our systems.
This requires that we build in some unused capacity in the beginning.
That's one reason that schools and other organizations are looking to adopt cloud-based infrastructure whenever they can.
They're no longer required to buy unused capacity.
They can just use what they need by spinning up additional resources in the cloud.
We can test the first layer of school IT by passing random data to confirm connectivity and capacity to access resources.
Designing IT for tasks requires IT professional support hardware, error connection, other protocols to produce meaningful, accurate, insecure data.
These additional requirements specify the operation and functions that will affect the selection of systems and its configuration.
The reality is that we need to not only connect to our accounting systems, but we also must be able to access the data.
So we are in some ways, we must align what we do on our side to align with the expectations and the designs of the folks who are managing the other systems.
Our clients must be configured to work with their servers, so we can't just do anything we want here.
We must align our practices with theirs.
So if you think about it, IT professionals really do have less control at this level.
They must align what they do with how other systems have been designed.
Yeah, I guess you're right.
But the protocols that are used to secure sites are similar, however.
So when we go and configure our systems, our clients to connect to the accounting system, that's going to be still an engineering problem.
Even though we are complying with the expectations of somebody else, we still have a way to test this before we actually deploy it and have folks accessing our financial data over the internet.
Got it. Layer 1 is the IT infrastructure. Layer 2 is connecting it to data systems. What is Layer 3 of your model?
Technology systems are designed for unknown users, and the assumptions that designers make about users can have important implications for how effective their systems are.
Ted Rose begins his 2015 book The End of Average with the story of fighter pilots in the 1940s who were unable to control their planes because the cockpits were designed for the average body.
Once cockpits were adjusted to the actual bodies and they could adjust to the actual bodies of the pilots, they found that more pilots were able to control their planes, fewer planes crashed, and fewer pilots died as a result.
While the consequence of designing IT systems in businesses and in schools is not as dangerous as the inability of a pilot to fly their plane, the principle is the same.
Once users begin interacting with IT systems, additional variables are introduced based on the user's capacity and their preferences, and those variables cannot be controlled by the designers.
When there is a disparity between designers' preferences and what the designers did and the user's capacity and preferences, then there is something that must be negotiated.
We must conclude that the system doesn't work and it's got to be changed.
So once we add in users, this do begin to be less controllable.
You're correct. We really have two options when there isn't agreement between the degree to which the systems meet the need. We can either train users and how to use it or we can redesign it.
Which should we do?
There's no real easy answer to that question. It really depends. Making those decisions is something that I've described in episode 5.
We have two layers left. I bet things will get less predictable at each.
You are correct. Teachers accomplish two different types of tasks using IT systems.
First, there's highly predictable tasks that resemble those that are performed by business users.
IT professionals can plan and test for functionality.
We're talking here about things like data management, recording attendance and grades, using structural tools in which the goals and the practices are aligned with workforce training, designing systems to meet the needs.
These kind of needs are very familiar to many IT professionals and they're similar to those used in other organizations. They're known and they are very predictable.
Second, however, we have those teaching tasks that are associated with what I call the authentic learning environments. These can be unpredictable.
They're driven by students' interests and teachers' interests. They rely on diverse sources of information and the products of students' learning emerge as the projects emerge.
So we can't really tell when we start exactly what students are going to need to be able to do.
When teaching with these methods, teachers tend to question their practices. They explore new options. They experiment with new tools and technologies.
These teachers and, of course, their students also may be trying to use the IT systems for purposes that were never conceived of when the system requirements were first defined.
Obviously, this introduces even more variables and greater uncertainty into the design and configuration of the IT systems that we have in schools.
Some teaching tasks can be unpredictable. That makes sense. So what is your fifth layer?
When we add students into the mix, things are even less predictable.
Tell me more.
One of the most distressing realizations one makes when they become a teacher is that the best teaching plans are really just guesses.
Teachers apply their knowledge of the curriculum. They're familiar with the students that they have, what they've done with similar students in the past when they're planning, but each classroom is different.
And what might be engaging and meaningful for one group is dull and boring to another.
Students arrive in classes with varying skills, different motivations, and different perspectives, and they even have some clever insights.
None of this can be known when they're planning, and this can lead teachers to revise their thinking and update their lessons, including what they want to do with IT.
So if they can respond to their perceived changes and needs in a timely manner, educators often ask for permission to change the system.
They want to install new applications. They want to upgrade things. They want to access data systems that they might not have had before.
We all know, at least some of us know better than others, that that's not always a good idea.
At least it's not a good idea if you want secure and reliable and robust systems, which is what we all really want.
In this situation can cause conflict in the schools between educators and IT professionals.
Resolving these conflicts really does require that individuals and groups look at the problem from the other's perspective.
The layers you have described seem to include three variables. IT infrastructure, tasks done with the IT, and the users who do the tasks.
Yes, and we can also understand them through the lens of whether they're tame or wicked.
IT problems and IT systems are a very tame problem. We have known solutions for them.
We can figure out if they're working or not before we deploy them, so it's tame.
When we start thinking about tasks, some are very predictable, thus tame, but other teaching tasks especially can be less predictable, so they're more wicked.
And then when we introduce students into the mix, this is a very unpredictable group. Things get very wicked indeed.
IT professionals who recognize these layers should be able to recognize where their expertise ends.
They must include users and they must include the tasks that they want to complete, that those users want to complete into their network designs.
Educators who recognize these layers will also see where their expertise ends, and they must allow the IT professionals to manage systems to ensure that they're robust and reliable and secure.
Because it doesn't matter what you plan to do with your students, if the systems are down, then you're not going to be able to do it anyways.
But then of course, if you and your students can't do what it is you need them to do, then the system isn't much use to you, is it?
So there are my five layers of IT in schools. Layer one is the IT infrastructure itself, the hardware and software.
Layer two is the tasks that we use to complete with our IT systems. Layer three begins to include users in the mix.
Layer four is including teaching tasks in the mix, and then layer five is including students and teachers using the IT for teaching tasks.
And I think you'll see that at each layer, things get more complicated and we have less control over what it is that we do.