Characteristics of a Good Solutions Architect in 2026

A good Solutions Architect has always needed a combination of technical expertise, strategic thinking, business awareness, and strong interpersonal skills. Those qualities remain essential in 2026, but the scope of the role has expanded considerably.

Solutions Architects are no longer designing only applications, integrations, infrastructure, and cloud environments. They are increasingly expected to design ecosystems that include generative AI, autonomous agents, data platforms, internal developer platforms, multiple cloud and SaaS providers, edge services, legacy systems, regulatory controls, and rapidly changing security threats.

The modern Solutions Architect must therefore do more than produce technically correct diagrams. They must help organisations make responsible decisions under uncertainty, balance competing priorities, and create solutions that remain secure, affordable, adaptable, and operable after the project team has moved on.

The Foundations Still Matter

Despite the pace of technological change, the core characteristics of a good Solutions Architect have not disappeared.

A capable architect still needs:

• Broad and sufficiently deep technical knowledge.
• The ability to translate business objectives into practical solutions.
• Strong analytical and problem-solving skills.
• Clear communication with technical and non-technical stakeholders.
• Leadership, collaboration, and negotiation skills.
• The ability to understand the whole system rather than isolated components.
• Curiosity and a commitment to continuous learning.

What has changed is how these qualities must be applied.

1. Business and Outcome-Oriented Architecture

A good Solutions Architect begins with the business outcome, not the preferred technology.

Before proposing a platform, product, cloud service, or AI model, the architect should understand:

• What problem is being solved?
• Who benefits from the solution?
• How will success be measured?
• What constraints must be respected?
• What risks is the organisation willing to accept?
• What is the cost of doing nothing?
• How will the solution be operated and improved over time?

This requires genuine business acumen. Architects must understand value streams, customer journeys, operating models, organisational capabilities, commercial constraints, and regulatory obligations.

Technical elegance is useful, but it is not the objective. A beautifully engineered system that costs too much, cannot be supported, or solves the wrong problem is merely an expensive monument to poor judgement.

A good architect connects every major design decision to a measurable outcome such as increased revenue, reduced operational effort, lower risk, improved customer experience, faster delivery, or greater organisational resilience.

2. AI and Agentic Architecture Literacy

By 2026, understanding artificial intelligence is no longer a specialist-only skill for Solutions Architects.

Architects do not need to become machine-learning researchers, but they must understand how AI-enabled solutions differ from deterministic software. They should be able to determine when AI is appropriate and, equally importantly, when conventional rules, search, workflow automation, or analytics would be safer and more economical.

Key capabilities include:

• Understanding foundation models, smaller specialised models, multimodal models, embeddings, vector search, retrieval-augmented generation, fine-tuning, and model routing.
• Designing grounding and context-management strategies.
• Selecting appropriate models based on quality, latency, privacy, cost, and operational requirements.
• Designing evaluation frameworks rather than relying on impressive demonstrations.
• Implementing human approval for high-impact or irreversible actions.
• Providing fallback behaviour when models, tools, or external services fail.
• Managing model and prompt versions as controlled solution components.
• Understanding agent orchestration, memory, tool use, delegated identity, and agent-to-agent communication.

The emergence of autonomous AI agents has made interoperability, secure delegation, identity, authorisation, and auditability major architectural concerns. NIST launched its AI Agent Standards Initiative in February 2026 to support secure and interoperable agent ecosystems. rchitect treats an AI agent as an untrusted and probabilistic actor, not as an unusually enthusiastic API client.

3. AI Governance, Evaluation, and Responsible Design

Connecting an application to a large language model is relatively easy. Demonstrating that the resulting system is reliable, safe, lawful, and valuable is substantially harder.

Solutions Architects must understand AI risk management across the full lifecycle, including:

• Data provenance and permitted use.
• Privacy and confidential information handling.
• Bias, fairness, and harmful outputs.
• Hallucination and factual reliability.
• Prompt injection and indirect prompt injection.
• Model or agent access to tools and enterprise data.
• Intellectual-property and licensing concerns.
• Audit trails and explainability.
• Human oversight and escalation.
• Continuous evaluation after deployment.

The NIST AI Risk Management Framework organises AI risk activities around four functions: Govern, Map, Measure, and Manage. Its Generative AI Profile extends these principles to the distinct risks of generative systems. tive AI architecture should therefore define measurable quality and safety thresholds before production. These may include answer accuracy, groundedness, task-completion rates, refusal behaviour, harmful-output rates, latency, cost per successful task, and the frequency with which human intervention is required.

“People liked the prototype” is not an evaluation strategy, despite its enduring popularity.

4. Security and Identity by Design

Security can no longer be represented by a padlock icon placed near the edge of an architecture diagram.

A good Solutions Architect incorporates security into the design from the beginning. This includes:

• Identity-first and zero-trust principles.
• Least-privilege access.
• Strong workload and machine identities.
• Secrets and key management.
• Encryption in transit and at rest.
• Network segmentation and controlled service communication.
• Threat modelling.
• Secure software development and deployment pipelines.
• Dependency management and software bills of materials.
• Supply-chain risk management.
• Policy as code and automated compliance checks.
• Incident detection, containment, and recovery.

CISA’s Secure by Design guidance encourages technology providers to make security a fundamental product requirement rather than shifting responsibility to customers. CISA also identifies software bills of materials as an important mechanism for improving software supply-chain transparency. ed systems add further requirements. Agents must have clearly bounded permissions, short-lived credentials, controlled tool access, action-level audit records, and approval gates for sensitive operations. Current OWASP guidance identifies risks specific to agentic applications and provides mitigations for systems that can plan and act autonomously. dern Data Architecture and Governance

AI has made an old architectural truth painfully visible: poor data cannot be repaired by adding a more expensive model.

A Solutions Architect must understand how data is collected, classified, owned, transformed, accessed, retained, shared, and deleted. Technical decisions should be informed by data quality, lineage, residency, sovereignty, privacy, and lifecycle requirements.

Important skills include:

• Designing transactional, analytical, streaming, and unstructured-data solutions.
• Understanding data products, data contracts, metadata, lineage, and semantic models.
• Establishing authoritative sources and ownership.
• Applying classification and access policies.
• Designing retention and deletion processes.
• Preventing sensitive data from leaking through logs, prompts, embeddings, training datasets, or model outputs.
• Balancing central governance with domain ownership.
• Understanding where data must physically and legally reside.

Data governance is not simply a policy exercise. It directly affects the feasibility, quality, security, and cost of modern solutions. NIST is developing a Data Governance and Management Profile to help organisations use its cybersecurity, privacy, and AI frameworks together. atform Engineering and Developer Experience

A good architecture should make the correct approach easier than the incorrect one.

Instead of expecting every delivery team to independently assemble infrastructure, security controls, observability, deployment pipelines, and operational processes, modern organisations are investing in internal platforms and reusable “paved roads.”

Solutions Architects should understand:

• Internal developer platforms.
• Self-service infrastructure and environments.
• Reusable templates and reference implementations.
• Infrastructure and policy as code.
• Secure delivery pipelines.
• Service catalogues and ownership models.
• Golden paths that accelerate common use cases.
• Developer experience as an architectural quality.
• Treating platforms as products with users, roadmaps, and measurable outcomes.

The CNCF describes internal platforms as integrated capabilities presented according to the needs of their users. Its platform-engineering guidance emphasises that platform value depends on people, processes, policies, technology, and sustained organisational support, not merely deploying a developer portal. itect’s role is not necessarily to design one enormous platform for every conceivable need. It is to identify recurring friction and create the thinnest viable platform that removes it without becoming a new bureaucratic kingdom.

7. Financial Architecture and FinOps

Cost is an architectural characteristic.

A good Solutions Architect understands not only whether a solution can scale, but how its economics change as it scales. This is particularly important for consumption-based cloud services and AI workloads, where demand, token usage, model choice, data movement, and repeated inference can produce unpredictable costs.

Architects should be able to reason about:

• Total cost of ownership.
• Cost per transaction, customer, user, workload, or successful AI task.
• Fixed versus variable costs.
• Capacity commitments and utilisation.
• Data-transfer and data-retention costs.
• Licensing and support costs.
• Model routing, caching, batching, and token consumption.
• Financial effects of availability and recovery requirements.
• Vendor pricing changes and exit costs.
• Sustainability and energy efficiency where relevant.

The FinOps Foundation’s 2026 research reports that managing AI expenditure has moved into the normal scope of FinOps practices. Its guidance highlights AI’s cost complexity, rapid development cycles, unpredictable consumption, and need for stronger governance. tect should be able to explain what the organisation receives for every major category of technology spending. “The cloud bill is complicated” is an observation, not a financial strategy.

8. Reliability, Resilience, and Observability

A solution is not successful merely because it deployed successfully.

Solutions Architects must design for real operating conditions, including dependency failures, traffic spikes, network disruption, corrupted data, regional outages, third-party service degradation, model errors, and ordinary human mistakes.

This requires knowledge of:

• Service-level objectives and error budgets.
• High availability and disaster recovery.
• Recovery time and recovery point objectives.
• Graceful degradation.
• Idempotency, retries, timeouts, and circuit breaking.
• Queueing, back-pressure, and load shedding.
• Backup integrity and restoration testing.
• Chaos testing and operational game days.
• Runbooks, support ownership, and escalation paths.

Observability must also be designed into the solution. Modern systems require correlated telemetry across applications, infrastructure, integrations, data pipelines, and AI components.

OpenTelemetry defines observability around signals such as traces, metrics, logs, baggage, and profiles. These signals help teams understand not simply whether a service is running, but whether it is behaving as users expect. ystems, observability should also capture model selection, prompt and context versions, retrieved sources, tool calls, token usage, latency, evaluation results, approval decisions, and outcomes, subject to privacy and security controls.

9. Integration, Hybrid Environments, and Pragmatic Modernisation

Most enterprise solutions are not created on an empty architectural canvas. They must coexist with legacy systems, SaaS platforms, multiple clouds, on-premises infrastructure, partner services, and manual processes that someone once described as temporary.

A capable Solutions Architect should understand APIs, events, messaging, workflow orchestration, batch integration, data synchronisation, and identity federation. They should also know how to select the simplest integration style that satisfies the requirement.

Modernisation skills include:

• Incremental migration and strangler patterns.
• Domain and capability decomposition.
• API and event-contract design.
• Anti-corruption layers around legacy systems.
• Coexistence and transition architectures.
• Data migration, reconciliation, and rollback planning.
• Deciding when not to use microservices.
• Managing dependencies across organisational boundaries.

The objective is controlled evolution, not rewriting everything because the existing system uses an unfashionable programming language.

10. Regulatory Literacy and Digital Sovereignty

Architects are not expected to replace legal, privacy, risk, or compliance specialists. They are expected to recognise when architectural decisions create obligations and involve the right specialists early enough to influence the design.

Relevant areas may include:

• Privacy and consent.
• Data residency and cross-border transfers.
• Records retention.
• Accessibility.
• Industry-specific security controls.
• AI transparency and risk classification.
• Automated decision-making.
• Intellectual property.
• Operational resilience.
• Government or critical-infrastructure requirements.

The European Union’s AI Act is one prominent example of legislation establishing risk-based obligations for AI systems. Similar requirements are developing across jurisdictions and industries. rchitect turns obligations into traceable design requirements, controls, evidence, and operational responsibilities. Compliance should be designed into delivery pipelines and platform capabilities wherever practical, rather than reconstructed shortly before an audit.

11. Vendor, Product, and Ecosystem Judgement

Solutions Architects are surrounded by products claiming to be platforms and platforms claiming to eliminate architecture.

A good architect evaluates technology using evidence rather than marketing momentum. This includes considering:

• Functional fit.
• Security and compliance.
• Service maturity.
• Integration capability.
• Operational support.
• Skills availability.
• Commercial terms.
• Data portability.
• Roadmap credibility.
• Ecosystem health.
• Lock-in and switching costs.
• Failure and exit scenarios.

Avoiding all lock-in is neither realistic nor necessarily desirable. The architect’s responsibility is to make lock-in deliberate, visible, and proportionate to the value received.

For fast-moving AI services, the architecture should also anticipate model replacement, provider changes, evolving safety controls, and differences in quality or price. Abstraction can help, but unnecessary abstraction can create its own expensive and poorly documented platform.

12. Communication, Influence, and Decision Leadership

Technical knowledge alone does not make someone an effective Solutions Architect.

Architects frequently work without direct authority. They must influence executives, product owners, engineers, security teams, vendors, delivery managers, and operational staff who have different priorities and vocabularies.

A good architect can:

• Explain complexity without hiding important details.
• Present options and trade-offs fairly.
• Separate facts, assumptions, risks, and recommendations.
• Facilitate difficult decisions.
• Challenge unrealistic requirements constructively.
• Resolve disagreement without turning every workshop into a territorial dispute.
• Record decisions and their rationale.
• Mentor teams rather than becoming a permanent approval bottleneck.
• Adapt communication to the audience.
• Admit uncertainty and identify how it will be reduced.

Architecture documents should support decisions and delivery. Useful artefacts may include context diagrams, architecture decision records, risk models, quality-attribute scenarios, transition roadmaps, cost models, threat models, prototypes, and measurable acceptance criteria.

The volume of documentation is not evidence of architectural quality. Often it is evidence that no one was brave enough to edit.

13. AI-Assisted Architecture Work

A Solutions Architect in 2026 should know how to use AI tools productively without surrendering professional judgement.

AI can assist with:

• Researching technology options.
• Exploring design alternatives.
• Producing initial diagrams and documentation.
• Generating prototypes.
• Reviewing code and configuration.
• Identifying potential threats and failure scenarios.
• Summarising standards and vendor documentation.
• Preparing stakeholder-specific explanations.
• Maintaining architecture knowledge bases.

However, architects remain accountable for verifying generated information, protecting confidential material, checking licensing restrictions, and ensuring recommendations reflect the organisation’s actual context.

AI should accelerate reasoning, not replace it. Producing an incorrect architecture document more quickly is not a productivity improvement.

14. Curiosity Without Trend Chasing

Continuous learning remains one of the defining characteristics of a good Solutions Architect.

The architect should monitor developments such as confidential computing, edge AI, digital identity, post-quantum cryptography, spatial computing, decentralised technologies, and new integration standards. They do not need to adopt every emerging technology, but they should understand when it may affect current decisions.

For example, NIST now advises organisations to begin planning migration to post-quantum cryptography, including discovering where vulnerable cryptographic algorithms are used and developing transition roadmaps. is horizon awareness: recognising developments early enough to avoid preventable dead ends, while resisting the urge to redesign the enterprise whenever a new acronym appears.

Practical Examples

AI Customer-Service Agent

A weak design connects a language model to customer records and several operational APIs.

A strong design also defines delegated identity, minimum tool permissions, data filtering, prompt-injection controls, human approval for sensitive actions, evaluation datasets, audit records, fallback workflows, cost limits, model-routing rules, and measurable customer outcomes.

Legacy-System Modernisation

A weak design proposes replacing the entire system with microservices.

A strong design identifies business capabilities, operational risks, dependency boundaries, transition states, data-reconciliation requirements, and the minimum platform capabilities needed to support incremental migration.

Regulated Data Platform

A weak design focuses on storage and analytics technology.

A strong design also addresses data ownership, classification, lineage, quality, residency, retention, access evidence, privacy, encryption, recovery, cost attribution, and how policies will be continuously enforced.

A 2026 Architecture Checklist

Before recommending a solution, a good Solutions Architect should be able to answer:

1. What measurable business outcome does this solution support?
2. Why is this approach preferable to simpler alternatives?
3. What assumptions are we making, and how will we test them?
4. How will the solution fail, recover, and degrade safely?
5. How are identity, security, privacy, and supply-chain risks addressed?
6. What data is used, who owns it, and where may it be processed?
7. How will quality and performance be measured in production?
8. What will the solution cost at expected and extreme levels of demand?
9. How will teams build, deploy, operate, and support it?
10. What regulatory or contractual obligations apply?
11. How easily can major components or vendors be changed?
12. What decisions must remain under human control?
13. What evidence will show that the solution continues to deliver value?
14. What is the transition path from the current state to the target state?

Conclusion

A good Solutions Architect in 2026 is not defined by mastery of a particular cloud platform, modelling notation, or architecture framework.

They combine technical breadth with selected areas of depth. They understand business value, data, AI, security, platforms, cost, resilience, integration, regulation, and operations. They communicate clearly, lead decisions, and help teams navigate uncertainty.

Most importantly, they exercise judgement.

The best architect is not the person who introduces the most technology. It is the person who helps the organisation make sound, explainable, and sustainable decisions while keeping the solution as simple as the problem allows.