EUCLID had a three-tier architecture model with duplicate tiers located in each of the University’s two main server rooms: Kings Building (KB) and Appleton Tower (AT). It used 6 machines (Solaris servers) as front Web Tier, which will not be supported any longer by Sun Oracle from 31st July 2013.
The six web servers did no real work anymore; all work was now done on the App Tier. This project was an opportunity to simplify/consolidate the architecture. Since the two-tier architecture is also now recommended by Tribal, this project was to decommission those 6 web servers, and EUCLID to become a two-tier architecture model using the existing mid application tier (6 servers), connected to the database.
The project’s scope was to decommission the Euclid Web Tier, as the Web servers will not be supported any longer from 31st July 2013, and set EUCLID as a two-tier architecture model.
1. To move the Web Tier functionality to the Application Tier.
2. To reconfigure the Application Tier.
1. Production of migration method. This will include identification of the Web Tier functionalities to be moved to the Application Tier: static files, style sheets, HTS files, java files. Need to update SITS System Parameters.
2. Testing strategy: functional and performance (must include success criteria), consider resilience test.
3. Update technical architecture document.
4. Implementation process. Consider the options for implementation in order to mitigate the risks: decommission servers gradually, over the two sites. Include back out plan.
5. Migrated system. All the Euclid environments need to be updated (Dev, Test, Live and Trn). Dev environment is a shared server, which may be used for other purposes, to be checked.
Were the project goals met?
Yes. The Web Tier was retired, and the App Tier was reconfigured.
Were the project deliverables fully or partially accomplished?
Yes, all deliverables were achieved.
1. All functionalities were moved from the Web Tier to the App Tier, and others updated accordingly (Incl QAS).
2. Performance and resilience tests were carried out successfully
3. Document TAD was updated alongside WIKI pages
4. Implementation was done with no disruption to the service.
5. All the EUCLID environments have now been reconfigured.
Did the project deliver a solution to the problems being addressed? Have the desired operational results been achieved?
Yes. EUCLID is now running on a two tier architecture model and no issues have been reported.
Were additional results achieved besides the original success criteria? Were there any unforeseen benefits delivered by this project?
Yes. An SQL script was developed to report the user login on SITS eVision. Apps Management will be able to run this report regularly to monitor the usage of eVision.
Does the Project Sponsor agree that this project can be closed at this time? Yes
Project Manager's Commentary on Reasons For Variance From Plans
There was no variance on the total days of the project.
The project needed more involvement from the project manager due to rescheduling delivery dates caused by the dependency for resources on the SITS upgrade project, and higher priority work for ITI .Delays were managed by Project Issues Log: https://www.projects.ed.ac.uk/project/sac013/issues
Key Learning Points
1. What went well?
Overall project went very well as it was delivered within budget, scope and time. The time variance was caused by delays in securing resource, both in ITI (due to higher priority projects) , and in IS Apps because of the dependency on the SITS upgrade carried out by the same person in Dev Tech (Pride).
The same implementation plan was followed in all environments, enabling a great level of consistency and reassurance.
Pride’s work was thorough and efficient. He kept the project team informed on all the progress in a timely manner.
2. What didn't go so well?
Unfortunately there was no enough resource available in the Configuration team for this project, and Defeng had to carry out most tasks. Though his time was limited, it did not cause any delay for the project delivery.
The dependency on ITI resources meant that some considerable time was spent trying to negotiate and agree switch over dates and times that were both convenient for ITI, IS Apps and SACS. Even when agreed, ITI were not able to perform some of the work at the specific required time due to their other commitments.
3. If you had a project like this again, what would you improve?
Could have planned the project to give more time between this project and the SITS upgrade project. Not ideal that it ended going through in the same time as the upgrade. Should bare this in mind for any other EUCLID Infrastructure projects.
There were some small issues where the reliance on Pride was quite high and could have impacted both this and the SITS upgrade project.
Need Tech Management engagement as early as possible in any other EUCLID infrastructure projects.
Unidesk call has been raised by Pride on 5/3 for ITI to shut down servers and dispose.
- Closure questionnaires received from Defeng Ma, David Foggo, Ruth McCallum, Pride Shoniwa (they are posted on the website)
- Completion report sent for comments to Defeng Ma, David Foggo, Ruth McCallum, Pride Shoniwa and Suran Perera.Comments received back from Defeng, Suran, Pride.
Analysis of Resource Usage:
Staff Usage Estimate: 51 days
Staff Usage Actual: 51 days
Staff Usage Variance: 0%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
Key Learning Points: