Завдяки хмарі сфери бізнесу все більше залучаються до технічної діяльності. Але без глибокої архітектурної експертизи все може стати дуже безладним — і дорогим.
Давайте визнаємо це – сьогодні всі закохані в інформаційні технології. Від власника візка з морозивом, який тепер може приймати кредитні картки через Square, до керівника аерокосмічної галузі, який тепер може контролювати працездатність авіаційних двигунів у польоті, 24x7, IT відкриває нові можливості та полегшує біль ручних процесів.
Але також існує тенденція переходити за межі, і з широким, часто необмеженим впровадженням хмари, SaaS або мобільні послуги, існує ризик сприймати ІТ як панацею від усього для недалекоглядних або неосвічених управління. Щоб уникнути дорогих небезпек простого використання технологій для вирішення проблем, існує дисципліна архітектури, як програмного забезпечення, так і корпоративного стилю.
Рут Малан, надзвичайний ІТ-архітектор, консультант з архітектури в Bredemeyer Consulting і лауреат премії Карнегі Меллона
2017 Лінда М. Нагорода Northrop Software Architecture Award, нещодавно роздумував про те, що означає бути архітектором. Вона зазначає, що архітектура часто пливе проти течії організаційної ентропії, інерції та недалекоглядності:"Закон Конвея стверджує, що структура організації та комунікаційні шляхи, які вона полегшує та гальмує, є потужними, навіть визначальними, форматорами системи. Я перефразую це так: «якщо архітектура системи та архітектура організації суперечать, архітектура організації виграє». Визнаючи, що це закон, як-от гравітація, ми можемо підіграти йому та використовувати межі команд, щоб підтримувати межі компонентів або мікросервісів, обмежуючи їх вгору. Є але. Ми повинні залишатися пильними, щоб нас не обдурили тим самим законом, який ми використовуємо для гри в ентропію. Сили, які ми використовуємо для захисту та зміцнення кордонів, збільшують сили інерції на кордоні – важче побачити, коли потрібні зміни, і важче змінитися. Крім того, враховуючи те, що комунікаційні шляхи сприяють і гальмують, нам доведеться докладати чітких зусиль, щоб гарантувати, що ми не отримати розповзання області в межах компонента (мікросервіс тощо) і керувати дублюванням (із супутньою невідповідністю) між компоненти».
Підсумок, робота архітектора — чи то архітектора програмного забезпечення, чи архітектора підприємства, якого ми збираємося досліджувати тут — полягає не просто в проектуванні та плануванні чудових, елегантних систем; це також навчати, направляти та, так, продавати ці ідеї та бачення тим, хто приймає рішення, яким постійно потрібно переглядати те, що вони роблять, чому вони робити те, що вони роблять, як вони можуть зробити це краще, і, що важливо, визнати, що сама по собі технологія не вирішить їхні проблеми чи не відкриє нових можливості. Для цього потрібне далекоглядне, далекоглядне керівництво. Архітектура підприємства закладає фундамент і робить правильні технології доступними для потрібного випадку.
Це було правдою ще в 1968 році, коли Мелвін Конвей написав свій закон, і тим більше актуально сьогодні, коли переходять до цифрових підприємств. Новий опитування від CompTIA, галузевої торгової асоціації, стверджує, що «критичний характер технологій і радикально нові моделі для доставки ІТ роблять архітектурне планування необхідністю. Так само, як бізнес-план потрібен для визначення майбутнього компанії, план ІТ-архітектури потрібен для досягнення успіху в цифровій економіці».
Дозвольте мені зробити крок далі. План ІТ-архітектури є бізнес-план. І бізнес-план є план ІТ-архітектури. Ці двоє єдині, і тепер вони нерозлучні.
У дослідженні CompTIA близько 13% керівників вважають свої організації «передовими», коли йдеться про інтелектуальне розгортання технологій для розвитку їхнього бізнесу. CompTIA каже, що керівництво передових компаній підтримує розумні технологічні рішення. «Серед компаній, які використовують більш передові технології, 52% кажуть, що вище керівництво, яке підтримує та фінансує технологічні ініціативи, є ключовою частиною передового підходу».
Серед фірм, які використовують менш передові технології, 44% кажуть, що недостатньо витрачають на технологічні ініціативи (за рахунок бюджетів, встановлених на виконавчому рівні) стримують їх від a сильніший підхід. «В обох ситуаціях бачення/підтримка/бюджет, встановлений керівництвом, є основним фактором формування мислення», — підсумовують автори звіту.
Гаразд, як можна впровадити технологічне бачення в керівництво своїм бізнесом? Автори CompTIA описують, що потрібно зробити:
«Для ІТ-фахівців або постачальників ІТ-рішень завдання досягнення консенсусу щодо планування архітектури є подвійним. По-перше, вони повинні переконатися, що обговорення починається з потреб бізнесу. Технічні працівники повинні розуміти кінцеві цілі; «Нам потрібен новий інструмент зв’язку» може означати «Нам потрібно ввімкнути віддалених працівників» або це може означати «Нам потрібно підключитися до внутрішніх дії з клієнтами». ІТ-відділ може запропонувати різні кроки для остаточного рішення на основі об'єктивний.
«По-друге, співпраця всієї організації має поширюватися на базове розуміння архітектури. [Є] зростаюча технічна активність серед напрямків бізнесу. Діяльність зростає, оскільки знайомство з продуктами SaaS та іншими рішеннями для кінцевих точок зростає, але вона також обмежена, оскільки бізнес-підрозділи не мають глибоких архітектурних знань. Оскільки бізнес-потреби керують технологічними рішеннями, цей вплив має впливати аж до взаємопов’язаних систем, які утворюють комплексне ІТ-середовище».