Практика документирования архитектуры

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

Давайте посмотрим на пример из достаточно "продвинутой" в плане использования ИТ финансовой индустрии. Как известно, деятельность финансовых организаций в настоящее время чрезвычайно сильно зависит от использования ИТ, так что инвестиции в ИТ в этой сфере уступают только телекоммуникационной отрасли. Поэтому достаточно интересным представляется изучение опыта разработки корпоративной архитектуры среди ведущих банков. Такое исследование было проведено Gartner в 2003 году среди банков США и финансовых компаний [2.45].

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

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

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

Архитектура предприятия: основные определения

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

Конфуций

В этой лекции мы обсудим наиболее общие характеристики таких понятий, как " Архитектура информационных технологий" и " Архитектура предприятия".

Прежде чем подойти к описанию того, что такое архитектура ИТ, проще отметить, что ею не является. В частности, архитектурой не является более или менее утвержденный список поставщиков и их продуктов типа "Мы используем серверную ОС MS Windows 2003, СУБД MS SQL, все остальное ПО тоже от Microsoft, серверы на платформе Intel и телекоммуникационное оборудование Cisco". Создание стандартного списка поставщиков и уменьшение их количества – это только частичное решение проблемы "кусочной" информатизации. По мнению Gartner, подход к формулировке архитектуры должен основываться на анализе общекорпоративных процессов и переоценке своих бизнес-процессов и поддерживающих их приложений.

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

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

С другой стороны, представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название "системное мышление ". Основным объектом изучения этой дисциплины является система, когда "целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов" [3.1]. Эберхард Речтин (Eberhardt Rechtin), чья цитата была только что приведена, является одним из основателей этого направления мышления.

Еще одно важное замечание состоит в уточнении понятия "Предприятие". Что мы имеем в виду, когда говорим о предприятии в контексте архитектуры? На самом деле, этот термин большинство специалистов по архитектуре и соответствующие методики описания архитектуры трактуют достаточно гибко. Это может быть организация в целом или одно из ее бизнес-подразделений, или же это может быть некоторая совокупность предприятий или организационных единиц в рамках единой цепочки создания добавочной стоимости. Таким образом, под термином "Предприятие" мы здесь и далее имеем в виду формальное объединение, не обязательно связанное с коммерческой деятельностью. Это может быть и государственная организация, и общественное, в том числе неформальное, объединение участников, связанных общей целью. Согласно более общему определению, приведенному в [3.2], Предприятие "... представляет собой комплексную систему культурных, технологических и процессных компонент, организованных для достижения целей организации".

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

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

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие.

Дата добавления: 2015-04-25