ITRampage

Вже котрий раз стикаюся з дивним намаганням вивернути/реверсивно використати закон Конвея в розробці інформаційний систем.

Чому я вважаю таке намагання дивним? Та тому, що закон Конвея постулює, що структура інформаційний рішень є відображенням організаційної структури. Маємо причину – структуру і маємо наслідок – розроблене рішення. Причину та наслідок не можна просто поміняти місцями. Це подібно дурним порадам декотрих тренерів т.з. саморозвитку стосовно того, що аби стати багатим – достатньо почати витрачати гроші, як це роблять багаті. Крім того, відображення організаційної структури в структурі інформаційної системи є власне бажаним результатом з точки зору Single Responsibility Principle, оскільки:

However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.

Robert C. Martin – The Single Responsibility Principle

Типовий приклад. У бізнеса є проблема з існуючим рішенням. Вони не задоволені швидкістю розробки та якістю результату і тому вирішують застосувати т.з. мікросервісну архітектуру для того, аби перейти до розробки малими автономними командами, які між собою (майже) ніяк не взаємодіють, що має пришвидчити ефективність праці та впровадження змін.

Наспавді ж, те, що код, інфраструктора й організація роботи ІТ – лайно, свідчить про те, що в компанії взагалі погано усе реалізовано. Якщо ми ігноруємо це і оптимізуємо лише ІТ, то це типова помилка локальної оптимізації, яка в найкращому випадку дозволить лише незначно позитивно вплинути на бізнес в цілому. Найбільш ймовірний варіант – це те, що компанія витратить купу грошей та часу на створення додаткової складності, яка лише погіршить ситуацію.

Неможливо виправити компанію через виправлення роботи деякого одного обслуговуючого департаменту як неможливо вилікувати хворий організм, через пересадку якогось одного органу, коли проблема полягає у певному стилі життя.

Повернемося до архітектури т.з. мікросервісів. Спробуємо змоделювати розвиток ситуації. Ітак, в нас залишаються департаменти без саморефлексії та орієнтованості на покращення результатів, формалізації, цифровізації та автоматизації і з поганою взаємодією/синхронізацією з іншими департаментами. Натомість ми маємо багато маленьких команд, кожна з яких відповідає за свій маленький сервіс. У такому випадку жодна команда не відповідає повністю за реалізацію деякої нової функціональності й майже ніколи не може самостійно вирішити деяку проблему чи реалізувати нову бізнесову вимогу.

Для вирішення цієї штучно створеної проблеми необхідний новий рівень – технічні менеджери / архітектори, які б проєктували саме реалізацію нової функціональності, розкидали завдання по різним командам та синхронізовували їх роботу. Це виглядає як збільшення штату працівників, збільшення кількості коммунікацій, посилення ефекту “зламаного телефону” та, як результат, ще більше повільної та менш якісної розробки нової функціональності.

При усьому цьому, якість вимог та їх ефект на бізнес вцілому залишаються вкрай поганими. Маємо типову ситуацію “сміття на вході – сміття на виході” і жодні мікосервіси не здатні цього виріши, а скоріше, навпаки, тільки погіршать ситуацію, зробивши розробку, розгортання, підтримку, моніторинг, хостинг в рази складнішими, повільнішими, дорожчими.

Іншою проблемою є сліпе слідування Domain Driven Design, а саме мантрі про те, що необхідно уважно прислуховуватися до думки експертів у предметній області. З експертами дійсно необхідно багато консультуватися, але не треба виконувати їх забаганки, а треба вивчати їх поведінку, знаходити у їх роботі помилки та виправляти усе це. Із власного досвіду можу сказати, що якби я робив усе так, як того бажали замовники, то отримані рішення були б жахливими. Натомість я намагаюся зрозуміти як відбувається робота того чи іншого департаменту, чи підрозділу, чи ролі та виправити у першу чергу сам підхід до роботи, вже потім цифровізувати та автоматизувати його.

У будь-якій сфері діяльності 98% людей дупля не ріжуть у тому, що вони роблять. Вони імітують діяльність, а не досягають результатів. Що може вийти з того, що розробники почнуть виконувати усі їх забаганки? – Тільки сміття! У цьому не можуть допомогти ні мікросервіси, ні DDD.

Інженери мають вирішувати проблеми, а не програмувати. Інженери мають бути найвпливовішими людьми у компанії. Якщо вивчити історію, то найкращими (найефективнішими) менеджерами завжди були саме чудові інженери.