The foundations of hooking up to a cloud provider – network, identity and integration
Part two of the series on cloud onboarding

The contract is done. You have executed the commercial cloud onboarding process which we looked at in the first part of the series. Now you need to connect to the service and make it usable for your users. While this looks easy at the first glance, as it is all web-based and appears easy to use, it can be slightly more complex. The providers tend to oversimplify the picture by picking greenfield examples from the startup world and single ecosystem target scenarios.

There is no existing enterprise which does not have an IT ecosystem in place. Usually, these ecosystems are historically grown into something that is neither simple nor easy. In addition, the future will be multi cloud and often even the current use of cloud services is in one way or the other already using multiple cloud providers. It might not be visible at the first glance, but different cloud providers operational throughout most enterprises. Be ensured, somewhere there is a SaaS service being used you are not aware of. Is that properly hooked up and integrated? In many cases, it is just being used over the internet. And therefore, the technical dimension of onboarding often shines a light on other services as well.

Technical dimension

This starts with something that is often missed or just an afterthought of hooking up a cloud service. It should be part of the longlisting and the decision but let us assume we need to do this now. So, what do we do, looking at the usage scenarios and the data that will be moved to and through the cloud solution and stored into it as well? This fundamental question not only sets the guard rails for usage by developers but also drives many decisions in the onboarding process. Non-critical data might be transferred directly over the internet where PII in a healthcare scenario might require dedicated networks and encryption.

Once you have clarity on the usage scenarios and the data, the following areas need to be considered on hooking up to public cloud providers.

• Network connectivity
• Identity and Access Management
• Data Integration and API Management
• Security & Governance
• Cloud Management
• ITSM processes

Let us look at these areas separately.

Network connectivity

The first step is to get an overview on the options available. From over the internet to dedicated encrypted lines of different performance and availability, there are several options. Hopefully, you have explored these options as part of the decision process and can focus on getting the cloud connectivity of choice up and running.

There are offerings by the cloud providers themselves, classic network providers and the so-called cloud hubs, often created by colocation providers.

Be aware that network concepts should include capacity considerations, mobile access and limits. I have had discussions over the years where potential customers thought that a cloud service can make the small bandwidth issue go away. That might be true in some scenarios up to a certain degree but let’s face it, as soon as someone clicks ‘download’ for the huge video or PowerPoint presentation, the performance is gone.

Also, keep in mind your future strategy towards multi-cloud. Think beyond the first cloud provider you connect.

Identity and Access Management (IAM)

What is your first thought when it comes to IAM? The reply I do get often is Single Sign On (SSO), making the life of the user easier by having one account. This is a good point, but what about security? Having multiple different accounts with different passwords, non-synced password updates and undocumented rights and control will be a result of unmanaged IAM.

Does this really happen? Yes, it does. Every small SaaS that is being used has its own set of credentials. The general rules are not enforced there. These credentials are not part of the credential processes, e.g. deletion on leaving the company.

The value in combined credentials becomes visible in the consumer market nowadays quite clearly. Just think about the many webpages where you can use your Google, Apple, Facebook or LinkedIn Account for login. I remember a time where pushing liveIDs was an individual target at Microsoft.

Aligning and connecting identities is slightly more complex than in the case of using Facebook to sync your game results across devices. The most common approach is a token-based approach, usually based on security assertion markup language or in short SAML. This can be used, for example, for O365 or Salesforce.

Next to enabling SSO, setting up logging and auditing of user actions is critical especially in regulated environments. You need to find the right mix between in-built functionality and separate tools. Also, fraudulent behavior should be observed. This is sometimes more difficult than you think. I remember at the end of the 90s when I was working in an operations team. In the data center team, we had someone who had used a data center admin account to grant his personal account admin privileges to look through files of other users. The only way it was detected back then was the deleted action report for the data center admin account. Nowadays, there are only named accounts and other measures are in use to prevent such actions, but the folks are noisy and creative. You cannot prevent everything, but you must make sure everything is documented and becomes visible in the audit trail.

Data Integration and API Management

Very few cloud-based applications, self-developed, COTS or SaaS, are enabled completely on their own. Or in other words, no application is an island.

The key integration activity is data and process integration. The area of data integration includes API Management. The difference is that data integration itself is about the way to organize ETL other than through point-to-point connections while API management is all about the knowledge and usage/exposure of APIs in the ecosystem to ensure that the right docking pods are available but also to avoid re-inventing the wheel or creating unwanted and undocumented entryways into your IT ecosystem. The difficulty is in deciding the right approach. Especially for the data integration, many cloud solutions bring along onboard functionality which is appealing in at a first glance. Only if the ecosystem is or becomes more complex, running integration by application rather than through a general integration platform becomes cumbersome and a security risk.

So, whatever your solution to data integration is, you need to hook up the cloud provider or enable hook up of applications that will run in the cloud providers cloud environment.

Integration into processes and alignment is critical if your application is working in conjunction or better in concert with the existing landscape. Whether it is integration into batch processes or business process where the cloud application replaces an older one, all this process and application level integration is part of the hook up. Either this happens over time or if you use an integrated application from the start, rather than IaaS, from the very beginning.

Now that we are aware of the technical considerations in terms of network connectivity, identity and access management and data integration and API management, lets look at the aspects of security and governance, cloud management and ITSM processes in the next blog of the series. Stay tuned!

Part 1: How to onboard a cloud solution provider

Part 2: The foundations of hooking up to a cloud provider

Part 3: Making Cloud Onboarding hassle-free and valuable

Part 4: Tips for Seamless Cloud Onboarding