Over the past ten years, the advent of the Internet had created a mindset among CIOs of large enterprises,that investment in information technology would bring immense competitive advantage to the businesses. Very little financial analysis was made before making such investments.
Today, while enterprises have not obtained all such perceived benefits, under a recessionary atmosphere CIOs are struggling to keep cost of maintenance of such IT assets as low as possible.
The picture of today’s large enterprise is usually one of two to three desktop operating systems spread across 3040,000 PCs, 20003000 laptops. 10002000 file and print servers running anywhere from 1 to operating systems, and this is only the Wintel platform. Such non uniformity of platforms makes upgrades expensive, implementation of enterprise security policy difficult, and cost of support very high. All these result in high TCO of IT assets.
To combat this, large enterprises have started to undertake massive desktop standardisation initiatives. Such initiatives usually end after completing migration of the desktop operating system. Little effort is spent towards managing the standards. The enterprise falls, again, into chaos of multiple standards, defeating the purpose of standardization.
Purpose Of the Build Factory
The Build Factory is body that creates standard deployable objects that are used in standardizing the desktop environment. It is brought into play initially whilst migrating to standardized desktop (which we will call an Enterprise Client). During this phase the Build Factory reduces the cost of roll out through a “build once, implement many times”approach. It also ensures that there is a uniform set of build images deployed across the enterprise.
After migrating to the standard desktop it is important that such standards are maintained on an ongoing basis.The change to the standard is made necessary by several factors. Periodic bug fixes and service packs released by vendors, new applications and technology decisions are some of these. build factory is also ideally placed to recommend new technology “best fit” solutions keeping the enterprise standards in mind. It can also serve as Level support for the Enterprise Help Desk.
Creation of this central build factory provides significant cost advantage for an enterprise while at the same time make its desktop environment more reliable.
The Enterprise Technology Council (ETC) is responsible for establishing the Enterprise Client standard. This group translates strategic technology policy into workable standards by conducting “Proof of Concept” exercises. These are followed by clear recommendations about what gets deployed on the desktop.
Recommendations approved by the ETC are made operational on the desktop by the Build Factory. This is executed continuously as the ongoing maintenance process. Central help desks responsible for providing enterprise wide desktop support to various business units may escalate critical support issues to the Build Factory. The Build Factory will then provide the best solution to the help desk, which will, in turn, implement the solution for the respective business unit.
The above process provides a vehicle to implement and continuously improve the compliance to the Enterprise IT Policy. At the same time it increases the effectiveness of help desk support through its deep technical skills. The advantage of creating this structure lies in the fact that, in today”s connected world, the Build Factory can be located anywhere, preferably offshore, which would significantly reduce the cost of operation.
*The Build Factory will be the execution arm of ETC
* Build Factory can augment central help desk support
*With the above, Enterprise Client standards always remain “contemporary”
*Build Factory will enable new technology adoption by conducting “Proof of Concept”
* Build Factory can be easily located Offshore providing cost benefits
organizational Requirements of a Build factory
Benefits from a Build Factory to an Enterprise are best realised by setting up the following:
*A governance structure with the highest level of executive sponsorship
* A complete standard of the Enterprise Client
* A communication mechanism through which the user community can influence the desktop standards
while at the same time “buying into” it
* A central help desk to provide support of the new standards on a continuous basis
* Enterprise Wide support contracts with major hardware and software vendors
The above are recognised as Critical Success Factors for the Build Factory.
Set up Approach
Before setting up the Build Factory, it is important to base line the scope of services to be provided from the Build Factory. The scope has to be jointly discussed between the supplier of services and the ETC.
Development and Test Process
The development starts with the base line scope consisting of monthly security patches released by vendors.Each patch is evaluated against the enterprise client standard and relevant patches are bundled using a scripting tool (usually MSIs). The “patch build” is tested in a test bench, which simulates a business unit. Test cases are documented and the entire build is tested against such cases. An installation document is then prepared which contains details of every patch and the guidelines for installation.
A mail is sent to all business units that a new build is ready for deployment and distributed from an Intranet domain. If a business unit has implemented any Enterprise Management (EM) Software like Tivoli or Microsoft SMS, the build can be pushed
to the desktops from these EM tools also. Specific tools like Script Logic or Zen works can also be used where such deployment can be managed using scripts.
Release Management Process
Once all builds have been tested, a detailed installation note is prepared which will help system administrators, of respective business units to install the builds. Once the build factory releases build, it is put up on a public domain with a mail notification to all business units that the latest build is ready for deployment. Business units then download the specific build and follow the instructions in the release notes for installation.
Infrastructure Requirement
This section will describe the hardware, software and communication link requirement for a Build Factory service delivery. The hardware configuration will depend on the standards of the Enterprise. Typically, the hardware will consist of file and print servers, desktops, laptops, PDAs, and switches for creating a LAN. The servers and clients must have the same configuration of the enterprise standard. Sufficient desktops need to be procured for development, test and production.
The software requirement will depend on the standard elements of the desktop (OS, Office Tools, Productivity tools, client versions of enterprise applications) and the tools responsible for delivering applications to Enterprise Clients (e.g. ScriptLogic/ZenWorks etc.). The exact number of file servers/desktops/laptops/hand held computers will depend on the number of versions to be maintained at a given instance. The greater the number of versions, greater the hardware required for creating test scenarios for each version.
An effective communication link that connects the Build Factory securely to the Enterprise domain is crucial for maintaining quality of delivery.
When the Build Factory is offshore it is connected to the customer premise through VPN devices behind configured firewalls. This connectivity is the most secure since it uses IPSEC encrypted packets for data transfer. It is possible to establish FTP, HTTP services through this link. The bandwidth requirement depends on the amount of data to be transferred.
*File and print servers of the standard enterprise configuration
* Desktops, laptops, PDA, for testing
*Dedicated LAN
* VPN box for IPSEC connectivity to enterprise domain
* Bandwidth for FTP/HTTP/Terminal services
* Tools for component packaging
* Tools for deployment
Timelines
Whereas the actual timelines for setting up a Build Factory from an offshore location will depend on the agreed scope,The above is an illustration of indicative time lines with identified core services of Build Factory. However, for value-added service offerings viz. Enterprise Application tests etc. the time taken to create such an infrastructure along with the knowledge transfer activities have to be accounted.
