A Real Solution Architect Is Not Just Someone Who Draws Boxes

In many software companies, the career path is presented as a fairly simple progression:

Developer → Senior Developer → Technical Lead → Solution Architect

The further someone moves along that path, the less code they are expected to write. At some point, the work of a Solution Architect becomes mostly about meetings, diagrams, technology choices, and high-level design reviews.

There is nothing inherently wrong with that arrangement. A Solution Architect clearly cannot spend all day working through tickets like a full-time developer. The problem begins when the distance between architecture and implementation becomes too wide.

At that point, the architect sees the system mainly through slides, documents, and status meetings. Developers, meanwhile, have to live with the consequences of those decisions: an abstraction that is awkward to use, a dependency pointing in the wrong direction, a framework leaking too far into business logic, or a small change that unexpectedly touches a long list of modules.

An architect should never move so far away from code that they can no longer feel these problems. They still need to be experienced programmers who remain close enough to implementation to understand whether their architecture is helping the team move faster or quietly creating more work.

Architecture Only Matters When It Survives Contact with Code

An architecture diagram can look perfectly reasonable:

• Presentation Layer
• Application Layer
• Domain Layer
• Infrastructure Layer
• Event Bus
• API Gateway
• Database Cluster

On a slide, every component appears to be in the right place. The lines are clean, the responsibilities are separated, and the dependency direction looks sensible.

Implementation can reveal a very different system:

• Business logic must inherit from a framework base class.
• Domain models contain ORM annotations.
• A simple use case passes through too many intermediate abstractions.
• Unit tests require a database or web server.
• A data change affects several unrelated modules.
• New developers cannot tell where the actual business rules live.

This gap between the architecture diagram and the architecture in the codebase is common.

A Solution Architect does not need to take on the same workload as a developer, but they should still be able to follow a requirement down into the code and verify whether the intended structure actually works.

That can take several forms:

• Building a reference vertical slice for the team.
• Writing a proof of concept for a high-risk decision.
• Reviewing code around important architectural boundaries.
• Tracing an execution flow from the API to persistence.
• Inspecting the dependency graph between modules.
• Reading tests to understand how well business rules are protected.

Code is where architectural decisions meet reality. A principle that exists only in documentation, but cannot be maintained in implementation, has not truly become part of the architecture.

Architectural Quality Shows Up in the Cost of Change

Architecture presentations often spend a great deal of time describing the technology stack:

The system uses microservices, Kubernetes, Kafka, Redis, MongoDB, PostgreSQL, Elasticsearch, and event-driven architecture.

That list tells us which tools are involved, but it says very little about the quality of the architecture.

A system may use every modern technology on the market and still be extremely difficult to maintain. Adding one business rule might require changes across several services, updates to multiple contracts, and a large regression cycle. Another system may use a much more conventional stack but remain easy to extend because its dependencies are clear and each change stays within a predictable scope.

The purpose of software architecture is to reduce the amount of human effort required to build and maintain a system over time.

A good architecture usually produces very practical outcomes:

• A new use case can be added without modifying many existing modules.
• Business rules can change without directly affecting the database.
• Core behavior can be tested without starting the entire application.
• An external service can be replaced without rewriting the core system.
• A framework upgrade does not become a migration project that lasts for months.
• A new developer can quickly locate the main business logic.

These benefits usually become visible only after the system has been running for a while. Good architecture does not always make the first few weeks of development faster. Its value appears when the number of features, dependencies, and contributing teams begins to grow.

An Architect Does Not Need to Decide Everything on Day One

Solution Architects are often expected to lock down the entire technical foundation early:

• Programming language.
• Database.
• Cloud provider.
• Message broker.
• Frontend framework.
• ORM.
• Deployment model.

Some of these decisions must be made early so that the team can begin. Others do not need to become permanent commitments at the start of the project.

Good architecture allows technical decisions to be delayed until enough information is available. This is not a way to avoid responsibility. It is a way to manage architectural risk.

Consider a project that chooses MongoDB at the beginning and shapes the entire domain model around its document structure. A few months later, the team discovers that the data has more relationships, transactional requirements, and reporting needs than expected. PostgreSQL may now be a better fit, but changing direction is expensive because the database model has already spread into business logic, API contracts, and test cases.

The problem is not simply that the team chose the wrong database. The deeper problem is that an infrastructure decision was allowed to control the structure of the whole application.

An architecture that supports delayed decisions keeps business rules independent long enough for the team to learn more about the domain, workload, and operational constraints. When the time comes to make a long-term technology choice, the decision can be based on evidence rather than early assumptions.

The Dependency Rule Protects the Most Valuable Part of the System

The Dependency Rule is one of the central principles of Clean Architecture.

Source-code dependencies should point toward high-level policies and business rules, not outward toward details such as databases, user interfaces, frameworks, or external services.

For example, an ApproveLoan use case needs to load customer information, apply lending rules, and store the approval result. It does not need to know whether the data comes from SQL Server, an external API, Kafka, or an in-memory repository used in tests.

When the application core depends directly on Entity Framework or Hibernate, business logic begins to inherit the constraints of the persistence layer. This may not create immediate pain, but it becomes obvious when the team needs to test behavior independently, change the storage model, or move part of the logic into a different deployment context.

Instead of letting the application service depend directly on the ORM:

ApproveOrderUseCase
    → EntityFrameworkDbContext
        → SQL Server

The source-code dependency can be inverted:

ApproveOrderUseCase
    → OrderRepository interface


SqlOrderRepository
    → OrderRepository interface
    → Entity Framework
    → SQL Server

At runtime, the use case still calls a repository and the data is still stored in SQL Server. The difference is in the source code: the business rule knows only the contract it needs, while the persistence implementation depends on that contract.

This does not mean that every class needs an interface. Abstractions have a cost, and applying them mechanically can make a codebase harder to follow.

A boundary is valuable when it protects important code from a dependency that is likely to change, difficult to control, or unsuitable as a foundation for business logic.

The Project Structure Should Reflect the Domain

A codebase organized like this is familiar:

/controllers
/services
/repositories
/entities
/configurations
/helpers

It shows that the team is using a layered architecture, but it does not tell us what problem the system solves.

Another structure might make the domain much clearer:

/order-processing
    /place-order
    /cancel-order
    /calculate-shipping


/inventory
    /reserve-stock
    /release-stock


/payment
    /authorize-payment
    /refund-payment

A developer can immediately tell that the system deals with order processing, inventory, and payments.

This is the idea behind Screaming Architecture. The structure of the system should make its business capabilities and use cases visible before it reveals the frameworks and tools used to build them.

In a healthcare system, concepts such as PatientRegistration, AppointmentScheduling, PrescriptionManagement, and InsuranceClaim should be easy to find in the codebase.

When the most visible parts of the project are Controllers, Repositories, Spring, MySQL, and Kafka, the technology has taken the place that belongs to the domain.

This does not mean that every project must adopt the same folder structure. The right organization depends on team size, domain complexity, and the modularization strategy.

The practical goal is that a new developer can open the codebase and understand which business capabilities the system provides, rather than only recognizing which framework it uses.

Frameworks and Databases Need to Stay in Their Proper Place

Frameworks, databases, and user interfaces should be treated as details that belong at the outer edge of the system.

That language is sometimes misunderstood as dismissing the importance of technology. In reality, a database choice has a major impact on consistency, performance, scalability, and operating cost. A poor framework choice can also create technical debt that lasts for years.

The distinction is that these technologies are not the reason the system exists.

An e-commerce platform exists to manage products, orders, payments, and delivery. It does not exist to use PostgreSQL or Spring Boot.

A carbon trading platform exists to manage carbon assets, transactions, audits, and regulatory compliance. It does not exist to use .NET, Angular, or MongoDB.

Technology serves business capabilities. When business logic is designed as an extension of a framework, that priority has been reversed.

Keeping frameworks and databases at the outer edge reduces the amount of the application core that is affected when those technologies change. Teams may never replace the database or framework, but limiting the reach of those details still has value.

A framework migration is easier to control when framework-specific annotations, lifecycle hooks, and APIs are not scattered throughout the domain model. A change in persistence strategy is less risky when use cases do not contain ORM queries directly.

What a Solution Architect Actually Does

A Solution Architect does more than translate requirements into technical diagrams.

The role sits at the intersection of business, engineering, security, operations, and delivery. Architects need to understand the business objective, but they also need to understand how each technical decision will affect the code and the production environment.

When a new requirement appears, an experienced architect usually considers several layers at once:

• Which business rule is actually changing.
• Which part of the system needs to remain stable.
• Which direction the new dependency will point.
• Which decisions must be made now so the team can continue.
• Which decisions can safely be delayed.
• Where the cost will appear if the current assumption is wrong.
• How independently the use case can be tested.
• How security, compliance, and operational constraints affect the design.

These considerations do not need to become a formal checklist in every meeting. Over time, they become part of how an architect reads a system.

A strong Solution Architect may not write the most code on the team, but they must stay close enough to recognize when a boundary is being broken, an abstraction is slowing implementation, or a design works only on a diagram.

They also need enough practical judgment to know when coupling is acceptable. Not every system requires a full Clean Architecture implementation. A short-lived internal tool with limited change may not need the same level of protection as a core banking platform or a government system expected to operate for decades.

Architecture always depends on context. A decision that is sensible in one project can become over-engineering in another.

Signs That Architecture Is Drifting Away from Implementation

An architect begins to lose touch with the system when most decisions are evaluated only through slides and documentation.

Common signs include:

• Choosing technology before understanding the domain.
• Locking down the entire stack while major assumptions remain untested.
• Applying the same rules to every service regardless of its business characteristics.
• Failing to verify whether diagrams match the dependencies in the code.
• Treating the number of components as evidence of architectural maturity.
• Viewing coding as low-level work that no longer concerns the architect.
• Never experiencing the cost the team pays to follow the proposed design.

At that point, architecture becomes a governance layer outside development rather than something that supports development.

A real architect is willing to open the IDE, read a section of code, trace a request, inspect tests, or check dependencies between modules. They do not do this to control every implementation detail. They do it to confirm that high-level decisions still make sense in practice.

They must also be willing to revise those decisions when implementation proves that the original assumptions no longer hold.

Architecture is not an immutable blueprint. It is a set of decisions that must be tested and adjusted throughout the life of the system.

Being Hands-On Is Not the Same as Only Being Good at Coding

Emphasizing that architects should stay close to code does not mean the strongest programmer automatically becomes the best Solution Architect.

The role still requires capabilities beyond programming:

• Understanding the business domain and strategic goals.
• Communicating with stakeholders at different levels.
• Evaluating security, compliance, and operational risk.
• Designing integrations across multiple systems.
• Balancing quality, cost, and delivery timelines.
• Explaining trade-offs clearly.
• Guiding the team without becoming a bottleneck.

An architect who is strong only in coding may create an elegant technical design that does not solve the right business problem.

An architect who is strong only in communication and presentation may create a convincing roadmap but fail to recognize the problems that will emerge during implementation.

A real Solution Architect has to operate in both worlds. They understand the business deeply enough to select the right problem, and engineering deeply enough to produce a solution that can be built, operated, and changed in practice.

The Final Measure Is the Ability to Change

After all the diagrams, architecture decision records, coding conventions, and technology evaluations, the value of architecture comes back to one practical issue: whether the system can continue to change at a reasonable cost.

When a new requirement arrives, can the team quickly identify where the change belongs?

Are business rules separated from frameworks and infrastructure at an appropriate level?

Does a local change remain local?

Can use cases be understood and tested independently?

Does development speed collapse as the codebase grows?

No system answers all of these questions perfectly. Architecture is always a collection of trade-offs. What matters is that the team understands what it is trading away and whether that decision fits the expected life of the product.

A real Solution Architect is not measured by the number of diagrams they produce or the number of technologies listed in the solution.

Their value lies in keeping business rules from being buried under technical details, making dependencies visible, delaying decisions that do not yet need to be made, and controlling the cost of change.

They still need to stay close to the code, because that is where architectural decisions either prove their value or fail.

When a system has grown for years and the team can still understand, modify, and extend it with a reasonable amount of effort, the architecture has done its job.