Designing Cloud Solutions Doesn’t Have to be a Daunting Task
Part 2 — How to Create Fit-for-Purpose Cloud Solutions Using the Architecture Framework
Carol B. Hernandez, Ph.D., Cloud Solutions Architect, IBM
Doug Eppard, Cloud Integration Architect, IBM
Much like training for a marathon, Cloud Architecture Design doesn’t have to be difficult if you take a structured approach to design.
The Architecture Framework introduced in Part 1 of this blog series provides a consistent approach — the “anchor”– to address Cloud Architecture Design. This blog describes a structured, iterative approach to apply the Architecture Framework to design Cloud Solutions. We recommend this approach to Cloud Solution Architects and Solution Engineers responsible for creating enterprise-ready cloud solutions.
This is part 2 of a 3-part blog series which will discuss:
1. Introduction to the Architecture Framework
2. How to use the Architecture Framework to create fit-for-purpose Cloud Solutions
3. Creating a Reference Cloud Solution Architecture based on the Architecture Framework
Simplifying Cloud Architecture Design
In Part 1 of this blog series, we provided an introduction to the Architecture Framework and talked about the multi-dimensional complexity of Cloud Architecture Solutions. The Architecture Framework and the approach explained below can be applied to address that complexity and create repeatable cloud architecture solutions and patterns as illustrated in Figure 1.
You can simplify Cloud Architecture Design and create fit-for-purpose Cloud Solutions by following 5 simple steps:
1. Create a Solution Architecture Heatmap that highlights the Aspects and Domains relevant to the solution requirements.
2. Identify Component Options for each domain in the Solution Architecture heatmap.
3. Use Decision Tools to select the best-fit components for each domain based on requirements and constraints.
4. Document Architecture Decisions for the components associated with each domain.
5. Create a Reference Architecture Diagram that illustrates how the main components of the solution come together.
Let’s take a deeper look at each of these steps.
1. Create Solution Architecture Heatmap
The Solution Architecture Heatmap is based on the Architecture Framework described in Part 1 of this blog series and is used to identify the requirements and drive the architecture decisions for the solution.
The Aspects and Domains of the Architecture Framework can be used as a guide to clarify requirements and determine which domains will be utilized for any solution. Here are some sample questions which can be used to determine the domains for which you need to make component choices.
1. Do you have requirements for Security — Network, Data, or Identity and Access Management?
2. What are your Resiliency requirements — Backup, Disaster Recovery and High Availability? What are the SLA, RTO/RPO requirements?
3. What are your connectivity (Network) requirements? Is dedicated, private connectivity back to your enterprise needed? Is the solution multi-tier? If high availability is needed, will you need a load balancing capability?
Your requirements will determine the domains applicable to the solution and drive the component choices.
Once it is completed, the Solution Architecture Heatmap provides an at-a-glance view of the domains mapped to your solution requirements. Figure 2 illustrates the aspects and domains associated with common requirements for containerized workloads deployed on a hybrid, multi-cloud environment. For each of the domains highlighted in the Solution Architecture Heatmap, an Architecture Decision needs to be documented in step 4.
2. Identify Component Options
Once you have created the Solution Architecture Heatmap, the next step is to identify the available Components (technology or product choices) for each domain on a specific target cloud deployment or cloud service provider.
The components are identified for the applicable domains highlighted in the Solution Architecture Heatmap, which are based on your solution requirements from step 1.
As an example, Figure 3 illustrates the components for all the Data domains when the target cloud deployment is Public Cloud and the Cloud Service Provider is IBM Cloud.
3. Use Decision Tools to Select Best-Fit Components
The third step is to use Decision Tools to evaluate the component options for the applicable domains against solution requirements and known constraints. Common constraints that impact the Cloud Architecture design include, but are not limited to: regulatory compliance, service level agreements (SLAs), performance, cost, timeline for product availability, compatibility and portability, geographic availability, and delivery support.
Decision tools are used to select the best component to satisfy the requirements mapped to each domain. You should evaluate available components for a specific target deployment and one or more cloud service providers to determine the best-fit-for-purpose component for your solution.
You can use your cloud service providers documentation, available comparison tables, and decision trees to evaluate the component options. Additionally, if you have an existing enterprise architecture organization with published principles, best practices, and standard guidance, you should utilize these guidelines to drive the decision process to ensure the solution adheres to your organization’s strategy and standards.
As an example, the following decision tree found on IBM Cloud Docs helps you select the right component to satisfy Enterprise Connectivity domain requirements.
4. Document Architecture Decisions
Once you have evaluated the component options, you can use architecture decision templates to document the components evaluated, the decision criteria, and the component chosen for your solution based on the assessment performed in step 3.
You should have one or more architecture decisions for each of the applicable domains highlighted in the Solution Architecture Heatmap (step 1) mapped to your solution requirements.
Documenting the Architecture Decisions is important for several reasons:
a. To provide traceability across the solution life cycle and a historical record of why a particular decision was made.
b. To capture dependencies across solution components.
c. To create the Bill of Materials (BoM) for your solution and build your cost case.
d. To estimate delivery timelines and perform risk assessments.
e. To transition to your delivery teams for detailed design and scrum activities.
Figure 6 illustrates a sample of Architecture Decisions for a containerized workload deployed on a hybrid, multi-cloud environment. It includes the component options for the requirements mapped to various domains in the Compute, Networking, and Resiliency aspects. It considers components available in two Cloud Service Providers: IBM Cloud and AWS. It also shows the component chosen for each domain using decision tools outlined in step 3 as well as the reason for choosing each component.
5. Create Reference Architecture Diagram
The last step is to create a Reference Architecture Diagram that illustrates the connections among the chosen components for the applicable domains identified in step 1, on the target cloud deployment model.
Figure 6 depicts a Reference Architecture Diagram example for a Containerized Workload Multi-Cloud Solution. This diagram reflects the Architecture Decisions for the requirements mapped to the Compute, Networking, and Resiliency Aspects illustrated in step 4. The diagram was created using reusable Draw.io templates available in the IBM Architecture Center. There, you will find a number of reusable reference architectures created by IBM which can be downloaded and edited to show the selected components for the solution.
In the final blog of this 3-part blog series, we will walk you through a use case based on common enterprise requirements and illustrate the five steps to create a complete Reference Architecture that meets those requirements.
