A potential challenge that IT teams face when in a cloud-native environment is working within a highly distributed ecosystem with multiple moving parts, such as microservices and containers. If design patterns are not followed or implemented correctly, achieving maximum value can be a challenge. Because of this, we recommend a platform approach for any organization looking to embrace cloud-native development.
How is a platform valuable?
A platform-centric approach provides a framework with best practices and proven patterns that have worked not just within a single organization but within others as well. A platform is a base set of capabilities and features that provide the foundation to optimize and innovate, in this case within a cloud-native environment. It can encompass technology elements as well as processes. For example, we worked with a global wireless carrier to establish two platforms: one was based on microservices with a standard technology set and the other a DevOps implementation containing standard tools, processes, and technologies. A platform can integrate with partners, suppliers, and consumers and drive your business capabilities.
From a modernization standpoint, a platform provides the infrastructure for transforming from haphazard communication between legacy systems to well-defined reusable services. This standardization allows a company to react to change faster. A platform is horizontal and sits outside any specific line of business, which facilitates standardization that simplifies the process of making technical changes while promoting efficiency and scalability. For example, Capgemini worked with an organization to build a NoSQL datastore when the traditional online database became a bottleneck. The underlying platform capabilities, such as the event bus, were essential for the technical team to make a decision on a solution, pilot it quickly, and launch to production without an impact on operations.
What should a platform consist of?
A platform is essentially a pre-defined set of APIs and services that enable and support applications, data, and business capabilities for the enterprise. It can include operational, orchestration, data, and network components as well as lead up to AI algorithms, DevOps tools, and security services. These pre-defined APIs and services can also be specific to your business and technology, as in the case of core business functionalities that are exposed by legacy wrappers for consumption by the business. A platform also includes a mechanism for standardizing across lines of business, allowing specific teams to request features via self-service provisioning. It also includes a sandbox for trying out new capabilities to be added.
Should you build or buy your platform?
A platform exists to facilitate the rebuilding of the portfolio and should improve processes. When thinking about how to construct a platform, you can opt to build these capabilities in-house or leverage third-party services like Kubernetes or PaaS features from a cloud provider.
Technical leaders should look at platform roadmaps to progressively migrate business operations from existing systems to platform capabilities. For example, re-architecting a legacy monolith as PaaS services requires the use of existing re-usable and production-proven capabilities that maximize efficiency and reusability. This is, in essence, a shift to a platform approach, facilitated by the process of application modernization. In the platform approach, all modernized capabilities are built to be reused internally and externally, enabling the move to API monetization.
It’s important to remember that the transformation to a platform-centric approach will not happen overnight, and we don’t recommend going for a big-bang migration approach to a new platform. Rather, we recommend first conducting a pilot project with a group that embraces change, and then building from there.
For more information, please check out The app-modernization manual: The definitive guide to building intelligent apps from Capgemini, or reach out.