Solution Architecture

Solutions Architecture at The Company

We empower The Company to achieve strategic goals with a tech-at-core, multiproduct strategy, driving an evolutionary, business-driven, composable architecture that fosters outcome-based autonomous teams to innovate and deliver customer value at scale.

Responsibilities

1) Align product and technology strategy to enable business goals:

• Fully understand The Company’s business, long-term strategy, goals, and customer needs
• Build and maintain the architecture vision and principles
• Partner with business stakeholders to influence product direction (roadmap)

2) Define a composable and evolutionary architecture to promote team autonomy at scale:

• Map domain areas, business capabilities, system components, and team ownership
• Build and maintain the target architecture and roadmaps
• Make critical decisions on technology stack, frameworks, design patterns, and standards

3) Design solutions to meet product needs:

• Understand the immediate and mid-term product needs (roadmap items)
• Define end-to-end tech architecture solutions (frontend, backend, data, etc.)
• Partner with engineering and solutions teams to align direction

4) Promote Technical Excellence and act as role models for Engineering Teams

• Act as technical role models by solving the most complex tech challenges and guiding critical decisions
• Mentor and elevate developers’ technical skills while driving the adoption of best engineering practices
• Lead by example, fostering innovation, technical mastery, and a focus on building robust, high-quality software

5) Foster an Engineering Culture and DevEx to optimize Engineering Effectiveness

• Optimize SDLC, release strategy, and testing practices
• Promote engineering excellence through clean code, testing, automation, and observability practices across teams
• Drive engineering organization design

6) Foster innovation and continuous modernization

• Identify emerging technologies that drive differentiation to stay ahead of the competition
• Drive architecture modernization
• Lead transformation and continuous improvement initiatives

7) Set governance to ensure high quality of the system and architectural integrity

• Maintain system quality to ensure reliability, resilience, scalability, evolvability, security, compliance, performance, and cost efficiency
• Observe the current state and health of the system to identify gaps between target and current architecture
• Manage technical debt, tech risks, and post-mortem incidents to drive corrective actions

8) Document and communicate to align vision and execution at all levels

• Document architecture for stakeholders at all levels, from detailed technical diagrams for developers to high-level strategy summaries for executives
• Communicate architectural decisions and changes at different levels and forums

9) Promote system thinking and knowledge building

• Facilitate cross-functional collaboration and knowledge sharing with different areas: CPE, QA, EA, Data, AI, Engineering teams
• Drive initiatives to improve cross-functional understanding of architecture: workshops, guilds, CoPs, mentorships, etc.
• Mentor tech leads

Skills

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

Roles

Responsibilities of the Solutions Architecture Team are shared by everyone; however, the scope could be different depending on the role.

While roles and job levels are interconnected, they are not synonymous. Nonetheless, everyone in The Company has a defined job level that must be mindful of, as well as the expected competencies.

Solutions Architect Director

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

Chief Solutions Architect is ultimately accountable for ensuring architecture goals are achieved by leading the team.

Lead and manage the team by:

• Defining priorities and goals
• Establishing the operating model, ceremonies, and communication channels
• Acting as the ultimate decision-maker in case of discrepancies

Systems Solutions Architect

Key Stakeholders: CTO, VP of Engineering, Security Director, Product Directors, Product Managers, Engineering Directors (Engineering, CPE, QA), Enterprise Architects

System Architects are accountable for the current and long-term system health, efficient evolution, and governance across product areas and cross-cutting concerns: reliability, performance, security, quality, etc.

They are responsible for identifying and solving the most complex tech challenges through hands-on engineering work when needed.

Domain Solutions Architect

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

Domain Architects are accountable for the architecture and governance of specific domain areas and cross-cutting concerns in their scope of action. They partner with product stakeholders and TLs, designing solutions to address current and mid-term product requirements.

Extended Team

Team Architect (a.k.a. Tech Lead)

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

Tech Leads are accountable for the software architecture in their teams. Along with the Domain Architect, they design solutions to address requirements and take full accountability for the software their teams produce, following architectural direction and decisions.

Lead the engineering team by:

• Contributing and ensuring architecture direction is implemented in the team
• Promoting engineering excellence within their teams
  • Clean code
  • Test automation
  • Release and observability in production
  • “You build it, you run it” mindset
  • Tech debt management

Cloud Architect

(To be filled in by Dawid, add a link)

Enterprise Architect

(To be filled in by Dawid, add a link)

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 is coming and co-define the product direction
• Engage tech leads proactively to identify future blockers and tech debt
• Monitor the state of the system to identify gaps, risks, and issues
• Dare to lead, dare to own

Tech-led business innovation: Influence business and technology 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 to build solutions for engineers, architects, and users
• Prioritize the most valuable items for the long-term success of the business

Simplicity: Untangle and simplify the architecture, processes, and artifacts to move faster with autonomy

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

• Reduce granularity—always prefer fewer moving pieces
• Code for today’s problems and refactor based on evidence
• Give teams code over comprehensive documentation; prefer documenting through code rather than text

Organization

Strategic Ceremonies

Quarterly Architecture Design Reviews

Purpose Design a consistent to-be architecture for all the roadmap items we will deliver in 2025. Mechanics For each focus area:

1. Briefly describe the jobs to be done in the focus area
2. Describe the as-is architecture related to the business requirement
   • C4 existing diagrams
3. Describe and discuss the first version of the to-be solutions architecture
   • Draw.io, miro, etc.
4. Identify the gaps, dependencies and tech risks

Checklist Questions/topics to be covered in each topic:

• Capabilities identification
• Product specific or product agnostic
• Most important cross(non)-functional requirements identified
• Ways of governing?
• Embedded analytics needs identified
• Data products identified
• Cloud services/infra identified
• New technology needed (libraries, programming languages, etc)
• External systems integration (SF, Avalara, etc)
• Alignment with ACL vision
• New ADRs
• Risks
• Dependencies
• Build vs Buy: Is there a tool/cloud service that we can use to avoid building it?

Expected outcomes

• Solution design for all the focus areas/jobs to be done
  • Including answers for the points in the checklist
• AS-IS system architecture
• TO-BE system architecture
• Tech stack definition updated

TOPICS List

• [Topic 1]
• [Topic 2]

Agenda Date - Who

Architecture Face-to-Face Workshops

Tactical Ceremonies

Monthly Architecture Assurance Sync (doc)

[Pending access]

Monthly Retrospectives

Operational Ceremonies

Weekly Updates (Slack board)

Weekly Solution Design (doc)

Agenda

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

Dynamics for presentation and discussion:

• Present the problem statement: This could be a focus area, a business requirement, a roadmap item, an improvement opportunity, etc.
• Identify the impacted areas in the system diagram: Bring the predefined systems diagram (draw.io, autogenerated C4) and walk us through the diagram highlighting the areas that need change and where the solution will take place.
• Present the solution: Solutions architecture diagram, whiteboard diagram is ok, C4 too. The presenter will have the time without interruptions to present the solution
• Group discussion: We will discuss respectfully focusing on the idea, not the people.
  • There is no bad nor stupid idea
  • Attack the idea, not the person
  • Promote a positive and constructive conflict: If no discussion happens, there will always be someone that will play the Devil’s advocate role.

Open Topics

Permanent topics to discuss

Weekly Cross-Area Architecture

Managed as a backlog

Governance Meetings

• Weekly Governance Meetings with CTO and Eng VP
• TL ↔ Architects Catchups
• Engineering Steering Committee

Documentation

Documentation we need

• Domains and Capabilities map
  • Architecture diagram
  • All the components in the architecture: how they are related to capabilities and domain, relationships, etc.
  • Domain architecture
  • AS-IS
  • TO-BE
• Application and services catalog
• SCLC - value stream mapping
  • The entire process from the card is in the backlog until it is released to production (with times, actors, systems involved, etc.
  • Path to prod with all the environments involved (including Legacy and MIcroservices)
• Tech stack
  • All the tooling we have
• Team