Application design

Many organizations want to leverage cloud computing as a means of reducing the operational costs associated with maintaining legacy applications. In these cases, the cloud solution architect is faced with an application migration task where application maturity may become a decisive factor in whether a cloud environment is beneficial or detrimental. Application characteristics could also profoundly influence the decision regarding CSP choice. Many legacy applications, for example, are tightly coupled to data, specific processes, and other related applications. This makes them very difficult to transition to a commodity-based technology service model. Embedded dependencies and unusually undocumented assumptions don't easily fit into a strictly standardized and not easily tailored environment.

Cloud-friendly applications are loosely coupled, with RESTful interfaces and modular design. This design approach makes them more amenable to modern cloud-based infrastructures. This difference must also be addressed when applications are newly developed for a cloud deployment. Developers have traditionally had the luxury of exploring new design approaches that often leverage the unique capabilities of a specific and targeted technology or vendor. These new approaches are often foundational to a company's market differentiation or customer value proposition. The resultant infrastructure customization or configurations are then presented to the supporting infrastructure system administrators as minimum requirements or must-haves. If the organization is organically responsible for deployment, these minimum requirements are translated into specific technology procurement and technical configurations. If the deployment is to be outsourced to a managed service provider or system integrator, the procurement official translates these requirements into a request for proposal (RFP) or request for quote (RFQ). Competitive vendors then follow the specified requirements to design and present a priced solution. After technical evaluations and cost-benefit analysis are completed, a contract is awarded and funded for the delivery of a selected solution.

This traditional approach is fatally flawed if the targeted vendor is a cloud service provider. First, cloud computing environments are designed and managed as a commodity service by the cloud service provider. This will typically negate most technology or configuration dictates from the end customer. It also prevents exploitation of most vendor- or technology-specific capabilities designated as minimum requirements or must-haves by the developer. Secondly, the solution design is fixed by the CSP based on previously finalized technology decisions and CSP-funded acquisitions. The technology service price is also dictated by the CSP based on its target marketplace dynamics, not the price sensitivity of any particular customer. In short, RFP or RFQ requirements have virtually zero effect on available CSP technology services or technology service price.

Cloud service acquisition fundamentally represents a 180° shift from traditional IT acquisition practices. This can not only wreck existing procurement process oversight and control, but it will also lead to unexpected deployment challenges, cost, application design changes, and failed migration projects. This pattern has repeatedly been observed across the IT industry. Its root cause is the cloud solution architect's failure to address procurement process differences between traditional IT service acquisition and cloud IT service acquisition.