The Missed Cloud Audiences

By: Majed Amer, Cloudivize Technologies; Co-Founder










Cloud vendors are investing a tremendous amount of money and effort to improve their offered services, to introduce more new services so software development and software delivery is simpler, and to shorten the software delivery lifecycle.

The question is, who are the targeted audiences for Cloud platform? In addition, how much Cloud is accessible to those audiences?


To answer those two questions, let us analyze the typical development lifecycle of cloud solutions used by many software companies, and to try identifying the involved parties.

Participants at Product Development Lifecycle

Mostly, the process starts with a Business Owner, who comes with a business or a customer need to develop a Cloud solution; he may provide a business plan, and may build a good business strategy for such cloud solution, then get the buy-in from Management.

As a responsible manager, he may perfectly present his vision and strategy to his organization and kick-start the technical teams to work on building and delivering the cloud solution.

From this point, the technical team led by the Solution Architects takes the wheel. They plan, design, discuss, brainstorm, and finally come up with the perfect architecture for the cloud solution. They may present it to Management (any level of management) to get approval.


At this point, Development Team and DevOps are unleashed.


The commonly use CI/CD cycle

During the development process, all parties may be involved, and more “players” may “join the game”, e.g. SysOps can join the review meetings to learn what is coming their way so they can operate when the product is released.


Fast forward, product is developed and delivered, DevOps handles deployment, SysOps take control and the cloud solution is “up and running”.


Along the above lifecycle, different cloud assets and resources are allocated and used. Most probably there was a cloud development environment deployed and cloud development tools used, maybe staging and/or beta environment deployed for testing and pilots, and clearly there are production deployments for customers.


The story continues… and change management process is used. Business Owner may come with more requirements and changes that need to be applied into the product, hence additional cloud assets may be allocated into the product (on the various deployed systems). This may continue as long as this product is in development and continuously deployed.

The Cloud Audiences

During the product lifecycle we identified the following parties that had some relationship to the Cloud, each one with their own tools and different responsibilities:

  • Management (mainly, middle-level management)

  • Business Owners

  • Architects

  • Development Teams

  • DevOps Personal

  • SysOps Personal

Let us look at the various stages of the above development lifecycle, and their impact on the used/deployed assets.

From the point Management gave the green light for developing and deploying such cloud solutions, while this product is developed and deployed, who has the control of all allocated assets? Is there a real comprehensive view to the process participants of the used cloud assets?


To control the development process and deployed systems, there will likely be multiple stakeholders that need to be assigned. Architects need to be kept up-to-date. DevOps need to be fully in control of the multiple deployments, management needs to be in control of the invest costs. In addition, all these parties need to communicate smoothly without continuously attempting to bridge communication gaps.


The question we asked ourselves at Cloudivize Technologies was: what are the tools used by all those stakeholders and involved audiences? Are those tools helping them to fulfill their responsibilities and communicate smoothly with other parties during the development process?

Different Tools, Broken Communication Chain

We recognized that multiple different tools were offered for each role. Such tools are exhaustive to maintain and may break communications between those tightly dependent parties.


Architects mainly use topology static diagrams to present their view on the product to development teams. However, development teams can apply interpretations, and development day-to-day reality can drive changes, which leads to topology changes, then the architectural static diagrams need to be updated.

Later, DevOps gets the product and architecture diagrams, they use their tools, mainly some sort of scripting language, to deploy the product. They may apply some field considerations that could affect architecture, hence more changes.

During the whole process, Management need to be kept updated, and their tools (mostly, kind of dashboards and reports), need to reflect all the cost implications of architecture changes.


Any minor noise in the communication chain could lead to chaos and significant money loss.


We believe that the different tools for the different roles are blocking many potential users from accessing the cloud, making the Cloud some unrecognized vague thing somewhere that only very technical people can understand and access.


The Cloudivize Way

Cloudivize suggests solving the above problems by making the cloud more accessible to all above stakeholders and audiences by using the same intuitive tools and methods to simplify communication.


Visualizing deployments, system topology, cloud assets, integrated with each asset cost, should provide the basis for smooth communication, standard operation process, accessible control, and unified processes.

Typical view at Cloudivize

Cloudivize shows the actual deployment and used assets, so Architects, Development, DevOps and SysOps see the same up-to-date view, so there is no need for change management processes on static diagrams, and no need for endless alignments.

Same view is used by DevOps and SysOps for cloud assets operating, and deployment control.


At the same time, Management can see all their organization cloud deployments with the invested costs on each deployment and each asset, using the same tool their teams are using.


We believe at Cloudivize that when all the above audiences get accessibility to the cloud, using the same simplified tools, and not leaving anyone out of the game, each role can contribute to the product and process from his position, and organization can become more efficient to provide better cloud solutions.


Visit www.cloudivize.com to learn more about Cloudivizie Technologies solutions



  • White Twitter Icon

Copyright © Cloudivize Technologies LTD. 2020. All Rights Reserved

See & Operate Cloud Like Never Before