How Cloud transformation can help align Business and IT strategies?

At Bolloré Transport and Logistics, Cloud strategy is part of architecture departments as it is a key pillar to accelerated global Transformation. Through a strategic program transformation in the domain of Transport and Logistics I was the architect of, I'll explain how we transformed a Move2Cloud strategy into a Move2Service approach.

About Transport and Logistics: Business and IT context

For decades, the world of transport and logistics has been continuously evolving, revising its approach and toolsets, to deliver faster, safer, with more visibility and at a lower cost.

Transport and Logistics business requires skilled specialized workforce, each using specific highly customized software, designed by the logistician players themselves. From Middle Office to Front Office, all Systems have become actors of success and several of them quickly became key differentiators as well, which explains why these companies have developed their own solutions internally.

Nowadays, with the advent of Cloud, accelerated by a massive Move2Cloud momentum at every level of every company, Cloud has reset the software architecture standards, making applications more decoupled, API oriented, Microservice based, and DATA driven.

The impact of such spectacular digital transformation worldwide on the IT impacted transport and logistics as well: it resulted in the emergence of new software packages, popping up on the market, functionally suitable, technically highly performant, and sold at reasonable cost if not proposed directly as Software as a Service.

Technology (IS) Architecture Transformation approach

To absorb this redesign of the application landscape, 3 major fields of enterprise architecture were reviewed: Make or Buy, Move2Cloud and scope of action of Enterprise Architecture.

Note that role of architecture department I lead is not to define strategy but to enable strategies execution, at minimal costs. Executing such enablers require a close collaboration with CIO / CIO Deputy.

• Simplify “Make or Buy” decision making: leveraging market solutions' services for non-strategic areas where tools exist and are efficient, and instead refocus technical efforts on parts that are business differentiators. To do so, we created a dedicated design pattern called Cargo Pattern (copresented with Microsoft and Confluent Cloud in 2022).
• Accelerate Move2Cloud transition: with no lift and shift, focusing exclusively on Cloud Native transformation, and starting with highly impacting business programs to take benefit of hyperscalers' built-in services,
• Revise organization of architecture departments to drive Microservice redesign, from a Business design standpoint, down to technical implementation. This was done in 2020/2021 by connecting Enterprise Architecture to Software, Cloud and Infra teams.

These "Enablers" have been executed with success on the program covering the most critical application for Middle Office (12.000 collaborators impacted).

This ambitious program addressed both the Digital Transformation, aimed at refocusing efforts on consuming value-added Services (Business Strategy), and in parallel, launching Cloud Native migration for the company (IS Strategy).

4 tips for a 1-year transformation, Go Live included

To my view, being Cloud Native means implementing solutions that consumes services (in the cloud), and not be limited to 'cloud services' calls. Final goal is to create a functional and technical service catalog, ready to be used, and let development team concentrate on added value. In other words, it means creating a SaaS and/or customized PaaS (resp. software and platform as a service) ecosystem.

To accelerate this “Move to Services”, the 4 following principals were adopted:

1- Focusing on security

Goal here is to go fast, without losing control on your product. For me, easiest way is not to secure the final solution, but to secure services by design and by default, may the service be consumed in the cloud, or be built in the cloud.

Focusing on security for services consumed from the cloud (PaaS or SaaS) means defining the enterprise good practices, to clarify what is allowed to do during service calls. For me, this job needs 2 elements: 1- cloud expertise, to know how the services works and identify with security team possible risks; 2- a cloud provider expertise, to validate what can be done (maybe in the roadmap) on APIs identified at risk. As a conclusion, it is required to create a cloud team (Cloud Center of Excellence) composed of at least: cloud architects, security members, and cloud providers expertise from time to time.

Focusing on security for services developed in the cloud, means training software engineers on security risks, trainings teams on appropriate patterns & practices and making code source reviews. As a conclusion, the cloud team should also be composed of dev and run/ops teams, to make the bridge with implementation teams.

2- Starting safer with MonoCloud is an option

Goal here is to go fast, but still ensuring high level of quality. Despite Cloud providers propose similar services, making a solution multi-cloud in less than a month with a small team is almost unrealistic because at minimum an extra expensive team dedicated to CaaS would be required.

Starting with a public mono-cloud simplifies choice of PaaS service to consume.

Starting with a public mono-cloud simplifies skills ramp-up, as only 1 set of tools needs to be used and mastered. In the cloud, training is a challenge, trying to answer this simple question "shall we train populations on administration or infra or tooling? " is not obvious, and training on all topics is not realistic either, plus makes people reluctant to change.

Starting with a public mono-cloud mitigates security risks as well, as it limits the number of topics to be train on, prevents from confusion (bad practice due to mix of configuration good practices), and simplifies training.

Starting with a public mono-cloud do not prevent from creating a Hybrid approach (Private Cloud + Public Cloud) for compliance purpose. Cloud providers sometime propose accelerators for hybridation and service consumption, like HCI for Microsoft Azure, and ARC to mutualize both monitoring and deployment user interface.

3- Selecting SaaS/PaaS to expose open source

Goal here is to save time in technical ramp-up, by selecting Confluent over Kafka, or selecting MongoDB Atlas over MongoDB on a VM.

Selecting SaaS/PaaS over IaaS highly simplifies the OPS as most parts of operations are built-in (by design, managed by service provider itself). Such services include their own issue tracking tool with 24/7 support, and a default configuration (as well as reconfiguration on the fly) is generally accessible in few click away on a UI or via APIs calls.

Selecting SaaS/PaaS over IaaS permits creating "partnerships with providers": a strong partnership with providers is for me key for make technology transformation a success. Providers share with you image of your success (or failure), therefore for big programs, they propose to support you to ensure good usage / practices through architecture reviews and validations.

Selecting SaaS/PaaS over IaaS also has positive costs impact, as, assuming you deploy services on the same Cloud as yours (ex. MongoDB Atlas on Azure as your apps are on Azure), it impacts positively your “commit consumption” engagements.

4- Creating coordinated Centers of Excellence

Goal here is to create Business appliances, and in my opinion, starting with "just a Cloud CoE" is not enough, the minimum is to add software architecture too, and make sure these two teams highly collaborate, like Dev & Ops do in DevOps.

Creating coordinated CoE breaks silos for real. In the real world, may you ask a software engineer what DevOps means, he will certainly answer something like “infra teams must join us” (and vice versa when you ask infra teams…). To prevent from this, idea is to have senior evangelists on both sides, cloud and software, to discuss with enterprise architects and with Business (sharing the same language and wording), in order to define together which service shall serve which applicative source code in order to best address which use case.

Creating coordinated CoE to train people, both functional and technical ones, on what a Microservice is and is not. It is important to have development team (software, functional, …) understand what a Domain is, and above all, why the "segregation of concerns" is a key directive, not just a nice to have architecture concept. For me, expecting team to be expert in every single domain is a useless source of stress and a waste of time & energy that negatively impact productivity and quality.

Creating coordinated CoE accelerates DevOps strategy?deployment. Delivering value in just a 2-week Agile sprint is considerably accelerated by consuming ready to go cloud services (it simplifies bug fixing, security fixing, testing, FinOps monitoring) ... But this won't fly unless experts regularly play the role of evangelist with development & delivery teams.

Situation today

All this story started 3 years ago, during the first covid period, and now being Cloud Native is no longer a matter of technical challenge, but rather a transformation accelerator.

2 years later, after v1 have Gone Live, Cloud Services are now managed as "Consumable Products", sometimes business entities (Microservice or SaaS APIs), sometimes technological (PaaS). Such Products become the tools to conduct digital transformation, focusing on Business strat, while accelerating IT strat deployment.

The ONE program continues its deployment, region per region, and several other strategic middle office complex program / projects have been launched since then, several of which are already live, and all are using the same successful approach.

As we turn to 2023, we will generalize this approach to Front Office as well.

And now, let us see what the future holds, what is coming next, any suggestion?