In this article, I would like to focus on how you can grapple with the following topics: expertise management amongst personnel, IaaS vs PaaS, how you can keep pace with innovations, DevOps culture, cloud security, and framework.
If you are an ISV and are switching from a legacy application to a SaaS application, your organization will undergo a transformation on five levels – strategy, finance, organization, go to market, and technology. We will be examining each of these levels in more detail in this five-part series. As the levels overlap one another somewhat, or one has an impact on another, they cannot be viewed as five separate areas. Nevertheless, each poses its own questions and topics that need to be taken into consideration.
This article will look at the technical change and the decisions that an ISV needs to consider when switching from a legacy application to a SaaS application in the public cloud. I also recommend that you take a look at the ISV playbook from Microsoft. It addresses many of the transformation levels based on in-depth research, which can help you to arrive at the right decisions.
Technology
This is the last of five articles in this series, looking at the technical change. We have written a lot about technical innovations using Azure and how you, as an ISV (software company), can take advantage of them – see also our website. This article will instead examine the business impact of the technical changes that will occur when migrating to the public cloud. We see a fairly mixed bag of scenarios amongst our clients. One company has optimized the code so well that they are able to switch directly to a PaaS (Platform as a Service) environment, while another has 20-year old code that needs considerable modification before the switch to PaaS can actually be made. Consequently, we often opt for an IaaS solution or a combination. Windows Virtual Desktop can play a role in this, as it allows for provision of applications online, with part PaaS and part IaaS. For further information about WVD, see the Azure pricing calculator. In this article, I would therefore like to focus on how you can grapple with the following topics: expertise management amongst personnel, IaaS vs PaaS, how you can keep pace with innovations, DevOps culture, cloud security, and framework.
Expertise Management
When you place your application or solution in the public cloud, you need to give some thought as to how you will train people in development for the public cloud and how that will be managed. Furthermore, how do you then retain these highly sought-after people within your organization? Once you’ve determined which public cloud supplier to use, a good starting point would be to carry out a skills assessment. This will allow you to gage the current level of expertise of your developers, plot that against where you want to be with your architecture, and understand what expertise you still need to get there, and then subsequently formulate a training or education plan. You can safely assume that the majority of changes will progress at a slow pace and won’t be completed within a day. This also means that working with the public cloud, developments in the cloud, and managing them are new skills that you will acquire by doing them and training yourself in them. And that takes time. Many of our clients take between six and twelve months to get that far. In addition, it is also important to keep track of what these people are working on, what the development plan should look like, and how they can keep up with those skills in the public cloud. Meetups is a good example of how they can actively share expertise, acquire it, and establish a network. Internal expertise-sharing sessions are also a good way of engaging people and encouraging them to move beyond their comfort zone to talk about the latest developments. Apart from building your own expertise internally, you will probably also want to make use of knowledge partners or partners who can help with management of the public cloud. It is important that you come to robust collaboration agreements on how you will safeguard the expertise that you acquire together and document internally within your own organization.
IaaS vs PaaS
I am often told that people should migrate to PaaS, otherwise the public cloud has little value. It’s an interesting point as it’s partly true, but not entirely. Yes, you should want to migrate to PaaS because it is cost-effective, scalable, secure, and robust. But that does not mean that you cannot start to migrate to the public cloud if you’re running on IaaS. There is nothing wrong with purchasing IaaS services within the public cloud. It may be more expensive and require extra work to ensure availability, but it’s still an excellent service. Plus, there are many reasons to start with IaaS. For instance, you are still a legacy application supplier and you want to position your application as a web application in the eyes of the end user. With IaaS, you can do that, and in so doing, have your first “cloud offering” or SaaS offer ready for your clients. No problem if it hasn’t yet been optimized at the backend – you can move on to work on that. The IaaS environment also allows you to make use of cloud native services, such as firewalling, gateways, etc., which is a considerable advantage. This means that it doesn’t have to be a case of EITHER OR but also an AND AND. Besides already having an SaaS solution on the market, you may, as a software company, be making efforts to attract investment to the company, and investors may only be interested if they see the solution operating in the public cloud. This could be a good reason to start working with IaaS right away. Another reason could be that your existing hardware is obsolete and that you are looking to replace the data center. There are myriad reasons to migrate to the public cloud now and not wait until you can operate with a completely serverless configuration. You will need to assign responsibility internally and have someone identify the most efficient service within the public cloud to help you achieve the goal that you are currently working toward. This means that you need to consider PaaS, serverless, microservice, containers, and IaaS when making decisions. Depending on your specific case, a different outcome may be appropriate.
Innovation Management
Changes in the public cloud landscape are coming thicker and faster than before. Having an Enterprise Architect design the architecture or structure for the next five years is no longer relevant. These people need to be intensively retrained so that they can keep up with the public cloud procession. As such, you will need to have a different structure in place to allow you to manage the innovation. That’s not to say that you necessarily need to manage the technology of the innovation or configure the innovation in the cloud, but that you need to facilitate a way of working that gives developers and DevOps staff the opportunity to work on and perhaps try out the latest innovations within a fixed governance structure. You should see yourself as someone who facilitates a culture of innovation instead of someone who determines what the route needs to be.
DevOps Culture
A few weeks ago, I came across two examples of what a huge change the technical aspects and way of working when transforming to the public cloud do not have to be. The first is a software company employing nearly 300 people that sells its software around the world and now wishes to make the transformation from data centers to the public cloud. We assisted with the first step from our Cloudify program, creating a cloud design. There will be no immediate migration to the public cloud; instead, they will take a year to further develop the DevOps culture within the organization. They are making four people available for the project for one year and are building pipelines and experimenting with CI/CD and how they will introduce it within the organization. It is, in a nutshell, a pretty sizeable investment when you think about it. And, I realize, it’s the right way to go about things. You can take the technical side of things as far as you can, but if you don’t adopt the culture and really make it your own, it’s all pretty meaningless. So, manage your DevOps culture! See it as a new sports car – if you can’t drive it, all you can do is look at it, and how frustrating would that be?
Secondly, I spoke to the team at Team Now, who have created an application that allows you to monitor and “gamify” your DevOps transformation. This way, you can monitor your DevOps team and its performance without having to look at boring figures. Take a look at their website and send them a message if you have any questions about transformation of your DevOps teams.
Cloud Security and Framework
Last but by no means least, cloud security. And the importance of being able to secure your technical decisions within your public cloud in the long term, and of using the same governance benchmark. You want to be in control of what you spend, but also of your security, and this means that you need a framework. In addition to having a framework, which is technically feasible within the public cloud, you will also want to be able to monitor it and report. After all, external parties also want to see that everything is technically well organized. That party could be a client, but it could also be an auditor or a client of a client. When you starting working with the public cloud, make sure that you make an early start on governance. We call it shifting left in the process. Start with the framework at the very beginning – that way, you avoid having to adjust all of your processes to your new framework later.
Would you like to read more about transformation levels for ISVs?
This article is part of a series of articles on transformation levels in the switch to the cloud. If you would like to know about what the transformation to the cloud involves on a strategic level, you can read more here.
