Software Architecture Review and Solutions Architect

What a software architect does, and what architecture consulting covers

System architecture is the sum of the decisions that are hard to change later: how the system is split into components, how they talk to each other, where data lives and who owns it, how the system is deployed and operated, and how it copes with load, failures and change. A software architect makes sure those decisions are made deliberately, with the cost of each one understood, rather than being set after the fact by whatever code got written first.

External architecture consulting complements your team rather than replacing it. It brings an outside view, questions that are hard to ask from inside and experience comparing alternatives. The output is not a generic slide deck but documented decisions and a plan your developers can start working from the next day.

It also helps to be clear about what architecture is not. It is not picking the newest technology, a diagram saved in a folder and forgotten, or a one-time phase at the start of a project. Good architecture evolves with the system, and its decisions are revisited when requirements change.

When you need an architecture review: familiar signs

A system that needs a review is not necessarily a bad system. More often it is one that succeeded and grew faster than the decisions it was built on: more customers, more features, more integrations, and the same basic structure from day one. At that point every change costs more, and the team feels it long before it shows up in any report.

Most organizations do not book a review when everything is calm. These are the situations where it pays off most:

• Every small change touches many places, and development keeps slowing down even though the team size has not changed.
• Production incidents are hard to diagnose, and nobody has a clear picture of what depends on what.
• The system needs to grow (more users, more customers, more data) and it is not clear the current design will hold.
• You are facing an expensive decision: moving to the cloud, splitting into microservices, replacing a platform or choosing a vendor.
• You want to bring AI into your product or organization, and it is unclear where it sits, how it accesses data and how costs stay under control.
• Knowledge of the system lives in one or two people's heads, and nothing documents why it was built the way it was.
• You received a proposal or design from an outside vendor and want an independent opinion before committing.

Types of engagement: from a focused review to AI solutions architecture

Architecture consulting is not a single product, and each stage in a system's life calls for a different kind of work. Recently a new area has joined the list and deserves its own attention: AI solutions architecture.

An AI solutions architect deals with questions that do not exist in conventional software: the model is an external dependency that changes, the output is not deterministic, cost is incurred on every call, and answer quality depends on the retrieval layer and on data permissions. So the design includes, from day one, a single access layer for models, an evaluation set, clear limits on what agents can do and human approval points, instead of bolting them on once the system is already in production.

A typical example: an organization that wants a RAG-based knowledge assistant over its internal documents. The architectural questions are where the model runs, how documents and permissions are synced from the source systems, how quality is measured and how cost is capped, long before the question of which model is smartest.

These are the main types of engagement, and they are often combined:

• Architecture review of an existing system: mapping the current state, identifying risks and bottlenecks, and recommending targeted changes in priority order.
• New system design: defining components, interfaces, data model and deployment approach before writing code, including a comparison of alternatives.
• Cloud and infrastructure architecture: how the system runs, whether containers, Kubernetes or managed services, plus infrastructure as code, CI/CD, networking and permissions.
• AI solutions architecture: designing LLM-based systems such as RAG, agents and organizational platforms, and integrating them with existing systems.
• Opinion on a decision or proposal: a focused assessment of a design, vendor or technology, with a clear recommendation.

What a software architecture review looks at

The review relies on evidence, not just interviews: reading code and checking infrastructure configuration, deployment pipelines, monitoring and cloud billing. Each finding points to where it was found and is rated by severity and by the effort needed to fix it, so it is easy to tell an urgent problem from an improvement that can wait.

A good review looks at the system as a whole, not just the code. These are the areas covered, depending on the agreed scope:

• Fit with goals: does the structure support what the business needs now and next, and what does it block?
• Components and boundaries: separation of responsibilities, coupling, interfaces and circular dependencies.
• Data: where data is stored, who owns it, how it flows and how consistency is maintained.
• Integrations: connections to internal systems and external services, and what happens when one of them is down.
• Security and access: identity and secrets management, least privilege and separation between environments.
• Deployment and operations: CI/CD, infrastructure as code, monitoring, logging and the ability to roll back.
• Performance, availability and cost: where bottlenecks are likely, what the failure points are and what drives the cloud bill.
• Maintainability and team: can the current team develop and operate the system, and where is knowledge concentrated in one person?

The process and timeline

The review does not happen behind closed doors. Interim findings are shared with the team throughout, so misunderstandings get corrected early and nobody is surprised at the end.

When the review includes AI components, discovery extends to the data itself: which sources exist, who is allowed to see what, and what a representative sample of the questions or tasks the system will handle looks like.

How long the work takes depends on the size of the system, the availability of documentation and people, and the depth required. A focused review of one component is much shorter than redesigning an entire platform. The stages themselves stay the same:

1. Goals and constraints

   Conversations with leadership and the technical team: what you are trying to achieve, the budget and timeline, and existing constraints such as internal policy, infrastructure and staffing. Together we define the scope of the review and the questions it needs to answer.

2. Discovery

   Reading code, diagrams, documentation, infrastructure configuration and CI/CD pipelines, alongside conversations with the people who build and run the system. Often the gap between the documentation and reality is the first finding.

3. Current-state map

   Drawing the system as it really is: components, data flows, dependencies and failure points. The map is validated with the team before moving on.

4. Analysis and options

   For each key problem, several alternatives are laid out with their trade-offs: complexity, cost, operations, risk and impact on the team.

5. Recommendation and execution plan

   A reasoned recommendation, documented decisions and a staged plan that starts with the changes that offer high value at low risk.

6. Presentation and follow-through

   Presenting the findings to the team and leadership and answering questions. As needed: support during execution, code review of the first changes or availability for decisions that come up along the way.

What you get, and how you know the review worked

At the end you get an architecture document with current-state and target-state maps, a risk list ranked by severity and likelihood, options with a transparent comparison, architecture decision records (ADRs) explaining what was decided and why, and an execution plan with milestones. Everything is written so your team can carry it forward without depending on the consultant.

Decision records are the part people tend to underrate, and they are the part that lasts longest. When someone asks a year from now why a particular database was chosen or why a service was not split out, the answer will be written down, including the alternatives considered and the conditions under which the decision should be revisited.

A review's success is not measured by the thickness of the document. These are the signs it did its job:

• The team agrees on the picture and understands the recommendations, rather than just accepting them.
• The decision that was on the table got made, with confidence.
• The first stages of the plan are underway, and key assumptions were tested early.
• Over time: changes ship faster, incidents are easier to diagnose, and infrastructure costs are understood and predictable.

How to choose an architect, and mistakes worth avoiding

An external architect needs to combine technical depth with the ability to explain and to decide. It also helps to know the common mistakes: choosing a technology because it is fashionable rather than because it solves an existing problem; splitting into microservices before the team is ready to operate them; designing for hypothetical load at the expense of today's problems; accepting an impressive document nobody reads; and leaving operations, security and cost questions until the end.

Questions worth asking an architect before you start:

• Will you work with our developers and read the code, or only interview people?
• What will the deliverable look like, and can we see its structure upfront?
• Do you have any interest in recommending a particular cloud, tool or vendor?
• Do you have hands-on experience with deployment and operations, not only design on paper?
• How will you prioritize recommendations, and what can we do first without stopping development?

Why work with me

I am Bechor Simhaev, an AI Solutions Architect with a strong DevOps and cloud background. I design and build end-to-end AI solutions (RAG pipelines, agentic and multi-agent workflows, and LLM-based organizational platforms) and take them from concept to production.

My path ran through automation development, technically leading automation development with C# and CI/CD, and working as a DevOps engineer with Kubernetes (including AKS and OpenShift), Terraform, Docker, Azure, Azure DevOps, GitHub, Nexus and microservices. So every recommendation I make is tested against a simple question: can this actually be deployed, monitored and maintained? Teaching as an assistant lecturer in a software engineering course at Ariel University taught me to explain complex decisions in a way a team can work with.

I work independently and vendor-neutral, with no commissions from cloud, tool or model providers, so recommendations come only from what is right for your system and your team.