Overview
Background
The primary aim of this project is to remove costly end of life services by decommissioning Solaris (including corporate firewall), obsolete Windows server versions (2000 & 2003), Red Hat 4.0 and obsolete backup technology (Networker). The introduction of new technologies has meant a growing complexity arising in our infrastructure that creates difficulties for maintenance and obstacles to keeping hardware and software up to date. This is particularly true for the obsolete technologies that in terms of all types of cost are proportionally more expensive to maintain (e.g. using older, less agile means for patching, sourcing parts for obsolete equipment) and have an increasing risk profile as they age (e.g. lack of support from vendors, more likely to break down).
The project should initially scope a list of migrations required for any services being provided on obsolete infrastructure and then plan a series of targeted migrations within a restricted time scale to move those services to new infrastructure. Those more complex cases that could not be easily migrated during the migration window provided by this project would need to go forward into separate projects on their own or in groups (depending on the nature of the migrations required). The goal would be to have a coherent and agreed plan that sees us making in-roads to removing all obsolete technologies out of our environment by July 2015..
Scope
The scope of this project should include the following:
- Cataloguing all current servers that have been deemed obsolete and that are to be decommissioned.
- Cataloguing what is on the obsolete servers (e.g. applications, software, databases) and should be decommissioned.
- Ascertaining if applications or programs can simply be 'switched off' or if they need to be migrated/can be migrated; or if they need to be upgraded/can be upgraded.
- Classifying each of the applications or programs identified in (3) and judging whether they can be included in this project, or if they should be included in related or new projects.
- Updating the catalogue of what is still on our infrastructure and how it will be dealt with if the budget for this project does not allow for its inclusion in INF105.
- The development of a matrix of current hardware; supporting software technologies (i.e. database software, CF, Java, Apache, etc.); operating systems; version numbers; indicative lifespans and exit times for these, and guidelines for their future management.
- Suggestions for improvements to project methodologies to include OS and application lifespans in future project documentation.
- The implementation of Tivoli Storage Manager (TSM) - the replacement for Networker
- Specific technologies will be targeted for removal - in particular, the Drum firewall; Networker storage; the server Tulla.
The above work will be approached and planned in a phased manner, with the first phase producing the necessary listing of hardware and software so that the scale of what needs to be planned can be measured and subsequent activities can be more fully estimated and scheduled.
Objectives and Deliverables
Objective 1 | Deliver a report that enumerates and details the obsolete infrastructure |
D1.1 | A report that catalogues all obsolete items on our current infrastructure that should be taken out of service |
Objective 2 | Publish a plan for decommissioning all obsolete servers, operating systems and applications |
D2.1 | Documentation that lists when and how each item identified under D1.1 can be decommissioned |
Objective 3 | Communicate the implications of decommissioning with business partners and other stakeholders |
D3.1 | A communications plan that involves all stakeholders and lets them know what is being taken out of service and the implications for them |
Objective 4 | Decommission identified servers and systems that can be taken out of service under this project |
D4.1 | The removal of particular obsolete servers and systems from our infrastructure |
Objective 5 | Produce report with recommendations for any outstanding items |
D5.1 | A set of recommendations and plans that identify when any remaining infrastructure can be decommissioned |
Objective 6 | Suggest procedures to keep inventory up to date |
D6.1 | Recommendations for amendments to project methodologies with regards to lifespans of future technologies and applications |
D6.2 | A matrix of current hardware; supporting software technologies; operating systems; version numbers; indicative lifespans and exit times |
Benefits
- The project will contribute to the delivery of a simplified infrastructure where more costly legacy services and technologies are diminished and rationalised. Legacy services (e.g. Solaris) are complex to manage and support and, by comparison to more contemporary equivalent technologies, offer poorer, more expensive, more time-consuming management and user experience.
- Reducing the number of ways that the technical infrastructure needs to be managed (for example, patching) should improve efficiency and predictability. This, in turn, should achieve a better quality of service and deliver a more reliable business infrastructure.
- One specific benefit will be that when Solaris is finally decommissioned all of the current security concerns for this technology will be removed from the infrastructure. This is equally relevant for legacy windows services etc.
- The benefits can be measured and delivered when the legacy services are entirely removed from service. This allows the development and support staff to have a more singular focus on the current technologies and the demands that they make.
- An improved and 'cleaner' environment should provide an improved and less costly environment for our end-users.
- The removal of obsolete technologies and software should also produce benefits through the need to discontinue training and knowledge or skills acquisition for these amomg IS Apps staff.
Success Criteria
Overall, the success of this project may be measured by the reduced complexity, improved efficiency and reduced security risks associated with legacy technologies.
Particular measures will be the publication of an updated technology lifecycle document (that can be used for annual review), and, moving forward, clear plans for any obsolete components and the communication of these plans.