The cloud: technological trend or business tool?

Michele Mauro
Senior Developer
#SoftwareDevelopment
#E-commerce ,#Retail management ,#Sales

The Cloud is no longer a frontier technology, but an everyday tool, especially in this period. However, like all Aton’s strategies, the choice to use the Cloud is not the pursuit of a fashion, but a precise business choice, reasoned on the terms of the company strategy.

Let’s see why.

Restructuring costs

 

One of the main impacts of adopting cloud technologies is certainly the change in the cost model of a project. In a traditional project, you initially have to calculate a set of resources, measure them against a hypothetical peak consumption, acquire them and commit them for an assumed duration of use. There are many uncertainties and unknowns, amplified by the volatility of today’s market, even in better-than-contingent situations. In a cloud project, on the other hand, resources are consumed on a day-to-day basis, charged by the hour (or less) of actual use and billed on a month-to-month basis. Often, their allocation can be changed on a moment-by-moment basis, following (even automatically) the profile of demand for services.

Of course, it is always necessary to make some assumptions in order to choose the most appropriate tools and to have an idea of the monthly costs; but changing direction on the fly is simple and economical: if a resource is little used, it is reduced or eliminated, and no longer paid for; if a resource is heavily used, calculating the ROI of its use or of switching to a different architecture is easy, and is based on reliable data.

 The cloud transforms CAPEX allocations made on risky assumptions into OPEX items that can be studied with numerical methods on real data, and can be modulated with full knowledge of the facts.

Automation, automation, automation

 

Cloud resources, intangible in their consistency, are not to be handled ‘by hand’ but are best expressed by automated processes that reduce opportunities for error and build value chains. The construction of a version for delivery is not a ceremony where someone follows a series of steps documented at the beginning of the project, but an automatic process, ‘programmed’ according to the needs of the project and able to evolve with it; it takes every change in the code, treats it according to its characteristics, and deposits it where it needs to be so that it can be easily put into testing, or into production. Possibly, again with another automatism, if possible.

Instead of an ideal document that can all too easily become detached from day-to-day practice, the construction of the software and the provision of the service are accompanied to become a value chain, which starts from the traced requirement, which becomes a modification or addition in the code or in the product configuration, which becomes an installable artefact capable of producing value. All this in a cycle where one can, with knowledge and control, decide where to invest and which arc to shorten or modify; at any time, depending on the needs of the project. And where knowledge is certain, literally “encoded” in the instructions that guide the construction of the software, and, like the rest of the code, guarded, traced in its evolution and accessible to anyone who approaches the development team.

From project, to product, to service. From cost per project, to product investment, to consumption per user

 

The terms of service to which users are increasingly accustomed, due to their experience with consumer products/services, are also beginning to affect business customers. Increasingly, companies prefer to allocate resources to research and innovation departments, rather than to structural IT cost centres, and it is becoming less and less unusual for a project not to have internal customer resources to support its execution, but instead to require a product that can be used without administrative commitment, with a pay-as-you-go fee. For the developer, this request translates into a powerful push towards a product organisation that is as configurable as possible to the client’s needs, but which must be able to be executed by consuming resources comparable to what the client is willing to pay or needs at that moment. It is true that the challenge is great, but the possibility of expanding the customer base to smaller sizes (but also to very, very large ones) and the efficiencies in innovation that can (and must) be sought to achieve this result are a very attractive prize, if not an imperative to compete effectively.

The synergy between the customers’ demand for flexibility and the innovations possible by making the most of the cloud deeply change the software producer’s value chain, but also push it to evolve to a new level of efficiency in execution and understanding of its business.

The cloud is not about chasing clouds to go where the technological fad takes you, it is a tool in the hands of the business within a strategy to address market demands.