Американский архитектор Фрэнк Гери говорил, что
У моды есть положительные и отрицательные стороны. В моде на ИТ-архитектуры хорошо то, что всласть поиграв понятием архитектуры, ИТ-сообщество и «заинтересованные лица» выработали более или менее сходный взгляд. А плохо то, что с модой к интересной идее прилипает множество «ракушек», искажающих ее смысл. Облепленная ими идея стремительно опускается на дно общественной востребованности, где и покоится, пока то или иное течение вновь не поднимет ее на поверхность. При этом — увы! — качество затонувшей идеи не имеет значения. Ажиотажная мода «на архитектуру» может привести к тому, что необходимый для ИТ подход ухнет на пару лет во тьму псевдонаучных статей. Уже сейчас при рассказе об архитектуре часто приходится ловить «стеклянные» взгляды слушателей, в которых читается «а зачем мне это надо?». Но архитектура как универсальная полноценная модель предприятия необходима для современных ИТ.
«Серебряная пуля», убивающая все проблемы (несвязанность приложений, отставание разработки и внедрения программного обеспечения от темпов развития компании, низкий процент задействованной функциональности программных систем) применения ИТ на предприятиях, является еще одним символом, который определяет модную идею. Но этот образ имеет и более глубокий смысл. В поиске «серебряной пули» отразилась естественная человеческая потребность решать простыми способами вопросы любой сложности. И чем труднее задача (а в случае с ИТ она очень сложна), тем истовее вера в чудодейственное средство. Архитектура — это не волшебное средство, а плодотворный подход к организации ИТ-структуры.
О какой архитектуре идет речь? Множится количество определений архитектуры предприятия (Enterprise Architecture), но все они сводятся примерно к следующему:
- архитектура описывает компоненты системы и их взаимосвязи;
- архитектура включает в себя принципы развития, совершенствования и поддержки.
Этого довольно, чтобы констатировать: архитектура является самодостаточной и полной динамической моделью системы. Под «системой» понимается не только программный комплекс, но и любой предмет, представляющий собой единство закономерно расположенных и взаимосвязанных частей. В роли системы может выступать предприятие, холдинг или общественная организация, а может и весь комплекс компьютерного оборудования, сетей, системного и прикладного программного обеспечения, который используется на предприятии и довольно условно называется «ИТ».
Изначально понятие «архитектура» относилось только к зданиям и сооружениям, но со временем в этом слове смогли разглядеть намного более широкий смысл. Показательна аналогия между зданием и ИТ: строительство того и другого представляет собой сложный, трудоемкий и часто непредсказуемый процесс. То и другое необходимо поддерживать и грамотно эксплуатировать. То и другое подвержено амортизации. Однако ИТ развиваются намного быстрее, чем здания.
Как описать архитектуру — полную модель системы? Для описания неподвижного и неодушевленного предмета достаточно трех проекций. При описании здания используют отдельные архитектурные проекции и разрезы, поэтажные планы, изображения фасадов и панорамные виды. Описывая ИТ (или их отдельный компонент — программную систему, базу данных и т.п.) только в каком-то одном ракурсе, мы строим соответствующую проекцию. Можно разработать проекции на основе точек зрения, присущих разным группам сотрудников внутри компании и ее партнерам. Это владелец компании, руководители подразделений, сотрудники и ИТ-специалисты, пользователи и администраторы программных систем, проектировщики баз данных и их администраторы, сотрудники отдела закупок, клиенты и т.п. Таких проекций может быть очень много. Даже если мы путем долгих усилий опишем их, то получим совершенно бесполезную модель, воспринять которую нормальный человек не сумеет. Что же делать?
Можно предположить, что набор архитектурных планов полностью описывает здание. Три проекции в совокупности являются полной архитектурной моделью неподвижного объекта. Но их уже недостаточно для описания движущегося объекта — понадобятся скорость и ускорение. Получается, что для любого предмета, системы или ИТ можно построить множество архитектурных моделей, каждая из которых будет с той или иной степенью полноты и достоверности отображать объект моделирования.
Будем называть проекцией отображение взгляда на систему с некоторой точки зрения, а полной проекцией — исчерпывающее описание определенного взгляда на систему. Описание архитектуры является совокупностью отдельных проекций, которая образует архитектурную модель, с той или иной степенью полноты описывающую систему. Любую систему можно полностью описать с помощью некоего конечного числа полных проекций. Совокупность проекций, полностью и исчерпывающе описывающих систему, назовем полной архитектурной моделью («полностью» в данном случае означает, что любую другую проекцию удастся построить на основе данной архитектурной модели). Архитектурная (в широком смысле слова) наука предлагает нам полную модель Захмана (см., например, О. Полукеев, Д. Коваль, «Моделирование бизнеса и архитектура информационной системы» // СУБД, 1995, № 4). Известные архитектурные модели (строго говоря, нотации описания архитектурных моделей) легко укладываются в эту модель. В свете введенных нами определений строки и столбцы модели Захмана являются проекциями: строки — с точки зрения групп заинтересованных лиц, столбцы — с точки зрения областей рассмотрения (что, кто, как, когда, где и зачем).
Остановимся на полноте модели Захмана. Если со строками (с заинтересованными лицами) все более-менее понятно и полнота зависит от грамотного выделения таких групп, то со столбцами дело обстоит несколько сложнее. Всегда ли достаточно этих вопросов? Например, из рассмотрения выпал важный вопрос «сколько стоит?». Кроме того, модель Захмана предполагает статику, и без «оживления» ее дополнительной проекцией, характеризующей динамику, попросту не обойтись. А поскольку предметы, движущиеся с постоянной скоростью, весьма редки, то надо знать еще и ускорение. Или, как вариант, применить к движению модели Захмана ее же парадигму 5W+1H: что движется (здесь подойдет статическая модель), кто движет предмет, как он движется (по какой траектории), когда происходит движение, какова его цель и где оно происходит.
Еще одно серьезное замечание связано с «начинкой» ячеек таблицы. Понятно, что полнота зависит от степени детализации их наполнения. Опять же очевидно, что, заполнив ячейки текущими знаниями по тому или иному вопросу той или иной группы заинтересованных лиц, мы полноты не достигнем. Поэтому при более чем благосклонном восприятии практиками модели Захмана у них всегда возникает множество вопросов по ее практическому использованию.
Рискнем предложить вариант заполнения ячеек таблицы Захмана (табл. 1). Строки в этой таблице отличаются от классической интерпретации модели и добавлены два столбца.
Таблица 1.
Можно утверждать, что модель Захмана является наиболее полной моделью корпоративной архитектуры. По крайней мере, другую модель практически всегда можно получить из модели Захмана.
А зачем нам вообще строить модели и описывать ИТ? Понятно, что на каждом предприятии они есть, и пусть себе будут. Прервем ненадолго архитектурную линию и немного поговорим о самих ИТ, воспользовавшись аналогией со строительством.
Видимо, если нужно построить конуру для собаки, то ее просто строят — без предварительной разработки архитектурных планов в трех проекциях. Итак, если дома у вас стоят один-два компьютера, то, вполне возможно, строить архитектуру не обязательно.
Обсудим другую позицию: любой объект может развиваться стихийно или планомерно. Стихийное развитие позволяет подстраиваться под изменения окружающего мира, но грозит авралами и ошибками. Планомерное развитие, к сожалению, часто отрывается от реальности и при излишнем упрямстве (или ажиотаже, восторженности, прямолинейности, узколобости) грозит привести к плачевному результату. Как всегда, истина находится посередине, а сформулировать ее можно так: необходимо планомерное развитие, позволяющее гибко реагировать на изменения окружающей обстановки. Однако стихийное развитие ИТ вовсе не отрицает важности архитектурного подхода — как раз наоборот. Хотя бы потому, что при определенной сложности ИТ вы просто не сможете определить, как реагировать на изменения.
Можно ли придумать другую полную модель, отличную от модели Захмана? Кажется перспективным воспользоваться классической архитектурной теорией. Нужно рассмотреть соответствие между этапами архитектурно-строительного проекта и построением корпоративной архитектуры (таблица 2). Полнота сложившихся стандартов в архитектурном проекте доказана успешным строительством множества зданий. Сравнив табл. 1 и 2, можно убедиться, что модель Захмана полнее «строительной».
Таблица 2.
Еще одна модель, претендующая на полноту, состоит из двух описывающих ИТ проекций — технической и функциональной. Первая представляет «основные средства» ИТ. Рассмотрим ее в классической модели «слоеного пирога». Нижний слой — сетевой. Следующий — слой оборудования (серверы, дисковые массивы, сетевые устройства, рабочие места). Следом расположен слой базового программного обеспечения, устанавливаемого на оборудование предыдущего слоя (операционные системы и сетевые протоколы).
Затем идет активно развивающийся слой, который представляет собой материал построения функционального программного обеспечения (СУБД, серверы приложений, технологические программы). Следующий слой — структура и форматы данных. За ним следуют слой приложений и, наконец, слой сервисов, предоставляемых пользователям.
Теперь применим все эти проекции к каждому слою модели Захмана (таблица 3). Получается, что в модели «слоеного пирога» технологической проекции содержание ячеек таблицы более единообразно.
Таблица 3.
Функциональная проекция охватывает бизнес-процессы ИТ. Она выросла из столбца «Как» модели Захмана при описании ИТ-архитектуры. «Слоеный пирог» тут менее привычен, но мы попытаемся также применить к нему модель Захмана (таблица 4). В совокупности технологическая и функциональная проекции обладают свойством полноты описания ИТ.
Таблица 4.
Существуют ли какие-то альтернативы полной архитектурной модели? Как и во многих других случаях, при работе с архитектурой имеются два подхода, дедуктивный и индуктивный. В первом случае, построив полную архитектурную модель, мы сможем по мере необходимости получать из нее нужные проекции. Во втором строятся отдельные модели, которые на каждом этапе развития все больше приближаются к полной архитектурной модели.
Пожалуй, среди моделей последнего типа наиболее полезна в практическом смысле иерархическая модель, или модель постепенного погружения. Она состоит из нескольких уровней, и каждый последующий раскрывает и уточняет предыдущий. Первое замечание состоит в том, что в иерархической модели важно вовремя остановиться. Что значит вовремя? Когда описание системы станет достаточным для достижения конкретной цели, ради которой оно и было предпринято. Как связаны полная архитектурная и иерархическая модели? Это зависит от предмета моделирования. Можно сформулировать так: иерархическая модель с бесконечным количеством уровней стремится к полной модели. В большинстве случаев, однако, иерархическая модель вполне способна перерасти в полную за конечное количество шагов.
ITIL и COBIT предлагают проверенные временем архитектурные модели, которые также можно использовать для описания архитектуры компании. Кстати, многие элементы их архитектуры, такие как Business Continuity, SLA, Help Desk, были задействованы в приведенных таблицах. Например, ITIL можно представить в виде иерархии следующих слоев: бизнес-перспектива, предоставление сервисов, их поддержка, управление приложениями, управление инфраструктурой. А COBIT представляет собой сочетание элементов планирования и организации, комплектации и внедрения, функционирования и обслуживания, мониторинга и контроля.
А теперь еще несколько замечаний, навеянных классической архитектурой.
Единство стиля. Даже далекие от архитектуры люди знают, что существуют архитектурные стили. В ИТ-строительстве ситуация значительно хуже, и о единстве стиля построения ИТ компании не задумываются. А это означает, что супермодные, дорогие системы соседствуют с теми, которые стыдливо называют «наследуемыми». Кроме отсутствия красоты такие решения дают отрицательный эффект. В таких случаях ИТ представляют собой отдельные не связанные или слабо связанные программные компоненты, что не позволяет добиваться эффективной работы современных систем.
Удобство. Андреа Палладио, архитектор и теоретик архитектуры, писал: «Удобным будет называться тот дом, который отвечает положению своего обитателя и отдельные части которого находятся в соответствии друг с другом и с целым». Часто ли мы задумываемся об удобстве, когда говорим об ИТ? В результате вместо небоскреба нередко получают избушку, правда, в избушке иногда будет уютнее, чем в небоскребе. Поэтому архитектура ИТ зависит не только от требований бизнеса, но и от конкретных пользователей и их представлений об удобстве.
Ландшафт. Архитектура ИТ существует не в безвоздушном пространстве — она должна вписываться в «ландшафт» предприятия. Отсюда можно вывести весьма полезное следствие: при изменении окружающей среды архитектура должна меняться, хотим мы этого или нет. Архитектура ИТ должна находиться в постоянном движении, ведь постоянно появляются новые задачи предприятия, требующие автоматизированного решения, постоянно уходят и приходят клиенты и партнеры и т.п.
Типовое и индивидуальное проектирование. Возможно, это обычное для строительства разделение позволит прекратить извечный спор: использовать готовое или разрабатывать свое? Каждый из подходов, как и в строительстве, имеет свои преимущества и недостатки. Компания должна определить, что ей больше подходит, готовые массовые ИТ или специализированные, созданные под ее задачи решения. Чем она готова поступиться, сроками и стоимостью или уникальностью и неповторимостью. В ИТ вполне жизнеспособна и комбинация этих подходов.
Особенности страны и общества. Архитектура разных стран имеет нечто общее, но обладает и отдельными национальными чертами. Опыт прямого использования западных решений показал, что в ИТ также есть такие особенности. И этого не надо пугаться.
ИТ — область никак не менее сложная, чем строительство зданий, но несоизмеримо более молодая. Преимущество ее молодости состоит в том, что можно использовать накопленные в других областях знания и опыт. Сам термин «архитектура» не случайно прижился в ИТ. Архитектура в классическом градостроительном смысле прошла долгий путь развития, поэтому является глубоко изученной, хорошо оформленной теорией, и ИТ еще далеко не все взяли из нее. Требуется, кажется, одно небольшое усилие, чтобы превратить ИТ в стройную соразмерную структуру. И она должна будет соответствовать всем трем элементам знаменитой триады, сформулированной древнеримским зодчим Витрувием в его трактате «Об архитектуре»: это удобство, надежность, красота.
Марина Аншина (anshina@mail.ru) — директор департамента программного обеспечения компании ISG (Москва).
