Применение архитектурного подхода в информатизации

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

Когда компания занимается информатизацией, она регулярно решает такие группы задач:

• Анализ и проектирование архитектуры
  
• Планирование и реализация
  
• Эксплуатация и развитие
  
  

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

Первым этапом в цикле, безусловно, является анализ и проектирование. Проработка архитектуры при этом может доходить до уровня системной архитектуры для ключевых ИТ-систем.

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

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

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

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

По статистике, треть проектов в ИТ-сфере не приносят ожидаемого эффекта, поэтому задача своевременного мониторинга соответствия системы бизнес-целям становится очень актуальной.

Что представляет собой корпоративная архитектура? Корпоративная архитектура — это симбиоз, согласованная совокупность бизнес-архитектуры, то есть модели хозяйственной деятельности предприятия, и ИТ-архитектуры, то есть набора моделей данных, информационных систем и ИТ-инфраструктуры.

Можно сказать, что корпоративная архитектура — это набор взаимосвязанных моделей. Этот набор позволяет увидеть части архитектуры как кусочки пазла, которые хорошо соединены друг с другом.

Модели деятельности, информационные системы, проекты, бизнес-требования, внедрённые системы — все это объекты, имеющие разный подход к управлению. Архитектура при этом является средством, позволяющим объединить такие объекты путём установления связей между ними. Когда все эти сущности связаны друг с другом, мы можем говорить об архитектуре как о наборе взаимосвязанных моделей. Эти модели позволяют хорошо управлять информатизацией.

В чём заключается сущность архитектурного подхода в информатизации? Архитектурный подход предполагает ни что иное, как взаимосвязанное и согласованное рассмотрение бизнес-архитектуры и ИТ-архитектуры при разработке информационных систем предприятия.

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

Являясь набором моделей и средством для управления информатизацией, архитектура устанавливает общий язык между участниками деятельности в сфере IT. Инвестиции в слаженное взаимодействие дают ценность, которую достаточно легко донести до бизнеса. Безусловно, архитектура позволяет увидеть бизнес со всех ракурсов, демонстрирует недочеты, помогает понять, как их исправлять, какие системы развивать и почему, что делать с ИТ-инфраструктурой, и так далее. Но гораздо убедительнее для бизнеса тезис о том, что с появлением корпоративной архитектуры все участники, имеющие разные точки зрения на уровне целей и задач компании, начнут говорить на одном языке.

Изначально все участники имеют разные точки зрения на бизнес, разные вопросы и приоритеты. Каждый смотрит «со своей колокольни». Акционеры смотрят на компанию с точки зрения целевых показателей. Они ставят показатели и ожидают, что высшее руководство придумает, как этих показателей достичь. Высшее руководство формирует бизнес-стратегию и ставит задачи функциональным направлениям, в том числе и ИТ-блоку. Интерес руководителей функциональных направлений заключается в том, чтобы сделать свои регулярные функции наиболее эффективными. ИТ-блок, в свою очередь, готов внедрять решения. Его задача состоит в том, чтобы «хорошо внедрять и эксплуатировать». Бизнес-партнеров волнует эффективность процессов взаимодействия между компаниями, а контрагенты предлагают внедрить различные продукты и услуги, потому что это в их интересах.

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

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

В соответствии с открытым международным стандартом TOGAF, архитектура — это структурированное поэлементное описание перспективного состояния предприятия, включающее его цели, функции, информацию, информационные системы, информационно-коммуникационную инфраструктуру и связи между элементами.

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

Каждый слой содержит одну или несколько моделей (различные представления сущностей в рассматриваемом слое архитектуры).

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

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

Третий слой архитектуры — это архитектура систем. Системы внедряются ради управления данными. При построении архитектуры необходимо показать, что определённый набор регулярных функций должен поддерживаться определёнными данными. У этих данных есть характеристики, которые нужно принимать в расчёт, когда мы решаем, какими должны быть системы для работы с этими данными.

Системы живут в инфраструктуре, и следовательно четвёртый слой архитектуры — это слой информационно-коммуникационной инфраструктуры.

Залог успеха при проектировании корпоративной архитектуры — выбор правильного архитектурного стиля. Главное здесь — увидеть факторы, показывающие, какие принципы необходимо применять здесь и сейчас. Эти факторы зависят по сути от самой компании.

На рисунке ниже показаны три основных архитектурных стиля с интересной бытовой аналогией.

Если компания находится на стадии развития, экспериментирует, если требуется быстро решать задачи, идеи о создании единой интеграционной среды и применении современных решений могут потерпеть крах, потому что компания к ним просто не готова. В таких условиях необходимо научиться жить со стилем «лоскутное одеяло». Несмотря на то, что такой стиль многие не любят, потому что его использование может приводить к проблемам, многие компании (даже крупные) живут в такой парадигме.

«Слабая» интеграция делает акцент на создание интеграционного комплекса, позволяющего установить взаимодействие между разными, лучшими в своём классе системами.

«Сильная» интеграция предполагает применение ERP-систем и действительно интегрированное информационное пространство.

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

Очень важно уметь распознавать «звоночки», указывающие на необходимость использования того или иного архитектурного стиля. Например, когда регулярно накапливаются проблемы связанные с потерей клиентов, увеличением времени обработки данных, увеличением объёмов деятельности, ухудшением уровня консистентности данных, очевидно, что пора переходить на «сильную» интеграцию — внедрять хорошую систему и делать интегрированную IT-среду.

В противовес этому можно привести ситуацию, когда полностью интегрируемые модули ERP-системы перестают отвечать функциональным требованиям по любым направлениям. Например, у нас сильно усложнился складской модуль и стало понятно, что часть функции стоит выделить в отдельную систему класса WMS, то есть переходить к «слабой» интеграции.

Нельзя не упомянуть, что в настоящее время, под влиянием высокого темпа изменений и смещения акцента с процессов и систем на управление данными, начинает формироваться новый тип архитектуры, который условно можно назвать «Интеграция данных». Тем не менее описание интеграции данных выходит за рамки статьи, поэтому углубляться в эту тему мы не станем.

Ранее мы говорили о том, что верхним и определяющим слоем корпоративной архитектуры является архитектура деятельности.

Бизнес-модель, модель деятельности, процессная модель, альбом бизнес-процессов — все эти понятия по сути являются синонимами понятия «архитектура деятельности».

Для описания деятельности существует очень много подходов. Традиционным является описание процессов, в результате которого формируется альбом бизнес-процессов. Существуют и другие нотации: модель Захмана, модель Портера.

В целях построения корпоративной архитектуры я рекомендую использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. По сути модель показывает, какие значимые процессы и активности регулярно происходят в бизнесе. Эта модель позволяет объединить как внутренние регулярные активности, так и внешние, предоставляемые бизнесу партнёрами.

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

Например, для крупного металлургического комбината такими областями могут быть: разведка, добыча, обогащение, выплавка, изготовление изделий, управление оборудованием и бэк-офис, т. е. управление бизнеса (финансы, кадры, юристы и т. д.).

Бизнес-компонент представляет потенциально самостоятельную часть организации, которая в принципе может быть частью другой компании. Компонент имеет определённую бизнес-ценность, использует ресурсы, информацию и приложения.

Как построить компонентную модель?

Проще всего оттолкнуться от организационной структуры и идентифицировать в ней ключевые подразделения, дополнительно выделив внешние структуры, которые интегрированы с нашим бизнесом. У этих ключевых подразделений необходимо сначала определить основные функции, а затем объединить смежные или сопутствующие друг другу функции в укрупнённые группы.

Полученные группы являются функциональными компонентами. В качестве примера можно привести такой функциональный компонент как «Договорная деятельность». Это компонент, так как в него хорошо встраиваются такие функции как подготовка договоров, заключение договоров, контроль исполнения договоров и т. д.

Важно помнить, что каждый компонент должен быть уникален и по отношению друг к другу компоненты должны обладать примерно одинаковым весом. Основываясь на практике, можно сказать, что компонентная модель крупного предприятия будет состоять из 50−80 компонентов, которые будут распределяться по 5−8 областям деятельности.

Такая модель является представлением деятельности AS-IS. При этом, учитывая, что компания предполагает развитие и оптимизацию, необходимо также сформировать и целевую модель деятельности.

Хорошим инструментом для формирования целевой модели деятельности является матрица Игоря Ансоффа (матрица товар-рынок).

Матрица задает возможные сегменты, в который нужно попытаться найти сценарии развития бизнеса. Ансофф предлагает рассматривать все возможные направления развития в контексте клиентов и продуктов/услуг.

Использование этого инструмента позволяет построить карту сценариев развития бизнеса. Полученные сценарии можно представить в виде набора требований к функциям модели деятельности.

Чтобы трансформировать модель AS-IS в целевую модель TO-BE, необходимо трансформировать или дополнить функциями компоненты исходной модели таким образом, чтобы это позволяло реализовать выбранный сценарий развития.

Подводя итоги второй части нашего цикла статей, можно выделить следующие тезисы.

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

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

3. В основе архитектуры предприятия согласно стандарту TOGAF лежит архитектура деятельности. Для её построения лучше всего использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. Модель показывает, какие значимые процессы и активности, как внутренние, так и предоставляемые партнёрами, регулярно происходят в бизнесе.

4. Для построения компонентной модели проще всего обратиться к организационной структуре предприятия, выделив в качестве компонент основные функции подразделений. Полученная таким образом модель является моделью AS-IS. Для построения целевой модели можно применить такой инструмент, как матрица Игоря Ансоффа, и описать релевантные бизнес-модели, для реализации которых компании потребуется развернуть дополнительные функции — эти функции должны быть добавлены в компонентную модель компании, что сделает её «целевой» моделью.

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