Skip to content

Purpose of Certification

29.1.1. Quality Assurance

The first purpose of TQS certification is to officially verify and assure the quality of technical assets developed and operated within the TIENIPIA ecosystem. Quality assurance is performed along four axes: code, architecture, testing, and security.

29.1.1.1. Code Quality Verification

TQS certification directly verifies quality at the source code level. This is the core differentiator that distinguishes TQS from existing process-centric certification systems.

  • Formatter application verification: Confirms that formatters specified by the standard, such as Google Java Format and Prettier, are actually applied. Code without formatter application must result in build failure in the CI pipeline.
  • Naming rule compliance: Verifies that the naming of classes, methods, variables, and packages follows the TQS standard's naming conventions.
  • Code structure standardization: Confirms that package structures, directory structures, and component designs conform to the standard.

Code quality verification ensures "consistent quality code regardless of who writes it." This serves as the foundation for improving code review efficiency, reducing handover costs, and securing long-term maintainability.

29.1.1.2. Architecture Verification

Verifies whether the project's technical architecture is appropriate in terms of scalability, maintainability, and security.

  • Confirms that the layered structure (Controller - Service - Repository) is properly separated.
  • Verifies that dependency direction is maintained as unidirectional.
  • Confirms that configuration management is separated by environment.
  • Verifies that cross-cutting concerns (logging, exception handling, authentication) are properly modularized.

29.1.1.3. Test Verification

Verifies the existence and quality of automated tests. Since code without tests cannot have its quality assured, testing is a mandatory item in TQS certification.

  • Line coverage of 80% or above and branch coverage of 70% or above must be satisfied.
  • Confirms that tests are structurally written following the Given-When-Then pattern.
  • Verifies that tests are automatically executed in the CI pipeline.

29.1.1.4. Security Verification

Security is a core component of quality. TQS certification verifies the actual implementation of security requirements at the code level.

  • Confirms that data encryption (At-Rest, In-Transit) is applied.
  • Verifies that input validation (Bean Validation, XSS defense, SQL Injection defense) is implemented.
  • Confirms that authentication and authorization control (RBAC) is properly applied.
  • Verifies that dependency security scanning (OWASP Dependency-Check) is integrated into CI.

29.1.2. Standardization

The second purpose of TQS certification is to establish consistent technology stacks and coding conventions across teams. Standardization enhances development productivity, facilitates cross-team collaboration, and proactively prevents technical debt accumulation.

29.1.2.1. Technology Stack Standardization

The TQS standard clearly defines the technology stacks to be used in each domain: backend, frontend, and infrastructure.

DomainStandard TechnologyPurpose
Backend RuntimeJava 21Unified on the latest LTS version
Backend FrameworkSpring Boot 3.xEnterprise-grade standard framework
Data AccessjOOQUnified on type-safe SQL builder
Frontend FrameworkVue 3 (Composition API)Unified reactive UI framework
State ManagementPiniaVue ecosystem standard state management
Build ToolsMaven (backend), Vite (frontend)Unified build environment

When the technology stack is standardized, developers can work in the same technology environment even when moving to different projects. This reduces learning costs, increases code reusability across projects, and streamlines the internal technical support system.

29.1.2.2. Coding Convention Standardization

Coding convention standardization ensures a consistent code style that does not depend on individual preferences or habits.

  • Formatter settings are included in the project to be automatically applied.
  • Linter (ESLint) settings enforce code quality rules.
  • Commit message format (Conventional Commits) is unified.
  • PR templates are standardized to ensure consistency in code reviews.

When coding conventions are standardized, style-related debates disappear from code reviews, and reviewers can focus on logic and design. This improves the quality of code reviews and reduces review turnaround time.


29.1.3. Interoperability

The third purpose of TQS certification is to ensure technical compatibility among internal solutions. Even though TIENIPIA's services are developed independently, seamless interoperation must be ensured.

29.1.3.1. API Compatibility

The TQS standard defines API design standards to ensure consistency in inter-service communication.

  • All APIs follow RESTful conventions. URL naming, HTTP method usage, and status code return rules are unified.
  • Error response formats are standardized so that clients can handle errors from any service in the same manner.
  • Date/time formats use ISO 8601 to prevent timezone-related errors.

29.1.3.2. Data Compatibility

Formats and rules must be unified when exchanging data between services.

  • Database design rules (table naming, column types) are standardized.
  • Migration tools (Flyway) are unified to consolidate schema management methods.
  • Serialization formats (JSON) and date/number formats are defined by the standard.

29.1.3.3. Infrastructure Compatibility

TQS-Infra standards ensure compatibility of infrastructure environments.

  • Deployment environment configurations (local, dev, staging, prod) are standardized.
  • Logging formats and monitoring metrics are unified, enabling shared operational tooling.
  • Network communication specifications (TLS versions, protocols) are unified.

When interoperability is secured, the cost of integrating new services into existing infrastructure decreases, and failure propagation between services can be predicted and prevented.


29.1.4. Technical Debt Management

The fourth purpose of TQS certification is to prevent the accumulation of technical debt through systematic criteria. Technical debt increases at a compound rate over time, and if left unattended, it severely impairs system stability and development productivity.

29.1.4.1. Technical Debt Prevention

The TQS standard serves as a defensive line that blocks technical debt before it occurs.

  • Code quality standards: Formatters, linters, and naming rules are enforced to prevent the introduction of low-quality code.
  • Test coverage standards: Minimum coverage thresholds are set to block the deployment of untested code.
  • Dependency management: The use of dependencies with security vulnerabilities is prohibited, and periodic updates are mandated.
  • CI/CD automation: Human errors from manual builds/deployments are prevented.

29.1.4.2. Resolution of Existing Technical Debt

The process of preparing for TQS certification itself becomes an opportunity to resolve existing technical debt.

  • Technical debt items are systematically identified through self-assessment checklists.
  • Tasks such as applying formatters, writing tests, and supplementing security configurations are performed to meet certification criteria.
  • The re-accumulation of technical debt is inspected at each certification renewal cycle.

29.1.5. Business Value

The fifth purpose of TQS certification is to create tangible business value through improved technical quality. Technical quality has a direct impact on cost reduction, customer trust, and organizational efficiency.

29.1.5.1. Enhanced Customer Trust

Products bearing the TQS Mark signify that technical quality has been officially verified. This provides customers with the following assurances.

  • The product is assured to have security verified at the code level.
  • The product is assured to have a certain level of test coverage and stability.
  • The product is assured to be operated under a systematic quality management process.

29.1.5.2. Maintenance Cost Reduction

Standardized code and architecture directly reduce maintenance costs.

  • Consistent code style shortens the time required to understand code.
  • High test coverage enables rapid detection of side effects during changes.
  • A standardized technology stack reduces the learning costs required for bug fixes and feature additions.

29.1.5.3. Handover Efficiency

Projects that have obtained TQS certification facilitate easy handover.

  • Standardized project structures allow new assignees to quickly understand the codebase.
  • API documentation (SpringDoc/Swagger UI) is included as a mandatory requirement, enhancing service comprehension.
  • Configuration management rules (Conventional Commits, PR templates) are applied, making change history easy to trace.
  • The same technology stack is used, allowing personnel to be deployed to work without a technology adaptation period.

Reduced handover costs increase the organization's workforce flexibility and ensure project continuity.

TIENIPIA QUALIFIED STANDARD