IT Focus Area: cloud
June 1, 2017
How to Increase the Speed of Cloud Deployment
Sirius and Forsythe are now one company. Sirius acquired Forsythe in October 2017 and we are pleased to share their exceptional thought leadership with you. Enjoy the podcast.
Why Companies Struggle with Cloud
The cloud can be complex. There are multiple cloud service models that exist in the marketplace such as private cloud, public cloud and hybrid cloud. However, organizations are struggling with how to use cloud, not the technology of the cloud.
Cloud deployment can potentially impact multiple areas of existing IT, including continuous integration/continuous deployment (CICD); DevOps; secure software development lifecycle; monitoring and alerting; change management; service provisioning; identity access; and authentication models and security approaches.
Many enterprises attempt to address all these things at once rather than approaching cloud as an organic construct where incremental improvement drives business and technical value.
To be successful with cloud, it is important to organize your cloud program around the functions of cloud. Focusing on this aspect helps you integrate cloud into your traditional IT services.
Often, cloud deployment frustrations are also the result of a clash between a company’s culture and a new operational model.
In many enterprises, there is an expectation of perfection in project delivery.
It is possible (but counterproductive) to deploy cloud without driving business innovation
At too many companies, cloud is not innovative to processes and people; it is simply the application of a modern technology.
The traditional waterfall project and old schools style of financial management practices can put the brakes on the potential cloud benefits of improved speed-to-market, speed-to-decision-making and speed-to-implementation.
The alternative: start small and go slow
In our experience from working on many diverse types of cloud projects, we are seeing a quick way to identify cloud gaps and add the appropriate capabilities in a timely manner.
Start by delivering limited cloud functionality.
Because it allows you to identify where and how your company needs to transform to accommodate for cloud.
It also provides your company with the needed cloud skillsets and insight into how best to integrate cloud into your existing enterprise portfolio.
The traditional way often presumes cloud knowledge is easily available.
It is not.
The critical question you should ask
After defining the business capabilities that your organization is looking for from cloud, the first relevant conversation should be around the question:
How are your applications that will run in the cloud going to align with your desired business capabilities?
Many companies think the conversation should start with understanding cloud, the different cloud models on the market, or how the underlying architecture of cloud works.
This is backward.
Cloud won’t have a significant impact on your applications or your operating model if you are simply deploying your applications on a different Infrastructure-as-a-Service (IaaS). If you are looking for better response time, higher availability, and business capabilities, it requires microservices and possibly containers.
This new agile operating approach may be more complicated but it is more impactful to your business.
Why is asking the above question so important? Because what you are trying to do is to define agility at your company.
Why minimum viable product is important in cloud deployment
Originally coined by Eric Ries, author of the New York Times bestseller The Lean Startup), minimum viable product (MVP) is effectively the smallest functional item that you can build which delivers some business value and enables client feedback to drive the next development cycle.
It is not just a product, it is a process.
You develop a minimum viable product or MVP to:
- Receive feedback
- Add features
- Build an incrementally improved MVP
And then, you repeat.
An MVP needs to show your company enough value that people are willing to use it. It needs to demonstrate benefits to continue to drive development and it provides feedback for future MVP work.
Having MVPs (in its smaller, bite-sized forms) at your company reduces the fear that cloud adoption can create within an organization and minimizes risks. It can act as a change agent against company inertia.
MVP helps overcome the mammoth “cloud is changing our world” conversation. It is a conversation on how an organization can make progress on cloud with defined successes and risks.
Defining MVP for Success
It is important to drive simplicity in your MVPs.
Let’s assume your goal is to deploy applications with higher availability. An MVP may be deploying an application in a microservice within a container (not using CICD or with a security model).
A classic mistake for enterprises is confusing the appropriate minimum for development with the necessary minimum for the organization. The fundamental differentiator of agile development is that the minimum for the organization is achieved over multiple iterations of MVPs.
The four process steps are:
1. Determine what is really required for MVP
Is this [insert a function here] technically required for the MVP? Not, “does my organization require this?” but, “does the MVP not work if this is missing?”
An example is monitoring. For many enterprises monitoring and alerting is required. But for MVP, the application in the cloud could still work, if monitoring wasn’t present.
2. Define the purpose of MVPs
Defining the purpose is of the MVP is so you meet that objective, not sub-objectives within the MVP. For example, is there a manual work around? Is a manual process acceptable? Could it be made to be acceptable in the short term?
A practical example is identity management. Does the MVP need to tie to a new identity management model? Or an existing one? Could local accounts be used for identity temporarily? Remember, it is important to accomplish the purpose of the MVP, not the purpose for the overall organization. (Yet, remember iterative improvements!)
3. Find what controls are really needed
Is there a control we must have? If yes, what is the control that meets your company’s requirements? If controlled and secure access for MVP is a requirement, could the environment be simply put behind a firewall so that control occurs at the perimeter rather than based on a traditional organizational model? Meet the control, don’t meet the current methodology.
4. Be ruthless with frills
When looking at your MVPs, you need to be ruthless. It is better to have fewer frills and faster development. Why? An MVP is orientated toward a practical approach for innovation. An essential component is “fast failure”: fail fast, learn and move forward to the next iteration.
As a result, MVP is an excellent approach to recognize wasted effort or incorrect strategies. It provides a learning approach for large organizations to identify their strengths and weakness, as they move towards cloud. It also allows them to be more transformative, at a faster pace.
Everything Doesn’t Have to Be Perfect
There is an understandable desire for companies to understand upfront the total cost of ownership (TCO) for cloud across the entire enterprise and how cloud can drive business value. However, in trying to do so, the essence of the cloud and the value of cloud to the business (flexibility and innovation) is often lost.
As 20th century international statesman and Nobel prize-winning author Winston Churchill stated, “perfection is the enemy of progress.” By applying agile, lean methodologies and accompanying strategies, your company can reduce risk and drive to a faster execution of cloud.
Understanding and using minimum viable product (MVP) can provide your company with the cloud skillsets and approach to integrating cloud into your existing portfolio of IT services.