Often, companies who migrate their applications to the cloud focus heavily on the technical aspects. Due to the fact that the technical issues can be immense, they might ignore or underestimate the organizational challenges. Translating the vision to concrete projects and actions heavily depend on the organizational power to change. It’s vital to understand which hurdles need to be addressed to make a smooth transition. These organizational challenges hamper your Cloud migration efforts.
No management commitment
Every major change needs to be supported by upper management. Without it, every change is doomed sooner or later. This is especially true for cloud migration strategies which include a bunch of (senior) managers, Business Owners, CISOs, heads of legal and compliance, etc. Conducting a bottom-up approach isn’t the most effective way to sell your project upstream since there is a constant battle for the right budgets, human resources, and project priorities. Not only for your (first) “to migrate projects” but also to lower the priorities for other projects which are less impactful to yours.
A committed management team helps to advocate your ideas, they promote your projects. Besides, they help to spread the word about your achievements among others in the organization. And most importantly, they inspire others to join your efforts and free up resources to push your ideas to the next level. Be sure to share your successes and transform negative stakeholders into positive ones. These valuable stakeholders who have a lot of influence push your project forward without constant engagement.
No portfolio assessment
Program management is all about the management of several projects inside a “program”. Your applications and other IT assets are the most valuable ones in your company (aside from skilled human resources). Before moving a single application to the cloud, it’s vital to conduct a proper application portfolio assessment. By answering questions like the following, your efforts are much more fruitful:
- Which applications will be phased out in the next 1-2 years? Perhaps it’s not worth the investment?
- What is the net value of application X and how does this relate to application Y? An application that does not bring in any revenue (external) or cost savings (internal) might not be worth the effort. Be aware of any (missed) business opportunities, so it’s not all about cost savings.
- Is the application suited to run in the cloud? Some applications use legacy technology, such as Progress or Fortran. You might need to transform those applications first before even thinking of migrating them.
- What is the technical dept of your applications? Suppose your application has a lot of security issues and vulnerabilities, you need to patch them first before moving to the cloud. The same is true for applications that need to be refactored and simplified first.
Your application portfolio assessment can be as complex as possible, but sometimes is a simple spreadsheet enough to compare them on a number of key criteria. Developers can feel frustrated if their efforts to migrate their applications are hampered, so it’s wise to share the outcome of this step within the organization.
Backlogs are not aligned and not prioritized
Suppose your business case is rock solid and there is an agreement on the IT products that will be delivered, your Product Owners can start building their backlogs. If there are multiple IT products to be created, multiple Product Owners need to gather requirements and prioritize their backlogs. If there is no synchronization between the Product Owners, their backlogs are not correctly prioritized. You risk building the same (application/infrastructure) components. You also face the risk of building the IT products in the wrong order, especially if there are (hard) dependencies between them.
On an individual level, this can hamper the DevOps team since they need to lay out the foundation first and then progress toward more specific tasks and activities later on. As a Product Owner, it’s vital to understand that the first bits and pieces must be carried out before the actual coding starts. Without it, you risk losing too much time on reworking to patch things and improve the foundation – which is hard.
Prioritization can then be achieved based on stories that deliver most of the business value. This is not measured in story points (relative complexity) but in proposed business outcomes. Think of a 10% increase in paying customers or reduce the number of complaints by 25%. Another one would be to reduce the latency for the mission-critical transactions to 10ms. These are practical and concrete User Stories that lead to measurable results and thus should be prioritized over other stories that do not contribute to or support these activities.
No valid business case
Every new project costs money. Pilot projects eat away money you can’t spend on other projects and activities. Especially projects that have a bit of an uncertain outcome tend to leak away more money than expected. DevOps is all about working software over lengthy documents and extended documentation. However, some key aspects need to be clear to get align the budget holders with your project. The end result of your business case should be: does this project actually bring in new revenue streams and profit after it has been finished? If not, the project outcomes are less predictable or even very disappointing.
Every valid business (document) case should at least have the following components: an overview and introduction, any assumptions, and a quick summary. These should be followed by a financial discussion and analysis together with the proposed benefits and business impact. Since things go the “Agile way of working”, the schedule and milestones should be brief but crystal clear. The risk management and analysis follow after and at the end, the author(s) should write down his conclusions and appendices.
Without this document, it’s impossible to have a clear business case that answers the primary questions of the budget holders and you can’t make any informed decisions. Your business case is also centered around three important IT change management activities. See the previous article that highlights these.
Together they act as a starting point to actually reserve funding or abandon the whole idea or project in the very first stadium.
A dis-balance between IT and business personnel
Every now and then people coin the phrase “the business is at the steering wheel”. It’s tempting to think that hiring more business professionals helps to push IT-related activities forward. Perhaps this helps to quickly clarify the requirements for the new applications or spin up new projects and activities to conduct pilots. More often, this leads to endless discussions since everyone has an opinion on things. Especially when PowerPoint presentations are the most dominant files being mailed around. If so many people interfere with “what the business wants”, who is going to actually do the work?
Watch out for companies that have a dis-balance between the people that have practical tech skills and people that only know about business-related aspects. It’s important that new technological trends are discovered. Business people do not seek opportunities in terms of a replacement of Helm or investigate time and effort to explore the options to run rootless containers. Having some “in-between” roles here is critical because the “pure business-minded” people cannot interpret these technological improvements. However, they are needed to support the tech ideas and to allocate funding for them.
Keep in mind that if the ratio between business and tech people is too high (f.e. 25% tech and 75% business) then you might need to correct that.
No investment in security training
IT security is a broad topic since it covers nearly everything: from the physical security of data centers to network security, data security to application security. It’s still a misconception that security is only a topic of interest for network and system administrators. Developers quickly become responsible for a lot of security-related aspects. They need to make sure that their deployment scripts are secure as well as the resources on which their application lands as well as their application and the connections to and from those applications (think of APIs).
Companies who do not invest in security training for their developers risk losing time and missed opportunities due to a number of reasons:
- Risk avoidance: without proper security training, developers might make mistakes so it’s tempting to “forbid and block everything”. That is risk avoidance from a tech perspective. However, it is a missed opportunity from a business perspective. Risk management is all about finding the right balance between them. Without risks, no progress and no evolution in things. Security experts are not the only ones who should judge security risks. Developers can do so as well, once they are trained well enough.
- Slow learning: if all security-related knowledge is within the heads of dedicated security experts, the company cannot learn as fast as possible. This knowledge needs to be distributed and expanded by non-security experts. Since developers closely work with core IT systems and they have a lot of domain knowledge, they are good candidates to handle security issues.
With these tips in mind, every decision that is security-related can be made a lot faster.
Wrap up
So far so good, you’ve seen a lot of factors that can hamper your cloud migration efforts. This article sheds some light on organizational challenges which you can now identify in your organization. It also provides tips and tricks to tackle them. Hopefully, the information presented here streamlines your projects and helps everyone without the organization. All in all, everyone is part of it.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.