Building long-term systems and fighting with technical debt.

1. We care about API cleanness.

  • We expose services to other teams through APIs on the Developer Portal. internal
  • We are following API Design Principles. Non compliant APIs should declared as a technical debt and modified.
  • Services do not provide a client library. The API and its data model are expressed as REST and JSON [?].

Practices & rituals:

30% rule
Each engineer may spend some part of his working time on R&D tasks, technical debt reduction or education. The percentage it is approximate number and should be determined by technical leader together with the product team.

2. We use modular architecture and avoid tight coupling between products.

  • Modules are isolated and loosely coupled.
  • Modules have single responsibility.
  • We can throw away existing, add on new or change sequence of modules execution safely without impact on other functionality.
  • We periodically review important architecture and technical debt issues.

Practices & rituals:

Architecture Committee

Enterprise & Solution architects meeting. Held by demand. Leader – CTO.

Main tasks:

  • solution architecture problem solving
  • escalation place for architecture gaps / technical debt grow
  • unblocking issues with technical debt
  • solution architecture consulting
High Cohesion
High cohesion is when you have a class (or module) that does a well defined job. Low cohesion is when a class does a lot of jobs that don’t have much in common. [source]
External Configuration
A changeable configuration of applications should be stored in the environment.
Orchestration / Choreography
Microservices pattern for building of sequenses of execution (SAGAs). Short explanation here. Detailed here.

3. We develop only economically sustainable products.

  • We avoid duplication of systems functionality.
  • Every system have single mantainer team.

Practices & rituals:

Revenue / Expenses Ratio
An estimated amount of money earned by product or feature divided on spends on it should be calculated before work run.
Keep It Stupid Simple. Like Occam said, «entities should not be multiplied without necessity». Adding new levels of abstraction must have a strong reason. Adding new data entities or solution components also must have strong reason. Simplification is a King and we welcome the approach to describe it as an architecture debt and rework the complex areas to make it simple.
Do Not Repeat Yorself. Differently said, we are not develop multilple systems/modules/microservices/components with the same purpose.