Monday, November 23, 2009

Tech Virtualization traps

Whenever an organisation looks into Virtualisation the cost savings is immediately pointed to as something that will just happen. This article points out many of the potential pitfalls or unexpected costs that can erode these benefits. Below I address some of the main issues in a virtual consolidation project.

FCW: 5 traps that can spoil virtualization savings

The main reasons are from some assumptions that your current IT systems are capable of handling the new infrastructure. This is not always the case for a variety of reasons. However each of these reasons actually can give way to new cost benefit. These benefits can make the case for going virtual even better than before.


1. Unanticipated Management Overhead
Existing toolsets don't understand virtual technologies. The additional layer of complexity is something that doesn't get represented well by older tools. However this does mean that we can manage this layer though and get added benefits. It can be advantageous to be able to map virtual systems to the hardware - so that you can find the physical box, minimise licenses, balance resources so that there is less waste in the overall system.

2. Running more hardware than you need
Many organisations building virtual clusters make them huge and future proof. Each individual physical system is overspecified and has lots of redundant capacity as organisations will overbuild systems to ensure that they handle the migration. There is an element of uncertainty in the migration process and every organisation has different needs.
To avoid this, ensure that you accurately measure the use of existing systems before migration and in the pilot phase of the rollout validate these needs on the new systems. It could be that the overall requirement is less that expected, leading to larger cost savings.

3. Licensing Bloat
Licensing virtual systems actually gives some benefits. Many vendors such as Microsoft have improved licensing usage rights that take into account virtual systems running on a host. However there are some vendors that have less than beneficial licensing metrics. Watch out for situations where you might need to license the whole physical server if you have an application running on a virtual server.  Isolate these to single servers or keep them physical.

Also, get a license management or software asset management  system that can keep track of virtual systems and calculating the best license metrics.

4. Virtual System Sprawl
It is very easy to create a new virtual server. Much easier than a physical server.  Instead of having to buy hardware, find rackspace to store it, get your infrastructure team to build the OS and install your applications, all you need to do is copy a folder of files and click start inside your management tool. This can lead to unauthorised or unplanned servers turning up in your network.  Avoid this by having the same strict levels of process around the commissioning of the servers in the first place.  Don't allow IT staff to just build another server unless there is a process around it.
Extra servers just waste your resources and cost you extra money in unneeded licenses, new systems and management.

5. Inadequate storage
In a large VM environment (or even a small one) a large amount of central storage is needed. To optimise this, the best way is usually through a SAN linked to the Host servers. Not all SANs are born equal however, and many new SANs support Virtual Server in better ways, recognising duplicate data to make better use of the storage.  So commissioning a new SAN to specifically support the Virtual systems may be the smartest idea and optimise the performance and data requirements from the system.

Monday, September 21, 2009

Working for the enemy

There comes a time when an SE might move on from their organisation and either work for the opposition or some totally new employer. Is it a moral question on what you can say and if you can write any analysis about your old product?


Of course, for many SEs, this is probably covered by a non-compete contract, or perhaps under an NDA that you cannot say anything (bad) about your old employer or their product.
However where this is not covered by a contract what should you do (and what could you do!)?


Many moral issues are black and white and I would not do anything like the following:

  • Write a full competitive analysis from your internal product knowledge
  • List all the bugs and problems that are known to the old company
  • Hire all the good people from the old company
  • Share future roadmap or directions of the old company
  • Demonstrating the old company's product (unless you are allowed to keep their software)

However there is still a lot of wriggling room in this list.  Part of an employee's worth is the knowledge that they have accumulated through their working experience. You cannot sign away your right to earn a living (at least not an honest living) so there are many things in my opinion that you should be able to do. These include the following:

  • Educate new colleagues about strengths and weaknesses of the old solution
  • Write a competitive analysis based on published product information
  • Write on forums about published usage of a product
  • Join the product user group
  • Work for customers of the old product (as long as this is clear in your contract)
  • Work with potential partners of the old company

Unless you have specifically agreed not to do items on this list, it is your right to do so.  I'd say that you should think twice about doing anything that would require access to product or information that is kept within your old organisation. You should delete any passwords, FTP access, VPN access, demonstration images or information that is of this nature. Keeping this kind of information (without permission from your old employer) could implicate you if any kind of leak was chased up by your old employer.


Also, keep in mind that many industries are actually quite small well networked groups, and what you do or say can well come back to haunt you. Don't burn bridges that you may want to cross again.  Many times the company your knowledge is most valuable to is the one you have just left.

Friday, September 18, 2009

Tips for Presenting Architecture Info

This article is a healthy reminder that you should know who you are presenting to!

Top Ten Tips for Presenting Architecture Information


Most SEs are probably aware of this, but every presentation you give should be tailored and structured to appeal to whoever you are presenting to. Don't just rerun the same slides and give a standard presentation. Make sure you present the way that appeals to your audience.

Tuesday, August 18, 2009

Recents Sales Engineering Stories

Here's what I've been reading lately. Lots of good tips!

Tech Demo Guy
Winning in a Crowded Field - How to differentiate your product in a crowded market
5 strategies for success in demo marathons - How to win in a lengthy product beauty parade

10 tips on how to think like a designer - thinking like a designer helps to match your demo to your customer's needs. Remember you are trying to sell a Solution.

The Roadwarrior - stuck in airports with little to do?

Money, Money, Money! - A look at SE compensation with a PDF to take away!
SE Compensation: A Dozen Thoughts (straight to the money)

Optimizing screen resolution for web demos - Keep your prospects in mind when sizing your screen