There is a saying in IT: "If you do it more than once, automate it."
Automation is manna from heaven, as it saves time and prevents errors. Well, it prevents errors if the automation process is correct, but that is for later. More importantly, it provides standardisation.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Now automation covers a whole gamut of processes, not just scripting. People even automate their document creation. Consider templates as an example. If a company stops their document creation at templates, then usually all is well. However, there has recently been a creep in the scope of document automation, to "standardised document sets". This in itself is not an issue, as a standardised set of documentation is useful to confirm that you have all the information needed for your design.
We now have RFC's (Requests for Comments), RFD's (Requests for Designs), HLD's (High Level Design Documents) LLD's (Low Level Design Documents), CCO's (Change Control Orders), etc. All this is deemed good process and practice and, if it is implemented correctly, it is!
Automation is manna from heaven.
Tom Howarth, Contributor,
However, companies, vendors and clients alike run into trouble when they insert the dreaded "assume" into the equation. The reason I say that assumption is brought into the automation process is because the client assumes the vendor knows what they are doing and has their best interests at heart -- as in, "they said they did at the pre-sales meetings, didn't they?" But the vendor assumes that the client's processes are mature enough to audit the process and, even though they may not have the skills to deliver the solution in-house, are technical enough to understand the vendor's processes.
I have worked on both sides of the divide, for tier one system integrators and for end clients, and I have seen the same mistakes being made time and time again. IT systems are, by their very nature, complex beasts.
Example of a virtualisation project
Let's take, for example, a simple and small-scale virtualisation project for a medium-sized company or autonomous government department. They are moving from a physical environment to a virtual one based on VMware vSphere, and at the same time they are taking the opportunity to move from Novell Netware and GroupWise running against a mixture of Windows 2000pro and XP clients to Windows 2008, Active Directory, Exchange 2007, and Windows7 running Office 2010. They are also moving their databases from SQL2000 to SQL2008.
On first look this seems to be a relatively simple virtualisation project. Build your virtual infrastructure, create your AD and Exchange on Windows 2008, migrate your users and start your Windows 7 role out -- no problem, right? Not so fast. Let's start to peel this little onion. First, look at the vSphere environment; this sub-project alone will touch at the minimum, the server, storage and network teams, and this is before we even start to install the guest operating systems and applications.
However, we also need to plan the migration from the legacy Netware and GroupWise environments to AD and Exchange 2007. This requires a distinct skill set; therefore it is very unlikely that the same design team that did the vSphere design will be used.
Next we have the client migration and uplift, which again requires distinct skill sets to ensure that user personalisation and data are migrated and available on the new system. We now have three distinct teams working on the same virtualisation project, resulting in several documentation sets being written by distinct teams.
There is an assumption from the client's side that all three design teams are talking to each other to produce a homogenous solution catering to the client's distinct needs; from the vendor's side there is the assumption that the client knows that there are three separate teams working on their project and that the client's audit process will pick up any anomalies. This is a common error by both parties. Clients do not understand that the "design team" is often working on other bids too; remember the bid team is a cost-centre to the vendor.
This pressure that the bid teams are put under leads to what I call "template design." This is a process where a solution is delivered "off the shelf" and shoehorned into the client's requirements. One of the key identifiers of "template design" is standardised documentation that just does not seem to fit. This causes discrepancies between documents, and requirements often get ignored or missed.
Vendors and clients need to collaborate more, be less confrontational and more conciliatory.
Tom Howarth, Contributor,
These issues are difficult for the client to identify. Why? Because they often lack the skills needed to pick up on these anomalies. You need to cross reference each and every document against each other. This is a time consuming task, time the client does not have. If they did, most likely they would have attempted the design themselves. Therefore, these issues tend only to be picked up by auditors, either as a result of a problem arising, for instance a failed machine that cannot be rebuilt because the documentation is incorrect, or as a result of a loss of trust in the vendor by the client and an "External Review" being procured. Both of these cost a lot of time and money.
How to tackle it
So how do we tackle these issues? Well, there needs to be a shift change in how virtualisation projects are initiated and run, especially within governments. More emphasis needs to be on requirement gathering and documentation process -- proper checks and balances need to be created. Vendors need to be more realistic about their staff's workload, and the clients need to read the documentation sent to them. There is no need for template design. A common argument vendors make, to support the approach, is that it makes the solution easier to manage when in fact it complicates things, as the design will most likely not be fit for purpose.
Sure, follow "best practices," but understand why, validate your reasons, and remember documentation automation is one step too far. But most of all, vendors and clients need to collaborate more, be less confrontational and more conciliatory. There is a history of "Them and Us" in contract negotiations, common in both Europe and the U.S. In the words of an old BT advert, "It's good to talk". And always remember: more design and less automation.
About the author: I live with my wife, Catherine, and our kids in Lancashire, U.K. When not working or spending time with my family, I am blogging or answering questions as a moderator on the VMware Communities Forum. I've been in IT for more years than I care to admit, starting as a junior support guy on Novell and "Green Screens." Along the way, I have been a Novell Guy, the Notes Guy, "the Citrix Bod," an IT manager, and more recently a consultant, firstly for resellers doing Citrix and server-based computing. Currently I am an independent consultant specialising in VMware and its associated technologies, with a bias towards VDI. I am also an owner/blogger at PlanetVM.NET and have contributed to two books, VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment and VCP: VMware Certified Professional on vSphere 4 Study Guide.