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

Про ІТ Архітектуру та Дизайн

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

Дуже часто архітектуру в ІТ вважають досить абстрактним поняттям для кінцевого користувача або замовника. Давайте поглянемо, як це бачить клієнт. Як клієнт я хотів би автоматизувати або оцифрувати деякі можливості свого бізнесу. Отже, мені потрібен новий ІТ-продукт, який повинен бути розроблений і працювати. Я усвідомлюю, що не можу продумати всі аспекти. Я просто маю ідею і мене цікавить:

• Чи можна реалізувати мій проект?

• Коли?

• Якими будуть витрати на його реалізацію?

З першого дня проекту варто звернутися до архітектора. Архітектор зробить наступне:

1. Поговорить із клієнтом, з’ясує, який продукт потрібен, з якою метою.

2. Побудує концепцію рішення, представить її замовнику, зробить оцінку витрат (на рівні архітектури)

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

4. Розробить дизайн рішення.

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

Гнучка “Agile” архітектура - це сукупність цінностей, практик та співпраці, які забезпечують активний еволюційний дизайн та архітектуру системи.

Основні моменти в роботі архітектора

1. Ідентифікація вимог

2. Розробка ІТ-архітектури

3. Архітектурний дизайн ІТ-рішення

4. Підготовка архітектурної документаціЇ.

5. Архітектурний аналіз

Люди мають на увазі різні речі, коли називають себе або когось “архітектором”. Натомість це спричинено розширенням ІТ-спеціалізацій, а також поступовим зближенням ІТ, системної інтеграції та сфери розробки продуктів у контексті цифрового бізнесу. Саме тому я приведу “найпопулярніші” використання ролі “архітектора”:

Усі вони є архітекторами, тоді як вони просто діють в різних контекстах.

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

Архітектор працює з усіма членами команди і повинен переконувати їх - як і керівництво - у правильності їх вибору при прийнятті рішень. Бути архітектором - це не обов’язково питання лише можливостей. Це питання фокусу та ролі.

Уже багато сказано і написано різними авторами про ІТ архітектуру, роль архітектора, обов’язки архітектора. Я не буду “відкривати Америку” і вирішив висловити мої думки щодо ІТ-архітектури та дизайну, надихнувшись приголомшливою статтею What Makes A Software Architect?, написаною Dr. Jim Walsh, CTO в GlobalLogic.

10 Рис, притаманних хорошому архітектору

1. Вирішувати проблеми

Невід’ємною рисою архітектора є вміння вирішувати проблеми. І чим більший масштаб цих проблем, тим досвідченішим є архітектор (з точки зору практичного досвіду — не обов’язково кількості років досвіду). Архітектори можуть мати різну спеціалізацію: від питань інфраструктури, мережі, до декомпозиції бізнес доменів, фокусі на високорівневу архітектуру типу “загальна картина”, інтеграції між системами або навіть і все вище перераховане одразу взяте. Але незалежно від їх фокусу, основним завданням архітектора є пошук оптимального вирішення проблеми. Результат роботи архітектора – це дорожня карта і ключ до того, ЯК вирішити проблему.

2. Фокусуватися на “Як?”

В розробці програмного забезпечення майже завжди існує безліч способів вирішення однієї і тієї ж проблеми. І серед усіх цих можливих рішень точно знайдеться кілька, які можна вважати “хорошими” рішеннями. Саме тому важливо вміти відділити «Як?» від самої реалізації – це дає простір для створення і вибору серед цих «хороших» рішень оптимального. Дві різні команди розробників можуть піти різними шляхами, але в результаті прийти до одного і того ж самого архітектурно правильного вирішення задачі.

3. Думати цілісно

• Щоб запропонувати правильне рішення, архітектор повинен спочатку цілісно зрозуміти проблему. Вирішувані проблеми завжди мають вплив на бізнес, хоча часто вони сприймаються, як суто технічні проблеми. Архітектор повинен розуміти контекст проблеми, яку він вирішує, перш ніж зможе запропонувати правильне рішення. Цей процес, як правило, вимагає комунікацій із широким колом зацікавлених сторін для отримання додаткової інформації. І часто люди, з якими ведуться інтерв’ю не обов’язково знають, що вони володіють інформацією, яка важлива для архітектора – її потрібно «витягувати», так як цілісне розуміння є важливим при пошуку правильного архітектурного рішення.

• Оскільки «нетехнічна сторона» компанії може мати мало уявлення про вплив технічного рішення на бізнес, архітектору випадає оцінити і донести ці наслідки від вибору того чи іншого рішення.

4. Творчо використовувати технології

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

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

5. Приймати рішення

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

• Людина, яка приймає архітектурне рішення, усвідомлює, що вона діє в архітектурній ролі, а не в суто управлінській чи політичній ролі.

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

6. Бути впевненим у своїх рішеннях (не плутайте з зарозумілістю)

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

7. Робити речі зрозумілими

Хороший архітектор повинен бути в змозі чітко описати систему як для 80+-річних дідуся і бабусі, бізнес-підкованого CEO, а також крутого CTO, таким чином, щоб всі вони змогли зрозуміти суть запропонованого рішення. Хороший архітектор адаптує своє пояснення для конкретної аудиторії.

8. Говорити про складні речі простими словами

Хороший архітектор не розкидається незрозумілими TLA (“Трилітерні абревіатури”), щоб вихвалятися.

9. Не боятися ризикувати

Архітектура – це ремесло. Щоб зробити шедевр автору (читайте архітектору) слід ризикувати.

10. Не боятися бути “неправим”

Працюйте. Перепросиш пізніше. (Do. Apologize after.)

Чим займаються архітектори

• Втілення бізнес-вимог у програмному забезпеченні

• Спілкування з клієнтом

• Визначення та проектування архітектурних компонентів

• Аналіз і вибір правильних архітектурних шаблонів та методів

• Підготовка та документування архітектурного рішення

• Презентація та роз’яснення архітектурних рішень командам розробників і усім зацікавленим сторонам

• Дослідження технологій і робота над створенням прототипів рішень

• Контроль за виконанням на високому рівні (загальний контекст)

Ролі, які помилково асоціюють із роллю “Архітектор”

1. Дослідник. Хоча архітектори і проводять частину часу на дослідження та експерименти, фундаментальна відмінність дослідника і архітектора полягає в тому, що архітектор вирішує конкретну бізнес-проблему.

2. Аналітик. Ключовим диференціатором між аналітиком і архітектором є те, що архітектор в кінцевому підсумку робить вибір або єдину рекомендацію в результаті проведених аналітичних досліджень.

3. Технічний експерт. Однак, є багато випадків, коли технічні експерти не є архітекторами, навіть якщо вони мають таке звання по позиції.

4. Оркестратор знань. З точки зору архітектури, оркестратор знань “бере участь” (involved) в пошуку правильних рішень, в той час як архітектори є відповідальним за прийняті архітектурні рішення (commited).

Підсумовуючи

Хороша архітектура програмного забезпечення - це те, що дозволяє вашій компанії:

1. швидко розвертатися і розвиватися;

2. мінімізувати витрати на технічне обслуговування та експлуатацію;

3. масштабуватися надійно і плавно;

4. створювати цінність для кінцевих користувачів, і генерувати дохід для вашого бізнесу.

Проглянути презентацію