Cloud architecture has settled into its “plateau of productivity” phase in the hype cycle. It has gone through experimental adoption, irrational enthusiasm, and despondent disillusion. Does that mean cloud projects are more likely to succeed now? Good question. The answer depends on both the business and engineering side of the project.
On the productivity plateau, the battle is over. Efficient implementations blithely pile up profits for the stakeholders. Stop! This is not exactly my experience as a software engineer and architect. Projects succeed and fail in every stage of the hype cycle. The predominant reasons for failure may change with the phase, but a more mature technology is no guarantee of success. An engineer builds systems to meet the stakeholders’ requirements. The hype cycle is perception and expectation, not requirements.
Unlike many other technologies, cloud has both business and technical aspects that determine the success or failure of the project. For example, the business value of a big data analysis project depends on the data analysis, not a changed business relationship. A cloud changes business relationships as well as technology. Even private clouds change internal business relationships.
Hype cycle
Both cloud business strategy and technology have experienced the ups and downs of the hype cycle. Gradually, perceptions of cloud systems have become more realistic. These phases describe market attitudes, not the experience of engineers designing and implementing code.
Marketers and product managers use the hype cycle to gauge the maturity of a technology. When a product emerges from cautious experimental adoption to expectations that exceed reality, marketing positions and features to attract sales must also change. But this has little significance for an engineer struggling with performance, supportability, and maintainability. At later stages in the hype cycle, engineers may have more experience and tools in their store of solutions, but this is the result of time and repeated installations, not market attitudes.
Phase One and Phase Two
I often think about technology in two phases. These phases correspond roughly to Type I and II errors in hypothesis testing. During the first phase, you strive for a replacement system that works as well as the system in the field. That is often difficult, but it is not progress. To progress, you must enter phase two and improve on the old system.
For some projects phase one is success. Older products contain code that was innovative when it was written but no longer appears in more recently written products. This code continually fades out of normal engineering practice and moves into standard libraries and modules. Replacing the old code with standard libraries makes the product easier to work with for junior engineers, which reduces maintenance. Replacement may also improve performance and scalability, but that is not the requirement. Matching the functionality and performance the old code in the field is enough for the first effort.
Cloud implementations
Phases one and two can get muddled between technology and business strategy on cloud projects. Cloud implementations are often chosen for business reasons alone. This is analogous to replacing old code for maintainability. An AWS EC2 project that replaces an in-house cluster running on aging hardware is an example. The project replicates the performance and output of an in-house implementation. It is not intended to improve on the in-house version, rather the goal is to lower upfront capital investment, maintenance costs, or other business concerns.
A service contract most often determines this kind of project’s business success or failure. The business has phase two improvement goals embodied in the contract, but the engineering remains phase one. In the end, business considerations will determine the final assessment of the project.
A phase one infrastructure replacement project like the above is not an engineering slam-dunk. Although similar, cloud virtual machines on a remote network are not identical to an in-house cluster. Two-aspirin engineering headaches come up after test-launching the first virtual machine. The headaches go away after the engineers do the phase one type work. Only then will the installation act as their customers expect. Performance and reliability may improve, but that is a bonus, not the technical goal. Even then, all the good phase one engineering may not matter. The business side's service contract must ensure favorable finance spreadsheets. If the spreadsheets come out wrong, the project fails and the blame often falls on everyone.
This can happen to a project at any point in the hype cycle. Engineers must not to ignore their phase one obligations. But the business must realize that business improvements depend on care with service contracts and service level agreements.