The concept of industry clouds is not all that new, but enterprise interest is rising by the day and investment in industry clouds is exploding as companies seek higher returns on their cloud computing investments. As industry-related technology becomes better and more available, enterprises that climb on the industry cloud bandwagon today will have noticeable successes in the future.
Many major public cloud providers do not have industry-specific expertise but are partnering with professional services firms and leaders in banking, retail, manufacturing, healthcare, and other industries. The result is a collaboration between people who understand industry-specific processes and data and people who understand how to build scalable cloud services.
It’s now our job to understand how to successfully deploy industry cloud-based systems. This new to-do list applies when migrating to a cloud service provider or building net-new systems and data stores.
What keeps me up at night is that we usually make many trial-and-error mistakes before we develop best practices to do things right the first time. Keep in mind that using industry-specific services will add cost and complexity, even though there will be more value returned to the business—at least, there should be.
To that end, I’ve put together the first three of many best practices of how to architect cloud systems that use industry-specific cloud services.
1. Understand the cost and complexity of service integration and consider all alternatives.
We’ve seen this movie before. Years ago, IT was dominated by service-oriented architecture concepts that are systemic to today’s clouds. We often looked for industry-specific services or APIs that could save us from writing those services ourselves. Sites like Programmableweb.com (now retired) arose as marketplaces for these APIs, and companies could choose from industry-specific services along with other common, useful services.
Today the issue is not which industry-specific service should be leveraged, but if an industry-specific service should be leveraged at all. “Build versus buy” is the best way to describe this concept.
Companies must consider the cost to integrate and operate a service versus the cost to build and operate it themselves. Most of us are trained to think it’s always a good idea to use OPC (other people’s code) rather than reinvent the wheel. However, in this case, there is often unanticipated cost and complexity to consider.
To master this best practice, just ask the questions and do the math. You’ll find that the cost and complexity often bring back more value to the business, but not always.
2. Security must be systemic to everything.
Make no assumptions about the security of industry-specific clouds. Those sold by the larger cloud providers may be secure as stand-alone services; however, they could become a security vulnerability when integrated and operated directly within your solution.
The best practice here is to build and design security into your custom applications that leverage industry clouds. Also, do so with integration in mind so no new vulnerabilities are opened. You can take two things that are assumed to be secure independently, and then add dependencies that entirely change the security profile.
3. Look for industry-specific services everywhere.
One frequent mistake I see is only using industry-specific cloud services from one provider. I get it, it’s easy to limit yourself to an industry-specific native service or perhaps a service from the marketplace. However, you’ll often find the best-of-breed option is on another cloud or perhaps from an independent industry cloud provider that decided to go it alone.
The best practice here is to not limit the industry-specific services under consideration. As time goes on, there will be dozens of services to do tasks such as risk analytics for investment banking, for example. Picking the less optimized choice means you’ll lower the value that’s returned to the business. In other words, you make less ROI when you make less optimized decisions.
Copyright © 2022 IDG Communications, Inc.
Discussion about this post