This article is a translation of アーキテクチャ戦略について考える.

Below is an English translation of the original text.

---

Thinking About Architecture Strategy

In software development, even if you are not in a clearly defined position such as CTO or architect, there are times when you feel the “need for an architecture strategy” and have the opportunity to think about it.

• “I want to establish a technical direction on the ground, but I’m not sure where to start.”
• “I want to design an architecture that takes into account future scalability and organizational growth.”
• “I want to know how to deal with the technical debt that’s already accumulated.”

This article organizes why an architecture strategy is necessary and how to leverage it in response to these kinds of questions.

Background and Disclaimer

There have been moments when I’ve thought, “Wait, which strategy is this plan being implemented under?” or “What is strategy in the first place?” During those times, abstract thoughts would float around in my head, but I couldn’t properly put them into words. I decided I needed to organize my thinking, so I studied the topic on my own and compiled this content.

I have neither served as a CTO nor an architect, and I lack extensive hands-on experience in devising many architecture strategies, so these ideas might amount to nothing more than daydreams in my head.

Therefore, if you notice anything clearly incorrect, I would be grateful if you could discreetly let me know.

1. Introduction

Before diving into architecture strategy, let’s clarify the terms “architecture” and “strategy.” Although these concepts are frequently used in software development, they can be surprisingly ambiguous or perceived differently by different people.

In this article, I will give an overview according to the following flow:

• What is an architecture strategy?
• Why is it necessary, and what are the benefits?
• How should you formulate it? (Process and concrete examples)
• Necessary skills, cautions, and reference materials

2. What is Architecture Strategy?

2.1 What Is Architecture?

In software development, “architecture” refers to the overall structure and design policies of a system. Specifically, it includes elements such as:

1. System Structure

   • Components that make up the system (e.g., microservices, databases, API gateways)
   • The relationships between these components (data flows, communication methods)

2. Design Principles/Patterns

   • Design approaches like layered architecture, clean architecture, microservices, DDD
   • Best practices such as the SOLID principles, CQRS, Event Sourcing

3. Consideration of Non-functional Requirements

   • Scalability, availability, security, performance, maintainability/extensibility, and more

4. Technology Selection

   • Programming languages, frameworks, databases, cloud providers, etc.
   • API design (REST, GraphQL, gRPC, etc.)

5. Development/Operations Process

   • CI/CD pipeline design, monitoring/logging, development flow (agile or waterfall), and more

These are just examples and are not exhaustive.

Architecture is a concept that sits at a higher level than design, indicating “the overall framework of a system” and “the guiding principles of design.” Based on that overarching directive, you then move on to the design stage, which involves concretely defining individual modules, classes, data models, and so on.

2.2 What Is Strategy?

Strategy refers to the overarching direction or plan to achieve a goal. While tactics refer to “specific individual methods or initiatives,” strategy has a long-term, comprehensive perspective that defines the overall direction of an organization or project.

According to the book Good Strategy/Bad Strategy, the author outlines what makes a good strategy versus a bad one:

• Key Points of a Good Strategy

  • Contains specific actions, making it clear what needs to be done
  • Makes appropriate choices and focuses resources, clearly delineating what you will and will not do
  • Consists of three elements: diagnosis (analysis of the current situation) → guiding policy → action

• Characteristics of a Bad Strategy

  • Hollow, lacking concrete details
  • Fails to address major problems head-on, avoiding serious issues
  • Merely sets goals without clarifying how to achieve them

2.3 Defining an Architecture Strategy

Combining the concepts of “architecture” and “strategy” yields architecture strategy—that is, “a plan or guideline for how an organization or project will build and evolve a system in a strategic and structured manner.”

Concretely, it can include elements such as:

1. Clarification of Vision and Goals

   • Align with the business strategy while indicating the technical direction
   • Example: adopting a cloud-native environment, event-driven architecture, migration to microservices, and so on

2. Architecture Principles and Guidelines

   • Criteria for technology selection, system design principles, guidelines for operational maintenance, etc.

3. Technology Stack Selection

   • Determining the foundation for development languages, databases, frameworks, etc.

4. System Scalability and Extensibility

   • Scalable configurations, load balancing, service decomposition strategy, etc.

5. Security and Compliance

   • Authentication/authorization, data encryption, compliance requirements (e.g., GDPR, SOC2)

6. Operations and Monitoring Strategy

   • Standardization of logging/monitoring, incident response processes, etc.

3. The Purpose and Benefits of an Architecture Strategy

Formulating an architecture strategy can yield the following benefits:

1. Unifying Business and Technical Directions

   • Avoids ad hoc technical decisions, allowing for long-term, strategic selections

2. Suppressing Technical Debt

   • Without planning, technical debt accumulates easily. A prior strategy can reduce such debt.

3. Increasing Development Speed and Productivity

   • With a clear set of guidelines, there is less need for extra discussion within the team, allowing smoother work progress

4. Improving System Quality and Stability

   • Addressing non-functional requirements (scalability, availability, security, etc.) upfront reduces failures and security risks

5. Aligning Team Decision-Making

   • Having shared goals and guidelines accelerates decision-making and helps the team move in a unified direction

A good architecture strategy eliminates various forms of waste in a project and supports efficient resource investment toward achieving business objectives.

4. Areas Where Architecture Strategy Is Needed

An architecture strategy can be formulated and applied at various scopes, from individual teams to the entire organization.

• Organization-Wide Level

  • Align with overall IT strategy, define common platforms and security policies
  • Create a long-term roadmap aiming for overall optimization

• Department Level

  • Tailor architecture to the business requirements unique to that department
  • Consider departmental system integrations and data sharing in formulating policies

• Team Level

  • Detailed architecture design for a particular service or application
  • Formulate a strategy for technology selection, implementation methods, testing policies, etc., closely related to daily work

Note that the broader the scope, the higher the cost of coordination and the difficulty of achieving consensus.

5. The Process of Formulating an Architecture Strategy

Formulating an architecture strategy involves clarifying “what business objectives will be achieved through what technical approaches, and how these will be operated and governed.”

Whether the architecture strategy should be set top-down, bottom-up, or through a hybrid approach depends on the specific case and the organization’s culture and business environment.

Below is one possible set of steps for formulating an architecture strategy.

1. Confirm Business Strategy and Vision

1. Understand Business Goals and Strategy

   • Grasp the business objectives and strategies set by top management or business units, and consider how the architecture can contribute to the business

2. Identify Stakeholders

   • Identify key stakeholders involved in the architecture strategy (management, development teams, business units, security teams, etc.) and organize their requirements, constraints, and expectations

2. Understand the Current Architecture (As-Is)

1. Investigate Existing Systems and Architecture

   • Document the system configuration, data flows, technologies used, operations processes, etc., in the target area

2. Extract Issues and Risks

   • Identify business/technical bottlenecks, cost structures, single points of failure, operational burdens, existing technical debt, and so on

3. Establish Architecture Principles and Direction

1. Set Architecture Principles

   • Define which architectural characteristics (non-functional requirements) you will prioritize
   • Clarify trade-offs (e.g., balancing flexibility and performance)

2. High-Level Direction and Priority Guidelines for the Roadmap

   • Decide where to start, which investments will yield the highest returns, etc.
   • Consider the priority of business requirements alongside technical feasibility

4. Define the Target State (To-Be)

1. Design the Architecture

   • From multiple viewpoints—such as Business Architecture (business flow, organizational structure), Application Architecture (structure of services/systems), and Technology Architecture (infrastructure/network configuration)—define the target state
   • Tools like the C4 model can be helpful

2. Consider Scenarios and Use Cases

   • Outline key business scenarios or use cases and validate them against the architecture
   • Also consider operational scenarios that include security and availability requirements

3. Architecture Evaluation and Selection (Comparing Options)

   • Often you will compare multiple architecture proposals, evaluating their pros and cons
   • Consider the technical stack (public cloud vendor selection, database types, programming language, etc.) and operating model (on-prem, cloud, hybrid, etc.)

5. Gap Analysis and Roadmap Creation

1. Gap Analysis of As-Is and To-Be

   • Identify gaps between the current state and the target architecture from technical, organizational, cost, skill, and other perspectives
   • Determine which gaps to address when and how, and prioritize them

2. Migration Strategy

   • Decide whether a large-scale overhaul is needed or if you can implement a phased microservices migration, how to handle legacy systems, etc.
   • Consider techniques to reduce risk in the early stages, such as the “Strangler Fig Pattern” or “Lift & Shift (Rehost).”

3. Roadmap Creation

   • Plan how and when architecture changes will be implemented, setting milestones for each phase
   • Outline deliverables, success indicators (KPI/KGI), resources, budgets, and organizational structures in each phase

6. Develop the Execution Plan

1. Clarify the Execution and Project Plans

   • Based on the roadmap, break down each initiative into projects and detail the schedule, resources, and organizational structure
   • Use project management tools (Jira, Confluence, etc.) to manage progress and risks

2. Communication and Consensus with the Organization

   • Present the strategy to stakeholders, get approval, and establish a cooperative framework

7. Continuous Evaluation and Feedback

1. Monitoring During the Implementation and Operations Phases

   • Do not merely follow the roadmap but regularly check indicators (KPI, monitoring results of non-functional requirements, etc.) to evaluate the situation
   • Introduce DevOps or CI/CD mechanisms to ensure smooth implementation, testing, and releases

2. Regular Architecture Reviews

   • Periodically review architecture in light of changing business environments and technology trends
   • Use governance forums (such as architecture review boards) to incorporate improvement proposals and update the roadmap

3. Organizational Learning and Sharing

   • Share success stories and failures to accumulate know-how on formulating and running architecture within the organization
   • Update practices and standards to apply lessons learned to the next project

6. Example: Architecture Strategy for an HR/Payroll SaaS

Here’s a simplified example of an architecture strategy for an imaginary “HR and Payroll SaaS.”

1. Technical Vision

“Provide strict access control for large-scale tenants while maintaining fast feature enhancements and operational efficiency.”

• Background
  • Usage by enterprises with complex organizational hierarchies is on the rise.
  • Features span multiple domains—time and attendance, payroll, year-end tax adjustments—requiring a comprehensive access control model.
  • A “common authorization management framework” is essential for easy extension, maintenance, and auditing.

2. Current State Analysis

1. Existing System

   • A “modular monolith” where each feature has its own authorization logic
   • Authorization definitions are scattered, making role setting and access control complicated for large-scale organizations

2. Issues and Challenges

   • Development Burden: Each new feature requires adding new permission flags or roles
   • Operational Risk: Role names and authorization requirements vary widely, complicating management and audits
   • Scalability: The current setup cannot adequately handle large-scale tenants with massive concurrent access

3. Architecture Principles

1. Cloud-Native Centered on GCP

   • Core infrastructure resources on GKE (Google Kubernetes Engine) or Cloud Run
   • Cloud Logging/Cloud Monitoring as the default for application logs/monitoring, possibly with Datadog as a supplement

2. A Dedicated “Authorization Service” Microservice

   • Separate authentication (Auth) from authorization (Authorization) and offer a shared Authorization API
   • Combine RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) to handle the complex hierarchies of large organizations

3. Thorough Infrastructure as Code and CI/CD

   • Use Terraform/Cloud Deployment Manager to manage infrastructure as code
   • Use Cloud Build or GitHub Actions + Cloud Run/GKE for automatic deployments

4. Standardize Operational and Audit Logs

   • Send all permission changes and access requests to Cloud Logging
   • Store audit data in BigQuery for easy reporting and analysis

4. Example of Technology Stack Selection

1. Authentication

   • Use Google Identity Platform or Auth0, leveraging OIDC/OAuth2 for SSO
   • Easily support connections to corporate/external IDs

2. Authorization

   • Deploy a custom Authorization service (written in Go or Python) on GKE or Cloud Run
   • Use Cloud SQL (PostgreSQL) to manage roles/policy definitions
   • Use Memorystore (Redis) for caching to handle fast lookups

3. Individual SaaS Modules

   • Attendance management, payroll, year-end tax adjustments, etc., each as containerized services referencing the Authorization service
   • For API Gateways: use Cloud Endpoints or Istio (service mesh) for traffic control and authorization flow

4. Monitoring and Log Collection

   • Cloud Logging/Cloud Monitoring as standard for all containers
   • Integrate error alerts and SLO/SLA management with Opsgenie or PagerDuty if needed

5. Roadmap (Example: 3 Phases)

1. Phase 1 (up to 3 months)

   • Design and PoC for the Authorization Framework
     • Determine data models for roles/policies
     • Separate Auth (authentication) from Authorization (authorization)
   • Build the CI/CD Pipeline
     • Validate automation with Cloud Build or GitHub Actions + Terraform

2. Phase 2 (up to 6 months)

   • Introduce the Authorization Service to Core Modules
     • Migrate existing roles in attendance management and user management first
     • Integrate partial on-prem systems (via VPN → VPC peering, etc.)
   • Set Up Audit Logs
     • Start storing change history and access logs in BigQuery; prototype reporting features

3. Phase 3 (up to 12 months)

   • Apply to All Modules
     • Gradually integrate the Authorization service into payroll, year-end tax adjustments, etc.
   • Load Testing for Large-Scale Tenants and Optimization
     • Test Redis caching, refine scaling policies, and move to production
   • Strengthen Governance for Long-Term Operation
     • Implement a UI for policy management and fully operationalize audit report auto-generation

7. Required Skills and Knowledge

When thinking about and implementing an architecture strategy, the following skills and knowledge are important:

1. Fundamentals of Software Design

   • Knowledge of basic design methodologies (clean architecture, microservices, monolith, etc.)
   • Familiarity with best practices like the SOLID principles and DDD

2. Ability to View the System Holistically

   • Understanding of architecture characteristics like scalability, security, performance, availability, and operations management
   • Ability to analyze trade-offs

3. Understanding of Business Requirements

   • Ability to explain why a particular architecture contributes to the business

4. Awareness of Technology Trends

   • Staying informed about the latest technologies and industry movements to broaden architectural options

5. Leadership and Communication

   • Skills in communicating, building consensus, and making decisions with teams and stakeholders

6. Understanding of Organizational Strategy

   • Comprehending how the architecture strategy ties into the overall business strategy, and formulating a strategy that aligns with organizational policies

8. Conclusion

This article introduced what an architecture strategy is, why it is necessary, how to formulate it, and concrete examples. Summarizing the main points:

1. Long-term View That Connects Business and Technology

   • This is more than just technology selection; it aligns with business objectives and provides a roadmap

2. Visualize Technical Debt and Trade-offs, and Build Consensus

   • Identify non-functional requirements and risks, involve multiple stakeholders, and find the best solution together

3. Ongoing Validation and Improvement

   • Because business environments and technology trends are constantly changing, regularly review and revise the architecture strategy

Clarifying your architecture strategy aligns the team’s direction and, in the long run, can significantly improve development efficiency, quality, and business momentum. Determine whether a strategy is needed for your product or organization, and adopt an approach that fits your situation.

9. References

Books

• Staff Engineer: Leadership beyond the management track
  
  (Japanese edition title: スタッフエンジニアの道 ―優れた技術専門職になるためのアーキテクティング)

  • Explains how software engineers can lead teams and organizations, including behaviors and techniques

• Fundamentals of Software Architecture: An Engineering Approach
  
  (Japanese edition: ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ)

  • Learn systematically about non-functional requirements and architectural decision-making

• Design It!: From Programmer to Software Architect
  
  (Japanese edition: Design It! ―プログラマーのためのアーキテクティング入門)

  • Acquire practical practices from an architect’s perspective

• Software Architect’s Handbook: Leadership, Technology, and Product Management
  
  (Japanese edition: ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用)

  • Detailed discussion on how architects make decisions and lead teams

• 97 Things Every Software Architect Should Know
  
  (Japanese edition: ソフトウェアアーキテクトが知るべき97のこと)

  • A collection of short chapters with experiences and insights from veteran architects

• Architect’s Textbook: Building Software Architecture That Delivers Value
  
  (Japanese title: アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築)

  • Provides a systematic understanding of an architect’s perspective and the required knowledge/skills

• Requirement-Optimal Architecture Strategy
  
  (Japanese title: 要件最適アーキテクチャ戦略)

  • Introduces how to strategically link requirements definition with architecture design

• Good Strategy Bad Strategy
  
  (Japanese edition: 良い戦略、悪い戦略)

  • Recommended for a deeper understanding of the concept of “strategy,” with examples of good and bad strategies

Organization/Team Topics

• Five Conversations That Transform Organizations
  
  (Japanese title: 組織を変える5つの対話)

  • Techniques and facilitation for driving organizational change

• An Invitation to Engineering Organization Theory
  
  (Japanese title: エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング)

  • Discusses building organizations and strategies for team growth in the face of uncertainty

• Team Topologies: Organizing Business and Technology Teams for Fast Flow
  
  (Japanese title: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計)

  • Explores how to optimize team structure and collaboration in software development organizations

• Dynamic Reteaming, Second Edition
  
  (Japanese title: ダイナミックリチーミング 第2版 ―5つのパターンによる効果的なチーム編成)

  • Introduces practical patterns on how to reconfigure teams

Blogs/Sites

• bmf-tech.com - Gathering Resources Related to System Design

  • Summaries of reference materials on system design and architecture

• jlhood.com - How to Set the Technical Direction for Your Team

  • Practical examples of how to set a technical direction at the team level

• sarahtaraporewalla.com - Defining a Tech Strategy

  • A concise introduction to key points in creating an architecture strategy

• leaddev.com - Technical strategy power chords

  • Focuses on the “core” of a technology strategy

• staffeng.com

  • Knowledge base and learning guides for staff engineers

• zenn.dev - How Are Architecture, Design, and Development Different?

  • Clearly explains the differences between architecture and design in a straightforward manner