Building a Solutions Architecture Organization

Building a Solutions Architecture Organization

Goal: Establish a Solutions Architecture function that aligns product and technology strategy, drives composable architecture, and enables autonomous teams to deliver customer value at scale.

Core Responsibilities

1. Align Product and Technology Strategy

• Understand business strategy, goals, and customer needs
• Define architecture vision and principles
• Partner with stakeholders to influence product roadmap

2. Define Composable Architecture

• Map domains, capabilities, components, and team ownership
• Build target architecture and roadmaps
• Make critical decisions on tech stack, frameworks, design patterns, standards

3. Design Solutions

• Understand immediate and mid-term product needs
• Define end-to-end architecture (frontend, backend, data)
• Partner with engineering teams to align direction

4. Promote Technical Excellence

• Solve complex tech challenges hands-on
• Mentor developers and drive best engineering practices
• Foster innovation and technical mastery

5. Foster Engineering Culture and DevEx

• Optimize SDLC, release strategy, testing practices
• Promote clean code, testing, automation, observability
• Drive engineering organization design

6. Drive Innovation and Modernization

• Identify emerging technologies for competitive differentiation
• Drive architecture modernization
• Lead transformation initiatives

7. Govern System Quality

• Ensure reliability, resilience, scalability, evolvability, security, compliance, performance, cost efficiency
• Identify gaps between target and current architecture
• Manage technical debt, risks, and post-mortem incidents

8. Document and Communicate

• Document architecture for all levels (detailed diagrams for developers, high-level summaries for executives)
• Communicate architectural decisions across forums

9. Promote System Thinking

• Facilitate cross-functional collaboration (CPE, QA, EA, Data, AI, Engineering)
• Drive knowledge sharing: workshops, guilds, CoPs, mentorships
• Mentor tech leads

Required Skills

• Broad software development experience
• Business acumen and domain expertise
• Communication and influence
• Leadership
• Proactive and goal-oriented

Team Structure

Solutions Architect Director

Key Stakeholders: CPO, CTO, CIO, VPs of Product, VP of Engineering, Head of Enterprise Architecture

Accountable for:

• Defining priorities and goals
• Establishing operating model, ceremonies, communication channels
• Acting as ultimate decision-maker

Systems Solutions Architect

Key Stakeholders: CTO, VP of Engineering, Security Director, Product Directors, Product Managers, Engineering Directors, Enterprise Architects

Accountable for:

• Current and long-term system health across product areas
• Cross-cutting concerns: reliability, performance, security, quality
• Solving complex tech challenges through hands-on engineering

Domain Solutions Architect

Key Stakeholders: Product Managers, Product Owners, Tech Leads, Engineering Managers

Accountable for:

• Architecture and governance of specific domain areas
• Designing solutions for current and mid-term product requirements
• Partnering with product stakeholders and tech leads

Extended Team

Team Architect (Tech Lead)

Key Stakeholders: Product Owners, Domain Solutions Architects, Engineering Managers, Developers

Accountable for:

• Software architecture within their teams
• Implementing architecture direction
• Promoting engineering excellence:
  • Clean code
  • Test automation
  • Release and observability
  • “You build it, you run it” mindset
  • Tech debt management

Cloud Architect

(To be defined)

Enterprise Architect

(To be defined)

Team Values

Proactivity: Take ownership and lead, don’t wait—make it happen

“The best way to predict the future is to create it.” – Peter Drucker

• Engage stakeholders proactively to know what’s coming
• Engage tech leads to identify future blockers and tech debt
• Monitor system state to identify gaps, risks, issues
• Dare to lead, dare to own

Tech-led Business Innovation: Influence direction through new technology

“The secret of change is to focus, not on fighting the old, but on building the new.” – Socrates

• Bring business solution ideas to product teams
• Research new technologies
• Prioritize items for long-term business success

Simplicity: Untangle and simplify to move faster with autonomy

“Simplicity is the ultimate sophistication.” — Leonardo da Vinci

• Reduce granularity—prefer fewer moving pieces
• Code for today’s problems, refactor based on evidence
• Prefer code over comprehensive documentation

Operating Ceremonies

Strategic: Quarterly Architecture Design Reviews

Purpose: Design consistent to-be architecture for roadmap items.

Process:

1. Describe jobs to be done in the focus area
2. Document as-is architecture (C4 diagrams)
3. Present and discuss to-be solutions architecture (draw.io, miro)
4. Identify gaps, dependencies, tech risks

Checklist:

• Capabilities identification
• Product specific or agnostic?
• Critical cross-functional requirements
• Governance approach
• Embedded analytics needs
• Data products identification
• Cloud services/infra identification
• New technology needed (libraries, languages)
• External systems integration (SF, Avalara)
• Alignment with ACL vision
• New ADRs
• Risks and dependencies
• Build vs Buy analysis

Expected Outcomes:

• Solution designs with checklist answers
• AS-IS system architecture
• TO-BE system architecture
• Updated tech stack definition

Strategic: Architecture Face-to-Face Workshops

Regular in-person collaboration sessions.

Tactical: Monthly Architecture Assurance Sync

Documented monthly reviews.

Tactical: Monthly Retrospectives

Team reflection and continuous improvement.

Operational: Weekly Updates

Slack-based progress board.

Operational: Weekly Solution Design

Agenda:

1. Review topics
2. Voting
3. Presentation and discussion

Discussion Dynamics:

• Present the problem statement (focus area, business requirement, roadmap item, improvement opportunity)
• Identify impacted areas in system diagram
• Present the solution (architecture diagram, whiteboard, C4)
• Group discussion:
  • Focus on ideas, not people
  • Attack the idea, not the person
  • Promote constructive conflict (Devil’s advocate if needed)

Operational: Weekly Cross-Area Architecture

Managed as a backlog.

Governance Meetings

• Weekly with CTO and VP Engineering
• TL ↔ Architects catchups
• Engineering Steering Committee

Required Documentation

Domain and Capabilities Map

• Architecture diagram
• Components: relationships to capabilities and domains
• Domain architecture (AS-IS and TO-BE)

Application and Services Catalog

Complete inventory of applications and services.

Value Stream Mapping

• End-to-end process from backlog to production (times, actors, systems)
• Path to production with all environments (legacy and microservices)

Tech Stack

Complete tooling inventory.

Team Documentation

Team structure and ownership mapping.