CloudA $100-billion-dollar Fortune 200 consumer packaged goods company recently partnered with CapTech to commercialize Microsoft Azure's Platform as a Service (PaaS) as an enterprise service offering. This blog is the sixth in a ten-part series of blogs. The purpose of this post is to highlight the design considerations and implementation activities involved with a cloud solution architecture. It is intended for anyone interested in gaining insight into the major bodies of work and considerations involved in commercializing cloud services for large enterprises.

Recommended Bodies of Work

The next couple of posts in this series are going to focus on some of the recommended bodies of work for commercializing the cloud at your organization. Below is a diagram that illustrates a high level and comprehensive view of the bodies of work with their relationships and dependencies. In the remainder of this post we will explore what's involved in designing a solution architecture highlighted in green.

Solution Architecture Workstreams

Design Solution Architecture

Designing a solution architecture will be unique to each enterprises needs so this post will be somewhat brief but it will serve as a good reference point. The first decision that the project team will have to make is to determine whether or not it will utilize Azure's Platform As A Service (PaaS) or Infrastructure As A Service (IaaS) or some combination of the two. In our case it made more sense to architect a PaaS solution. This solution architecture challenges the project team to define what Azure PaaS resources will be made available for the enterprise and how to utilize them. This requires creating a service catalogue with definitions, configurations, naming conventions, and security considerations for Azure resources like storage, web applications/web jobs, web/worker roles, Azure SQL, Redis Cache, mobile applications, API mgmt. etc. The design should also describe what products and technologies (e.g. Jwt, OAUTH, Azure AD,Azure AD Graph API, etc.) will be used to authenticate/authorize these Azure resources (e.g. website, API, mobile client, etc.).

In addition, network designs for the Azure VNET address space and defined subnets should be documented. Establishing connectivity between Azure resources within Azure (e.g. Azure VM to Azure VM) as well as between Azure resources and on-premise data using Express Route should be documented (see pre-requisite hybrid design pattern). Also, network security groups must be identified and mapped out between the various Azure resources.

Finally, other aspects to consider in the Solution Architecture may include input from the Governance Model, Security Assessment, design patterns, Express Route design, and the Continuous Integration process.

Conclusion

This sixth post in the ten-part series described designing the solution architecture required to commercialize Azure with this Fortune 200 CPG client. These were the just some of the design considerations we had to make in determining what the solution architecture should look like. This architecture should be very similar an on-premise architecture.

The entire series:

In the next post we are going to talk about defining the governance model.