I wanted to share my thoughts around solution design and architecture in tech. In my opinion, there isn’t a single “correct” way to design a solution, since each person brings their own perspective based on their experiences, preferences, and challenges. Some stick to a specific tech stack, whether that means opting for cloud-based, serverless solutions, containerized microservices, or choosing specialized databases like document DBs. And that may be fine as long as they are confident in their approach, keep costs within expectations, and meet the customer’s needs and goals in the end – but, you should always consider that your approach is overly complex for the task, or too simplistic for the plans ahead.

When I approach a new project and working with solution design, I’ve found that striking the right balance between best practices theory and practicality is key for me, and also for my customers.

Processing stakeholder requirements

When I meet stakeholders who need a solution, I process a lot of information while they present their needs to be able to translate their requirements into a high level technical implementation early on. It’s part of how I bridge the gap between business needs and practical architecture.

Early in the process, there are many crucial considerations and questions that help shape the solution, like:

• Where are we going with this? What’s the ambition?
• What’s the target group? Is it locally, regionally, globally?
• How many users can we expect? How will they log in? Are there different roles?
• What are the primary use cases? Do users require fast response times? Do we need caching?
• Do we need integrations? Is it event driven, or do we act based on other triggers?
• Is it an internal app, or is it publicly available? If internal, how should access be restricted from the outside?
• What are the availability requirements?
• What’s the budget?
• When should it be released? How will the rollout happen?
• Are there integrations with third-party systems? How can we access them? Do we need network adjustments?

These are just some of the many thoughts running through my mind as we discuss requirements. The goal is to map business needs to a working and scalable design without getting lost in unnecessary complexity early on.

Practicality and early results

One principle I’ve always prioritized is delivering visible results early. Showing customers outcomes early on builds trust, increases collaboration, and I think it keeps the momentum up. While theoretical frameworks and best practices play an important role, overly focusing on them up front can sometimes slow down the process – at least in my experience.

Take, for instance, the Five Pillars in the Azure Well-Architected Framework which focuses on reliability, security, cost optimization, operational excellence, and performance. These are foundational concepts that help ensure a solution is robust and aligned with best practices which is important that we as architects have in the back of our heads. However, in my experience, many customers, especially those new to the cloud, struggle to have clear opinions on all of these topics right away. I try to guide the customer into the most important topics that need to be sorted out straight away, and wait with other’s that can be tackled later on in the implementation phase.

Adapting to the customer

It’s crucial to base your approach on the customer’s size, their current capabilities, and goals. Large enterprise customers often have governance models and compliance measures already in place. For them, deeper discussions around security, scalability, availability, and compliance may be more structured and prepared which leads to productive dialogues and insights.

I have a lot of experiences from small to medium sized businesses, which doesn’t always have well-established guidelines or operational processes. Spending excessive time diving into each aspect can lead to over analysis and over-engineering a solution that is unnecessarily complex and hard to maintain for the customer going forward.

For smaller businesses or organizations just starting with Azure, simplifying the conversation and addressing immediate pain points can give better results than introducing comprehensive frameworks too early.

Balancing vision and immediate needs

While it’s tempting to solve all potential problems up front, it’s essential to find a balance. Over-engineering often leads to higher costs, stretched timelines, and solutions that are harder to adapt as business needs evolve. Instead, I prefer to start with an architecture that addresses immediate requirements while leaving room for future iterations.

Examples on this could be if you are about to implement an API in Azure, then you would maybe start off with something like:

• An App service for hosting your code
• Azure SQL database for storing data
• Application insights for monitoring

Over time, you can evolve this architecture by adding:

• API Gateway for better management and security
• Containerization for more flexible deployments
• A Redis cache to reduce latency on specific endpoints
• Auto scaling and resilience patterns like circuit breakers and retries

By delivering incremental value, the solution can evolve naturally while staying aligned with the customer’s changing needs.

Learn and adapt!

Being an architect is also about widening your horizon, be aware of the surroundings and possibilities by focusing on continuous learning. Technology, especially in the cloud, evolves rapidly. Staying updated with the latest Azure innovations and best practices is essential to be able to make good choices.

Being an architect is not about dictating solutions – it’s about helping customers navigate their to reach their goals, and to deliver solutions that works both now and in the future in the most optimal way.

And finally, as with other things in life, it’s important to listen to others, being able to realize when you may have failed, and to stay flexible and be able to adjust course.