Cloud Service Review at SEB part 2

This is part two of a two-part series on Cloud Service Review at SEB. The first part covers the need for, and most critical controls of a service review process, while this article focuses on strategic service considerations and the SEB way of working with the process.

Cloud Service Review at SEB – part 1 

Architectural requirements for a service review

While Information Security and Legal aspects form the most critical risks a consumer may be exposed to when using a Cloud Service, there may be additional risks to consider when reviewing a cloud service.

Specifically, architectural and strategic goals of cloud consumption should be factored into a service enablement. This is a multi-faceted discussion that can range from implementation complexity to communication confusion.

For instance, how easy is it for a developer to utilise the service through self-service procedures? Is it necessary for a centralised platform team to “package” the service for internal consumption, or can the service be used as/is? If packaging is required, how much work should be considered worth the investment?

And what about other similar services? There are many options, even within a single Cloud Service Provider’s offering, to compute or database options (as an example). Will the introduction of a new service confuse developers, and create a scattered technological landscape that makes maintenance harder down the line? What does or should the path to production look like?

The architectural intention of cloud usage is very much an input to the acceptance criteria of using a Cloud Service.

Technical details

Closely related to architectural requirements are technical details around the service. How expensive is it to use? How would one go about enabling the service technically? Is the mapping between legal and contractual descriptions of the service versus its technical implementation clear? What is the Service Level Agreement of the service, and does it match the requirements of the solution that will be developed using the service? How mature is the service, is it used by other customers in production workloads?

It is worth considering the use-case in light of these questions, and make sure that the services used for critical workloads match your requirements of the solution to be developed using said services.

An example implementation of a Service Review Process

We’ve discussed factors that go into a Service Review. At SEB, these are some of the questions we ask ourselves when enabling a Cloud Service for internal consumption.

Reflecting on the procedure for consuming a Cloud Service, (presented in Part I of the article) at SEB today, we make use of a request flow that a developer can submit. This request flow should provide details around the Cloud Service to be consumed, the rationale for enabling the service and why this need is not already satisfied by the existing activated services in the Cloud Platform.

This request is then reviewed by a Service Review Forum, where distinct roles of expertise answer questions regarding the different risk categories. For example, an information security representative will consider the risks related to information security, a contract manager will review and provide input to the contractual questions, and an architect will supply guidance on the architectural as well as technical considerations. The review forum is coordinated by the Cloud Platform Product Owner, who also owns the Service Review Process.

Once the service has been reviewed in light of the controls of the different risk categories, a recommendation is provided to the Cloud Governance Forum which provides the final decision on activating a service. The activation is then technically implemented by the Cloud Core Platform Team, unless the service in question requires additional domain expertise, in which case a designated team might “package” the service for internal consumption. An example of this may be a service that requires detailed administrative configuration to satisfy the enterprise requirements. Such configuration would mean too much operational overhead for the Cloud Core Platform Team to work with.

This is one example of how to instantiate a Cloud Service Review Process, but it’s important to note that just as the cloud is not static, the processes that govern it should not go stale but adapt dynamically to maximise value. Process for process’ sake is not a sustainable solution to governing enterprise cloud usage.

…but what about?

The astute reader will note that we’ve mentioned continuous updates to services. What happens when a service changes? Do we need to continually monitor all of these changes and respond accordingly? The short answer is yes, but as with any relevant question, the answer is typically more nuanced than a simple yes/no.

Three things come to mind that should be considered explicitly:

1. Organisation Cloud maturity and impact of the service usage
2. Maturity of the Cloud Service itself
3. Service changes.

These three topics are discussed in brief below.

Organisation Cloud Maturity

Not only do Cloud Services change, your understanding and readiness to utilise them should as well. As the enterprise becomes more accustomed to the desired Cloud Operating Model, processes should be updated to reflect that maturity. This means that controls for a Cloud Service Review Process change. Specifically, the understanding of how different services impact your operating model in terms of criticality and business relevance should be reflected in the number of controls and regulations you apply to the service review. For instance, fundamental compute, database and analytical services may serve as the baseplate for most of your organisational workload. But there might be an edge case that requires a more bespoke service for one particular workload, the risk mitigations and review controls should then reflect the fact that the service may not be considered a part of the standard path to production.

Cloud Service Maturity

As stated, Cloud Services are continually updated. One aspect of this is the launch stage of a product. Typically, a production-ready service has a launch stage of “Generally Available” (GA), whereas a non-GA or pre-GA service is not suitable for production workloads. The benefit of using a pre-GA service before its GA release is that it can give you time to assess and become ready for a service release, so that products developed using the Service are ready for production launch as soon as the service itself is. Typically, a pre-GA service does not meet common certification standards, may lack technical functionality, and is not covered by the regular service schedule terms. Depending again on the return on investment, the review process may be tailored to account for pre-GA services if it is something that your business desires.

Changes to a previously reviewed service

Finally, any given Cloud Service may change at any time. While it is unfeasible for one person to keep up with all changes in all services of a major Cloud Provider, the company should identify which changes may be more problematic and make sure to closely monitor those changes. For example, glancing at the list of risk categories discussed in part I of this article, risks in information security and legal terms will have the greatest impact on the service usage. These changes should therefore be monitored more closely.

The Service Review Process should tailor to monitoring contractual changes to begin with, information security changes second, and finally considering the most critical services in use, monitor the changelogs of those services to make sure that the assumptions and arguments made in the service review is still valid. If a change has broken a previously held assumption or argument, the review process should begin anew – depending on the impact level.
Stay safe using your Cloud Services and maximise the provided value versus effort of reviewing a Cloud Service!

Exploring further

For more reading, Microsoft has several in-depth resources on service compliance. Consider the following article for a good discussion on trade-offs between rigid governance and high-paced innovation.