CXO Role in Implementing Open Source Cloud

July 7, 2020

Today we are going to discuss the CXO Role in Implementing Open Source Cloud. Our today’s blog post is actually the ninth post in the series which captures my notes with various CXOs during the Comprehensive Database Performance Health Check.

Here are the blog posts in the series which you can read in order to learn more about this topic:

CXO Role in Implementing Open Source Cloud CXORole-800x730

CXO Role Conversation

Today we are going to discuss the role of CXO Role in Implementing Open Source Cloud. We have already discussed how you can select the best cloud platform for you in this blog post. Once you know what is going to be your cloud platform, you can continue to start planning your journey to the cloud. Here are 5 key steps you need to know as a CIO, CTO, or CXO for your organization.

Step 1: Workload Analysis and Application Classification

It is very critical to understand what applications, data, and processes can be moved to the cloud and what needs to stay in the hybrid model. Not every application can be moved to the cloud immediately. Contradictory to what most believe the biggest challenge to moving any workload to the cloud is not the technology but the compliance regulations and privacy laws.

Here are the three prime candidates of the applications which should go first on the cloud:

The application which runs the most infrequent but takes the most computing resources and does not involve any complication of the regulations or privacy laws are the best candidate to move to the cloud-first.
The application which requires the frequent provision of the infrastructure can use the auto-scalability of the cloud very well and needs to be considered first to move to the cloud.
Stand-alone new projects should be considered for the cloud-first architecture, where you build the design based on the availability of the cloud features rather than the on-premises legacy concepts.

Step 2: Building Business Case for Leadership buy-in

Once the classification of the workload and application is completed, it is relatively easy to build a good business case for the leadership buy-in. CXO should build a business case involving the following concepts:

Service Level Agreements (availability, performance, security, and privacy)
Business Health (revenue, compliance, ease to do business, etc)
Cost Analysis (license, human resources, service and support, data migrations, uptime monitoring, etc)

The biggest discussion I often see around SLA and Business Health in the organizations, however, when the cost analysis is presented, often it brings closure as the financial discussion shifts from capital expenditures to operating expenditures. Most of the organizations prefer to spend their fortune when their products start to bring in revenue and cloud brings that opportunity.

Step 3: Technical Roadmap (Model, Application and Data migration)

This is where the checklist from the previous blog posts comes very handy. The technical roadmap should be built on the following concepts:

IaaS, Paas, SaaS, FaaS migrations
Security certifications
Data governance, privacy, and security
Management Tools (orchestration and integration tools)
Service level agreements and support availability
DevOps, automation, and scope of innovation
API management
Single sign-on
Master data management

I have been involved in many different organizations and the biggest discussion I see is often around the ground level infrastructure of Virtual Machines and Bare Metal servers. If your business requirement is such that you need to execute the complete stack on a single server keeping cost in the focus, virtual machines are a great choice and if you need flexibility and performance Bare Metal servers are a great choice.

When the technical roadmap is built for the solution one should make sure that it is robust, scalable, and performing optimally. While flexibility is key, it is important to remember to use the standards otherwise, it is quite possible that the end product face issues with interoperability in the future.

One of the biggest factors which create complication and increases the cost for any technical implementation is regulatory laws and privacy laws. It is always a good idea to start the migration roadmap keeping them in the focus to avoid any “redo”s in the future.

Step 4: Cost, Timeline and Readiness of Human Resources

Once the technical roadmap is built in step 3. Now is the time as a leader to answer one of the most important questions about the cost and timeline. Longer the timeline to complete the project more cost is often involved with it. Additionally, it is critical to get the right set of skilled experts to complete the project on the time.

The readiness of skilled experts is always a challenge for any organization when they are making groundbreaking changes. Moving from the in-premises setup to open source cloud is not something that happens every day. Not every IT professional is lucky to work on such projects before and that limits the available expertise in the market.

This is when CXO role has to make the difficult decision to either build the entire solution in-house or just offload to set another organization that has done this multiple times before. The decision is easy if your technical roadmap in step 3 is built with carefully considering all the aspects of the business and technology.

Your cost and timeline prediction will be very accurate if you have spent a good amount of time building your technology roadmap.

Step 5: Feedback, Support, and Innovation

Once the project is in the progress or completed, the job of the CXO is not over. It is very important to get the necessary feedback on the project and build the next technical implementation road map on it. If the feedback is good, it is easier to focus on the next part of the innovation in the platform. However, if the feedback is negative, it is critical for CXOs to build a support system to rectify all the inefficiency. Additionally, along with the progress and innovation bit, more checks have to be implemented in the future to reduce the support needs.