Портал №1 по управлению цифровыми
и информационными технологиями

Трущобы или точечная застройка?

На прошедшем пару недель назад семинаре itSMF об управлении ИТ-архитектурой я услышал эту аналогию про трущобы, генеральный план и точечную застройку. 

Когда времени и денег мало, результат нужен прямо сейчас, и планирование в целом осуществляется на горизонте "дожить до утра", коробка от холодильника – отличный способ укрыться от дождя на ночь. Или на две. Или на неделю. Мусор при этом удобно уносить в кучу за углом, его там не видно и оттуда не слышно. Если так рассуждает достаточно большое число людей, вокруг вырастают трущобы. Примерно такие: 

Если (как в Мумбаи, где сделана эта фотография) вокруг достаточно тепло, а жители склонны смотреть на этот мир как на временное и не очень важное пристанище, трущобы могут существовать очень-очень долго. 

Однако бывает так, что на смену трущобам приходит новая застройка – тщательно спланированная, учитывающая существующие и прогнозируемые потребности и возможности, удобная и красивая, насколько себе это представляют архитекторы. Такая, например (это не Мумбаи, это Сингапур):

…но так бывает редко. Чаще бывает так: оказывается, что городу очень нужен бизнес-центр (жилой комплекс класса люкс/стадион/ресторан/мегамолл…) – тщательно спланированный, учитывающий существующие и прогнозируемые потребности и возможности, удобный и красивый, насколько себе это представляют архитекторы, но все это – в границах его территории, а вокруг пока придется оставить трущобы, потому что на масштабную перестройку нет времени и сил, так сделаем по-человечески хотя бы что-то. Примерно так (снова Мумбаи):

Характерно, что в последнем случае часто по-человечески все равно не получается: очень непросто поддерживать порядок в небоскребе, если у его жителей годами формировалась привычка сваливать мусор в кучу за углом. А если и получается отгородить оазис чистоты и комфорта от окружающих его трущоб, организовать охрану периметра и пропускной режим – вид города в целом от этого не становится намного лучше. 


Аналогия с ИТ-архитектурой очевидна. На том семинаре я спросил докладчика, знает ли он лично компании (желательно в России), которые или построили бы свои информационные технологии в соответствии с разумным генпланом с самого начала, или осознанно и успешно перешли от хаотично растущих трущоб к новой целостной архитектуре. Ответ я понял так, что компания первого типа известна докладчику одна (телеком-оператор в Канаде), а компаний второго типа он пока не встречал. Чем же тогда занимаются ИТ-архитекторы? Как и многие городские архитекторы – точечной застройкой. 

И вот что я тогда подумал: ИТ-архитектура – это ведь очень широкое понятие. Очень. Сюда ведь всё входит при желании – и инфраструктура, и приложения, и информационные потоки, и процессы, и организация, и каталог услуг, и управление рисками… И во всех этих направлениях большинство компаний (ок, большинство известных мне компаний) в лучшем случае занимаются точечной застройкой, в худшем – строительством трущоб. При этом все изучают передовой опыт архитекторов в создании городов будущего. 

Как это, в сущности, грустно. 

Комментариев: 9

  • сергей

    Откуда же тогда берется передовой опыт, если строят все трущобы? Может этот передовой опыт и не опыт вовсе, а ненаучная фантастика?

  • Ну, я думаю так:

     – частично это передовой опыт точечной застройки;
     – частично это передовой опыт редких случаев постройки "с нуля по уму" или полной перестройки
     – частично – фантастика разной степени научности. 

    Долю каждой части оценить не берусь, думаю, что они распределяются по-разному в разных направлениях ИТ-менеджмента: в, скажем, управлении рисками выше доля первой группы, а в, скажем, IT Governance – третьей. Или наоборот…

  • компания первого типа известна докладчику одна (телеком-оператор в Канаде)…

    Лично знаю такую компанию в РФ, в Москве.

    …а компаний второго типа он пока не встречал

    Есть примеры постепенных, но заметных улучшений. А состояние "перешли", как мне кажется, не очень достижимо – ты же сам рассказывешь про дорогу и лучшие/хорошие практики. Здесь, я думаю, примерно также.

    В целом мне не кажется, что ситуация настолько плачевна, но может быть у меня просто меньше опыта, чем у докладчика. Однако, как говорит один мой знакомый специалист по ИТ-архитектуре, "проклятие архитектора" заключается в том, что для упрощения сначала приходится усложнять (ведь старые системы, от которых мы избавляемся, не ичезают в одночасье – иногда им приходится работать годами, иногда с ними строятся решения по интеграции и так далее).

    • Андрей

      Поддержу Дмитрия. Как и процессное управление, управление архитектурой это деятельность по постепенному улучшению. И можно согласиться с Максимом в том, что «дошедших» до высокой зрелости действительно мало. Несмотря на это во многих организациях с которыми приходится сталкиваться в той или иной степени с архитектурой работают. Конечно мы не найдем примеров «разрушили все – построили правильно», но постепенные, возможно локальные, улучшения происходят. Да и тот же TOGAF говорит нам, что заниматься архитектурой можно на разных уровнях. Определение топологии сети, анализ реализуемости проекта и планирование развития ПО это все аспекты архитектуры.

      Причин заниматься этим у организации может быть несколько: активный рост, который требует новых технических решений, например интеграционных шин; оптимизация портфеля используемых приложений и их интерфейсов, когда их количество превышает сотню; оптимизация проектной активности и затрат на ИТ в целом, например анализ выгод от перевода части ИТ в облако или анализ соответствия трат целям организации; начало чего-то нового и комплексного, например строительство нового завода. Другой пример не из наших широт – Clinger-Cohen Act, который требует наличие описанной архитектуры для всех организаций, реализующих проекты за счет бюджета США. В Европе существует аналогичный EU Directives on the Award of Public Contracts.

      Правильно выстроенные процедуры управления архитектурой в свою очередь будут способствовать движению в верном направлении. Например, известно несколько организаций в которых Архитектурный совет действительно исполняет свои функции – новые разработки укладываются в единую картину организации, старые постепенно заменяются. Более того, многие аспекты управления архитектурой так или иначе уже могут исполняться в организации так не называясь: управление спросом, мощностями, непрерывностью.

      В аналогии с городами рядом с трущобами мы строим новый молл и жилой центр, если он нужен, с дорогами, водопроводом и садами, в нем устанавливаем новые правила и за исполнением следим; все новые постройки делаем не менее Х этажей; за самостроем следим; в получившейся картине определяем наиболее проблемные места и правильным образом расставляем приоритеты развития.

  • Альберт

    "Бытие определяет сознание" 🙂 Можно обладать знаниями, опытом и т.д. но все будет определяться экономической целесообразностью.

    • Ivan Krouglyi

      1) Одно дело в принципе не знать как надо и делать наобум (даже если есть и время и средства), ежедневно блуждая по граблям и другое дело, зная как надо, сознательно какие-то аспекты игнорировать или держать на другом уровне зрелости.

       

      2)

      Ю:- Мне надо сейчас, срочно. Не важно как. На денек. 

      Через неделю

      Ю:- А почему не работает?

      С: – Ну как, вам же надо было срочно, для тестирования, ну упало и упало.

      Ю: – Нет, вы что, мы уже все пользуемся.

      С: – Так в эксплуатацию не передали.

      Ю: – Куда?

       

      3) "Нет ничего более постоянного, чем временное"

       

       

  • Sergey Usik

    Лично знаю такую компанию в РФ, в Москве.

    Почему никто не называет имен? Герои стесняются?

  • Rafhat Osmonov

    Очень интересная аналогия, спасибо за статью.

    Как собственно понять, занимается IT строительством трущоб или точечной застройкой? По сути мы строим эти "помещения" (процессы и прочее) вокруг себя, живем в них и порой даже не видим что получилось в итоге. Можно даже сказать радуемся тому что построили. Выйт трезво взи "наружу" и трезво посмотреть на результат своей работы или на

  • Rafhat Osmonov

    Что то у меня случилось…

    Выйти "наружу" и трезво посмотреть на результат своей работы или найти человека снаружи, который нам честно скажет что у нас трущоба, мне видится в этом основная задача. До этих пор IT все может полностью устраивать и само IT может полагать что у них "Сингапур".


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM