Архитектура информационных систем предприятия

Почему-то архитекторам свойственно напускать много сиреневого тумана на свою деятельность: и определения что такое архитектура единого нет; и книжки про архитектуру все почему-то довольно толстые. Даже великий Буч, как мне кажется, больше написал о том, чем не является архитектура, а не о том, чем же она является.  Мне хочется сделать простой и по возможности краткий обзор того, что же такое архитектура. Может начальникам как-нибудь расскажу. Обзор будет субъективный, потому сразу прошу – тапками в меня не кидайтесь.

Если говорить о чем-то одном в корпоративной ИТ-архитектуре, то говорить надо о моделировании. Если говорить о моделировании, то говорить надо об UML. Современный подход к моделированию  информационных систем появился в январе 1997 года. К тому времени «трое друзей», сначала под эгидой Rational, а затем OMG завершили работу над первой версией языка UML. До появления UML картинки информационных систем каждый рисовал по своему разумению. Причем, десять человек могли нарисовать одну и ту же систему абсолютно по-разному. Более того, рассматривая эти картинки, мы приходили к совершенно разным, зачастую прямо противоположным суждениям о системе. Справедливости ради надо заметить, что и сейчас такие веселые картинки довольно распространены. Но их не стоит причислять к архитектуре, т.к. это чистой воды маркетинг. Т.е. цель этих картинок в значительной мере в том, чтоб продвинуть свою точку зрения, и поколебать точку зрения оппонента. К архитектуре такие картинки отношения не имеют.

Итак, в 97 году появился язык UML, определивший какие квадратики и какие стрелочки следует рисовать. По сути, авторы языка собрали под одной крышей несколько ведущих подходов и предложили придерживаться именно их. Теперь технический художник, рисуя очередную картинку, должен четко сказать какую именно диаграмму он делает, а каждая диаграмма состоит из определенного набора квадратиков и стрелочек, имеющих достаточно точный смысл.

На мой взгляд, графическая составляющая UML имеет второстепенное значение. Куда более важным является набор стереотипов объектов и отношений между ними. Подход, позволяющий посмотреть на ИТ-решение с нескольких сторон (separation of concerns)  и для каждой из точек зрения выделить вполне конкретные элементы – это и есть архитектура.  Впрочем, большинство айтишников не пользуются диаграммами. Намного удобней работать с объектами, представленными в интегрированной среде разработки или административной консоли. На картинке вы можете разместить максимум пару десятков объектов. При большем количестве объектов она становится нечитаемой. Интегрированные среды предоставляют возможность оперироваться сотнями объектов и отношений довольно сносно. Если команда работает в рамках одной платформы, то интегрированная среда вполне приемлемый инструменты для отображения архитектуры.

Но платформы разные и средства работы в них разные, потому и нужны «платформонезависимые» инструменты. В принципе на рынке есть несколько таких инструментов, но все они обладают существенным набором недостатков, например:

  • Лицензирование по количеству пользователей и высокая стоимость
  • Толстый клиент (это плата за красивые картинки)
  • Закрытый формат репозитория (а тем временем OMG упорно стандартизирует XMI, какие умники)
  • Недостаточная гибкость в части определения стереотипов
  • Отсутствие средств генерации картинок из репозитория объектов
  • Слабые средства управления ролями и разграничения доступа

Кроме того, различные архитектурные бюро постоянно раскачивают лодку, добавляя все новые и новые диаграммы. И, тем не менее, UML сделал очень важную вещь. Он, по крайней мере, дал нам принципиальную возможность перекинуть мостик между реальность, состоящей из серверов, приложений, сетевых взаимодействий и пр. и фантазиями в формате PowerPoint. А вот пользоваться этой возможностью или нет – вопрос уже к нам.

Архитектура информационных систем предприятия: 2 комментария

  1. Максим, спасибо за статью. Просто и доступно объясняет, зачем вообще нужен UML.
    Мне по долгу службы надобно бы с ним очень близко познакомиться, но так пока и не знаю, с какой стороны к нему подступиться.

    1. Анна, UML – довольно объемное “творение”. Если Вы расскажете пару слов о том, зачем Вам требуется близкое знакомство с UML (можно не в блоге, а по e-mail mxsmirnov@gmail.com ), то я постараюсь подсказать с какой стороны к нему подступиться

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

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