Moving Beyond Vision
Vision is great but it only gets a company so far. The true testament of success is the ability of the company to not only create the vision and product but to succinctly execute. A wise VC once told me that a man and a product does not make a company make. The testament of a true company is one that can 1) create a vision of product, 2) refine it to meet succinct customer needs, and 3) execute from inception to deployment.
Those 3 steps are a lot harder than they appear. The weakest link that I have seen over my career that determines the success or failure of a product in the market is the ability of the company to listen to their customers. Although the opinion of the CEO, CTO, Engineers, Marketing, and Sales are interesting - they are not as relevant as that of the customer that uses the products in production to solve real world problems. Here is a list of my top 10 lessons learned implementing application virtualization.
Top 10 Deployment Considerations: Application Virtualization
Application Virtualization is a departure from the norm typically on how most Enterprise solutions are packaged and deployed. Communicating and planning based on what you know regarding the application life cycle is critical to both the customer and the company.
Key Questions to Ask:
1) Target Application Dependencies?: are there any dependencies with physically installed applications on the endpoint? If so what are those applications? Should or can they also be virtualized? What will the potential impact be? Always good to get a list and/or dependency mapping of all applications.
2) Why is the customer migrating the application to a virtual paradigm? The typical responses are either Application Compatibility issues, OS Migration requirements, Implement Software As A Service in a Cloud, Offshore support, Reduce Terminal Server Footprint or reduce life cycle overhead. How and what you architect and implement will vary depending on what the ultimate goal of the customer is. How they will measure the success or ROI of your product within their environment.
3)Compatibility with Target OS?: Not all Application Virtualization can simply be migrated to a newer version of the OS. Some require additional repackaging of the application to move to the new version. If OS Migration is a key reason - it is important to see if the applications are already virtualized and to make sure that you are working with the version of the Application Virtualization solution that is compatible with the target OS.
4) Who are critical People, Processes and Technology that will be impacted? It is important to identify all the stakeholders during a production roll out, educate them on what application virtualization is, the purpose of the deployment, and what the expected impact will be to them or their organization. Typically I suggest training a SWAT team initially of the key stake holders so there are less issues around communication and misunderstanding because it is a departure from the norm.
5) What is the Plan from Inception to Maintenance? The road to hell is paved with good intentions. Key to vet out and plan for not only the knowns but add time for the unknown factors that will come up.
6) What is the impact on Current Solutions, Processes, and Systems? Such as can internal products used for testing, deployment, troubleshooting etc work with the virtual application? If not what are the contingency plans for this new way of packaging applications? Does the vendor supply a virtual reg edit for example? How will current processes for deployments, change orders, and asset tracking be impacted? Any special integrations needed with existing tools such as Discovery, CMDB, or Delivery mechanisms?
7) What is the CUSTOMER'S Starting Point? Every customer and environment is unique. It is critical to understand what the customer's understanding is of Application Virtualization, educate them on the different approaches and work with them to take baby steps to implementing a solution so they can adjust along the way. This last one is particularly critical because too often People don't know what they don't know. It is better to start with a smaller pilot, identify GAPs in technology, training, and processes - have them addressed and then continue.
8) How critical is/are the applications being virtualized? I once had a Architect ask me the impact of using virtualization in the emergency room of a hospital and the best way to recover. My answer was not to use virtualization for that purpose as the technology in general is still in early stages. When it comes to life or death - always proceed with caution when deciding whether or not to give new technology a go. The more critical the application the smaller the steps that should be taken and more planning required to cover back out plans in the event something goes wrong.
9) Does the proposed architecture meet hardware requirements? One of the key reasons many people did not migrate to Vista was the hardware tax. Meaning the overhead would exceed the capacity of their system requirements. When a customer is proposing to deploying multiple versions side by side on a machine - Disk Consumption, Port Conflicts, Network Capacity, I/O, and other hardware related questions should be considered as part of the equation. Understand what the overhead is going to be on a per application basis to architect a realistic solution. Just because you theoretically can deploy multiple versions of the same application doesn't mean existing hardware can support it when this exponentially grows as more applications are virtualized.
10) What is the communication strategy? Meaning people are busy with their day to day distractions of their job - it is important to set aside time to clearly create the plan, touch point calls to ensure execution, and take time to evaluate overall plan to adjust if needed. This allows everyone to set the right expectations that are achievable and realistic.
Some of this may sound like simple project management - but one would be surprised by how many times key items like compatibility with current systems, regulatory requirements, or simple lack of communication cause deployments to fail.