How to implement feature flags and filters in .NET apps? A step-by-step guide
Along with improved DevOps expertise comes a better performance of delivery teams. And when many deployments take pl...
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.
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 FinOps principles at 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)
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.
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:
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.
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 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:
More about this method and best practices here.
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!”.
Read similar articles