Why you should care about cloud architecture and how to get started Cloud architecture

Are you afraid that at some point in time your IT teams will run out of control over what they are doing and why?

The feeling of chaos amidst an increasing number of bugs, lack of communication between people, useless burndown charts and a lack of business understanding can be depressing, and what’s worse – negatively influence the outcome of the project.

Fortunately, there are tools and good practices that can facilitate this work. One of them is preparing an architecture of your IT solution, before work on the project even begins.

In the previous articles, me and my colleague shared some tips on why and how you can start your cloud journey with PaaS and what to know about other cloud architecture models. Your solution design choice requires considering many options, discussions with your team and stakeholders and finally making some crucial decisions.

It is this set of decisions that we call ‘architecture’. What’s more, this ‘architecture’ must be stored somewhere, communicated, and maintained, which also requires some planning.

It seems like a lot of work! Let me share how I would figure it out, assuming that I had standard technical background.

Cloud architecture – understand the benefits

Your issue: I’m not sure if it’s worth the effort.

If the topic of architecture seems difficult to understand, it’s worth exploring what values will cloud architecture bring to your business to appreciate just how important it is.

There are a lot of different areas where architecture can help, including:

·        Costs prediction

Without architecture it’s impossible to calculate the final cost of developing and maintaining software. Why? Every architecture decision influences desired quality attributes. So, if you want high availability, you will need to increase hardware spending to attain a desired system quality. It’s worth following principles Azure FinOps this point.

·        Risk management

No architecture = many unexpected surprises. Designing an architecture, you start thinking about risk factors very early in the process. This allows you to get initial assumptions and start resolving, owning, accepting, or mitigating risks. I recommend using the ROAM method here.

·        Trade-offs and constraints

Some IT decisions seem unreasonable or unclear, but with proper explanation and context they become easier to understand. Trade-offs and constraints can provide this context. In simple terms, a trade-off is when one factor increases, and another must decrease (availability vs. higher hardware cost). Constraints impose limitations and restrictions on what you can do (e.g. you can spend only this much $ on hardware)

·         Agility

It’s difficult to determine which change is possible without predefined boundaries. Architecture provides the structure which allows to detect these boundaries, and determine what are the opportunities within it. Thus, architecture enables IT teams to be more agile, because they know exactly when they can change something, and when not.

·        Team awareness

An architecture enables you to see how your teammates should work together on system development. In addition, the architecture makes it easier for team members to understand how the system is supposed to work.

·        Avoiding mistakes

Architecture enables you to discover the most challenging and important parts of the system, that can cost you dearly in the future if you make a bad decision there.

·        Better overview

Some systems are huge. Having an architecture, you can “eat the elephant one bite at a time”, which means easier progress tracking and milestones setting.

Cloud architecture – define requirements and possibilities 

Your issue: I don’t know where to start 

One of the first responsibilities of an architect is to identify important requirements that have big impact on software. It’s highly recommended to start writing down Architecturally Significant Requirements (aka ASR) using the following structure: 

•         Constraints – can be technical or business
•         Quality Attributes – expectations from the system (e.g. reliability)
•         Influential Functional Requirements – features and functions that require special attention in the architecture (e.g. multi-tenant SaaS database tenancy)
•         Other Influencers –teams’ skills and experience, office politics or legal restrictions 

Having these things determined will guide you into defining the system’s boundaries (context) and which services you should use (web services, databases, queue etc.).  

These architecture design options should be measured against the desired quality attributes of your system. For example: 

The table can be easily expanded to include other factors: estimated costs, constraints, readiness for delivery… It is important though to always include the assessment of each option.

This method provides a handy way to summarize findings, facilitate discussions with stakeholders and make good decisions.

Cloud architecture – document the decisions

Your issue: I don’t know which toolset to use

There are several industry standards and techniques in terms of documenting your decisions. I’d like to show you two of them, that are easy to use and apply immediately. Both enable you to deliver the best quality architecture.

C4 MODEL

C4 Model is a great tool for visualizing your architecture. This model is divided into 4 interconnected layers, each responsible for a different part of the system. Let’s check out the details:

Level 1 – Context: diagram shows how the system in scope fits into the environment around it

Level 2 – Container: diagram zooms into the system in scope, showing the high-level technical building blocks (e.g., web services, databases, queues)

Level 3 – Component: diagram zooms into an individual container, showing the components inside it.

Level 4 – Code: diagram can be used to zoom into an individual component, showing how that component is implemented

Different points of view encourage you to think about different aspects of your architecture and discuss it with the appropriate audience – for instance, you will speak with the DevOps team about things on the Container level, rather than the Component level. More about the C4 model here.

ARCHITECTURE DECISION LOG (ADL)

ADL records your architectural decisions in a standardized way. Regardless of the schema your ADL will take, it’s worth considering the following sections:

• Context – why are we interested in a given issue
• Decision – what approach do we choose
• Consequences – what type of trade-offs can we expect

More about this method and best practices here.

Summary:

I hope the importance of creating an architecture is clearer, and now you can face this challenge with more confidence.

If you still have trouble with it, don’t hesitate, and check out our dedicated offer. Based on our experience with numerous simple and complex projects, we have built up a large stockpile of knowledge and expertise, which allow us to choose the most balanced architecture for each individual solution, show options, and explain when to apply them.

Whether you decide on our offer or not, please remember: “Choose the architecture before it chooses you!”.