Forget about IaaS, PaaS and SaaS – opportunities are above!

Indeed, the integration of cloud services into your IT landscape, and the subsequent migration of your application portfolio to it is a challenge. While a technical view to the cloud may be the primary driving force for migrating to the cloud, it is the secondary effects on the business applications that are transformational. For being beneficial, there's a more concise view than looking at famous service models like IaaS, PaaS or SaaS. Instead, it's the business applications that enable the objectives set to be achieved. Read more about the benefits of cloud migration when you primarily focus on improving business capabilities rather than automating the infrastructure layer.

What really matters here?

What distinguishes cloud applications from those running on traditional platforms? Not the business functionality, but the characteristics of the service delivery are the decisive characteristics by which “Drivers and Goals” are addressed when migrating an application portfolio to the cloud.

The adoption of Cloud Computing as such is not the goal. Rather, the cloud strategy and its leverage effect must support these “Drivers and Goals” of the business and corporate level (e.g. Faster time to value or market, higher agility, lower costs, security compliance, new business model etc).

 

 

It’s an excellent idea to use the business strategy as a lens for your cloud strategy!

But many companies start their cloud journey on the infrastructure layer and then work their way forward (bottom-up, resources first, application after).

In the cloud however, it is much more appropriate to focus directly on the applications and then turn the perspective around (top-down, application first, infrastructure requirements after).

 

Does “as-a-service” really capture the essentials?

The type of cloud service selected should match the characteristics of the business process. Traditional cloud “as-a-service” categories don’t adequately reflect where you primarily should focus on:

 

 

Depending on the type of application and its requirements, the business objectives are better or less achieved with different service models. In a cloud strategy geared to the business objectives, it is therefore necessary to evaluate applications individually and to define a suitable scenario according to the objectives, as these are individual use cases.

If in a business case agility and cost savings are at the forefront of your business objectives, are you able to optimally achieve these in an IaaS model and a “lift and shift” scenario? Essentially, you are just replacing hosting, but do you improve agility and reduce costs by that? Wouldn’t it also mean that your application was already optimized in terms of agility and cost savings before the migration? Then why migrate at all?

PaaS however, offers a great variety of services and processes for optimization in the areas of performance efficiency, cost optimization, reliability, security and operations excellence. Couldn’t such business goals as agility or cost savings potentially better be achieved in the long run by PaaS than moving to IaaS?

An important point for the choice of the adequate service model is also the type of the applications. Ideally this is not done via “mission-critical”, “business-critical” or similar (according to Gartner, 50% of all applications in the public cloud are classified as “mission-critical” anyway). Rather, the following classification could be useful when choosing a service model:

  • This is an application with standard functions, as used by many organizations.
  • This is an application with functionality that is unique to my organization.
  • This is a record-keeping application that informs many other applications in my organization.
  • This is an innovation system that offers functions for experimentation.

Which service model do you consider suitable then?

  • SaaS as a quick way to enable pilot projects without having to purchase and install infrastructure in advance.
  • PaaS for rapid IT experiments with new technologies.
  • IaaS if control and autonomy over the infrastructure is needed.
  • SaaS for functionality with minimal IT effort.
  • IaaS for using existing applications without major upgrades.
  • And of course, there are many more use cases …

The important element here is to consider for each use case which cloud services can best support the defined business objectives.

There is no “one-size-fits-all” service model for all applications in your portfolio.

This finding leads to the conclusion that the choice of the service model should be based on its capabilities to design an appropriate solution for each application individually.

What the “Shared Responsibility Model” entails

The following figure shows the cloud service models and the concept of shared responsibility for applications customer and provider are burdened in the cloud. The diagram illustrates the importance of having a detailed understanding of who is responsible for what concerning architecture and operations and what this responsibility entails. Again, ideally this is done on a per application basis and includes comprehensively all aspects (including, security, monitoring, availability, desaster etc).

 

 

 

Unlike outsourcing or traditional managed services, the responsibilities of the provider are defined by the characteristics and capabilities of the cloud products offered. It is the customer’s responsibility to configure and use these capabilities of the cloud services on its own responsibility to achieve the desired result. Based on the service model, you therefore also decide which services you are responsible for and operate and which you are not and outsource implicitly to the provider.

This after all, is a risk and cost assessment and a make-or-buy decision (for example according Gartner, about 95% of cloud security failures are the customer’s fault. Do you decide to manage all the security risk by yourself or ease your burden and choose the provider to get the job done?)

Conclusion

For the successful migration of your business application portfolio, you need a clear corporate strategy and defined objectives as to how cloud computing should support this.

You also need a sound knowledge of all aspects of cloud computing and you need to have a sound understanding of the nature and requirements of your business application portfolio.

Develop a cloud strategy in accordance with your business requirements.

Put your business applications at the center of attention, rather than platform considerations.

Ideally, make decisions based on individual business applications instead of the overall portfolio.

Don’t forget your customer!

Swisscom’s “Organizational Readiness Assessment” and “Business Application Portfolio Assessment” helps you analyzing where you should focus your efforts for a successful cloud migration.

Please  contact  us for more information around our Journey to the Cloud (J2C) and cloud adoption services.

Author:

Christian Jutzi, Cloud Architect, Swisscom

As a member of Swisscom’s Global Public Cloud Team,
I deal with cloud adoption for enterprises.
In my team we support customers in developing well-architected cloud solutions on well-planned transformation paths.

I’m certified on AWS and Dell/EMC pro level, ISACA CISM, Togaf, FinOps and others.

Also, I’m happy to answer your questions:  contact