The Ploy in Deployment
Over the years a lot has been done to enhance the control and efficiency of application development processes. From agile development to change management solutions based on ISO and ITIL standards, the progress has been remarkable. However, like everything else, this too has a downside. They say that every cloud has a silver lining, but in the world of technology, this silver lining is likely to affect the functionality of the cloud. The increase in the use of agile development has aggravated the pressure IT organizations face in deploying new applications.
Each new enterprise application brings in several diverse application components spread across numerous environments, including application servers, desktops, Web servers, mobile devices, databases, etc. Also, most large organizations have different departments handling each of these functions, and the potential product users are often not in control of the timelines. Besides, since security and compliance requirements put a lot of burden on the IT teams, companies adopt a “better safe than sorry” approach and discourage employees from easily getting new applications or their versions. For the product vendor, the total cost of support is directly proportional to the number of older versions out there in the field.
Although the vendor is not in control of the organization’s processes, they can certainly make the process of deployment simple enough to ensure it doesn’t add any further delays. So, what can be done to facilitate the process of product deployment? Well, the process must start from the start. If you’re designing an application for large enterprises, then a lot of aspects need to be taken care of. These can make or break the time-to-value of the product. I’ve compiled a list of all my learning over the years, which I have seen work most of the times.
A typical enterprise application should be designed in a way that client deployments, server deployments, network permissions, database creation/access are segregated as functionalities which can be performed by different roles. Don’t assume the user of your product to have these roles within the organization. For example, databases in many large organizations are centrally managed. Creating a database can be potentially done through a ticketing system rather than through your product. Make sure you handle it.
Product Documentation & Support
Product documentation should have role wise information so that it’s easy for your users to understand which departments they need to talk to for prerequisites before they even get to the deployment. Also, your product support team should be fully-equipped to handle the prerequisites required for each department with good reasoning. Be prepared to answer tough security review questions, if you expect too liberal access privileges through your product.
Understanding what the client wants to achieve with the product is yet another critical factor. Do not push further if you realize that your product can’t deliver or live up to their expectations. Regardless of the outcome, the focus should be to understand the client’s requirement and then communicate the facts to the product team. The aim should always be to win a customer and not sell a product. Often times, the oversold product start experiencing problems at the deployment stage itself. Example – Would it function across site boundaries with stringent firewall rules? Yes, of course!
Proof of Concept
This is a crucial stage in the success of a product deployment and will require some effort. To be fully prepared from your own standpoint:
- Ensure all customized components are consummate;
- Review data schemes and sample data sets wherever applicable
- Make sure that success measurement criteria is clearly defined
- Ensure the POC demonstrates how a mishap is handled.
The worst part of delays in product deployment is that even the employees who were enthusiastic about welcoming the new and improved technology, lose their buzz along the way. The tedious and lengthy process not only takes a toll on their eagerness to use the application but sometimes also puts an end to an opportunity that could’ve been game-changing. I’d once read this- “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change,” strangely enough, it applies well to enterprise products aspiring to thrive in the complex world of enterprises too.
Author: Monica Paul