This seems futuristic, but this is how agile and rapid development methodologies have painted the image, and the IT players have no option but to go with the flow.
So, it is pretty common for a customer to ask its preferred partner or an aggressive product vendor to do a proof of concept. The reason (mostly genuine and sometimes not) could be one of the following:
- To see the promised features of the solution/technology in action.
- To get a first-hand view of the to-be system.
- To settle any stakeholder conflict over multiple tools (e.g., a VP favors Microsoft whereas the CIO prefers Oracle).
- To address a tactical issue.
- To plan for next quarter because there’s a lack of budget in this quarter.
- To subdue over-excitement.
Imagine you’ve just completed a BI POC for a customer, made a good presentation and the customer is very excited about it, and requests you to move the POC in the Production environment as soon as possible.
Before you start celebrating, there are a few key things you need to be cautious about. This article illustrates some of the critical checks and balances required before moving the POC to Production.
As shown in the figure one (see chart at left), rather than performing a “lift and shift” of the POC to the production environment, addressing the following questions will ensure fewer surprises when the solution goes live.
Is the Bigger Picture Known to You?
Sometimes the customer asks for a POC to address a tactical or a pressing need, and this may or may not be in line with the architecture roadmap or the long-term vision of the client.
If the customer has already started on a particular architecture roadmap, it would be worthwhile to make sure the POC is in line with the chosen roadmap; if not, the deviations aren’t justified.
If the customer does not have a roadmap and is not planning one in the short to medium term, you should make sure the customer is aware of the pros and cons of the POC – including the technology stack used for the POC and the functional requirements addressed in it.
Do You Have an Exhaustive Assumptions List?
This is the most important checkpoint, especially if you are the primary driver of the POC rather than the customer.
Having an exhaustive assumption list will help you and the customer understand the scope and the limitations of the POC and can help plan the POC’s journey to the project – both in terms of the realistic time and efforts required for the journey.
Did You Bypass Any Business Process Which Would Require Business Intervention?
If your POC is addressing a functional requirement, it is likely that the business users interact with the data. To simulate the same scenario in the POC, you might have automated the process in the back-end or assumed some default values for the inputs.
This step makes the POC development faster, but to make this happen in the live environment will require a business process change which may impact your effort or schedule, depending on how fast the customer organization adapts to that change.
Is Any Hard-Coding Involved?
POCs are normally time-boxed, which often leads to hard-coding in the code which otherwise would have been a variable or a configurable item in the project. Documenting all the hard-coded instances will ensure that the journey from PoC to the project is not a bumpy ride and will also help you justify the cost required for the journey.
Did You Use Any Work-Arounds in the POC?
It is a very common to use work-arounds if you have adventurous developers in your POC development team. While work-arounds are good for a technological problem, they might cause issues in the customer’s live environment.
Again, the best thing to do would be to document each of these and make sure that they are addressed before you move the POC code to production.
Version Mismatch?
Ensure that the versions of the operating system, ETL tool, database and reporting tool used for the POC development are the same as the production environment. If the versions are different, additional testing in the target version is advised.
If you’ve used some third-party utilities, make sure that they work in the different versions – especially if you move from a 32-bit to a 64-bit version, or vice-versa.
Is the Design Scalable?
More often than not, when the POC is in design phase, the data model design, the ETL or the reporting layer is not created with the project in mind. The data model is the heart of any BI project; if it is designed without considering scalability, the additional modules you add later will be more like a patchwork, instead of being integrated with the enterprise system, as the customer intended it.
Things like indexing, error logging framework, audit logs, and archiving mechanism are generally given a lower priority during the development of the POC. While these do not hamper the POC, the customer will surely be expecting to have them in place when prior to deployment time.
Have You Tested for Peak Performance?
