DEV Community

Cover image for Considering Architecture Strategy
Kenta Takeuchi
Kenta Takeuchi

Posted on • Originally published at bmf-tech.com

Considering Architecture Strategy

#architecture #organizationaldesign #design #systemdesign

This article was originally published on bmf-tech.com.

Considering Architecture Strategy

In software development, even if you are not in a clear position like CTO or architect, there are opportunities to feel the "necessity of architecture strategy" and think about it.

  • "I want to consolidate technical policies on-site, but I don't know where to start."
  • "I want an architecture that considers future scalability and organizational growth."
  • "I want to know how to deal with the technical debt that has already accumulated."

This article organizes the necessity and utilization methods of architecture strategy to answer such questions.

Background and Disclaimer

There are times when I wonder, "What strategy is this plan being executed under?" or "What is strategy in the first place?"

At such times, abstract thoughts swirl in my head, but since I couldn't properly verbalize them, I decided to organize my thoughts and study on my own to summarize the content.

Since I have no experience as a CTO or architect, and little practical experience in thinking about architecture strategies, it may just be a figment of my imagination.

So, if there is anything clearly wrong, I would be happy if you could let me know quietly.

1. Introduction

Before talking about architecture strategy, let's first organize the words "architecture" and "strategy." These are concepts often used in the field of software development, but they are surprisingly ambiguous and can be perceived differently by different people.

This article will outline the following flow.

  • What is architecture strategy?
  • Why is it necessary, and what are the benefits?
  • How should it be formulated (process and specific examples)?
  • Necessary skills, points to note, reference materials

2. What is Architecture Strategy?

2.1 What is Architecture?

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

  1. System Structure
  2. Components that make up the system (e.g., microservices, databases, API gateways, etc.)
  3. Interrelationships between components (data flow, communication methods, etc.)
  4. Design Principles and Patterns
  5. Design methods such as layered architecture, clean architecture, microservices, DDD, etc.
  6. Best practices like SOLID principles, CQRS, Event Sourcing
  7. Consideration of Non-functional Requirements
  8. Scalability, availability, security, performance, maintainability, and extensibility
  9. Technology Selection
  10. Selection of languages, frameworks, databases, cloud providers, etc.
  11. API design (REST, GraphQL, gRPC, etc.)
  12. Development and Operation Processes
  13. CI/CD pipeline design, monitoring/logging, team development flow (agile or waterfall)

These elements are examples and are not exhaustive.

Architecture is a higher-level concept than design, indicating the "framework of the system" or "design policy." Based on that guideline, the stage of concretizing individual modules, classes, data models, etc., is "design."

2.2 What is Strategy?

Strategy refers to the major direction or plan to achieve goals. While tactics indicate "individual specific means" or "measures," strategy defines the direction of the entire organization or project from a more long-term and comprehensive perspective.

According to Good Strategy, Bad Strategy, the quality of a strategy is described as follows:

  • Key Points of a Good Strategy
    • There are specific action guidelines, and what to do is clear
    • Appropriate selection and focus are possible, and "what to do" and "what not to do" are clear
    • Consists of three elements: diagnosis (current situation analysis) → basic policy → action
  • Characteristics of a Bad Strategy
    • Hollow and lacks specificity
    • Avoids facing major problems head-on and evades issues
    • Simply sets goals without clear methods to achieve them

2.3 Definition of Architecture Strategy

Combining these concepts of "architecture" and "strategy" results in architecture strategy. It can be defined as "a policy or plan to systematically indicate how to build and evolve systems within an organization or project."

Specifically, it includes elements such as:

  1. Clarification of Vision and Goals
  2. Aligning with business strategy while indicating technical direction
  3. Examples: adopting cloud-native, event-driven architecture, transitioning to microservices, etc.
  4. Architecture Principles and Guidelines
  5. Criteria for technology selection, principles of system design, standardization guidelines for operation and maintenance
  6. Technology Stack Selection
  7. Establishing criteria for adopting development languages, DB, frameworks, etc.
  8. System Scalability and Extensibility
  9. Scalable configuration, load balancing, service division strategy
  10. Security and Compliance
  11. Authentication/authorization, data encryption, compliance (e.g., GDPR, SOC2)
  12. Operation and Monitoring Strategy
  13. Standardization of logging/monitoring and incident response processes

3. Purpose and Benefits of Architecture Strategy

Formulating an architecture strategy provides the following benefits:

  1. Unification of Business and Technical Direction
  2. Technical decision-making is not ad-hoc and can be chosen strategically and long-term
  3. Suppression of Technical Debt
  4. Without planning, technical debt tends to accumulate. Pre-strategy can reduce debt
  5. Improvement of Development Speed and Productivity
  6. With clear guidelines, unnecessary discussions within the team are reduced, allowing smooth progress
  7. Improvement of System Quality and Stability
  8. By consciously addressing non-functional requirements (scalability, availability, security, etc.), risks of failures and security issues can be reduced
  9. Team Consensus
  10. With common goals and policies, decision-making is faster, and the team can align more easily

A good architecture strategy eliminates all waste in the project and supports efficient resource allocation towards achieving business goals.

4. Areas Requiring Architecture Strategy

Architecture strategy can be formulated and applied at various scopes, from team units to the entire organization.

  • Organization-wide Level
    • Align with company-wide IT strategy and define common infrastructure and security policies
    • Formulate a long-term roadmap aiming for overall optimization
  • Department Level
    • Optimize according to department-specific business requirements
    • Decide policies considering system integration and data sharing within the department
  • Team Level
    • Detailed architecture design for a specific service or application
    • Formulate strategies directly related to practice, such as technology selection, implementation methods, and testing policies

As the scope expands, the cost of coordination and the difficulty of consensus building increase.

5. Process of Formulating Architecture Strategy

The formulation of an architecture strategy is a process to clarify "what business objectives to achieve, with what technical approach, and how to operate and govern."

Whether the architecture strategy should be formulated top-down, bottom-up, or hybrid depends on the case and varies according to the organization's culture and business situation.

Below are example steps in the process of formulating an architecture strategy.

1. Confirmation of Business Strategy and Vision

  1. Understanding Business Goals and Strategy

  2. Understand the business goals and strategies set by management and business divisions, and consider how architecture contributes to the business

  3. Identification of Stakeholders

  4. Identify key stakeholders involved in the architecture strategy (management, development departments, business divisions, security personnel, etc.) and organize their requirements, constraints, and expectations

2. Understanding the Current Architecture (As-Is)

  1. Investigation of Current Systems and Architecture

  2. Investigate and document the system configuration, data flow, technologies used, and operation processes in the target area

  3. Extraction of Issues and Risks

  4. Identify business and technical bottlenecks, cost structures, personalization, operational load, technical debt, etc.

3. Formulation of Architecture Principles and Direction

  1. Setting Architecture Principles
  2. Define which architecture characteristics (non-functional requirements) to prioritize

  3. Clarify trade-offs (e.g., balance between flexibility and performance)

  4. Policy for General Direction and Prioritization of the Roadmap

  5. Determine which areas to address first, where the return on investment is high, etc., and draw a high-level direction

  6. Consider the priority of business requirements and technical feasibility

4. Definition of the Target State (To-Be)

  1. Architecture Design

  2. Define the target state from perspectives such as business architecture (business flow, organizational structure), application architecture (structure of services and systems), and technology architecture (infrastructure and network configuration)

    • It is beneficial to use tools like the C4 model

  3. Consideration of Scenarios and Use Cases

  4. Materialize major scenarios and use cases expected in business and verify if they align with the architecture

  5. Consider operational scenarios incorporating security and availability requirements

  6. Architecture Evaluation and Selection (Option Comparison)

  7. Often compare multiple architecture proposals and evaluate their pros and cons

  8. Consider technical stacks (selection of public cloud vendors, types of databases, development languages, etc.) and operational models (on-premises/cloud/hybrid, etc.)

5. Gap Analysis and Roadmap Creation

  1. Gap Analysis between As-Is and To-Be
  2. Identify differences between the current state and target architecture in terms of technology, organization, cost, skills, etc.

  3. Consider when and how to resolve each gap and prioritize

  4. Formulation of Migration Strategy

  5. Design migration patterns, such as whether a large-scale overhaul is necessary, whether to transition gradually to microservices, or how to handle legacy systems

  6. Consider methods to reduce initial risks, such as the "Strangler Pattern" or "Lift & Shift"

  7. Creation of Roadmap

  8. Set milestones for when and how to proceed with architecture changes

  9. Roughly plan deliverables, success indicators (KPI/KGI), required resources, budget, and structure for each phase

6. Preparation of Execution Plan

  1. Clarification of Execution Plan and Project Plan
  2. Break down each measure into project units based on the roadmap and detail the schedule, resources, and structure

  3. Use project management tools (Jira, Confluence, etc.) to manage progress and risks

  4. Awareness and Consensus Building within the Organization

  5. Present the strategy content to stakeholders, obtain approval, and build a cooperative system

7. Continuous Evaluation and Feedback

  1. Monitoring during Implementation and Operation Phases
  2. Not only proceed according to the roadmap but also regularly check indicators (KPI and non-functional requirement monitoring results, etc.) and evaluate the situation

  3. Introduce mechanisms such as DevOps and CI/CD to ensure smooth implementation, testing, and release of technical changes

  4. Regular Review of Architecture

  5. Regularly review the architecture in line with changes in the business environment and technology trends

  6. Incorporate improvement proposals at governance meetings (such as architecture review meetings) and update the roadmap

  7. Organizational Learning and Deployment

  8. Share success and failure cases and accumulate know-how on architecture formulation and operation within the organization

  9. Update practices and standards and apply them to the next project

6. Example: Architecture Strategy in HR and Labor SaaS

Here, we present a partial example of an architecture strategy assuming "HR and Labor SaaS" as a simple sample.

1. Technical Vision

"Achieve strict permission management for large-scale tenants while balancing rapid feature expansion and operational efficiency."

  • Background
    • Increasing use by tenants with complex organizational hierarchies, such as large enterprises.
    • A permission model that spans multiple functions, such as attendance management, payroll, and year-end adjustments, is necessary.
    • A "common permission management platform" that is easy to expand and maintain and can handle audits is essential.

2. Current Analysis

  1. Existing System
  2. "Modular Monolith" structure where each function implements its own permission logic.

  3. Permission definitions are scattered, making role settings and access control for large organizations complicated.

  4. Problems and Challenges

  5. Development Load: Need to add permission flags and roles every time a new feature is added.

  6. Operational Risk: Role names and permission requirements are inconsistent, making management and auditing difficult.

  7. Scalability: Unable to handle large-scale tenants with many users accessing simultaneously.

3. Architecture Principles

  1. Cloud-Native Centered on GCP
  2. Utilize GKE (Google Kubernetes Engine) and Cloud Run for foundational resources.

  3. Use Cloud Logging/Cloud Monitoring as the basis for application logging/monitoring, while also using Datadog as needed.

  4. Single "Permission Service" Microservice

  5. Separate authentication (Auth) and authorization, and make the authorization platform a common API.

  6. Combine RBAC (Role-Based Access Control) + ABAC (Attribute-Based) to accommodate complex hierarchies of large enterprises.

  7. Thorough Infrastructure as Code and CI/CD

  8. Manage infrastructure with Terraform/Cloud Deployment Manager.

  9. Improve operational efficiency with Cloud Build or GitHub Actions + Cloud Run/GKE auto-deployment.

  10. Standardization of Operational and Audit Logs

  11. Aggregate all permission changes and access requests in Cloud Logging.

  12. Accumulate audit data in BigQuery to facilitate reporting and analysis.

4. Example of Technology Stack Selection

  1. Authentication
  2. Use Google Identity Platform or Auth0 to achieve SSO with OIDC/OAuth2.

  3. Configuration that easily supports internal/external ID integration.

  4. Permission Management (Authorization)

  5. Custom Permission Service (based on Go or Python) running on GKE or Cloud Run.

  6. Manage role/policy definitions with Cloud SQL (PostgreSQL).

  7. Use Memorystore (Redis) for caching for fast reference.

  8. Each SaaS Module

  9. Containerize function services such as attendance management, payroll, and year-end adjustments, and refer to the permission service.

  10. API Gateway: Integrate traffic control and authorization flow with Cloud Endpoints or Istio (Service Mesh).

  11. Monitoring and Log Collection

  12. Cloud Logging/Cloud Monitoring is standard for all containers.

  13. Error alerts and SLO/SLA management may also be linked to Opsgenie/PagerDuty.

5. Roadmap (Example: 3 Phases)

  1. Phase 1 (up to 3 months)
  2. Design and PoC of Permission Platform
    • Formulate data model for role/policy definition
    • Separate Auth (authentication) and Authorization (authorization) services

  3. Build CI/CD Pipeline

    • Demonstrate auto-deployment with Cloud Build or GitHub Actions + Terraform integration

  4. Phase 2 (up to 6 months)

  5. Introduction of Permission Service to Major Modules

    • Migrate existing roles starting with attendance management and user management
    • Integrate some remaining on-premises systems (integrate with VPN connection → VPC peering, etc.)

  6. Prepare Audit Logs

    • Accumulate change history and access history in BigQuery and prototype reporting functions

  7. Phase 3 (up to 12 months)

  8. Application to All Modules

    • Gradually transition microservices such as payroll and year-end adjustments to the permission service

  9. Load Testing and Optimization for Large-Scale Tenants

    • Verify Redis cache and scaling policies and deploy them into operation

  10. Strengthen Governance for Long-Term Operation

    • Fully operate policy management UI and automatic generation of audit reports

7. Skills and Knowledge Required for Consideration

The following skills and knowledge are important when considering and executing an architecture strategy.

  1. Basics of Software Design
  2. Basic design methods such as clean architecture, microservices, monoliths

  3. Best practices like SOLID principles and DDD

  4. Perspective to Overlook the Entire System

  5. Understanding of architecture characteristics such as scalability, security, performance, availability, and operational management, and the ability to analyze trade-offs

  6. Understanding of Business Requirements

  7. Ability to explain why the architecture contributes to the business

  8. Grasp of Technology Trends

  9. Ability to follow the latest technologies and industry trends to broaden architecture options

  10. Leadership and Communication

  11. Skills in communication, consensus building, and decision-making with teams and stakeholders

  12. Understanding of Organizational Strategy

  13. Ability to understand how architecture strategy connects to business strategy and formulate strategies aligned with organizational policies

8. Conclusion

This article introduced what architecture strategy is, its necessity, the formulation process, and specific examples. The key points can be summarized into the following three:

  1. Long-term Perspective Connecting Business and Technology
  2. Not just technology selection, but showing policies and roadmaps linked to business goals
  3. Visualizing Technical Debt and Trade-offs and Building Consensus
  4. Identifying non-functional requirements and risks, involving multiple stakeholders to find the optimal solution
  5. Continuous Verification and Improvement
  6. Since the business environment and technology trends are constantly changing, regularly review the architecture strategy

By clarifying the architecture strategy, the team's direction aligns, and in the long term, development efficiency, quality, and business promotion power are expected to improve significantly. It is important to judge whether a strategy is necessary according to the situation of your product or organization and adopt an appropriate approach.

9. References

Books

Organization and Team Related

Blogs and Sites

Top comments (0)