Why looking before you leap is a good idea in the cloud...
Ever wonder how cloud providers produce such reliable products? Well if you do, then you can be sure that any successful cloud provider is aware of the height they can fall from in the cloud if they get it wrong. One of the key focal points of cloud development is technical project management and analysis of new technology integration into their solutions. Requirements analysis when this type of priority and focus lens is applied becomes a very important first step, with nobody looking before they leap upon the cloud. Misdefined and/or undefined requirements lead at best to quality compromising pivots to changing requirements, and their resulting outcomes. In the SaaS world, cloud companies should bear this learned lesson in mind and think first about the detail of what they want, what they are willing to accept in cost, time and resources applied along with expected outcomes.
When one does, applying all the assigned resources to an outcome that is not fully understood becomes clearly unwise and complicated by new technologies that engineers, architects and managers are unsure of. The first go-to for expediency is often industry reputation, which can prove fatal to a project if the new technology provider simply has a capable marketing department. Accordingly, after validating a project's statement of work, moving into the requirements analysis phase should be treated as a critical first juncture especially when functional and/or non-functional requirement definitions bring new technologies into a scope statement. Some of the things to consider at this point regarding new technologies:
- Are they newly released? If under 12 months after initial release they should be considered buggy. Alternatives with release notes to study should be evaluated to see if the feature requirements and stability/integration capabilities favour the new product or its older alternative.
- If there is no first-hand experience on the team at the application and infrastructure/cloud level of the 3rd party product, then cost and define the project into two-stage iterations. The first-stage iteration is an assessment of the product with the project technical team gaining experience in its use. This should include running (test) use cases on it to gain insight into bugs along with workarounds required recording impacting issues around security, performance and/or feature use. This should run on the GUI, Command Line API and SDK levels to fully understand the service provider's product and its capabilities. If successful, move into the second-stage iteration with learned lessons along with requirement updates recorded to assist in the second-stage iterations.
- If the technology is found to be not providing what the project requires by its requirements definitions, then move to the 2nd technology preference and keep on going until the benefits of a product outweigh its limitations along with known workarounds. This lowers the risk of 3rd party inhibitions on project success.
- Lockdown your requirements by design when the implementation part of the iteration occurs. Do not let political influence, indifference or boisterous forcing of changes occur. If a new change or alteration is required, record it as a pending requirement action item. Make sure you finish the implementation, test it and then evaluate the new and/or changed requirement(s) with a view to the next iterative cycle over that stage of the project. This requires management buy-in and should be enshrined in policy for support on a project basis.
- Establish ground rules with your 3rd party provider around support at all stages in the project and factor in SLA on support and availability when engaging them for the product. This support feature is critical in navigating technical and commercial issues found inflight on a project.
Whilst this may seem obvious to many, the pressures of a new project can often lead to errors in judgement at the earlier stages, which become clear later down the project path when correction is more costly than the compromised results the project produces. When you are relying on a 3rd party for your success, it's always wise to adopt a deep and cautious approach to the adoption of their technology as it directly affects your own product success in the digital world of SaaS products.
Stay tuned for more on Infrastructure in this blog along with articles on other areas of interest in the Writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!