Переставляя картинки будущего

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

Только давайте сразу отбросим более-менее банальные задачи, типа пойти и разобраться почему не работает та или иная хрень информационная система.  Безусловно, архитектор согласится заняться и этим видом деятельности, но скорее всего покажет вам ценник на несколько миллионов рублей, объяснив, что решение этой задачи требует кропотливой работы нескольких экспертов в течении 2-5 месяцев. А результат этой деятельности вряд ли даст удовлетворительный ответ на вопрос: что делать? Можно, конечно, дать меньше денег и времени или же попросить в те же сроки описать весь корпоративный ландшафт, но тогда вы не узнаете не только куда двигаться дальше, но и где вы сейчас находитесь.  Другой банальной задачей является декомпозиция проекта или продукта на системы. Не то чтоб это было не нужно. Наоборот, такая работа нужна и полезна, но разве она олицетворяет ваши ожидания от деятельности действительно сильного архитектора?

Не берусь точно предугадать Ваш вариант ответа (можете поделиться им в комментариях), но я бы ожидал от архитектора оконтуренных вариантов будущего. Концептуальных картинок того, как могла бы выглядеть ситуация в перспективе +1 месяц, квартал или год. Из чего будет состоять и что будет делать наша система, что в ней будет хорошего и плохого, как новые проблемы заменят старые ограничения и т.д. Сошлюсь на Фредерика Брукса (Frederick P. Brooks), человека, написавшего две книжки: в 1975 году знаменитый “The Mythical Man-Month: Essays on Software Engineering”, а в 2010-м “The Design of Design: Essays from a Computer Scientist”:

Самая сложная задача проектирования состоит в определении того, что должно быть спроектировано… Основная услуга, которую проектировщик оказывает клиентам, состоит в определении того, что же действительно они хотят получить в результате

Именно в отсутствии четкого понимания конечной цели в начале пути и кроется причина того, что рациональная модель проектирования не работает. Не зная куда идти, вы не можете построить дерево решений и выбрать в нем оптимальный маршрут. Согласившись с изложенной точкой зрения нам следует сделать несколько очевидных наблюдений и выводов:

У каждого свой горизонт планирования. Операционный менеджер решает задачу здесь и сейчас, создавая технический и не только технический долг. Проектный менеджер видит ближайшую запланированную веху и момент завершения проекта. Для менеджера продукта в этот момент всё только начинается. В ходе разработки услуги он тоже присутствует, но для него даже время движется в другую сторону. Он живет в мире с обратным отчетом времени. В общем, просто так они никогда не договорятся. Кто-то будет напористо срезать углы, целеустремленно двигаясь к ленточке «старт-финиш». Другой будет пытаться затащить её на самую верхушку горы, чтоб затем ошеломить рынок своим молниеносным стартом (или же кубарем скатиться вниз).

Множество вариантов будущего не является непрерывным и связным. Прошу меня простить за наукообразную формулировку. Я хочу сказать лишь то, что пути перехода в будущее есть развилки. Если мы пойдем по одной дороге, то не пойдем по другой. Причем во времени, в отличии от пространства, нет дороги назад. Мы далеко не всегда сможем вернуться и перерешать куда нам идти. Более того, попав во одну область мы не сможем перепрыгнуть в другую. Признание этого потребует от нас более осторожного отношения к таким идеям, как рефакторинг и реинжениринг, заставит усомнится в возможностях восстановления после сбоев и отката неудачных релизов. Это чем-то похоже на картинки из книжек про теорию относительности, на которых планеты создают вокруг себя гравитационные воронки, типа такой

gtr

Я не стану пугать читателя черными дырами, в которых проект может застрять навсегда. Но, в определенном смысле, такая картинка позволяет объяснить приверженность архитекторов паттернам проектирования. Паттерны и анти-паттерны — это центры масс, к которым мы будем скатываться на своем пути.

Не все варианты достижимы. Пожалуй, это наиболее печальный фактор в деятельности архитектора. Современное нам общество больше всего любит успех. Субъективное ощущение недостаточной успешности заставляет людей заменять его видимостью. Естественно, архитектура информационных систем попала в этот глобальный тренд. Значительная часть архитекторов уже не проектирует дома, а рисует потемкинские деревни. Спрос рождает большое количество симулякров. Кто-то искренне считает, что сделанный из соломы самолет полетит, а кто-то решает для себя, что сейчас он создает прототип. Кстати, прототипы – отличная вещь для обсуждения проектируемого решения. Намного лучше, чем слова на бумаге, картинки в Power Point или UML диаграммы. Я даже думаю, что развитие PaaS позволит скоро объединить деятельность по проектированию и прототипированипю. Подождать осталось чуть-чуть. Но пока мы имеем довольно серьезную дилемму: надо ли потакать заказчику овеществляя его несбыточные фантазии или оставаться в области реализуемых вариантов. Выбор второй альтернативы несет за собой следующие последствия:

  1. Лучшим является тот проект, который был подвергнут критике, но устоял. Это как в тестировании ПО – отсутствие выявленных дефектов может свидетельствовать о недостаточном тестировании
  2. Сам архитектор должен сомневаться в своих фантазиях. Если все кажется идеальным, то надо поинтересоваться мнением скептически настроенного товарища. Уж он то не откажет вам в критике.
  3. Такая работа не добавит вам авторитета среди коллег.

Для чего я решил сегодня озвучить эти очевидные соображения. У меня сейчас довольно много предложений о работе. Я готов ими поделиться, но сразу должен предупредить, что во всех этих предложениях есть определенные дефекты. В большинстве случае работодатель надеется заткнуть архитектором дыры в своей операционной модели(или операционной модели заказчика) вместо того, чтоб её поменять. Проще говоря, они почему-то считают, что организации, имеющие потребность в ПО и возможность эту потребность профинансировать могут научиться разрабатывать, развивать и эксплуатировать современное ПО, сохранив устаревшие подходы. Лет 20-15 назад, во времена, RUP-а вроде бы получилось впихнуть в корпорации чуждую им модель. Сегодня, с CI/CD, DevOps-м, XaaS-ом, продуктовым мышлением и инвестиционным подходом к финансированию ИТ-решений, скорее всего, это просто не получится.

p.s. Некоторые идеи этой статьи родились в результате обсуждения с Дмитрием Безуглым методов разработки стратегии в условиях высокой неопределенности.

Переставляя картинки будущего: 4 комментария

    1. Вроде бы везде поменял. Правда старая статистика сбилась. А что именно не так работает? Я под своей учетной записью не вижу каких-то проблем

  1. > Лет 20-15 назад, во времена, RUP-а вроде бы получилось впихнуть в корпорации чуждую им модель. Сегодня, с CI/CD, DevOps-м, XaaS-ом, продуктовым мышлением и инвестиционным подходом к финансированию ИТ-решений, скорее всего, это просто не получится.

    Просто подождать, пока старые корпорации умрут? Потому что впихивать в них все это, действительно, напоминает работу Дона Кихота.

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

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