In the first installment in our A Practical Cloud Journey blog series, Woolpert Cloud Solutions Director Dylan Thomas provided practical considerations for the planning stage of your cloud journey and provided an orientation for the trek. In this post, we give you pragmatic advice for solution design. Let’s hit the trail! First Stop: cloud architecture—with your guide, the cloud architect.

Do I Really Need a Cloud Architect?
In our agile, tech-savvy world, the need for a cloud architect is sometimes met with skepticism. But a cloud architect is professionally adept in this space. He or she can help you wade through your specific business and technical needs, map them to a proper solution design, provide counsel throughout the construction effort and inspect the build. The cloud architect creates order out of chaos. We see the architect as a key contributor to project success by maintaining vision and acting as a communications conduit between the business and engineering folks. These are difficult tasks for an agile software developer to tackle alone, not necessarily due to lack of skill, but rather due to a misalignment of scope and purview. We recommend having a hands-on cloud architect.

What’s Important
At the outset, a project’s scope and goals are often fuzzy. We need to figure out what’s most important to dampen the noise and amplify the value. Begin with understanding the business drivers, or the whys. These drivers have roots in your digital transformation strategy. Examples of these include, “minimize time to market” or “increase system reliability.” To materialize these drivers in tangible form, product leads and other influencers may participate in drafting service-level indicators (SLIs), objectives (SLOs) and agreements (SLAs). Technical requirements also need to be discovered. For example, it may be critical to build with a certain software stack (LAMP, .Net) or an open-source component such as Kafka for event streaming. These must-haves relate to a variety of reasons, including skill sets of existing personnel and integration with on-premises solutions.

The Drawing Board
Now that we know what’s important and why, we can begin mapping the system requirements to a design and sketch things out.

Stay Oriented
We stay oriented along our journey by following design principles. The three major cloud vendors publish frameworks, which are checklist reminders of the multiple facets we need to consider. Google Cloud’s Architecture Framework identifies the following principles of system design: operational excellence; security, privacy, and compliance; reliability; and performance and cost optimization. Remember these principles and revisit them at each stop along the way.

Recognize What We’re Building
Now that there is a clear understanding of the big picture, it’s important to recognize what type of solution we’re building. If we can identify an archetype, we can lean on reference architectures to jump start our design work. Is this an IoT ingestion platform with a streaming analytics component? Are we lifting an existing on-prem enterprise system wholesale to the cloud? Does it lend itself to a microservices design, built with container technology? Or, is this a machine learning/artificial intelligence project? Our solution may not fit into any single box. If that’s the case, we decompose it until each subsystem resembles one of the archetypes.