Архітектура додатка — термін, що часто використовують в розробці. Всеосяжний, багатозначний і, на перший погляд, складний. Спробуємо подивитися на нього з точки зору не-розробника та відповісти на часті питання.
1. Ключова складова поняття архітектури програмного забезпечення (ПЗ).
Заведено вважати, що архітектура ПЗ — це набір технічних рішень з організації програмного продукту. Дуже часто, коли команда говорить про архітектуру, ви чуєте слова: monolithic, microservices, вибір frameworks. Але це тільки технічні слова, а не архітектура в цілому.
Насправді весь набір технічних рішень є прямим наслідком Business Architecture та Information Architecture. Business Architecture відповідає на питання “що ми отримаємо в результаті роботи” та “які проблеми необхідно вирішити” протягом роботи над продуктом. Інакше кажучи, ми окреслюємо коло задач, що буде вирішувати майбутня система. Результат Information Architecture — опис доменів сутностей системи та їх взаємодія на основі описаної до цього концепції.
Формування архітектурних рішень стартує зі збору вимог та опису бізнес сутностей. У цьому процесі якісно зібрані вимоги та описані сутності та їх взаємодія — основа для прийняття оптимальних технічних рішень. Ще одна корисність Business Architecture та Information Architecture — у вас завжди під рукою аргументи для вирішення спірних ситуацій з клієнтом на тему “чому це не врахували раніше при формуванні архітектури додатка”
2. Архітектурні рішення приймаються в ході виконання задачі.
Архітектура ПЗ умовно розділяється на рівні: high та low.
High level architecture описує структуру системи, способи взаємодії, розгортання складових. Приймають такі рішення на старті проєкту та ситуативно в ході еволюції проєкту. Low level — це той самий дизайн коду або наскільки якісно програміст пише код. Є об’єктивний мінімум оцінки якості коду — принцип SOLID.
Необхідність в контролі low level architecture очевидна — мінімізація рефакторингу та стабілізування швидкості розробки. Контролюючи це все за допомогою практики соde review та аналізаторів коду. Особливо важливо слідкувати за low level architecture на старті проєкту та у фазі active development. Це закладе хороший фундамент для масштабування розробки в майбутньому.
3. Зміна архітектурного рішення.
Болюче питання часто зустрічається протягом життєвого циклу продукту: “Як відрізнити необхідність змін від технічного перфекціонізму розробників?”
Перша ознака необхідності роботи з архітектурою — зниження швидкості розробки при постійному складі команди. Так, можливо програмісти стомилися, але якщо це не так — це перший дзвіночок звернути увагу на якість архітектурних рішень.
Індикатор номер 2, характерний для legacy проєктів. Він полягає у спробах збільшити швидкість розробки шляхом збільшення команди. На практиці швидкість розробки залишається такою самою або навіть знижується. Це викликає багато нерозуміння зі сторони замовника. Насправді причина очевидна — прийшов час вкладати сили та засоби в перепроєктування системи.
4. Що робити і з чого почати?
Якщо ви перейнялися побажаннями від команди змінити архітектуру, то у вас виникає питання “як це робити?”. Почати треба з аналізу якості коду — тобто з low level architecture, тому що цей захід не такий дорогий як зміна high level рішень. Для початку додайте у ваш командний DoD (definition of done) практику соde review та використання аналізаторів коду. Потім складіть з командою план рефакторингу, по якому можна буде поступово поліпшувати архітектуру.
Не допомагає? Тоді необхідно переходити до дороговартісних змін high-level рішень. Тут необхідно залучити solution architect для розробки концептів, планів, термінів та аргументації, затвердити це все з менеджментом. І поступово починаємо міграцію high level рішень. Наприклад, з monolithic на SOA. При тому, треба пам’ятати: з точки зору еволюції продукту, зміна архітектурних рішень – це нормальні процеси, які варто розуміти та аргументувати їх необхідність клієнту та менеджменту. Бо час йде, задачі продукту змінюються, тому логічно, що й інструменти їх досягнення будуть іншими.
Радимо вам наш технічний словник бізнес-аналітика, для того, щоб найголовніша інформація завжди була під рукою.
Більш детально про архітектуру додатку й інших технічних навичок для РМ і ВА ми будемо розмовляти на нашому курсі Technical skills for Project Managers and Business Analysts.
