Teams developing web- or cloud-based solutions have gone through a huge transformation, starting from the early web developments, then moving into cloud services and cloud applications and now doing full-fledged cloud-based computing. The teams that develop for cloud as a primary focus cover a truly amazing range of often new and rapidly developing areas– including a huge range of methodologies, tools, and applications. 

The question we now need to ask is how can this transformation, with its new methods, design and delivery approaches, and ways of thinking, be standardized across large corporate systems and adopted by other parts of the business as well as IT?

As developers and architects, we intuitively know the answer to this question.  Our objective is to support a clean digital core, enable agile business, and maximize opportunities from a cloud strategy and a cloud-first mindset.Simple, right?

However, just as our solutions have transformed, so too have corporate systems. Large internal corporate systems are likely quite diverse– some may be outsourced, some may be running on cloud or on-premise and yet, also utilize in-memory speeds or, more amazingly, the systems may have remained fairly static for years, if not decades. Yet cloud services along with cloud solutions and platforms will need to interact back to the core line of business solutions, enterprise resource planning (ERP) platforms, or other on-premise solutions. Historically, these teams may not have been brought up with the web, let alone the cloud.

We are, thus, left with a large disconnect between how things are today and the “cloud-first” future with a prevalence of cloud applications and cloud-based solutions.  How can we start building bridges between these two worlds?

1. The first stage in becoming cloud-native is to become aware of the need to do so.

   Congratulations! Just by reading this, you have begun the journey! The next steps will be dependent on the key drivers within your business, such as:

   1. The level of cloud-native work already occurring
   2. The expected level of SAP or other application-focused delivery needed
   3. The user and business needs being met

2. Acknowledge that the days of knowing just a few core development languages, tools, databases, design methods, and development methodologies are gone.

   Many companies have started to realize that everyone needs to become literate in cloud-based delivery and become “cloud native”. It is still early days in breaking down barriers and sharing insights between cloud-first teams and the wider corporate teams. Yet, this must happen in order to maximize opportunities and align approaches across the technical and business landscape to meet evolving business needs.

3. Establish a cloud native strategy.

   Having a clear cloud native strategy now can go a long way toward avoiding future challenges in terms of the costs of upgrading diversified systems and application portfolios– with the added benefit of helping drive a positive ROI from future investments. You will need to ensure that you have an agreed development approach, methodology, development framework, and governance around cloud native items. Important considerations include:

   1. What is to be developed and where?
   2. Will it be a cloud-first team?
   3. Should development remain within the application teams?

   Part of this strategy also needs to include a plan for how to close the cloud native knowledge gap between cloud-first and non-cloud-first resources.

4. Plan to retrain or upskill all developers on cloud-first approaches.

   Many companies have been building web and cloud solutions for years. However, given the diversified application portfolios of most companies, they will also have a pool of resources in specialized applications, tools, or programming languages that need to become cloud native. This will either mean retraining or updating existing capabilities with a cloud native mindset: all teams will need to know how cloud (and possibly, wider disruptive technology options) will impact how they design and deliver in the future, in order to ensure that they remain effective, efficient, and relevant.

5. Once trained, ensure that the wider (non-cloud-first) resource base focuses on building solutions that are cloud-first. Avoid developing solutions that are application-specific and rooted in heritage methods or approaches.

   The good news is that platform and application providers are already helping make this shift to cloud native as easy as possible by providing cloud tools and methodologies and making simpler platforms, services, or development landscapes for developers to work within. The SAP Cloud Platform is a good example of this practice.

Applying cloud native approaches means that application architects must become familiar with platforms [such as Google (GCP), Azure, AWS, and SAP’s Cloud Platforms (SCP)] and know how to utilize micro-services or RestAPIs to expose or consume cloud services. They will also need to become conversant in a whole new vocabulary– 12 factor principles, domain-driven designs, Spring frameworks, Agile or DevOps delivery, and containers/Kubernetes (examples include SAPs Kyma and Gardener Projects), to name but a few.

It will take time to get up to speed– but the payoff is worth the effort.

Once architects learn to take advantage of the cloud’s scale, performance, and flexibility, they will have a platform for innovation onto which they can build resilient and sound architectural design patterns to enable companies to become truly cloud native. The sky’s truly the limit here.

I realize that cloud native is a very broad topic, but hopefully, this blog has introduced ideas on how to structure a more complete approach to becoming cloud native. In the meantime, please don’t hesitate to get in touch  to discuss this.