Cloud computing seems on the rise according to many sources. Companies are slowly but surely including cloud technologies in their IT landscape. In evolving the IT environment they are confronted by the need to move, migrate, evolve, transform, modernize (use the term you prefer) their applications. In parallel CIOs are pressed by the business to respond faster to new demands, to deliver functionality quicker and to integrate new ways of interacting with clients such as mobile and tablets.

These demands can be addressed by combining cloud computing and automation. But they often require the transformation of applications. So, where to start?

What is your objective?

Objectives will vary from company to company, but I would argue they can be grouped in three major classes:

Business Transformation. A number of companies are looking at addressing business disruption in their industry and look at better using their IT assets to build new business models enabling them to be a disruptor in their industry. In doing so they look at developing new business approaches, building on their existing assets. This implies their applications may have to be used differently, requiring them to be re-architected so they are able to support those new business models. What is important to them is to exploit the functionality available in the application. For them it is key to assess whether their applications are able to be transformed to support these new approaches or whether new applications need to be built. In case the existing ones can be used, how is the functionality exposed? How can the business logic call upon it?

Increased Agility & Responsiveness. Many IT departments are not seen as being up to the task by their business counterparts. This lack of responsiveness often leads to bypassing IT and implementing new functionalities on external systems without knowledge of IT, possibly resulting in reduced security and even noncompliance to regulations. Some CIOs are taking the problem at heart and are looking at ways to improve the responsiveness of their IT department, implementing DevOps and Agile methods to address the needs of the business better. In doing so they may have to review their application portfolio and look at how to automate the deployment of applications, how to enable more and faster releases etc. Often these requirements go hand in hand with the need for new channels to market, mainly associated with the use of mobile devices and tablets. The result of implementing such new channels is that the demand for the back-end systems often becomes unpredictable. Are applications capable of responding to such demand or do they need to be re-architected so they can scale up and scale down according to the demand.

Infrastructure Optimization. Many application portfolios run on outdated infrastructure and middleware stacks, resulting in increased support costs or exposure to security breaches and downtime. New technologies such as cloud are seen as being cheaper than traditional datacenters. Outsourcing is often also considered as an alternative. But both require up to date environments forcing the upgrade of the application portfolio. In this case the objective is not to transform the application so it can run differently and address new needs, but to migrate the application on the new infrastructure. The application portfolio will continue operate in the same way is it did before, but on a new, optimized and supported infrastructure. Whether a company wants to get out of a datacenter quickly, whether it is looking at a public/private cloud approach, there is an application migration required. As often the infrastructure team funds such migrations, companies are looking at the cheapest possible application migration. However, it is important to understand an appropriate approach needs to be taken to ensure the future evolution of the application.

Analyze and differentiate your portfolio.

imageOnce you understand your main driver, take the time to analyze your portfolio of applications. You may actually want to plot it on a diagram such as the one shown here. The objective is to understand what is expected from your applications moving forward. Core back-office applications don’t change that often. They’re mostly used by a well identified number of users that does not vary widely over time. So, upgrading them to the latest technologies while moving them to the new IT environment is probably all you need to do. If you do not plan more than one or two releases per year, it’s probably not cost effective to build a complete automation stack for the application. So, keep the cost down by upgrading and moving.

On the other hand, if you have an application that the business wants to open up to the client base, it’s a different ballgame. You can no longer predict the demand pattern for the application, but you know that the user experience is critical for your clients to use the application repeatedly. The application has to be responsive regardless of the user base. This requires its actual architecture to be reviewed. The front-end modules may need to scale when demand augments. Cloud Computing provides that functionality, but can the application coop with it. It requires message queues between the front-end and back-end modules so the activities are executed in the appropriate order, even if the actual demand results in a delay in the back-end process. This application is transformed or re-architected in the process.

As the business is experimenting with new ways of doing business, you know they will want to change things regularly. You’ll have more than one or two releases per year. Here automation definitely has its role to play. You may actually want to go further and look at implementing a microservices architecture to enable the release of just the components you changed rather than having to go through a full release process.

And then you will have applications that are somewhere in the middle. They are used by your employee basis and support them in their day to day operations. What should you do with them? The answer is, it depends. If you plan to replace those applications in the near future, just upgrade and move them if you cannot keep them on the current environment. It’s not worth it to invest in them.

Think end to end business process

But if you plan to keep such application, review with the business how their needs are going to evolve. As business is increasingly moving towards a more digital business approach, understanding how applications in that middle ground evolve is critical to take the right decision. Will the digitally supported business processes reach deeper and deeper in the organization? Will processes need digital support end-to-end? If yes, think about when it makes sense to adapt the applications under review. Does it makes sense to just do an upgrade/move now and wait for a transformation later, or should both be done at once. How often are these applications changing? Is the need for change increasing? Answer to those questions may lead you to decide to set-up the automation from the start.

Transformation and Automation, in increasing demand

Evolving an application portfolio is definitely not a “one size fits all” exercise. I’d strongly advise you to take time to go through the portfolio, understand how the demand for these applications will evolve, where the business wants to take things and what they expect from you. With that in mind, take a down to earth approach and identify the applications that will be at the center of the new business approaches, the ones that will be in a supporting role, and the ones you need to keep the shop running. Question whether you need the applications that are not in one of those three categories. Maybe you can replace them by a SaaS service to reduce cost and eliminate the management and operations needs associated with them. Planning with the future in mind is of the essence to evolve your application portfolio in a cost effective manner.