Deployment Guide: Contract 153/2007
|Deployment guidelines: |
|Servers and Storage |
|Document no.: |SRD-00012 |
|Revision: |2.0 |
|Author: |Izak de Villiers & Deon Nel |
|Date: |2012-12-03 |
|Electronic File: |Deployment Guide_Servers and Storage 2.0.doc |
Notice
© 2011 SITA. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means
Without the express written permission of SITA.
Document enquiries can be directed to: R&D Technology Lab
SITA (Pty) Ltd. P.O Box 26100, MONUMENT PARK, 0105, SOUTH AFRICA
Attention: Izak de Villiers (izak.devilliers@sita.co.za)
Telephone: 012 482 2749
Acknowledgement of receipt
The signatories hereof, being duly authorised thereto, by their signatures hereto confirm their receipt of the contents hereof and authorise the implementation/adoption thereof, as the case may be, for and on behalf of the parties represented by them.
| | | |
|Chairperson: GITOC Technology Task Team | |Date |
| | | |
|Maropeng Maeko | |Date |
|Manager: R&D PAS | | |
| | | |
|Deon Nel | |Date |
|Senior Specialist: R&D PAS | | |
| | | |
|Izak de Villiers | |Date |
|Senior Specialist: R&D PAS | | |
Foreword
This document forms part of a transversal acquisition programme driven by Government and SITA via SITA Procurement processes to enable Government to procure and deploy appropriate technology solutions. The document is intended to inform the ICT architecture of Government departments in terms of usage models, hardware and infrastructure requirements. It does not replace or supersede any other document, but this document replace the deployment Guide of the existing/previous Contract 153/2007.
Contents
Contents 5
Figures 5
Tables 6
1. Introduction 7
1.1 References 7
1.2 Background 7
2. Overview: Contract for Servers and Storage 12
2.1 Scope 12
2.2 Value-adds 12
2.3 Product and supplier details 13
3. Engagement guidelines 13
3.1 Historical engagement models 13
3.2 Supplier guidelines 14
3.3 Department guidelines 15
3.4 Requirements per Category 19
3.5 RFQ process 25
3.6 Services and components NOT included in the base specification 25
3.7 Solution and supplier selection 26
4. Services, best practice and deployment guidelines 26
4.1 Contract management 26
4.2 Deployment of server, storage and UPS solutions 26
5. Conclusion 29
Annex A: Glossary 31
Annex B: Contract summary 37
Annex C: Sample RFQ 39
Annex D: Latest Tech Update 42
Annex E: Product list procedure 43
Annex F: Product list 45
Annex G: List of accredited suppliers 46
Annex H: R&D Technology Advisory Services (Technology Lab) 47
Figures
Figure 1: Platform diagram 8
Figure 2: e-Government House of Values 8
Figure 3: Typical high-level architecture diagram for an Intel-based server 10
Figure 4: Equipment vs. downtime costs 29
Figure 5: Autofilter feature in Excel 42
Figure 6: Autofilter selecting only Item Srv4 43
Figure 7: Platform diagram 47
Figure 8: Enterprise architecture 49
Tables
Table 1: Categories on Servers and Storage certification 12
Table 2: Service delivery zones 18
Table 3: Details of Srv category 19
Table 4: Rack and tower server components and requirements 20
Table 5: Details of Bl category 20
Table 6: Blade server components and requirements 21
Table 7: Details of DAS category 21
Table 8: DAS components and requirements 21
Table 9: Details of NAS category 22
Table 10: NAS components and requirements 22
Table 11: Details of SAN category 22
Table 12: SAN components and requirements 23
Table 13: Details of Lib category 23
Table 14: Library components and requirements 24
Table 15: Details of UPS category 24
Table 16: UPS components and requirements 24
Table 17: Details of Rack category 25
Table 18: Server rack components and requirements 25
Introduction
This document best practice for X64 servers, storage and related hardware, and provides guidelines and best practices for the appropriate selection and deployment of the technologies available on contract.
R&D PAS was tasked to produce these guidelines by DPSA prior to publication of the tender. The guidelines were developed during the course of the evaluation process, with input from suppliers and OEMs.
The guidelines are not intended to replace Departmental ICT policies and processes, but should complement these while focussing on the specific platforms available on the contract that makes provision for Servers and Storage. Guidelines should be used in conjunction with other Contract documentation, including contract conditions, definitions and technical specifications. A comprehensive list of definitions is provided in Annex A for reference.
Specialised requirements are not addressed in the document, and should be handled on a case-by-case basis, with input from SITA if required.
1 References
The following documents are referred to in this document, or have an impact on the implementation of the processes described herein:
a) The relevant Servers and Storage bid document and bid conditions.
b) The Constitution of R.S.A., 1996
c) Public Finance Management Act (Act 1 of 1999), as amended by Act 38 of 2002
d) Preferential Procurement Policy Framework Act (Act 5 of 2000)
e) State Information Technology Agency Act (Act 88 of 1998), as amended by Act 38 of 2002
f) SITA Regulations as published in Government Gazette No. 28021 of 23 September 2005
g) Engagement Guidelines, Procedures and information for the relevant Contract for Servers and Storage.
h) Technology Renewal Process: Transversal Hardware Contracts, rev. 2.1, 2007-03-05 (PSAD-00050)
2 Background
1 Transversal contract goals
Government’s technology and business goals for transversal ICT contracts include the following:
a) Standardisation to ensure interoperability between Government systems, as well as with systems outside of Government;
a) Economies of scale (translating to cost benefits);
b) Support for Government’s security and confidentiality requirements;
c) Elimination of the duplication of costs and effort to specify, evaluate and manage technology contracts;
d) Access to national and regional service and support structures to maximise system uptime and end-user productivity;
e) Contract negotiation for the whole of Government for better service delivery and pricing; and
f) Overall view of Government technology procurement, ensuring a holistic solution design by aligning contracts.
The diagram below illustrates an overall view of platform, infrastructure and low-level application services, showing specific contracts that have been established by SITA for Government use.
[pic]
Figure 1: Platform diagram
|[pic] |
|Figure 2: e-Government House of Values |
2 Design principles
The following principles were incorporated into the design of the related Bid document for Servers and Storage.
a) Support for the e-Government House of values:
i) Security
ii) Interoperability
iii) Reduced duplication
iv) Economies of scale
v) BEE enablement
vi) Lower cost
vii) Increased productivity
viii) All of the above result in improved service delivery and increased citizen convenience
g) Support for regional procurement, service and support to build skills and capacity in the local ICT industry.
h) Sustainability for resellers, including small regional players: empower BEE/SMME organisations to build a sustainable business supplying and servicing Government infrastructure.
i) Mandated and measured service value-adds: e.g. tendered pricing must reflect value-adds so that Government will receive the required service levels in a sustainable model for BEE/SMME suppliers.
j) Mandated regional SMME/BEE involvement: Government has a mandate to procure regionally, but the structure of the economy currently concentrates most of the skills and value in one or two large provinces. Enable and mandate development of regional capacity by OEMs and large role players in the large provinces.
k) Address ICT infrastructure requirements via standardisation and cost containment.
l) Support as many OS and operating environments as possible (Windows, Linux, Unix, 32-bit and 64-bit platforms, virtualisation, etc.).
m) Enable deployment of applicable technology for specific requirements.
n) Scaleability and upgradeability: all Servers and Storage solutions are upgradeable to a greater or lesser extent. For example, certain Srv5 products can scale to 8 sockets and 32 CPU cores.
o) The contract was designed to be product-, vendor- and brand-agnostic. No preference was given to any specific product or brand name. The specification purely focussed on capabilities, functionality and industry standards.
p) In line with the previous bullet, an “equivalent or better” principle was followed: if it could be proven that a specific product provided equivalent or improved functionality, even if in a different way or via different mechanisms, the product would be accepted as complying with requirements.
q) Suppliers are to offer the lowest configuration that complies with the baseline requirements as specified (taking into account solution scaleability). This principle is aimed at discouraging suppliers from offering solutions that far exeed specifications and cost expectations, and forcing Government to pay for unnecessary functionality and capacity.
3 Evaluation criteria
The following high-level criteria were specified and evaluated for the Contract for Servers and Storage to ensure the best solution for Government:
a) Industry standards (both de facto and de jure standards)
r) Vendor-level certification against specific standards (e.g. ISO/IEC technology and environmental standards, software standards, etc.)
s) Compatibility and interoperability (both hardware and software) via ISV and OEM certifications — Government’s FOSS drive is supported by this initiative via mandatory compatibility with several Linux distributions.
t) Reliability and availability.
u) Systems management capabilities (including alerts and remote fault diagnosis).
v) Security.
w) Cost elements directly related to the offered solution, as well as hosting/housing costs.
x) Usage profiles based on business requirements.
y) Detail technical criteria (including configurations, capacities, etc.).
z) Baseline service and support levels, with SLA upgrade options.
aa) SABS-endorsed electrical safety and radiation standards.
4 Evaluation goals
Using the above criteria, the following overall goals were set for the related contract and tender evaluation:
a) Fair (“apples to apples”) comparison of offered solutions, measured against the published specifications. All variables are taken into account in a fair and open process.
b) Lowest Total Cost of Ownership. Supply chain regulations require Departments to measure TCO as part of the procurement process. Although customised for SA Government, TCO remains dependent on client and case, and therefore cannot be accurately specified or measured at transversal level. An RFQ-based process needs to drill into client specifics at procurement time. However, to ensure the best possible TCO, the following elements were specified and measured during evaluation as part of Technology TCO (TTCO):
i) Minimum hardware uptime requirements (99% for mission-critical devices)
ii) Mean time before failure (MTBF) – reliability indication
iii) Mean time to repair (MTTR) – measurement of downtime (hardware only)
iv) Manageability: Remote systems management received significant focus during evaluation, including automated fault alerting and remote diagnostics and repair capabilities
v) Reliability, availability and serviceability (RAS) of all solutions
vi) Comprehensive countrywide warranties with upgrade options
vii) Power consumption and cooling requirements
viii) Duty cycles and usage profiles
ix) Other elements impacting productivity, including security.
|[pic] |
|Figure 3: Typical high-level architecture diagram |
|for an Intel-based server |
ab) Service levels:
x) Basic SLA (next-day repair requirement) with upgrade options
xi) Enforcement of service levels via penalty clauses
xii) Cost of downtime taken into account
xiii) Dispute resolution via contract management
ac) Performance: by understanding and specifiying the underlying technology architecture, the best possible performance can be ensured for Government applications.
xiv) CPU architectures (number of cores, interconnects)
xv) CPU performance levels (clock speed, cache, bandwidth)
xvi) Chipset-level functionality
xvii) Memory architectures
xviii) System design
xix) System-level functionality
All these factors were researched and taken into account starting with the original design of the tender specification, long before the evaluation commenced. Inputs from component vendors (e.g. Intel, AMD), OEMs (e.g. Dell, HP, IBM, Mecer, Proline, Quantum, Sun, and many others), industry research institutions (e.g. GartnerGroup), and the client base (including GITOC TTT) were consolidated in the final specification.
5 Tender and contract processes
Transversal hardware contracts are specified, evaluated and managed via a specific process and philosophy. During a tender process, products are evaluated strictly according to the published criteria, following procurement regulations and guidelines. The Constitutional requirements of fairness, equitability, transparency, competitiveness and cost-effectiveness are incorporated into all levels of the process.
The technology component of these processes is handled by the SITA R&D Technology Lab, of which an overview is provided in Annex H.
Evaluation process
The technical evaluation of the bid for Servers and Storage comprised both theoretical and physical evaluation of products via the following evaluation processes:
1. Screening phase: Theoretical evaluation of technical bid responses. Products not meeting mandatory requirements were screened out during this phase, did not form part of the subsequent evaluation process, and were also not accredited for inclusion in the final approved product list. Only products that complied with all mandatory requirements were considered in subsequent evaluation phases.
2. Theoretical phase: Technical verification of mandatory functionality. Sample equipment was requested from OEMs, specifying a desired configuration per Item. The evaluation committee verified whether tendered information was accurate against the functionality of the supplied sample. Failure to demonstrate any specified capability or feature resulted in disqualification of the product.
3. Physical test phase: Laboratory tests of evaluation units.
3.1 Validate tendered information via system tests.
3.2 Verify interoperability via compatibility tests.
3.3 Performance benchmarks using industry-standard benchmarks as well as methodologies developed in-house.
4. Tech TCO phase: Calculation of Technology TCO based on supplied cost information and component pricing.
The primary output of the evaluation process was a list of accredited products that conformed to all technical requirements.
Technology management process
Technology management on transversal hardware contracts is done for the entire period of the contract, and includes continually updating technology requirements (typically on a quarterly or six-monthly basis), accrediting new products offered to Government, and accrediting replacements of existing products on contract.
Updates to CPU specifications, memory configurations, industry standards, etc. are managed via a formal Tech Update process. Tech Updates are published to the user community and industry, including OEMs and contractors resoncible for servers and storage for ratification before implementation. All changes to the technology specification are moderated and managed as an input to the regular Price Update process, which ensures that Government has a fair basis of comparing product pricing and costs.
Model changes are initiated by the OEM via a formal request, after which the same evaluation process is done for the new product. Once the new product has been accredited, the previous product may no longer be supplied via the contract.
The entire technology management process is described in the document Technology Renewal Process: Transversal Hardware Contracts (see References).
Overview: Contract for Servers and Storage
1 Scope
The Contract for Servers and Storage caters for high-volume X64 (x86) tower, rack and blade servers (1-socket to 4-socket); related storage products, including DAS, NAS, SAN and tape automation; power management solutions (UPS); and rack infrastructure products.
The previous Contract (153), orignaly established in 2004, only contained 6 server Items, from a single-socket tower server through to an 8-socket rack server. Storage options were handled as a sub-set of these Items, but this created serious issues with procurement regulations. To address these issues, as well as additional client requirements, the latest cerification comprises the following categories of ICT products:
|Servers |Tower and rack servers |
| |Blade servers |
|Storage |Direct-Attached Storage |
| |Network-Attached Storage |
| |Storage Area Networks |
| |Tape Libraries |
|UPS |Line-interactive UPS |
| |On-line UPS |
|Server racks |Standard 19" racks |
| |Environmental racks |
Table 1: Categories on Servers and Storage certification
Annex B has more detail on the individual categories and Items.
Note: The current certification process for Servers and Storage does not cater for specialised RISC/Unix or Itanium computing architectures, which are typically procured via ad hoc tenders. It also does not include high-end storage products, which caters for data centre-level hosted solutions. Any inadvertant overlap between datacentre products and producs certified for Servers and Storage was resolved as part of the design.
2 Value-adds
The following features add value to Government infrastructure acquisition processes by mandating minimum requirements that support local ICT initiatives and requirements:
a) Because of the critical nature of Government’s back-end infrastructure, very stringent technical and quality standards are specified. Mandated quality and environmental standards ensure high-quality solutions that support Government environmental drivers.
ad) Compatibility with all standard operating systems and environments (including Windows, Linux, Unix, VMWare, etc.)
ae) Certified software and support for all standard operating systems and environments, including 32- and 64-bit Windows, Linux, Unix, clustering and VMWare.
af) A strong emphasis is placed on systems management, allowing support staff to remotely deploy, configure and troubleshoot devices, saving on labour and travelling costs, and minimising downtime.
ag) Countrywide, 3-year on-site warranty with 8-hour repair for all systems (Zone A only; Zones B and C extend the repair time to 16 and 24 working hours respectively). To further ensure maximum availability, SLA upgrade options are also mandated for all products. Please refer to the Glossary for detail information on which towns are included in which zone.
ah) 99% (hardware-only) uptime requirement for high-end systems, with an associated penalty for non-performance. Calculations indicate that 1 hour’s downtime of a server hosting 1000 users could easily cost twice as much as the acquisition cost of the server.
ai) Validated products, components and solutions are available for direct procurement from a selection of accredited suppliers.
aj) A full range of upgrade options, components, accessories and media is available with each Item. This includes CPUs, memory, hard drives, tape drives, adapter cards, software, etc. Departments will be able to build a complete solution with these options.
ak) Software licences for all basic functionality as specified are included in the Base Price. Additional software functionality may be licenced via component price lists.
al) Empowerment of regional, SMME and BEE resellers.
3 Product and supplier details
More than 150 products are available from a wide range contractors on the Contract for Servers and Storage. This includes products from all major OEMs in each category, and the channel includes all major players in the local ICT space, as well as smaller BEE and SMME resellers.
See Annex B for a summary of Categories and Items, Annex F for a complete list of accredited products, and Annex G for a list of accredited suppliers.
Engagement guidelines
The bid document describes a basic bid/engagement model for Departments and suppliers, including a process for amber-listing and blacklisting suppliers. Departments are encouraged to consult the relevent Bid Document for details on the process..
Apart from the stipulations in the bid model, the specific contract conditions stipulate additional requirements in terms of service delivery, security, response times, etc. Clients and suppliers are urged to familiarise themselves with these documents in terms of their respective rights and responsibilities.
1 Historical engagement models
Client and supplier engagement models for Contract 153/2004 (the original contract for Servers and Storage) were stipulated in the contract conditions, technical specifications, and guidelines drawn up by SITA Procurement. Specifications included the following:
a) Acquisition processes and procedures were defined in the document Engagement Guidelines, Procedures and information for Servers and Storage (see References).
b) Solution, contract management and service stipulations:
i) Suppliers were given final accountability for the operability of the entire solution; incorrect specifications or configurations were not the responsibility of the Department. Suppliers had to verify the correctness of a solution prior to RFQ and/or delivery.
ii) Suppliers had to submit regular reports on Government expenditure on the contract for Servers and Storage to the relevant SITA contract management for collation.
iii) Solutions of a value larger than R1 000 000 needed to be submitted to SITA for ratification.
These guidelines have been expanded and incorporated into the contract conditions for Contract for Servers and Storage, as well as the bid model and deployment guidelines.
2 Supplier guidelines
Accredited suppliers are required to use the following guidelines to supply to Government via the relevent Contract:
a) The final responsibility for a working solution rests with suppliers and OEMs. An incomplete specification by Government does not absolve suppliers of this mandate.
am) Suppliers must ensure that all required information is gathered from Departments before quoting for or delivering a solution. This is to ensure that Government’s business needs are met by the proposed solution, and that only complete solutions are offered.
an) OEMs and resellers must participate in the technology management process as per tender conditions (refer to Technology Renewal Process: Transversal Hardware Contracts)
ao) Suppliers must recommed that Departments negotiate SLAs over and above contract uptime specifications for mission-critical systems.
ap) Suppliers must inform Departments of best practices in terms of SLAs and operations.
aq) Suppliers must commit to only proposing suitable and appropriate solutions given Government’s business requirements.
ar) Only accredited products and services may be offered to Government via the contract, as stipulated in the contract conditions.
as) Suppliers must be accredited to supply, install, support and maintain each individual product or solution offered to Government.
at) Registration of all product warranties must be done by the supplier after delivery of a solution. Government will not be required to register products for warranty to be eligible for warranty claims and support as per contract conditions.
au) Quarterly sales reports must be submitted by contractors to the Contract Manager. These reports must include number of units, client Departments, and total monetary value per client and category. Reports consolidated at OEM level would be preferable.
av) OEMs have the responsibility of determining the appropriate parts required to build a working solution, and communicating this to all their resellers on contract.
aw) OEMs and distributors must establish a single order code per system configuration as specified for in the contract for Servers and Storage. This will ensure that none of the mandatory requirements are left out of RFQ amounts. Again, there is a very real risk of financial loss for suppliers if these guidelines are not followed.
ax) OEMs must also support the contract process in by supporting all their resellers in terms of certification, training and regional service provision.
ay) All storage must be quoted in terms of usable capacity, not raw capacity. Suppliers will be required to adhere to this requirement, even if the quoted amount was calculated incorrectly. This could entail financial losses, so contractors have to take cognisance of associated risks.
az) OEMs must supply an approved configuration report to all resellers for inclusion in the RFQ. RFQs that don’t include the configuration will not be accepted.
If the prime contractor fails to perform according to contract conditions, the accountability will devolve onto the OEM automatically. Failure to comply with these guidelines will initiate the processes stipulated in the bid model in terms of amber- and/or blacklisting contractors.
3 Department guidelines
As detailed as the SITA tender process is, it cannot measure individual client requirements without including variables applicable to specific Departmental scenarios. By definition, this cannot be done in a transversal contract, as it caters for all of Government for a period of 3 years (typically). Therefore, an RFQ process subsequent to tender award should be followed to arrive at the best solution for specific client needs. SITA can also provide additional data and a consultation service to inform the criteria for a Departmental evaluation.
To ensure suitable proposals from suppliers, an exhaustive statement of business and technology requirement, including network, applications, database, client specifications, response times, etc., is required. These will allow proper sizing of the solution to ensure value for money as well as supporting Government’s business needs.
Departments are encouraged to use the following guidelines and variables in specifying solutions for RFQ on the contract for Servers and Storage.
1 Business requirements
a) Business requirements, not technology, must drive ICT acquisitions. This is to ensure that costs are contained and specific business needs are met. All business requirements must be specified up front, including capacity, performance, application and OS details.
ba) Government offices are located all over South Africa, and provision has been made in the contract for localised service delivery. Departments must stipulate the required locations of service provision to determine which contractors can provide support to the client. The zones of service delivery must be taken into account during this process. E.g. if a Department requires service delivery in the Eastern Cape, only the contractors with a direct presence in that province should be considered.
2 Service and support
a) Service and support is a non-technology issue that needs to be addressed thoroughly by the client via service level agreements (SLAs).
bb) For mission-critical solutions, Departments should negotiate SLAs that are uplifted from the standard 99%, 3-year hardware SLA.
bc) Support and maintenance requirements must be stipulated up front as part of the RFQ.
bd) Current certification of service providers is vital to maintain vendor warranties: certification for some OEM products have to be renewed annually.
be) The contract specifies basic requirements for out-of-warranty maintenance. Most OEMs commit to supporting a product for at least 3-5 years after being discontinued. Government can address this concern by opting for more comprehensive warranties up front.
bf) Countrywide delivery is included in the Base Price on the contract for servers and storage. Delivery times should be negotiated at quotation time with the contractor, and non-performance can be managed with involvement from the SITA Contract Manager. The contract specifies a maximum of 28 calendar days for delivery.
bg) Changes to any ICT infrastructure should only be done by certified resources, whether internal or contracted. This will ensure that all changes are done in a controlled way, and system reliability is maximised.
bh) It is not the responsibility of the contractor to replace or reload software in the event of a hard disk failure. However, the contractor must at least re-image the hard drive with OS and drivers. Any other repairs can be done at technical support tarriffs as tendered.
bi) Installation costs cover the unpacking of an item, connection of the equipment to power, network and running a set-up / test program to ensure that the equipment delivered is in good working order.
3 Solution certification
a) Compatibility and vendor certification (in addition to the basic certification specifications of the Tech Updates) should be made prerequisites for any RFQ. While a base compatibility evaluation was done for the bid, any unique or specialised requirements need to be addressed by the RFQ (in conjunction with SITA if required).
bj) The reliability of a solution is often directly related to system complexity. Environmental factors such as cooling and electricity supply also play a significant role. In addition, the MTBF ratings of individual components affect system availability. For highly-available solutions, redundancy and other RAS requirements must be specified up front.
4 Sizing and performance of solutions
a) As with reliability and performance, the configuration and operational parameters of a system largely determine TCO, or cost-effectiveness. Capital costs and on-going costs (service, support, warranty, transaction costs, etc.) vary widely based on many factors. Licensing costs for additional required functionality (e.g. storage management software) must also be calculated. All these factors need to be incorporated in the RFQ to ensure real-world measurement of cost.
bk) Sizing of the solutions should take into account application, database and OS requirements. Guidelines from developers and software and hardware vendors must be used to specify the required capacity and performance. Existing and planned network infrastructure also affect final system performance. For example, a web server has a different set of performance criteria from a database server, which differs in turn from an application server or a terminal server.
bl) Departments should specify storage capacity requirements in terms of usable capacity, and not raw capacity. There are significant differences in the way different vendors utilise raw disk capacity to add value to storage solutions. Therefore, raw capacity is not a realistic guideline. Suppliers must also take note of this fact, quoting all storage in usable terms, not raw terms.
bm) Storage performance is often related to the number of hard drive spindles in the system. Therefore, the lowest-cost solution that provides the required capacity may not always be the right solution. Departments may need to deploy a larger number of spindles to achieve the desired performance level. Solid-state technologies will alleviate some of these issues going forward.
bn) 32-bit vs. 64-bit computing options need to be considered, especially given the increase in storage and application sizes. All computing solutions on contract fully support both 32-bit and 64-bit environments. However, given the growth in memory capacity, 32-bit solutions are typically no longer required, and 64-bit solutions should be deployed as standard.
bo) System configuration, including component specifications such as CPU and hard disks, memory size, etc., needs to be correctly specified to support sizing requirements.
bp) X64 servers are typically under-utilised, with activity levels of 20% and below on average. Consolidation of servers via virtualisation can address this inefficiency by deploying fewer servers that are utilised at higher rates.
bq) Best practice dictates that servers must be fully populated with CPUs up front, as adding additional CPUs at a later date is typically not supported by availability and compatibility constraints.
br) The choice of hard disk type (SATA, FATA, SAS or FC) should be based on application-specific variables: e.g. mission-critical vs. high-performance vs. large-capacity and low-cost. FC and SAS drives are more costly, but offer significantly more performance and reliability than SATA. SATA, on the other hand, offers high capacity for low cost.
bs) Dual connections (multi-path I/O) to the SAN fabric is a typical requirement (estimated at more than 80% of SAN-attached servers), and this needs to be factored into the solution requirements for RFQ purposes.
bt) The detail configuration (Paragraph A in the technical specification) must be specified for all items on contract as part of the RFQ. This is addressed in detail later in the document.
5 Blade server issues
a) Blade server solutions must be designed with network requirements in mind, as a fully-populated blade enclosure could require several dozen new network and storage connections (e.g. 1 blade server may have up to 4 network interfaces and 4 storage interfaces).
bu) Best practice is to procure the full blade infrastructure (blade enclosure fully populated with power supplies, fans, connectivity, etc.) up front, instead of populating the enclosure as blades are added.
6 Racks
a) Server racks must be populated according to weight, taking rack load-bearing limits into account. Heavier devices (e.g. UPS) should be installed at the bottom of the rack.
bv) The load-bearing capacity of floors should be taken into account for rack solutions. E.g. some blade server solutions can weigh up to 250kg when fully populated, which means a fully-populated rack can weigh more than 1000kg. Most raised data centre floors are not designed to carry loads this large.
bw) To ensure optimum use of cooling resources, blanking panels should be installed in racks with free space.
7 Data centre design
a) Design or planning of data centre facilities should be done in conjunction with Department of Public Works.
bx) Power consumption: more and more computing environments are forced to make a trade-off between absolute performance and cooling and power supply constraints. This is certainly true of most data centres, is even becoming a concern for stand-alone servers. New technologies and methodologies are addressing this issue to an increasing extent, but as computing requirements keep increasing, power use needs to be monitored and managed carefully. Focussing on a value-per-Watt measurement may be the best way forward as data centre computing becomes more dense and power-hungry.
by) Redundant cooling infrastructure should be considered for mission-critical environments. While this is more costly up-front, it will go a long way towards ensuring system availability. Despite the fact that servers and storage solutions may have redundant components, a single air conditioner failure could bring down or damage all these systems.
bz) Cooling and UPS sizing are directly related to the power requirements of computing and storage solutions, and these need to be factored in before deploying the data centre infrastructure.
ca) Due to the size and design of some solutions, physical data centre constraints must be taken into account:
i) Floor load carrying capacity (e.g. 250kg mass per 10u blade chassis)
ii) Electrical capacity (total amperage)
iii) Electrical connections available
iv) Cooling capacity (BTU capacity)
v) Accessibility (delivery/loading zones, doorway dimensions, elevators, stairs, etc.)
cb) Large data centres should be configured in a hot aisle/cold aisle configuration to ensure optimum distribution of cool air.
8 Service delivery Zones
In terms of warranty turn-around times, the following zones are defined for items on contract:
|Province |Zone A |Zone B |
|Eastern Cape |Bisho |Grahamstown |
| |East London |Umtata |
| |Port Elizabeth | |
|Free State |Bloemfontein |Welkom |
|Gauteng |Entire Gauteng province | |
|Kwazulu Natal |Durban |Ladysmith |
| |Pietermaritzburg |Richards Bay |
| |Ulundi | |
|Limpopo |Polokwane |Thohoyandou |
|Mpumalanga |Nelspruit |Ermelo |
| |Witbank |Standerton |
|Northern Cape |Kimberley |Upington |
|North West |Mmabatho |Klerksdorp |
| | |Rustenburg |
|Western Cape |Cape Town |Beaufort West |
| | |Grahamstown |
| | |Oudtshoorn |
| | |Saldanha |
| | |Worcester |
Table 2: Service delivery zones
These zones and locations must be taken into consideration when declaring the location of equipment for equipment delivery, installation and warranty provision.
Zone A is defined as locations in or within 50km from major cities or Provincial capitals as listed above.
Zone B is defined as locations in or within 50km from major towns as listed above.
Zone C comprises all towns and rural Zones not included in Zone A and Zone B where services may be required.
4 Requirements per Category
This section provides an overview of each category, and specifies the minimum information that must be supplied by Departments in order for contractors to compile a meaningful solution proposal and quotation. As many of these details as possible must be established prior to approaching contractors for quotations.
Several components are included as standard in the Item Base Price, and these included components are listed for each category. The standard components do not necessarily constitute a working solution, as additional configuration details usually need to be supplied by the client before a solution can be delivered. This document focusses on providing a working server solution; any additional infrastructure and software required by the client is not necessarily addressed here (e.g. DBMS or business application). It must however be specified by the client to ensure suppliers provide a complete solution.
Note that the contract precludes the possibility of supplying incomplete solutions (e.g. servers without CPUs), and contractors are mandated to request the necessary details from Departments before submitting a quotation. In terms of infrastructure requirements (e.g. electricity and space constraints), both Departments and suppliers need to ensure that the solution can be supported by the existing facility, or else take steps to rectify any shortcomings via the appropriate channels.
1 Rack and tower servers
This category represents the traditional rack-mountable and stand-alone server products. The emphasis has moved largely towards rack-mount servers, with tower models occupying a shrinking part of the market. Servers on Contract can have anything from several dozen to more than 100 upgrade options and components, including CPUs, memory modules, operating systems, etc.
An important change to server architecture was made with the introduction of newer-generation processors, specifically in the 2-socket space. This caused changes to the memory configuration of servers, to the point where two different types of memory modules (DIMMs) are available, and Departments must ensure that the right type of module is deployed in the right configuration. One type of DIMM (UDIMM) is well-suited for lower-end, low-power usage models, while the other type, RDIMM, is better-suited for high-performance applications requiring large memory configurations.
|Srv | |
| |Description |
|Base unit with capabilities as specified in Section 1 of the technical |Operating system (if preload required) |
|specification |Applications (if required) |
|Standard power and interface cables |CPU and memory capacity |
|Warranty (3-year on-site with specified repair time) |Storage capacity (usable), capabilities and connectivity |
|Standard network and storage interfaces |Network and storage interfaces (SAS/FC/iSCSI) |
|Power supply |Removable storage (e.g. DVD drive) if required |
|Rack-mounting rails (for Srv2, Srv4, Srv5) |Backup device and software (if required) |
|Keyboard and mouse (for Srv1, Srv3) |Server form factor: rack-mount vs. stand-alone |
|Software: |LCD monitor (if required) |
|Configuration and management tools |On-site installation |
|Drivers for all subsystems for certified operating systems | |
|Documentation | |
|Packaging and delivery to client site | |
Table 4: Rack and tower server components and requirements
2 Blade servers
Blade servers represent a new server design where much of the required infrastructure (power, cooling, connectivity) is shared between several servers. This could have a significant impact on reliabity and TCO in terms of redundancy, supportability, ease of deployment, density, etc. Blade servers have a higher initial capital cost than traditional servers, but due to the shared infrastructure, adding additional servers can be done at a lower incremental cost. A rule of thumb is that the break-even costs point between blades and rack servers is at a half-full blade enclosure.
|Bl |Description |
|Blade enclosure: | |
|Base unit with capabilities as specified in Section 1 of the technical |Connectivity options: Ethernet and FC switches or pass-through |
|specification |modules as required |
|Standard power and interface cables |KVM and media tray (if required) |
|Warranty (3-year on-site with specified repair time) |CRT or LCD monitor (if required) |
|Redundant power supplies |On-site installation |
|Redundant cooling modules | |
|Software: | |
|Configuration and management tools | |
|Rack-mount fittings | |
|Documentation | |
|Packaging and delivery to client site | |
|Blade server: | |
|Base unit with capabilities as specified in Section 1 of the technical |Blade server configuration |
|specification |Operating system (if preload required) |
|Standard power and interface cables |Applications (if required) |
|Warranty (3-year on-site with specified repair time) |CPU and memory capacity |
|Software: |On-board storage capacity (usable), capabilities and connectivity |
|Configuration and management tools |I/O capacity upgrades and options (mezzanine cards for additional |
|Drivers for all subsystems for certified operating systems |network and storage fabric connections – FC/iSCSI) |
|Standard network and storage interfaces |Additional licensing for clustering and multi-path I/O requirements |
|Documentation |Backup device and software (if required) |
|Packaging and delivery to client site | |
Table 6: Blade server components and requirements
3 DAS
Direct-attached storage devices are designed to expand local storage for servers with insufficient internal hard drive bays. In general these devices cannot be shared among multiple servers, but exceptions exist where two servers can be connected in specific configurations.
|DAS |Description |
|Base unit with capabilities as specified in Section 1 of the technical specification |Storage capacity (usable), performance and redundancy|
|Standard power and interface cables |(e.g. RAID 5) |
|Warranty (3-year on-site with specified repair time) |Host connectivity options (SCSI/SAS/FC), including |
|Standard host/network interfaces |HBA requirements |
|Power supply |Other redundancy options (controller, fabric, etc.) |
|Rack-mounting rails (for rack-mount devices) |Application(s) and host systems that storage will be |
|Software: |connected to |
|Configuration and management tools |Licencing for additional storage management software |
|Drivers for all subsystems for certified operating systems (HBA-based) |(if required) |
|Documentation |On-site installation |
|Packaging and delivery to client site | |
Table 8: DAS components and requirements
4 NAS
Network-attached storage devices provide a means by which a single storage pool can be shared among several hosts without a dedicated file server. Storage is accessed at file-level via industry-standard network protocols such as CIFS (Windows) and NFS (Unix/Linux).
|NAS |Description |
|Base unit with capabilities as specified in Section 1 of the technical |Storage capacity (usable), performance and redundancy (e.g. RAID 5) |
|specification |Host connectivity options (Ethernet/iSCSI) |
|Standard power and interface cables |Other redundancy options (controller, fabric, etc.) |
|Warranty (3-year on-site with specified repair time) |Application(s) and host systems that storage will be connected to |
|Power supply |Number and types of host systems that will access the device |
|Rack-mounting rails (for rack-mount devices) |Additional storage management capabilities required (e.g. licences for |
|Software: |snapshots, mirroring, etc.) |
|Configuration and management tools |On-site installation |
|Documentation | |
|Packaging and delivery to client site | |
Table 10: NAS components and requirements
5 SAN
Storage area networks provide shared storage to multiple hosts via a dedicated fibre channel network. This category focusses on the SAN-attached storage arrays, but all components of a SAN (e.g. HBAs, fabric switches) can be procured from contract via components attached to each Item.
|SAN |Description |
|Base unit with capabilities as specified in Section 1 of the |Storage capacity (usable), performance and redundancy (e.g. RAID 5) |
|technical specification |Host connectivity options (HBAs, multi-path I/O, clustering, etc.) |
|Standard power and interface cables |Other redundancy options (controller, fabric, etc.) |
|Warranty (3-year on-site with specified repair time) |Fabric switches if required |
|Power supply |Additional storage management capabilities required (e.g. licences for snapshots, |
|Rack-mounting rails (for rack-mount devices) |mirroring, etc.) |
|Software: |Application(s) and host systems that storage will be connected to |
|Configuration and management tools |Number and types of host systems that will access the device |
|Documentation |On-site installation |
|Packaging and delivery to client site |Licensing for number and types of host servers |
| |Licensing for clustering and multi-path I/O requirements |
Table 12: SAN components and requirements
6 Tape libraries
Tape libraries automate the process of loading and unloading tape cartridges as part of backup operations. This typically results in a more reliable backup process, as human intervention is minimised. The 5 library Items included in contract range from a low-end 8-cartridge autoloader to a scaleable midrange library starting with 2 drives and 60 cartridge slots. Virtual tape libraries have also been included for disk-to-disk backup requirements.
|Lib |Description |
|Base unit with capabilities as specified in Section 1 of the |Backup capacity and growth projections |
|technical specification |Performance required (backup window) |
|Standard power and interface cables |Host connectivity options (SCSI/SAS/FC) and cables |
|Warranty (3-year on-site with specified repair time) |Tape drive and media type requirements |
|Standard tape drive(s) |Number of tape drives required (based on performance needs) |
|Standard host/network interfaces |Number of media slots required |
|Power supply |Labelling requirements must be stipulated |
|Rack-mounting rails (for rack-mount devices) |Number of tape cartridges required (based on capacity and tape rotation strategy) |
|Software: |Number of cleaning cartridges required |
|Configuration and management tools |Backup software (if required), including scheduling capabilities |
|Documentation |Backup application(s) and host systems that library will be connected to |
|Packaging and delivery to client site |On-site installation |
Table 14: Library components and requirements
7 UPS
Uninterruptible power supplies provide backup power to allow applications and servers to shut down gracefully in case of power failure.
|UPS |Description |
|Base unit with capabilities as specified in Section 1|Backup power requirements: |
|of the technical specification |Number of devices to power |
|Standard power and interface cables |Type and power usage per device (total KVA/Watts) |
|Warranty (3-year on-site with specified repair time) |Backup time required |
|2 AC output cables |UPS type: on-line or line-interactive |
|Rack-mounting rails (for rack-mount devices) |Number of output ports and cables required |
|Software: |Type of host communications required (RS-232/USB/Ethernet) |
|Configuration and management tools |UPS form factor (rack or tower) |
|Documentation |Remote management requirements |
|Packaging and delivery to client site |Will the UPS be connected to a generator? This will typically require “generator-friendly” |
| |design, and should be an on-line UPS. |
| |Transistor-based vs. transistorless design |
| |The wiring requirements must be specified for UPS5: wired into DB vs. wall socket |
| |On-site installation |
Table 16: UPS components and requirements
8 Server racks
Server racks are required for all rack-mount equipment, which includes most servers, storage and UPS devices. Environmental racks allow Departments to deploy “mini data centres” in locations where sufficient environmental controls are not available.
|Rack |Description |
|Rack1 |22u server rack |
|Rack2 |42u server rack |
|Rack3 |42u environmental server rack |
Table 17: Details of Rack category
Components included in the Base price and details the client must specify are listed below:
|Included in Base Price |Not included in Base Price / Client to specify |
|Base unit with capabilities as specified in Section 1 of the technical |Rack size (full- or half-height) |
|specification |PDU requirements |
|Standard power and connection cables |Cooling requirements |
|Cooling modules |Environmental rack required? |
|Warranty (3-year on-site with specified repair time) |Other rack options: e.g. KVM unit |
|Documentation |On-site installation |
|Delivery to client site | |
Table 18: Server rack components and requirements
5 RFQ process
The following high-level RFQ procedure may be followed when engaging suppliers:
a) Determine and document detail requirements (see guidelines and requirements sections for specific information around this).
cc) Verify appropriate sizing of requirement before publishing RFQ.
cd) Approach SITA for advice (if required).
ce) Publish RFQ with documented requirement. All information about requirements, infrastructure, constraints, etc. must be shared with all RFQ respondents, i.e. if new information becomes available during adjudication, all respondents must be allowed to update their responses. A reasonable time must be allowed for industry to respond to the RFQ.
cf) Local content: the RFQ must request suppliers to submit the percentage of local content with each RFQ. This will form part of the solution evaluation.
cg) Suppliers must quote all equipment, accessories and upgrades in accordance with the line numbers as on the detail specification of the Tech Updates. This is to ensure that the solution is made up only of accredited components.
ch) Evaluate RFQ in terms of TTCO, supplier TCO, BEE and compliance with requirements. The PPPFA 90/10 principle should be utilised in this process. Departments are encouraged to tailor TCO calculations for their specific environment.
ci) Award RFQ to the most suitable contractor.
6 Services and components NOT included in the base specification
The Servers and Storage Contract caters for the delivery of complete solutions. Any services or components included in the solution must be delivered, fully functional, to the client. Apart from the full solution as specified, the following needs to be specified separately as part of the RFQ if a client has such a requirement:
a) Transfer of data from old to new system
b) Additional installation services (e.g. software, applications). Any software apart from OS and drivers are typically excluded, apart from software procured as part of the full solution (e.g. VMWare, backup software).
c) Integration services (connect to existing UPS, storage, network).
d) Configuration of system and/or applications (creating user accounts, shares, etc.)
The contract makes provision for these services via an hourly charge tendered as part of each Item. Suppliers must base quotations on this hourly value.
7 Solution and supplier selection
The following criteria need to be considered when selecting a product and supplier:
a) Does the offered solution (both technology and scope) meet the client’s business needs?
cj) Certification of products and resources (OS-level, OEM-level, skills-level, etc.) for specific platforms and applications.
ck) Client’s current installed base: moving to a new supplier and/or product range may increase TCO by impacting on existing certifications, training, logistics and compatibility.
cl) Supplier track record and relationship.
cm) Support for and understanding of client’s unique requirements.
cn) Service issues such as delivery and repair times.
co) Other soft issues (support footprint, regional distribution, etc.).
Services, best practice and deployment guidelines
1 Contract management
This section provides and overview of the processes and services performed by SITA during the contract period. This includes the following technology and contract management processes:
a) Tech updates (including structural changes such as new categories, and moving products between categories)
cp) Model changes
cq) Price updates
cr) Contract/technology refresh: a 6-monthly process allowing additions of new technologies, products and suppliers.
cs) Removal of duplication between contracts
ct) Dispute resolution
cu) Consultation to Departments
2 Deployment of server, storage and UPS solutions
This section provides an overview on best practices in terms of deploying solutions available on Contract. As most of these solutions offer significant capabilities and capacity, care should be taken to have the correct implementation framework in place.
a) The following policies or strategies should be in place to inform business practices, technology requirements and procurement initiatives:
i) Security policy in terms of information and physical access control
xx) Information management policies and strategies:
1) Data management policy
2) Storage and backup strategy, policy and procedures
3) Archival policy
xxi) Disaster recovery (DR) policy and strategy
xxii) Infrastructure management policy
xxiii) Support strategy
xxiv) Maintenance strategy:
1) Ceding of warranty to in-house service providers may be done at purchase time, depending on existing agreements that Departments have in place.
2) Transfer of maintenance contracts should be done to in-house service providers after the standard contract 3-year warranty expires.
cv) Mission-critical systems:
xxv) SLAs must be signed for specific response/repair times and uptime for entire system, not just hardware.
xxvi) Downtime intervals should be scheduled for preventative maintenance on all equipment to ensure optimum functioning.
xxvii) The call/failure escalation procedure for each solution should be followed when downtime occurs. The procedure must be visible to operational staff to ensure quick response in case of failures.
xxviii) All vendor-provided fixes, patches, updates and alerts (affecting hardware, firmware and software) should immediately be acted upon and implemented as recommended to ensure the best possible availability and reliability fromm the systems.
cw) FOSS operating systems and environments are supported by all products cerified by SITA, and are available preloaded with all servers. Departments are encouraged to make use of this option where advisable.
cx) Departments should start migrating to 64-bit OS and applications — all servers on contract support 64-bit environments. The increased memory address space enabled by 64-bit environments is becoming a necessity for all but the smallest requirements.
cy) Server consolidation via virtualisation is supported both at OS and hardware level by all servers on contract. VMWare and MS Virtual Server are standard upgrade options available with all servers.
cz) Storage consolidation can simplify storage management processes and reduce costs for Departments by using SAN, NAS or iSCSI solutions to connect multiple hosts to fewer storage devices.
da) Highly available (HA) solutions may be built by combining products from the contract, as most of these devices support redundancy, failover options and clustering configurations.
db) Multi-core systems (quad-core is a minimum requirement on contract, with larger number of cores imminent) require highly parallelised workloads and specific optimisations. System and application developers must take this into account to make effective use of available performance. The industry has already launched initiatives in this regard, as designing applications for parallel processing places new burdens on both developers and compilers. Application versions should be identified that specifically support and utilise multi-core systems. This issue could also have a serious on licensing costs.
dc) Certification of solutions to be interoperable with third-party solutions (e.g. a server connecting to a third-party storage solution) needs to be taken into account during the RFQ process. Departments run the risk of losing certification when selecting non-supported configurations, which could seriously impact system reliability and a Department’s recourse in case of failures. The recommendation is therefore that the entire existing infrastructure be stipulated as part of the RFQ process to enable suppliers to offer a suitable solution. In some cases a qualification process may have to be done before a solution can be certified as “supported”.
dd) Standardisation of data centre infrastructure: best practice indicates that Departments should not deploy solutions from too many different suppliers, as this impacts on supportability and interoperatibility, and ultimately TCO.
de) Server OS installations must be hardened and optimised beyond the standard installation. Best practice for Departments would be to create and certify a baseline OS image with only needed features and components activated, and order this image pre-installed with all servers.
df) Backup solutions must be deployed as far as possible to protect Government data. The cost of backup solutions must be weighed against the risk of losing data, and the costs associated with recovering from a disaster.
i) RTO and RPO considerations: minimum time take for restore + be as close to data loss point as possible.
dg) Installation services are available at additional cost for each item as certified by SITA. It is highly recommended that Departments make use of these services for complex solutions, specialised devices, or where in-house skills are not available.
dh) Downtime penalties:
xxix) The countdown for downtime measurement starts from the logging of a valid call at the appropriate service desk. Disputes in this regard can be escalated to the SITA contract manager.
xxx) A contractor may be held responsible for downtime when equipment was deployed and utilised within the guidelines stipulated by the contract and by vendor warranty requirements, and when a valid call was logged with the service desk within a reasonable time.
xxxi) Abuse or misapplication of equipment are not covered under this stipulation.
xxxii) Both a fully redundant configuration (PS, HDD, NIC, cooling) and optimal operating environment (in terms of HVAC) are required to qualify for the contractual 99% uptime clause.
xxxiii) The following formula can be used to calculate actual system uptime: 9.5 hours daily (7:30 - 17:00) X 22 (working days per month) X 99%. Based on this, actual system uptime should be measured over a 4-month period to stay within standard support SLA requirements.
di) Operational guidelines for tape libraries:
xxxiv) Tape rotation and regular head cleaning should be done for tape libraries to ensure maximum reliability and service life.
xxxv) Off-site storage of backups to ensure data availability in the event of a disaster.
xxxvi) Only tape media certified by the library manufacturer should be used to maximise drive and media life and system reliability.
dj) NIA guidelines must be followed in terms of data protection when failures occur on storage devices (e.g. hard disk drives). In general, storage devices containing Government data may not be removed from Government premises under any circumstances. Erased disk drives or tape cartridges must be certified to be erased before they may be removed from Government premises.
|[pic] |
|Figure 4: Equipment vs. downtime costs |
dk) Select appropriate solutions for specific requirements. The graph below illustrates the relationship between equipment and downtime costs using the contract for Server category as an example. As is shown in the graph, the impact and associated costs of downtime increase exponentially with the scale of the server. At the lower end where the risk is less, low-cost products are adequate for Government’s requirements. Conversely, at the higher end, higher-priced products are required to satisfy Government’s reliability requirements.
Conclusion
We trust that the document makes it clear that a thorough analysis of user requirements must be done before selecting a product or supplier from the Contract for Servers and Storage. SITA can assist Government in this regard with advice, guidelines and focussed calculations.
The Contract for Servers and Storage establishes a procurement vehicle for a baseline technology platform that should support 80–90% of Government’s server and storage requirements from a transversal contract point of view. Following the guidelines in this document should enable Government to make use of this platform to its maximum potential in supporting Departmental ICT and service delivery goals.
SITA is committed to supporting Government via this contract by ensuring that contract conditions are maintained and Department technology requirements are met by continously revisiting these and making adjustments where required. Any inputs in this regard may be forwarded to SITA using the contact details provided below, or escalated via other channels (e.g. TTT, GITO Council).
More information and contact details
The latest Tech Update, detail specifications, Engagement Model, and the latest version of this document can be found at the following web site:
sita.co.za/procurement/tenders/contracts.htm
SITA contact persons for the relevant contract:
|Division |Name |Role |Contact details |
|Procurement |Carl Masekoameng |Contract manager |carl.masekoameng@sita.co.za |
| | | |012 482 3000 |
|R&D Tech Lab (TAS) |Deon Nel |Innovation and Research: Technology |deon.nel@sita.co.za |
| | |Advisory Services |012 482 2136 |
|R&D Tech Lab (TAS) |Izak de Villiers |Innovation and Research: Technology |izak.devilliers@sita.co.za |
| | |Advisory Services |012 482 2749 |
Glossary
|Term |Definition |
|2N |Measure of redundancy: full redundancy of components, with double the required capacity available. |
|Accessories |A component or subcomponent that complements or increases the capability of the tendered product, including software, parts,|
| |etc. |
|Add-ons |Components or products that complement or increase the capability of the tendered product. |
|Array replication |Replication of all data stored in a storage array to an alternative location, preferably off-site, for disaster recovery |
| |purposes. |
|ASR |Automatic Server Recovery: Detection of component failure, deconfiguring of failed component, and rebooting of the server to|
| |a working state. Only applicable to servers/components with redundant or backup components. |
|Base evaluation |A baseline (minimum) specification in terms of capacity and capabilities that will be used for testing, pricing and cost |
|configuration |comparison. This should not be confused with the minimum technical specification. |
|Base Price |The total price for all components included the Base System as specified in Paragraph A of the technical specification. |
|Base system |All components included the Base System as specified in Paragraph A of the technical specification (spreadsheet). |
|BBBEE |Broad-Based Black Economic Empowerment as defined by Act 53 of 2003. |
|BEC |Bid Evaluation Committee |
|BEE |Black Economic Empowerment as defined by Act 5 of 2000. |
|Brand owner |The legal entity representing a product in South Africa. Legal entity status implies that the Bidder is not the manufacturer|
| |of the product. The brand owner takes ultimate responsibility for branding, marketing, distribution channels and product |
| |direction. Single point of contact for Government (see Legal entity, OEM). |
|BTU |British Thermal Units |
|Capacity on demand |Expansion of available storage or processing capacity as required by the user or application. Often an on-line facility, |
| |i.e. the upgrade can be performed with no down-time. |
|Category |A collection of tender Items representing a functional area, such as Servers, UPS or NAS (containing Items NAS1, NAS2 and |
| |NAS3). (see Item). |
|CD |Compact Disk, should be read to be equivalent to DVD (Digital Versatile Disk) |
|Channel partners |All enterprises that operate in the market as small and medium sized enterprises. An example of a channel partner is a |
| |value-added reseller that provides industry-specific software solutions and services. |
|CIFS |Common Internet File Services |
|Clone |A complete copy (mirror) of a dataset or storage volume that can be used for testing, migration, etc. To be distinguished |
| |from a snapshot, defined elsewhere. |
|Consumables |Components that have a life span or are consumed during the normal operation of the tendered product, including printer ink,|
| |toner, photoconductors, etc., or lamps, batteries, belts, rollers, maintenance kits, etc. |
|Cooling modules |Fan assemblies installed in servers, storage arrays or server racks. Cooling modules are often redundant and hot-swappable. |
|COTS |Commercial Off-the-Shelf |
|CPI |Consumer Price Index |
|DAS |Direct Attached Storage |
|DBMS |Database Management System |
|Distributor |Official channel warehousing and distribution, logistics partner appointed by the brand owner. |
|Distro |Linux distribution (e.g. Red Hat Enterprise Linux or SuSE Linux Enterprise) |
|DOA |Dead On Arrival: equipment that fails immediately or within a specified period from delivery. |
|Drive tray |Hard disk bay configured in server or storage device, hot-pluggable, removable or fixed |
|DTI |Department of Trade and Industry |
|Dynamic rack load |The maximum load a server rack can bear while being transported. |
|ECC |Error Correcting Code |
|EDMS |Electronic Document Management System |
|ESM |Enterprise Systems Management |
|FC |Fibre Channel |
|FOSS |Free / Open Source Software |
|Fulfilment agent |Solution or Service Provider |
|GITOC |Government IT Officers Council |
|GUI |Graphical User Interface |
|HBA |Host bus adapter |
|HDI |Historically Disadvantaged Individual |
|HVAC |Heating, Ventilation and Air Conditioning |
|I/O |Input/Output |
|ICT |Information and Communication Technology |
|Installation |Unpack system, configure, plug into power and network, and switch on to ensure proper operation. Installation excludes |
| |migration of software and data on previous system. |
|IOPS |I/O Operations per Second — a measure of performance for storage devices. |
|IS |Information Systems |
|ISM |Information and Systems Management |
|ISO |International Standard Organisation |
|ISV |Independent Software Vendor |
|IT |Information Technology |
|Item |Lowest-level technology subdivision on contract as represented in the technical specification, e.g. Srv1, Lib5. A product |
| |must be tendered at Item-level. Multiple products may be tendered by numbering the Item offers, e.g. NAS1A, NAS1B, NAS1C. |
| |Items are organised into Categories, e.g. Servers, Libraries. (See Category). |
|JBOD |Just a Bunch of Disks — a grouping of disks with no redundancy configured. Cf. RAID |
|KVM |Keyboard, Video, Mouse: connections required to a server console to allow full user interaction with the server. |
|LAN |Local Area Network |
|LDAP |Lightweight Directory Access Protocol |
|Legal entity |As defined by SA law, the sole OEM-appointed representative for a product brand in SA. Not necessarily the importer or |
| |distributor. (see Brand owner, OEM). |
|List price |For the purpose of this Contract, a price including VAT for a product, component or service that has been published formally|
| |to a reseller or partner network and can be audited during evaluation. |
|MCBF |Mean Changes Before Failure: measure of tape library reliability by quantifying the average number of tape load/unload |
| |cycles before a failure can be expected. |
|Minimum requirements |The lowest level of capability that will perform the required function. Exceeding this level is allowed, but not reaching |
| |this level will result in disqualification. (See Minimum specifications). |
|Minimum |A specification representing minimum requirements. Improving on minimum spec is allowed at all times, while not complying to|
|specifications |minimum spec will result in disqualification. For example, if 4GB RAM is specified, 8GB would be allowed, but 2GB would be |
| |disqualified. Bidders shall at all times configure offered products to meet minimum specifications (See Minimum |
| |requirements). |
|MIOS |Minimum Interoperability Specification |
|MISS |Minimum Information Security Standards |
|MNC |Multi-National Corporations: typically international OEMs |
|Model change |Replacement of an existing product by a new product due to the existing product having reached end of life, or no longer |
| |meeting requirements. A formal SITA process must be followed by Bidders to request and perform a model change. |
|MOU |Memorandum of Understanding |
|MPIO |Multi-path I/O |
|MSBF |Mean Swaps Between Failures: see MCBF |
|MTBF |Mean Time Between Failure |
|MTTR |Mean Time to Repair: Average time required to rectify any fault to a system or component (typically hardware). This does not|
| |specify mean time to response, but refers to the time to a fully working system/component. Hardware-only repair time, not |
| |SLA. Clarify the distinction |
|Multi-core |A processor with more than CPU 1 core per socket |
|N/A |Not Available: will be interpreted in the technical evaluation as a potentially disqualifiable answer. N/A could also be |
| |interpreted as “Not applicable”, which will be handled in the same way as “Not available”. |
|NAS |Network Attached Storage |
|Native capacity |Raw, uncompressed capacity of a tape cartridge or library. Does not refer to projected compressed capacity. |
|NDA |Non-Disclosure Agreement |
|NFS |Network File System |
|NIC |Network Interface Card, typically Ethernet-based |
|NIPP |National Industrial Participation Programme, as defined by the DTI. |
|NT |National Treasury |
|ODM |Original Design Manufacturer |
|OEM |Original Equipment Manufacturer. Unless noted otherwise, the term includes the concepts of Brand owner and Legal entity (see|
| |Brand owner, Legal entity) |
|Offer |A specific instance of a product tender, e.g. Bl2B or Srv3A. Combines the Item specification with a product offer, including|
| |component pricing. See Item, Bid, Category. |
|OS |Operating System |
|OSS |Open Source Software |
|PAI |Product Acquisition and Installation |
|PAS |Platform Advisory Services, the Technology Lab section of SITA R&D |
|PC |Personal Computer |
|PCI |Peripheral Component Interconnect |
|PCIe |PCI Express |
|PFMA |Public Finance Management Act |
|PPPFA |Preferential Procurement Policy Framework Act, 2000 |
|Pre-failure warranty |A warranty that covers components that have not actually failed, but have been predicted to fail by the Management |
| |infrastructure (e.g. SMART for hard drive failures), thereby improving system reliability and uptime. Components will be |
| |replaced under pre-failure warranty with no cost to the Client. |
|Price for base eval |Compare with Base Price |
|config | |
|PS |Power Supply |
|QA |Quality Assurance |
|Rack-mountable |19” rack-mountable device with support for sliding rails (not shelf-mounted) |
|RAID |Redundant Array of Inexpensive Disks — a grouping of disks configured with redundancy. |
|RAM |Random Access Memory |
|Raw capacity |The total capacity of a disk storage array with no redundancy features enabled or configured. Equates to the total capacity |
| |of all drives in the array added up. Raw capacity is typically not available for use by applications or end users. Cf. |
| |Native capacity |
|Required |What the Client requires as a working solution, and places an order for. Due to the transversal nature of the Servers and |
| |Storage Contract, detailed requirements cannot be specified in the tender, as they vary between users of the Contract. |
|Reseller |Final value-added step in the channel before the end user. Compare with Solution provider |
|RFB |Request for Bid |
|RFI |Request for Information |
|RFP |Request for Proposal |
|RFQ |Request for Quotation |
|RPM (rpm) |Revolutions per minute: typically used to indicate the rotational speed of hard drives |
|RSA |Republic of South Africa |
|SAN |Storage Area Network |
|SAS |Serial Attached SCSI |
|SATA |Serial AT Attached |
|SCProc |GITOC Standing Committee on Procurement |
|SCSI |Small Computer System Interface |
|Server/secure mode |A configurable boot mode whereby access is denied to all the server’s input and boot devices (keyboard, mouse, optical and |
|boot |diskette drives) from power-on until a password has been entered. The boot process is not interrupted for a password prompt,|
| |which means that service is not denied. |
|Service / support |See Technical support |
|charge | |
|SITA |State Information Technology Agency |
|SLA |Service Level Agreement |
|SMME |Small, Medium and Micro Enterprise as defined and interpreted by Act 102 of 1996. |
|SMS |Seat Management Services contract: Tender 285 |
|SMTP |Simple Mail Transport Protocol |
|Snapshot |A copy of a set of data files or directories at a specific point in time. A full copy is not made, but references are kept |
| |to original storage blocks as well as all changes made since the snapshot to enable quick roll-back. |
|SNMP |Simple Network Management Protocol |
|SP |Solution provider: the second value-added step in the supply chain before the end user. |
|Static rack load |The maximum load a server rack can bear after installation (i.e. not while being transported). |
|SW |Software |
|TCO |Total Cost of Ownership: all costs associated with an ICT solution, including capital, labour, services, running costs, etc.|
|Tech update |Periodical refresh of technical specifications during Contract period. |
|Technical and pricing|A description of one product/system in terms of specifications and component pricing. Contained in Excel workbook |
|schedule |accompanying the tender documents. Two systems cannot be offered in a single document. The document must be copied for each |
| |individual offer (see guidelines later in the document.) Sections cannot be tendered apart from a "host" server (e.g. just |
| |hard disks). Must be completed and submitted electronically. |
|Technical support |A technical service rendered for out-of-warranty work, or work related to, but not covered by, the services specified as |
| |included with offered products. |
|Technology originator|Manufacturer of base technology components such as CPUs, memory, disk drives, etc. The development of base components drives|
| |the solutions that can be offered by OEMs. |
|Technology |A process by which the initial level of proposed technology is updated, upgraded or “refreshed” to reflect industry |
|refreshment |advancement over a period of time. Will be managed by SITA in conjunction with the OEMs for this tender. |
|Technology TCO |Measurable costs over a defined period of time that can be directly associated with the evaluated technology or equipment |
| |(e.g. capital, maintenance, support, installation, power and cooling, consumables, etc.) |
|Transversal term |A Contract with one or more Suppliers for the supply of information technology Goods or services over a period, required by |
|Contract |more than one department or public body according to approved user requirement specifications, with overall pricing of Goods|
| |being firm, unless otherwise provided for in the Contract. |
| |The purpose of a transversal Contract generally can be stated as addressing 80–90% of Government requirements, reducing the |
| |need for ad hoc tenders. Transversal Contracts typically exclude niche or special requirements by definition, and there will|
| |consequently always be a need for ad hoc Contracts. |
|TTCO |See Technology TCO |
|TTT |GITOC Technology Task Team |
|U320 |Ultra 320 SCSI |
|Upgrades |Components or subcomponents that have the purpose of expanding the capacity of the tendered product, including RAM, hard |
| |disks, CPUs, etc. Upgrades are typically expansions that can be done inside the system chassis (e.g. printer duplexer or |
| |additional RAM). “Fork-lift” replacements of systems are not seen as upgrades. Upgrades are not necessarily after-market |
| |operations. A base system may be upgraded with additional capacity at purchase time. |
|UPS |Uninterruptible Power Supply |
|URS |User Requirement Specification |
|Usable capacity |The total capacity to applications and end users of a disk storage array with all redundancy features enabled and |
| |configured. (Cf. Raw capacity) |
|Validated server |Component-level certification of server configuration by CPU manufacturer. Certification will apply to in-chassis |
|platform |components: memory, storage controllers, I/O, NIC, and graphics. |
|VAT |Value Added Tax |
|WAN |Wide Area Network |
|Warranty |Offered products are warranted to be free of material and workmanship defects for the period specified in the Item technical|
| |specification. Any defects of this nature will be rectified (via repair or replacement) at the expense of the Bidder under |
| |the terms specified in the Item technical specification, while maintaining minimum system availability as specified. All |
| |parts, labour and travel costs will be covered by the Bidder for the extent of the warranty period. The warranty period |
| |commences from date of delivery of the product in good working order at the end-user’s premises. Consumables are not covered|
| |under the warranty, except for a reasonable expectation of performance per component (e.g. batteries). Damage due to |
| |shipping is covered under the warranty. Preventative maintenance should be done by Suppliers to ensure that SLAs are |
| |maintained. |
|WORM |Write Once Read Many |
|WWN |World Wide Name used to uniquely identify Fibre Channel devices. |
|X64 |Industry-standard high-volume CPU architecture, the 64-bit successor to the previous 32-bit x86 industry standard. Supported|
| |by both AMD and Intel’s high-volume parts. Does not include IA-64 (Itanium) or 64-bit RISC architectures. |
|X86 |Industry-standard CPU architecture based on Intel’s 80X86 instruction set. |
|Zone |Geographical areas within South Africa where product and service delivery are required. These areas are designated as Zone |
| |A, B or C, depending on proximity to large centres. The definition of zones are as follows: |
| |Zone A: The entire Gauteng Province, as well as in or within 50km from major cities or Provincial capitals, i.e. Cape Town, |
| |Port Elizabeth, East London, Bisho, Bloemfontein, Durban, Mmabatho, Polokwane, Kimberley, Pietermaritzburg, Ulundi, Witbank |
| |and Nelspruit. |
| |Zone B: In or within 50km from major towns, i.e. Welkom, Umtata, George, Grahamstown, Thohoyandou, Rustenburg, Klerksdorp, |
| |Ermelo, Standerton, Ladysmith, Oudtshoorn, Richards Bay, Saldanha, Upington, Worcester and Beaufort West. |
| |Zone C: All towns and rural Zones not included in Zone A and Zone B where services may be required. |
Contract summary
A summary of items and categories available on Contract for Servers and Storage is given below.
RFB for Servers and Storage - SITA X64 (x86) Server & Storage Tender
Add user profile???
|Servers |
| | |
|Tower and Rack Servers |
| | |
|Srv |Description |
|Srv1 |Entry-level 1-socket |
|Srv2 |Rack-mount 1-socket |
|Srv3 |Entry-level 2-socket |
|Srv4 |High-end 2-socket |
|Srv5 |Rack-mount 4-socket |
| | |
|Blade Servers |
| | |
|Bl |Description |
|Bl1 |Blade Enclosure |
|Bl2 |2-socket blade server |
|Bl3 |4-socket blade server |
| | |
|Storage |
| | |
|Direct Attached Storage |
| | |
|DAS |Description |
|DAS1 |Entry-level / Value |
|DAS2 |Workgroup |
|DAS3 |Departmental |
| | |
|Network Attached Storage |
| | |
|NAS |Description |
|NAS1 |Entry-level / Value |
|NAS2 |Workgroup |
|NAS3 |Departmental |
| | |
|Storage Area Networks |
| | |
|SAN |Description |
|SAN1 |Entry-level / Value |
|SAN2 |Workgroup |
|SAN3 |Departmental |
| | |
|Tape Automation |
| | |
|Lib |Description |
|Lib1 |Autoloader/Small library |
|Lib2 |Workgroup |
|Lib3 |Departmental |
| | |
|Virtual Tape Libraries |
| | |
|VLib |Description |
|Lib4 |Entry-level |
|Lib5 |Midrange |
| | |
|Uninterruptable Power Supplies |
| | |
|UPS |Description |
|UPS1 |Entry-level |
|UPS2 |Midrange |
|UPS3 |Entry-level on-line |
|UPS4 |Midrange on-line |
|UPS5 |High-end on-line |
| | |
|Server Racks |
| | |
|Rack |Description |
|Rack1 |22u server rack |
|Rack2 |42u server rack |
|Rack3 |42u environmental server rack |
Detail category specifications:
The latest detail specifications (including Tech Updates) can be found on the SITA web site, under active contracts.
Sample RFQ
This Annex contains a sample RFQ that users of the Contract should consult to ensure that adequate information is provided to prospective suppliers, and that specific requirements are met in terms of the transversal process.
Using the standard SITA RFQ template as a basis, the following information must be inserted into Annex A of the RFQ, which represents the technical and solution specification for which suppliers must quote.
RFQ requirements
|1. MANDATORY |Comply |Do not comply |
|Bidder commits to implement and follow all contract conditions and specifications as agreed to in the | | |
|MOU. This includes all technical and solution requirements listed in the bid document, including | | |
|up-to-date technical specifications. No services, features or capabilities listed as “standard” (included| | |
|in the price) in the bid specification (e.g. 3-year on-site warranty) may be excluded from the RFQ, and | | |
|no RFQ conditions may override or cancel out any bid conditions or specifications. | | |
|Substantiate |
|2. MANDATORY |Comply |Do not comply |
|Bidder is accredited by SITA as supplier (i.e. listed on SITA contract for Servers and Storage database) | | |
|Substantiate |
|3. MANDATORY |Comply |Do not comply |
|Bidder is accredited for product supply and service delivery (as applicable) in the province where the | | |
|solution must be delivered/installed. | | |
|Substantiate |
|4. MANDATORY |Comply |Do not comply |
|Bidder is accredited by SITA to supply the required product Category (e.g. VC units or Display devices), | | |
|Item (e.g. VC1) and specific product offered in the RFQ. | | |
|Substantiate |
|5. MANDATORY |Comply |Do not comply |
|Bidder is accredited by OEM to supply the specific products offered in the RFQ. | | |
|Substantiate |
|6. MANDATORY |Comply |Do not comply |
|Bidder acknowledges that the responsibility for a working solution lies solely with them, not with the | | |
|client, and that any additional costs over and above the RFQ amount required to arrive at a working | | |
|solution (i.e. a non-compliant or incomplete solution was offered) will be for the account of the bidder.| | |
|Substantiate |
|7. MANDATORY |Comply |Do not comply |
|The solution bid must include technical details on the offered solution, as well as a complete | | |
|configuration report from the OEM (i.e. the output from the OEM’s system configuration tool) to ensure | | |
|that all required components are included in the bid. Failure to include this report will result in | | |
|disqualification of the bid. | | |
|Substantiate |
|8. MANDATORY |Comply |Do not comply |
|The pricing schedule must include a complete price breakdown per component. If the price breakdown does | | |
|not allow the evaluation team to verify the presence of mandatory or required components, the bid may be | | |
|disqualified. | | |
|Substantiate |
Pricing schedule
The only changes made to the standard SITA pricing schedule is that the schedule is divided into three different sections to separate product pricing from service pricing, and to quote separately for products and services not on contract (e.g. furniture, air conditioners, etc.)
|Pricing: Accredited products, accessories and |Contract Item & Line # |Quantity |Unit Price |Nett Price (VAT Excl.) |
|services |(per latest TU) | |(VAT Excl.) | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|Subtotal | |
|VAT 14% | |
|Total VAT Incl. | |
Latest Tech Update
This Annex contains the current Tech Update at the time of publication. The latest Tech Update, as well as other contract documentation, can be found at the following web address:
sita.co.za/procurement/tenders/contracts.htm
Product list procedure
This Annex defines a procedure for Department procurement personnel to identify available products on contract by filtering for province, Item and even product name. The spreadsheet published on the SITA web site will be used for the procedure. Departments are to download the latest version to ensure that up-to-date information is used.
The product list as published on the SITA website contains all suppliers on Contract, the regions of service delivery, as well as all producs which were awarded. Since the list is several thousand lines long, buyers will need to drill down to their specific requirements in order to identify appropriate products and suppliers.
Excel offers an Autofilter feature, which allows users to quickly filter out unwanted line items, enabling quick decision making when large numbers of data points are considered. The screenshot below shows the product list with the autofilter enabled, and the Item drop-down open. This will allow the user to filter only a specific category of Item (e.g. Srv2), making it much easier to drill down to a specific solution.
[pic]
Figure 5: Autofilter feature in Excel
If a Department is interested in procuring mid-size servers, the product list can be filtered only to Item Srv4, as shown in the screenshot below. The blue line numbers and arrow next to the Item heading show that the full list is not being displayed, but only a subset as filtered.
[pic]
Figure 6: Autofilter selecting only Item Srv4
Using this method, Departments will be able to quickly identify appropriate products and solutions for RFQ and procurement purposes.
Product list
A complete list of products accredited for supply to Government under Contract is available on the contract website at sita.co.za.
Note: As tech updates, model changes and new accreditations are done during the contract period, this list will change over time.
List of accredited suppliers
A complete list of products accredited for supply to Government on Contract is available on the contract website at sita.co.za.
Note: As new accreditations are done and other processes are implemented during the contract period, this list will change over time.
R&D Technology Advisory Services (Technology Lab)
R&D Technology Advisory Services (TAS) performs applied research in the Platform space (see diagram) to enable it to support SITA and Government in obtaining the best, most cost-effective technology for their requirements.
The value-add that the Lab offers to Government includes the following:
b) Expertise in the Platform domain, which includes computing, communications and networking, storage, peripherals, operating environments and related areas.
dl) Relationships with technology manufacturers (including component vendors, OEMs and technology suppliers) — Non-Disclosure Agreements are in place between R&D and many of these manufacturers. Good information about the future plans of these manufacturers is available to R&D, and is invaluable in drafting strategy and specifications for transversal initiatives.
dm) Technology management services to ensure that existing contracts keep delivering the required value to Government.
dn) Skills, facilities and processes to perform evaluations on applicable components and devices
do) Relationships with standards bodies and industry workgroups (including SABS, CSIR, ICASA, etc.)
As noted above, TAS focuses largely on the Platform domain, which includes the following technology domains and services:
[pic]
Figure 7: Platform diagram
TAS resources have been involved in the design of technology acquisition solutions for Government transversal platform procurement for the last decade. Current SITA contracts where the Lab performs technology management services are the following:
Terms of Reference
The following philosophies guide TAS in the work done for Government and SITA:
Support for South African industry: Since its inception, TAS has worked towards empowering the local industry. As a consequence, local quality levels have improved significantly, with several standards such as ISO9000 and Windows Hardware Quality Labs certification implemented by local manufacturers. These standards were implemented by local vendors only after being made mandatory for Government contracts.
Total cost of ownership: While all institutions have financial limitations, Governments, and specifically those in Africa, have huge challenges in meeting service delivery targets with limited budgets. It is therefore imperative to ensure that the best possible use is made of available funds. Hardware acquisition costs only make up a part of total cost. Significant contributions to total cost include costs of downtime (lost productivity), operational costs, and labour costs. The Lab has endeavoured to quantify and measure total cost as far as possible to provide the most cost-effective solution to Government, especially given the unique circumstances in Africa. Directly measurable cost elements have been defined as Technology TCO in the evaluation process.
Open, non-exclusive process: The Constitution requires that procurement be fair, equitable, transparent, competitive and cost-effective. Allowing all players to offer their solutions to Government is a vital application of these principles. TAS has always allowed equivalent functionality as a principle for all evaluations (this includes chipsets, processors, standards and classifications). In addition, input is required from industry and the client base during development of tender specifications to ensure as inclusive a process as possible. The Lab process has been audited several times, and no favouritism or unfair treatment of any supplier has ever been found. Suppliers are also welcome to query evaluation results, which is a standard part of the process.
Best solution for government: Using TAS knowledge of the ICT industry and Government environment, our task is to specify an open and fair tender that will result in the best technical solution for Government with the lowest possible TCO.
Good relationships with industry: TAS prides itself upon excellent relations with the ICT industry. The nature of our work requires close collaboration with vendors and manufacturers. OEMs (Original Equipment Manufacturers) and technology manufacturers are often our primary source of information, and nurturing these relationships is vital to our success. Relationships with industry are being extended with the establishment of non-disclosure agreements with manufacturers to ensure the availability of timely information to R&D.
OLA with Procurement: The Lab has formal Operational Level Agreement with SITA Procurement. Work done on the OLA is managed by this agreement, and Procurement is relied upon as a partner in meeting Government ICT goals via transversal contracts.
Architecture focus
TAS provides input into architecture plans via accreditation of products, certification of solutions and consulting services. This is done in collaboration with Government ICT bodies, including the GITO Council and sub-committees such as the SCProc and TTT.
Business requirements flow from the business and IS architectures via infrastructure, application and information. Departments are advised to initiate the process from a business requirements perspective. In accordance with the PFMA, specifications supplied by vendors can never be the basis for a business requirement.
[pic]
Figure 10: Enterprise architecture
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- index edu
- configuration guide
- linux lehman college
- deployment guide contract 153 2007
- po operations maintenance guide sourceforge
- 1 reportlab
- information technology services user satisfaction survey 2006
- open source software
- open software development organizational culture in a virtual
- l210 advanced linux system administration i
Related searches
- 82nd airborne division deployment 2019
- crm deployment plan
- deployment antonym
- deployment pay calculator 2020
- military deployment pay chart
- military deployment benefits
- salesforce deployment checklist
- microsoft office 2007 download office 2007 microsoft
- air force deployment pay chart
- dod civilian deployment pay calculator
- office 365 proplus deployment tool
- download office deployment tool