Продумывал ли архитектурные решения на проекте?

Архитектурные решения: роль BA в проекте

Да, я активно участвовал в архитектурных решениях. Может звучать как то что должны делать архитекторы, но в реальности BA играет критичную роль. Расскажу как и почему.

Роль BA в архитектурных решениях

BA не пишет код архитектуры, но BA знает требования лучше всех. Архитектура должна поддерживать эти требования.

Моя роль:

1. Raise вопросы которые влияют на архитектуру
2. Challenge предложенные решения
3. Обеспечить что архитектура поддерживает business требования
4. Документировать решения и их rationale

Пример 1: Microservices vs Monolith в marketplace

Ситуация: Проект рос. Tech lead предложил: split на microservices (freelancer service, project service, payment service и т.д.).

Мои вопросы как BA:

1. "Какие требования диктуют эту архитектуру?"

   • Он ответил: "Масштабируемость"
   • Я спросил: "А какие требования к scaling?" (месячный рост юзеров? пиковая нагрузка?)

2. "Какие trade-offs?"

   • Microservices сложнее для разработки
   • Нужны больше devops операций
   • Cross-service debugging сложнее

3. "Может ли monolith справиться с требованиями?"

   • Мы estimate: monolith справится с 100k юзеров
   • Наш 1-2 летний target: 50k юзеров
   • Вывод: microservices рано

Решение: Stay с monolith на 2 года. Планируем refactor на microservices когда достигнем 80k юзеров.

Результат:

• Faster development (вместо 10 человек нужно только 5)
• Simpler debugging
• Faster deployment
• Сэкономили 6 месяцев разработки

Техлид потом сказал: "Спасибо что questioned, мы бы over-engineered".

Пример 2: Database архитектура в fintech

Ситуация: Все платежные данные в PostgreSQL. Вопрос: нужна ли отдельная database для analytics?

Как я влиял на решение:

1. Задал вопросы о требованиях:

   • Какие analytics нам нужны?
   • Как often они запускаются?
   • Могут ли slow queries影响на production?
   • Когда insights нужны (real-time или daily OK)?

2. Предложил варианты:

   • Вариант 1: Все в one database. Риск: analytics queries slow down production
   • Вариант 2: Отдельная analytics database (replica). Overhead: ещё один database to maintain
   • Вариант 3: Hybrid. Production queries на main DB, analytics на read-only replica

3. Помог evaluate trade-offs:

   • Вариант 1: проще, но рискованно (финтех не может иметь slow payments)
   • Вариант 2: безопаснее, но больше затрат
   • Вариант 3: лучший balance

Решение: Вариант 3. Main PostgreSQL для payments, read-only replica для analytics и reporting.

Результат:

• Production payments никогда не slow
• Analytics работает без влияния на production
• Costs reasonable

Пример 3: Caching architecture в CRM

Ситуация: Получение списка контактов медленный (200ms). Нужен caching.

Архитектурные вопросы которые я задал:

1. "Как often данные меняются?" (раз в час? в минуту?)
2. "Есть ли requirements для freshness данных?" (может быть 5 минут delayed?)
3. "Какие failure scenarios?" (если cache down, что happens?)
4. "Сколько нужно cache?" (все контакты или только часто accessed?)

Варианты которые мы рассматривали:

• Redis cache (быстро, но need to maintain)
• Database query optimization (maybe достаточно)
• In-memory cache (просто, но не scalable)

Решение: Databasequery optimization первым. Если не достаточно, то Redis для frequently accessed contacts.

Результат: Query optimization alone сократил время с 200ms до 50ms. Redis не нужен.

Сэкономили разработку и operational complexity.

Пример 4: API versioning в marketplace

Ситуация: Есть 1000 мобильных клиентов. Нужно change API. Как handle backward compatibility?

Мои требования которые влияют на архитектуру:

1. "Старые версии приложения still должны работать" (может быть 3 месяца graceful degradation)
2. "Не want двух version APIs at same time" (сложно поддерживать)
3. "Обновления приложения должны быть обязательны" (force update)

Архитектурные варианты:

• Вариант 1: URL versioning (api/v1, api/v2) - support both
• Вариант 2: Feature flags (one API, but feature flags для different behavior)
• Вариант 3: Deprecation gradual. Old API returns deprecated warning, force update

Решение: Вариант 3. Мы deprecate старый API, даём 3 месяца на transition, потом force update.

Результат:

• Одна версия API to maintain
• Smooth transition для users
• Clear timeline

Пример 5: Data pipeline для analytics

Ситуация: Нужна system которая transfers данные от production DB в analytics warehouse.

Мои требования:

1. "Какой latency для reports нужен?" (real-time? overnight batch OK?)
2. "Что если pipeline fails?" (reports delayed на 6 часов OK?)
3. "Какой объем данных?" (100GB? 1TB? важно для technology choice)
4. "Какой retention?" (храним 2 года? 5 лет?)

Варианты архитектуры:

• Вариант 1: Real-time streaming (Kafka + expensive infrastructure)
• Вариант 2: Batch ETL (Airflow, simple but delayed reports)
• Вариант 3: Hybrid (real-time for critical data, batch for rest)

Решение: Вариант 2. Overnight batch достаточно для наших reports.

Результат:

• Simple setup
• Cost effective
• Reports ready каждое утро

Как я влияю на архитектурные решения

1. Во время planning:

• Я list все требования которые impact архитектуру
• Tech lead propose варианты
• Я challenge их: "А это really нужно?" "Есть ли simpler solution?"

2. Во время design:

• Я present бизнес требования которые техлид может забыть
• Я remind про constraints (budget, timeline, team size)
• Я help evaluate trade-offs (complex but powerful vs simple but limited)

3. Во время implementation:

• Я ensure что implemented architecture соответствует принятым решениям
• Я monitor: что если архитектура не supporting требования?

4. Документирование:

• Я document почему выбрали эту архитектуру
• Я document trade-offs
• Я document когда нужно refactor

Key principle: Requirements drive architecture

Не должна архитектура быть "красивой" для архитектора. Она должна быть правильной для business.

Если requirement: "максимум 100k юзеров", не need microservices architecture. Если requirement: "payments never slow", need separate analytics database. Если requirement: "batch reports OK", not need real-time streaming.

Вывод

БА не architect, но BA must understand и influence архитектурные решения. BA knows requirements better than anyone. Архитектура должна serve requirements, не наоборот.

Мой contribution: ensuring что technical decisions aligned with business goals и constraints.