This has been a big project for us, starting from scratch to get a Windows 7 image built for our particular uses. At times it has been kind of overwhelming. I wrote before that monolithic is out and componentised is in. However the simple fact is that no single solution will suit all requirements. After my previous experience of being unable to create a monolithic application, I tried componentised, then when that didn’t seem to be going anywhere, I tried monolithic again with a freshly built image on a virtual machine this time. Applications got installed in two stages – the optional or “Feature” applications that staff like to have (like iTunes and some specific teaching situations) and required or “Core” applications (antivirus, Office, etc). Both capture stages were completed successfully leaving me with images that could be successfully deployed to test platforms. The next step is to deploy to a production environment, our laptops, so I created a deployment sequence to add the hardware specific drivers, and the specific additional applications just for these laptops. At the moment the first production deployment is completing and has just had two minor glitches so far with dialog boxes popping up that shouldn’t be there. I think the model we will follow in the future is to build the monolithic image on a generic VM for the base OS and applications for a specific scenario and then customise it to the specific hardware with the drivers and any related apps. The great advantage of this scenario is being able to use the VM to customise the image and therefore I don’t have to have an example machine at hand to test it on, although one will have to be borrowed for the production deployment test. This time around the settings I specified in the deployment wizard were applied (joining the domain etc) so that is also good. With the particular image we are using at the moment, the base OS + apps image takes about 40 minutes to be installed and the platform specific apps take about another 40 minutes. We are currently using MDT 2010 gold to do everything except sysprepped captures and MDT 2010 Update 1 beta to do the captures. I guess the total experience has been for a similar amount of time as our first Vista image but in this case being a lot more repeatable and reusable so learning MDT will be worth a lot more to us overall.
The other issue I am writing about today is data ownership in major databases. The biggest database that a typical NZ school will have is their Student Management System, which I will use here as an example. There is a tendency to think of applications in terms of the old file based DB approach where each application has its own data and tends to use it exclusively. For those of us with DBA experience that is not taking advantage of the key advantages that databases have to offer, mainly centralisation and ease of management. However most vendors are well aware of this in providing the capability to export data for other uses and, in some cases ODBC access to their backends. One of the important considerations is being able to allow other applications access to a major database such as an SMS, and being able to take that data to another product of the same type (e.g. another SMS) if for some reason you need to change vendor. An SMS vendor should be prevailed upon to give you, at least, read-only access to all of your data, and full documentation of its functionality and how it uses the data. Our experience of Integris being that both of those requirements were fulfilled – the documentation has not always been complete but enough information was available to begin with to enable me to link two specific reporting applications into Integris to analyse PAT and other assessment data (STAR, WL etc), using Integris as the data entry frontend, and Microsoft Access to do the reporting.
The important consideration in getting free and full access to your data, particularly to all of it, and to proper documentation, is that at some future stage you may need to switch, for example, an SMS, as your requirements change. Having your data locked into the vendor’s proprietary format with sparse documentation can make it difficult to switch to another SMS as easily as you would switch an operating system or other general purpose application. To a certain extent the specialisation of SMSs is part of the problem, but vendor lock-in is a consideration that needs greater attention from the powers that be. I understand that there is official interest in getting NZ SMS vendors to move to client-server architecture, which gives better options for sharing SMS data. Within a school locally this can still be ensured if a backend provides access to other apps using a standard interface such as ODBC.
