Envoy is a multi-faced SIF agent that solves a number of challenges encountered by larger organizations implementing a SIF architecture to be shared by a large number of schools and/or local authorities. These challenges include: Accessing consolidated data from multiple schools as if it came from a single source with records from many school-level zones matched […]
In most larger organizations, several computer applications are used to support the process of educating students, in one way or another. The majority of these applications know about who attends the school, who teaches there, and who the teachers are. Some of them know the students' schedules while others know details such as the grades they received or detailed health-related information such as immunizations or records of injuries. The point is that much of this information is common to many of them.
So, what is the "best" approach to managing the information that is shared by these applications?
If you read about the theoretical foundations behind the different methods to interconnect applications, you will no doubt hear challenges to a message broker's ability to scale (especially coming from Enterprise Service Bus vendors). This is most likely because they use examples of non-scalable brokers to prove their point. We could do that too with almost any technology — take a faulty implementation, make the assumption that its design is the only possible way to implement the technology and then generalize until as much as necessary to "prove" that the principle (theory) is flawed, but we won't. Instead, we will consider the claim itself ("brokers are not scalable") in more detail and see why its foundation is not sturdy. (Click article title to read more)
In the fall of 2001, Visual Software began its journey to take its technology that "added services to existing applications without requiring changes be made to those applications" and modify them to work with an emerging educational standard called SIF, or the Schools Interoperability Framework. This new standard had the promise, and in later years, advantage of allowing educational applications from any compatible vendor to exchange information with any other compatible vendor. In 2007, with the acquisition of our first larger customer (London, with 1.7 million students and 2,700 schools), we began a process to re-design all of our products from the ground up to handle implementations this large and larger where the infrastructure is implemented in a single location and is shared by all the endpoints. (Click article title to read more)
Schools and school districts get most of or all of their funding from their parent organizations. Depending on their location, this may be a school district, a state or some other organization. But, regardless of where the funding originates, the source of that funding requires accountability in the form of reporting of some kind (most likely this will be in the form of digital reporting).
Recently, we took a survey of several US school districts to find out how much they spent gathering and preparing this information to send to their respective states as required to receive state funding. The answers were surprisingly alike for places that hadn't used our software or methodologies…
On our home page, we claim that our products scale from small to large implementations. Handling a small implementation is easy to imagine, but how large an implementation can our software support?
Some of our smaller examples include single school implementations. Larger examples in education include regional implementations in the UK with 2.7 to 3.2 million learners each, US states with millions of students and nationwide implementations with over 8 million students in attendance…